Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Getters & Setters argument
149 views
Skip to first unread message
JiiPee
Mar 4, 2015, 8:46:50 AM3/4/15
to
Two people, Peter and John, arguing. Any comments; which one of them is
right and why? Who won the argument?:
Peter: I created a nice struct (kind of class) for my coordinates:
struct Coordinate
{
int x;
int y;
};
John: well, not so nice.... they teach that you should put member
variables to private section
and create Get and Set functions to get and set their values... Thats
what they teach in schools
and all the books seems to say that as well. You did not know that??
Peter: Yes most of the time, but lets look at this code:
...
int main()
{
int age = 35;
std::cout<<"My age is "<<age;
}
Should age be inside a class and should we have a Get to get access to
it, just like we did with coordinate? Like this:
class Integer
{
public:
int Set(int val) { _value = val; }
int Get() { return _value; }
private:
int _value;
};
So the code should be (according to you Peter):
...
int main()
{
Integer age;
age.Set(35);
std::cout<<"My age is "<<age.Get();
}
Right???
John: Do you think I am stupid???? or course not!!! Why an earth would
you hide integer inside a class like that?
Peter: But what fundamental difference is there with age and coordinate
variables? Why the other one should be hidden
as a private and the other one not?? Tell me....
right and why? Who won the argument?:
Peter: I created a nice struct (kind of class) for my coordinates:
struct Coordinate
{
int x;
int y;
};
John: well, not so nice.... they teach that you should put member
variables to private section
and create Get and Set functions to get and set their values... Thats
what they teach in schools
and all the books seems to say that as well. You did not know that??
Peter: Yes most of the time, but lets look at this code:
...
int main()
{
int age = 35;
std::cout<<"My age is "<<age;
}
Should age be inside a class and should we have a Get to get access to
it, just like we did with coordinate? Like this:
class Integer
{
public:
int Set(int val) { _value = val; }
int Get() { return _value; }
private:
int _value;
};
So the code should be (according to you Peter):
...
int main()
{
Integer age;
age.Set(35);
std::cout<<"My age is "<<age.Get();
}
Right???
John: Do you think I am stupid???? or course not!!! Why an earth would
you hide integer inside a class like that?
Peter: But what fundamental difference is there with age and coordinate
variables? Why the other one should be hidden
as a private and the other one not?? Tell me....
Message has been deleted
JiiPee
Mar 4, 2015, 9:02:07 AM3/4/15
to
sorry, there is a mistake; should be:
struct Point
{
int x;
int y;
};
instead of:
So the original example using Point instead of Coordinate
struct Point
{
int x;
int y;
};
instead of:
struct Coordinate
{
int x;
int y;
};
like Stefan pointed out.
{
int x;
int y;
};
So the original example using Point instead of Coordinate
JiiPee
Mar 4, 2015, 9:02:37 AM3/4/15
to
On 04/03/2015 13:54, Stefan Ram wrote:
>> int y;
> It depends on the definition of the meaning of the entity (the contract).
>
> »struct Coordinate« is kind of semantic mismatch, because each one
> (x and y) is called »a coordinate« (singular). So, together, they
> /are not a coordinate/ (they might be »coordinates« in the plural).
>
> This mismatch shows that the author is not clear in what he wants
> to model. To improve, first write the contract of the struct, then
> think about how to implement it.
>
> Sometimes records of public fields are ok, but it depends on the
> meaning (contract).
>
Yes, should be "Point" instead. I mention it now there
> JiiPee <n...@notvalid.com> writes:
>> Peter: I created a nice struct (kind of class) for my coordinates:
>> int x;
>> Peter: I created a nice struct (kind of class) for my coordinates:
>> int y;
> It depends on the definition of the meaning of the entity (the contract).
>
> »struct Coordinate« is kind of semantic mismatch, because each one
> (x and y) is called »a coordinate« (singular). So, together, they
> /are not a coordinate/ (they might be »coordinates« in the plural).
>
> This mismatch shows that the author is not clear in what he wants
> to model. To improve, first write the contract of the struct, then
> think about how to implement it.
>
> Sometimes records of public fields are ok, but it depends on the
> meaning (contract).
>
Yes, should be "Point" instead. I mention it now there
Jens Thoms Toerring
Mar 4, 2015, 10:07:55 AM3/4/15
to
JiiPee <n...@notvalid.com> wrote:
> sorry, there is a mistake; should be:
> struct Point
> {
> int x;
> int y;
> };
> instead of:
> struct Coordinate
> {
> int x;
> int y;
> };
> like Stefan pointed out.
> So the original example using Point instead of Coordinate
What about th other question Stefan asked? What's the purpose
> sorry, there is a mistake; should be:
> struct Point
> {
> int x;
> int y;
> };
> instead of:
> struct Coordinate
> {
> int x;
> int y;
> };
> like Stefan pointed out.
> So the original example using Point instead of Coordinate
of this 'Point' structure? If this is to be always used for
points with arbitrary coordinates then this will do nicely as
it is. On the oter hand, if this is (or might be at some later
time) used for points with certain restraints (e.g. only points
in a certain quadrant are allowed), or this class is meant as
the base class for something like that, then you need a setter
in order to be able to control that coordinates only can be
modified so that the extra condition is still satisfied. And
once you've a setter you also need a getter, of course.
And in your 'age' example the same principle applies. To start
with it might have been preferable to use an unsigned int instead
of an int, since an age normally can't be negative. And if there
are extra conditions to that age (e.g. it's the age of a person)
a range check might be useful in some circumstannces since there
is no known person who's 1000 year old, which then would re-
quire to create an 'Age' class with a setter and a getter.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
JiiPee
Mar 4, 2015, 10:30:19 AM3/4/15
to
On 04/03/2015 15:07, Jens Thoms Toerring wrote:
> JiiPee <n...@notvalid.com> wrote:
>> sorry, there is a mistake; should be:
>> struct Point
>> {
>> int x;
>> int y;
>> };
>> instead of:
>> struct Coordinate
>> {
>> int x;
>> int y;
>> };
>> like Stefan pointed out.
>> So the original example using Point instead of Coordinate
> What about th other question Stefan asked? What's the purpose
> of this 'Point' structure? If this is to be always used for
> points with arbitrary coordinates then this will do nicely as
> it is. On the oter hand, if this is (or might be at some later
> time) used for points with certain restraints (e.g. only points
> in a certain quadrant are allowed), or this class is meant as
> the base class for something like that, then you need a setter
> in order to be able to control that coordinates only can be
> modified so that the extra condition is still satisfied. And
> once you've a setter you also need a getter, of course.
It is meant to be a simple point structure with only few functions, like
> JiiPee <n...@notvalid.com> wrote:
>> sorry, there is a mistake; should be:
>> struct Point
>> {
>> int x;
>> int y;
>> };
>> instead of:
>> struct Coordinate
>> {
>> int x;
>> int y;
>> };
>> like Stefan pointed out.
>> So the original example using Point instead of Coordinate
> What about th other question Stefan asked? What's the purpose
> of this 'Point' structure? If this is to be always used for
> points with arbitrary coordinates then this will do nicely as
> it is. On the oter hand, if this is (or might be at some later
> time) used for points with certain restraints (e.g. only points
> in a certain quadrant are allowed), or this class is meant as
> the base class for something like that, then you need a setter
> in order to be able to control that coordinates only can be
> modified so that the extra condition is still satisfied. And
> once you've a setter you also need a getter, of course.
Move, Increase etc. No plan for use it as a base class.
Or possible even so that no functions there, only datamemebers x and y.
Used like in most of the graphical systems, like VC++ Point, SFML Point
... a graphical point.
The point being that why Point needs to have getters but Integer not
(because Integer is type int)? Why dont we also hide ingeters and floats
inside a class then?
>
> And in your 'age' example the same principle applies. To start
> with it might have been preferable to use an unsigned int instead
> of an int, since an age normally can't be negative.
Integer a, b;
a.Set(1);
JiiPee
Mar 4, 2015, 10:40:26 AM3/4/15
to
> What about th other question Stefan asked? What's the purpose of this
> 'Point' structure? If this is to be always used for points with
> arbitrary coordinates then this will do nicely as it is. On the oter
> hand, if this is (or might be at some later time) used for points with
> certain restraints (e.g. only points in a certain quadrant are
> allowed), or this class is meant as the base class for something like
> that, then you need a setter in order to be able to control that
> coordinates only can be modified so that the extra condition is still
> satisfied. And once you've a setter you also need a getter, of course.
The fact that x and y are bundled inside a struct does not mean we must
> 'Point' structure? If this is to be always used for points with
> arbitrary coordinates then this will do nicely as it is. On the oter
> hand, if this is (or might be at some later time) used for points with
> certain restraints (e.g. only points in a certain quadrant are
> allowed), or this class is meant as the base class for something like
> that, then you need a setter in order to be able to control that
> coordinates only can be modified so that the extra condition is still
> satisfied. And once you've a setter you also need a getter, of course.
add there functions as well, isnt it? Adding functions are optional/extras.
One might say "But if you do not make the getters and setters now, it
will be difficult later on to change it". But the other one could argue
the same with all int, float, double etc primitive values/types!! For
example:
int age;
Now, one could argue that somewhere in the future we might want an
"intelligence age type". So putting age not into a class as a private
might cause that later on its very difficult to change it like that if
we start now with only:
int age;
right?? hmmmm.... But if it was like this, then why most of the
programmers most of the time do use ints, floats, doubles etc? :)
Point being, that if one says that in a struct /class variables must be
private, then using the same logic ALL the variable should be embedded
inside a class as a private members and then call them from there, like
for float:
class Float
{
float get() { return f; }
private:
float f;
};
Christopher Pisz
Mar 4, 2015, 11:32:22 AM3/4/15
to
Your Point class as is, is a POD. It doesn't do anything in any method
to the data.
Once my class has some functionality of some kind in it, then I no
longer allow data to be public.
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Christopher Pisz
Mar 4, 2015, 11:39:14 AM3/4/15
to
On 3/4/2015 9:40 AM, JiiPee wrote:
> On 04/03/2015 15:07, Jens Thoms Toerring wrote:
>> JiiPee <n...@notvalid.com> wrote:
>> What about th other question Stefan asked? What's the purpose of this
>> 'Point' structure? If this is to be always used for points with
>> arbitrary coordinates then this will do nicely as it is. On the oter
>> hand, if this is (or might be at some later time) used for points with
>> certain restraints (e.g. only points in a certain quadrant are
>> allowed), or this class is meant as the base class for something like
>> that, then you need a setter in order to be able to control that
>> coordinates only can be modified so that the extra condition is still
>> satisfied. And once you've a setter you also need a getter, of course.
>
> The fact that x and y are bundled inside a struct does not mean we must
> add there functions as well, isnt it? Adding functions are optional/extras.
>
> One might say "But if you do not make the getters and setters now, it
> will be difficult later on to change it". But the other one could argue
> the same with all int, float, double etc primitive values/types!! For
> example:
One needs to look for the find/replace feature in their IDE...
> On 04/03/2015 15:07, Jens Thoms Toerring wrote:
>> JiiPee <n...@notvalid.com> wrote:
>> What about th other question Stefan asked? What's the purpose of this
>> 'Point' structure? If this is to be always used for points with
>> arbitrary coordinates then this will do nicely as it is. On the oter
>> hand, if this is (or might be at some later time) used for points with
>> certain restraints (e.g. only points in a certain quadrant are
>> allowed), or this class is meant as the base class for something like
>> that, then you need a setter in order to be able to control that
>> coordinates only can be modified so that the extra condition is still
>> satisfied. And once you've a setter you also need a getter, of course.
>
> The fact that x and y are bundled inside a struct does not mean we must
> add there functions as well, isnt it? Adding functions are optional/extras.
>
> One might say "But if you do not make the getters and setters now, it
> will be difficult later on to change it". But the other one could argue
> the same with all int, float, double etc primitive values/types!! For
> example:
> int age;
>
> Now, one could argue that somewhere in the future we might want an
> "intelligence age type". So putting age not into a class as a private
> might cause that later on its very difficult to change it like that if
> we start now with only:
>
> int age;
Either it is or isn't, before coding begins. If one fails to design
first, then, again, he can make use of find/replace.
But no, if I saw:
class
{
int m_age;
public:
const int GetAge() const;
void SetAge(int age);
};
there would be comments in my code review for sure.
> right?? hmmmm.... But if it was like this, then why most of the
> programmers most of the time do use ints, floats, doubles etc? :)
>
> Point being, that if one says that in a struct /class variables must be
> private, then using the same logic ALL the variable should be embedded
> inside a class as a private members and then call them from there, like
> for float:
>
> class Float
> {
> float get() { return f; }
> private:
> float f;
> };
JiiPee
Mar 4, 2015, 11:41:06 AM3/4/15
to
functions but they keep x and y public. I made my own Point class as
well and desided to put them public Point being that its very simple
class and its easier to call
obj.x
than obj.x();
because x is called so often. Sutter argue though that you do not lose
anything by making it a function rather than its a bit longer. He is
right, but yes.... its a bit longer call and writing, for me enough to
make it public :). Donno about future but with point i still prefer public.
JiiPee
Mar 4, 2015, 11:47:00 AM3/4/15
to
On 04/03/2015 16:39, Christopher Pisz wrote:
> On 3/4/2015 9:40 AM, JiiPee wrote:
>> On 04/03/2015 15:07, Jens Thoms Toerring wrote:
>>> JiiPee <n...@notvalid.com> wrote:
>>> What about th other question Stefan asked? What's the purpose of this
>>> 'Point' structure? If this is to be always used for points with
>>> arbitrary coordinates then this will do nicely as it is. On the oter
>>> hand, if this is (or might be at some later time) used for points with
>>> certain restraints (e.g. only points in a certain quadrant are
>>> allowed), or this class is meant as the base class for something like
>>> that, then you need a setter in order to be able to control that
>>> coordinates only can be modified so that the extra condition is still
>>> satisfied. And once you've a setter you also need a getter, of course.
>>
>> The fact that x and y are bundled inside a struct does not mean we must
>> add there functions as well, isnt it? Adding functions are
>> optional/extras.
>>
>> One might say "But if you do not make the getters and setters now, it
>> will be difficult later on to change it". But the other one could argue
>> the same with all int, float, double etc primitive values/types!! For
>> example:
>
> One needs to look for the find/replace feature in their IDE...
But this argument ("difficult to change it later") I think is used even
> On 3/4/2015 9:40 AM, JiiPee wrote:
>> On 04/03/2015 15:07, Jens Thoms Toerring wrote:
>>> JiiPee <n...@notvalid.com> wrote:
>>> What about th other question Stefan asked? What's the purpose of this
>>> 'Point' structure? If this is to be always used for points with
>>> arbitrary coordinates then this will do nicely as it is. On the oter
>>> hand, if this is (or might be at some later time) used for points with
>>> certain restraints (e.g. only points in a certain quadrant are
>>> allowed), or this class is meant as the base class for something like
>>> that, then you need a setter in order to be able to control that
>>> coordinates only can be modified so that the extra condition is still
>>> satisfied. And once you've a setter you also need a getter, of course.
>>
>> The fact that x and y are bundled inside a struct does not mean we must
>> add there functions as well, isnt it? Adding functions are
>> optional/extras.
>>
>> One might say "But if you do not make the getters and setters now, it
>> will be difficult later on to change it". But the other one could argue
>> the same with all int, float, double etc primitive values/types!! For
>> example:
>
> One needs to look for the find/replace feature in their IDE...
among top C++ people, I think even Bjarne uses it.
>
>> int age;
>>
>> Now, one could argue that somewhere in the future we might want an
>> "intelligence age type". So putting age not into a class as a private
>> might cause that later on its very difficult to change it like that if
>> we start now with only:
>>
>> int age;
>
> One needs to work out his design before implementing.
> There is no might. Either it is or isn't, before coding begins. If one
> fails to design first, then, again, he can make use of find/replace.
>
> But no, if I saw:
>
> class
> {
> int m_age;
>
> public:
>
> const int GetAge() const;
> void SetAge(int age);
> };
>
> there would be comments in my code review for sure.
Christopher Pisz
Mar 4, 2015, 11:51:15 AM3/4/15
to
On 3/4/2015 10:40 AM, JiiPee wrote:
> On 04/03/2015 16:32, Christopher Pisz wrote:
>> On 3/4/2015 7:46 AM, JiiPee wrote:
>>>
>>> John: Do you think I am stupid???? or course not!!! Why an earth would
>>> you hide integer inside a class like that?
>>>
>>> Peter: But what fundamental difference is there with age and coordinate
>>> variables? Why the other one should be hidden
>>> as a private and the other one not?? Tell me....
>>
>> If I am designing a POD, then I don't mind making member data public.
>> Your Point class as is, is a POD. It doesn't do anything in any method
>> to the data.
>>
>> Once my class has some functionality of some kind in it, then I no
>> longer allow data to be public.
>>
>>
>
> Almost all Point classes I have studied in graphics they have many
> functions but they keep x and y public. I made my own Point class as
> well and desided to put them public Point being that its very simple
> class and its easier to call
True, but are they still PODs? Probably.
> On 04/03/2015 16:32, Christopher Pisz wrote:
>> On 3/4/2015 7:46 AM, JiiPee wrote:
>>>
>>> John: Do you think I am stupid???? or course not!!! Why an earth would
>>> you hide integer inside a class like that?
>>>
>>> Peter: But what fundamental difference is there with age and coordinate
>>> variables? Why the other one should be hidden
>>> as a private and the other one not?? Tell me....
>>
>> If I am designing a POD, then I don't mind making member data public.
>> Your Point class as is, is a POD. It doesn't do anything in any method
>> to the data.
>>
>> Once my class has some functionality of some kind in it, then I no
>> longer allow data to be public.
>>
>>
>
> Almost all Point classes I have studied in graphics they have many
> functions but they keep x and y public. I made my own Point class as
> well and desided to put them public Point being that its very simple
> class and its easier to call
If you were to make a Get and Set method would anything every go inside
them aside from return m_x; or m_x = arg? Probably not.
The concept is probably one of those things that come down to opinion
and have to be hashed out in coding standards for wherever you work.
Mine is if(POD) then public, else protected or private
>
> obj.x
>
> than obj.x();
>
> because x is called so often. Sutter argue though that you do not lose
> anything by making it a function rather than its a bit longer. He is
> right, but yes.... its a bit longer call and writing, for me enough to
> make it public :). Donno about future but with point i still prefer public.
>
Christopher Pisz
Mar 4, 2015, 11:56:45 AM3/4/15
to
foresee, otherwise we'd be writing for eons.
I've really never had any trouble, even in huge projects doing a find
".m_age" replace ".GetAge()" if needed later.
Again, my opinion.
>> There is no might. Either it is or isn't, before coding begins. If one
>> fails to design first, then, again, he can make use of find/replace.
>>
>> But no, if I saw:
>>
>> class
>> {
>> int m_age;
>>
>> public:
>>
>> const int GetAge() const;
>> void SetAge(int age);
>> };
>>
>> there would be comments in my code review for sure.
>
> Class name is missing?
>
Mr Flibble
Mar 4, 2015, 12:40:01 PM3/4/15
to
On 04/03/2015 13:46, JiiPee wrote:
seems I have to repeat myself.
Member variables need only be private if they contribute to the class
invariant. The coordinates/point class in the OP as it stands has no
class invariant so making the member variables public is perfectly fine.
/Flibble
Geoff
Mar 4, 2015, 12:55:42 PM3/4/15
to
On Wed, 04 Mar 2015 13:46:38 +0000, JiiPee <n...@notvalid.com> wrote:
[snip]
At what point does an object become complex enough to deserve being a
class?
Answer: it depends on the abstraction of the object and the design
goals for that object.
In the case of an integer or any of the intrinsic types, they are
probably not complex enough to deserve a class or the usage of the
object would be more cumbersome as a class that it is as a naked
object. One wouldn't write a class for unsigned int age but one would
write a class for object Student, possessing attributes, age, grade,
sex, GPA, ID_Number, etc.
It's a design choice that is dictated by the scope of the program and
it's goals.
[snip]
>
>Peter: But what fundamental difference is there with age and coordinate
>variables? Why the other one should be hidden
>as a private and the other one not?? Tell me....
The question you seem to be asking, in a long and tortuous way, is:
>Peter: But what fundamental difference is there with age and coordinate
>variables? Why the other one should be hidden
>as a private and the other one not?? Tell me....
At what point does an object become complex enough to deserve being a
class?
Answer: it depends on the abstraction of the object and the design
goals for that object.
In the case of an integer or any of the intrinsic types, they are
probably not complex enough to deserve a class or the usage of the
object would be more cumbersome as a class that it is as a naked
object. One wouldn't write a class for unsigned int age but one would
write a class for object Student, possessing attributes, age, grade,
sex, GPA, ID_Number, etc.
It's a design choice that is dictated by the scope of the program and
it's goals.
JiiPee
Mar 4, 2015, 12:56:11 PM3/4/15
to
structure it is. With point public, but maybe with person details
private and getters & setters there. Thats how I might do it. My
argument is the one mentioned here, that if:
int main()
{
int a=6;
..
}
a there is not private class member, then its kind of same as if x and y
in Point are not privates. they are kind of similar data types.
JiiPee
Mar 4, 2015, 12:59:11 PM3/4/15
to
On 04/03/2015 17:55, Geoff wrote:
> On Wed, 04 Mar 2015 13:46:38 +0000, JiiPee <n...@notvalid.com> wrote:
>
> [snip]
>> Peter: But what fundamental difference is there with age and coordinate
>> variables? Why the other one should be hidden
>> as a private and the other one not?? Tell me....
> The question you seem to be asking, in a long and tortuous way, is:
> At what point does an object become complex enough to deserve being a
> class?
oh yes, you got it! :) people seem to be intelligence here...:)
> On Wed, 04 Mar 2015 13:46:38 +0000, JiiPee <n...@notvalid.com> wrote:
>
> [snip]
>> Peter: But what fundamental difference is there with age and coordinate
>> variables? Why the other one should be hidden
>> as a private and the other one not?? Tell me....
> The question you seem to be asking, in a long and tortuous way, is:
> At what point does an object become complex enough to deserve being a
> class?
>
> Answer: it depends on the abstraction of the object and the design
> goals for that object.
>
> In the case of an integer or any of the intrinsic types, they are
> probably not complex enough to deserve a class or the usage of the
> object would be more cumbersome as a class that it is as a naked
> object. One wouldn't write a class for unsigned int age but one would
> write a class for object Student, possessing attributes, age, grade,
> sex, GPA, ID_Number, etc.
this makes sense , sure. and thats how I also do these.
But am a bit against people who say "ALWAYS" put all data private in
classes.
Bo Persson
Mar 4, 2015, 1:05:55 PM3/4/15
to
On 2015-03-04 16:07, Jens Thoms Toerring wrote:
>
> And in your 'age' example the same principle applies. To start
> with it might have been preferable to use an unsigned int instead
> of an int, since an age normally can't be negative. And if there
> are extra conditions to that age (e.g. it's the age of a person)
> a range check might be useful in some circumstannces since there
> is no known person who's 1000 year old, which then would re-
> quire to create an 'Age' class with a setter and a getter.
>
The 'Age' is also a bad example, because you don't arbitrarily change
>
> And in your 'age' example the same principle applies. To start
> with it might have been preferable to use an unsigned int instead
> of an int, since an age normally can't be negative. And if there
> are extra conditions to that age (e.g. it's the age of a person)
> a range check might be useful in some circumstannces since there
> is no known person who's 1000 year old, which then would re-
> quire to create an 'Age' class with a setter and a getter.
>
the age of a person.
There might be a celebrate_birthday() function that adds 1 to the age,
but it's hard to see the need to set_age(19) for a guy that is 42.
This just shows that there is no general solution, it all depends on
what you want to model.
Bo Persson
Öö Tiib
Mar 4, 2015, 3:21:39 PM3/4/15
to
On Wednesday, 4 March 2015 15:46:50 UTC+2, JiiPee wrote:
>
> Peter: Yes most of the time, but lets look at this code:
> ...
> int main()
> {
> int age = 35;
> std::cout<<"My age is "<<age;
> }
> Should age be inside a class and should we have a Get to get access to
> it, just like we did with coordinate? Like this:
>
> class Integer
> {
> public:
> int Set(int val) { _value = val; }
> int Get() { return _value; }
> private:
> int _value;
> };
> So the code should be (according to you Peter):
> ...
> int main()
> {
> Integer age;
> age.Set(35);
> std::cout<<"My age is "<<age.Get();
> }
>
> Right???
No, where is written that human age is integer? Integer without
>
> Peter: Yes most of the time, but lets look at this code:
> ...
> int main()
> {
> int age = 35;
> std::cout<<"My age is "<<age;
> }
> Should age be inside a class and should we have a Get to get access to
> it, just like we did with coordinate? Like this:
>
> class Integer
> {
> public:
> int Set(int val) { _value = val; }
> int Get() { return _value; }
> private:
> int _value;
> };
> So the code should be (according to you Peter):
> ...
> int main()
> {
> Integer age;
> age.Set(35);
> std::cout<<"My age is "<<age.Get();
> }
>
> Right???
unit, accuracy and limits?
To my knowledge it is time interval from moment of birth until
now. Birth is such an messy event that it is hardly ever fixed
with better accuracy than minute. Also that particular time
interval can not be negative, because we can not predict when
someone will born in the future. Longest documented human age is
122 years and 164 days. Oldest fictional human Methuselah lived
969 years. So there are clearly limits too.
IOW Peter's example clearly shows that numeric data is too complex
for him. That does not pass any reviews and so he should go back
practicing to output ASCII texts ... "Hello World!" and from there
perhaps Visual Basic, PHP ... no way C++. ;)
JiiPee
Mar 4, 2015, 4:26:00 PM3/4/15
to
>
Paul N
Mar 4, 2015, 5:42:51 PM3/4/15
to
On Wednesday, 4 March 2015 13:46:50 UTC, JiiPee wrote:
> Two people, Peter and John, arguing. Any comments; which one of them is
> right and why? Who won the argument?:
>
> Peter: I created a nice struct (kind of class) for my coordinates:
>
> struct Coordinate
> {
> int x;
> int y;
> };
>
> John: well, not so nice.... they teach that you should put member
> variables to private section
> and create Get and Set functions to get and set their values... Thats
> what they teach in schools
> and all the books seems to say that as well. You did not know that??
The point (no pun intended) here is that it doesn't matter if you change the value of one of the coordinates. You just get a different point. Getters and setters are for when a class needs to manage its own data, without other people messing about with it. Or, as Flibble pointed out, where there is a "class invariant".
> Two people, Peter and John, arguing. Any comments; which one of them is
> right and why? Who won the argument?:
>
> Peter: I created a nice struct (kind of class) for my coordinates:
>
> struct Coordinate
> {
> int x;
> int y;
> };
>
> John: well, not so nice.... they teach that you should put member
> variables to private section
> and create Get and Set functions to get and set their values... Thats
> what they teach in schools
> and all the books seems to say that as well. You did not know that??
> Peter: Yes most of the time, but lets look at this code:
> ...
> int main()
> {
> int age = 35;
> std::cout<<"My age is "<<age;
> }
> Should age be inside a class and should we have a Get to get access to
> it, just like we did with coordinate? Like this:
Öö Tiib
Mar 5, 2015, 2:43:50 AM3/5/15
to
JiiPee
Mar 5, 2015, 3:00:16 AM3/5/15
to
bit PHP, its simple to learn and easy to use, I like that with internet
programming. Good tool for that purpose, although some complain its not
so safe but donno.
Fred.Zwarts
Mar 5, 2015, 3:33:15 AM3/5/15
to
"Geoff" schreef in bericht
news:g6hefa98cd8bboqe4...@4ax.com...
I think it is not only the complexity, but indeed also the scope/locality of
an object.
If you need an age for only four of five lines of code for a few operation
and then discard it, it can be modeled with an int, but if an object
representing an age is used everywhere in a big program and passed to many
different functions (maybe written by other authors) then it may be wise to
restrict is usage (like its range) and put it in an more complex class.
The same considerations as for variables in a function are valid for members
of a class. An age within a class can sometimes be modeled with an int, but
often one needs a subclass.
news:g6hefa98cd8bboqe4...@4ax.com...
an object.
If you need an age for only four of five lines of code for a few operation
and then discard it, it can be modeled with an int, but if an object
representing an age is used everywhere in a big program and passed to many
different functions (maybe written by other authors) then it may be wise to
restrict is usage (like its range) and put it in an more complex class.
The same considerations as for variables in a function are valid for members
of a class. An age within a class can sometimes be modeled with an int, but
often one needs a subclass.
Juha Nieminen
Mar 5, 2015, 4:29:52 AM3/5/15
to
JiiPee <n...@notvalid.com> wrote:
> int main()
> {
> int age = 35;
> std::cout<<"My age is "<<age;
> }
I'd say that unless this is a small throw-away program, the best way is:
> int main()
> {
> int age = 35;
> std::cout<<"My age is "<<age;
> }
typedef int Age_t; // this somewhere, usually some header file
...
Age_t age = 35;
// etc
This way Age_t can be easily changed into a class if needed. (Thanks to
operator overloading, the usage syntax doesn't need to take the
possibility into account.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
JiiPee
Mar 5, 2015, 4:33:17 AM3/5/15
to
like that :)
I meant, any integer, like:
int b;
b = 55;
age was not the point here.
JiiPee
Mar 5, 2015, 4:35:22 AM3/5/15
to
On 05/03/2015 09:29, Juha Nieminen wrote:
class or just an int, can be changed later.
David Brown
Mar 5, 2015, 6:34:24 AM3/5/15
to
invariant beyond its data type (such as limited range, or a specified
relationship with other data), then it needs to be private. If not,
then it doesn't /need/ to be private, but you might want to anyway (for
example, to limit access).
There is no need to use a getter function just in case you need it later
- it should not be hard to change from direct member access to getters
and setters, unless you try hard to write risky changes (such as making
a getter have the same name as the original public member).
JiiPee
Mar 5, 2015, 8:49:23 AM3/5/15
to
getters-functionality (as I think it is with Point-class) then no need
for getters... and can always then change later if needs, which is very
unlikely though.
Message has been deleted
woodb...@gmail.com
Mar 5, 2015, 2:44:32 PM3/5/15
to
care of themselves and others.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Öö Tiib
Mar 5, 2015, 2:59:05 PM3/5/15
to
that I can read I know code of very different quality. Not so in PHP.
In PHP I have seen only bad or very bad quality code. So it must be
it is typically written by likes of Peter of yours. ;)
Öö Tiib
Mar 5, 2015, 3:55:07 PM3/5/15
to
"any integers". Numeric data in actual programs usually consists of
meaningful quantities that are interrelated in problem domain of
the program.
Lets say you got exceptional case where your problem domain is
actually dealing with 'int'. Say it really asks for two 'int's
and just adds those together. It is still not an obvious task:
#include <climits>
#include <iostream>
int main()
{
std::cout << "enter first int:";
int first;
std::cin >> first;
std::cout << "first int is " << first << "\n";
std::cout << "enter second int:";
int second;
std::cin >> second;
std::cout << "second int is " << second << "\n";
std::cout << "sum of first and second int is ";
// you think first + second ???
// WRONG !!!
if ((first > 0) && (second > INT_MAX - first))
std::cout << "overflow" << std::endl;
else if ((first < 0) && (second < INT_MIN - first))
std::cout << "underflow" << std::endl;
else
std::cout << first + second << std::endl;
}
So if you need to add up the 'int's in more than in one location
of your program or even need to do other arithmetic operations
with 'int's too then you start soon to see why you better make a
class around that 'int' to whose members to put that logic of
operating with 'int's.
Or if you don't do it but simply write 'first + second' then it
is PHP ... plain mess of ugly security vulnerabilities.
Scott Lurndal
Mar 5, 2015, 5:01:01 PM3/5/15
to
woodb...@gmail.com writes:
>> 969 years.=20
>
>Oldest human was Methuselah. They knew how to take=20
for more than 3 score and 10.
All myths.
>On Wednesday, March 4, 2015 at 2:21:39 PM UTC-6, =D6=F6 Tiib wrote:
>> On Wednesday, 4 March 2015 15:46:50 UTC+2, JiiPee wrote:
>> To my knowledge it is time interval from moment of birth until
>> now. Birth is such an messy event that it is hardly ever fixed
>> with better accuracy than minute. Also that particular time=20
>> On Wednesday, 4 March 2015 15:46:50 UTC+2, JiiPee wrote:
>> To my knowledge it is time interval from moment of birth until
>> now. Birth is such an messy event that it is hardly ever fixed
>> interval can not be negative, because we can not predict when
>> someone will born in the future. Longest documented human age is
>> 122 years and 164 days. Oldest fictional human Methuselah lived=20
>> someone will born in the future. Longest documented human age is
>> 969 years.=20
>
>Oldest human was Methuselah. They knew how to take=20
>care of themselves and others.
>
There was no such person. Nor did the patriarchs live
>
for more than 3 score and 10.
All myths.
Christopher Pisz
Mar 5, 2015, 5:12:53 PM3/5/15
to
Robert Wessel
Mar 5, 2015, 10:33:34 PM3/5/15
to
On Thu, 5 Mar 2015 11:44:01 -0800 (PST), woodb...@gmail.com wrote:
Even if you make the (rather big) assumption that the bible has
historical accuracy, it does not assert that Methuselah was the oldest
human, but he is the oldest it mentions, and perhaps the oldest in the
genealogy leading to Noah, although that's still something of a
stretch.
historical accuracy, it does not assert that Methuselah was the oldest
human, but he is the oldest it mentions, and perhaps the oldest in the
genealogy leading to Noah, although that's still something of a
stretch.
woodb...@gmail.com
Mar 6, 2015, 12:54:18 AM3/6/15
to
On Thursday, March 5, 2015 at 9:33:34 PM UTC-6, robert...@yahoo.com wrote:
>
> Even if you make the (rather big) assumption that the bible has
> historical accuracy, it does not assert that Methuselah was the oldest
> human, but he is the oldest it mentions, and perhaps the oldest in the
> genealogy leading to Noah, although that's still something of a
> stretch.
OK, oldest documented human was Methuselah.
>
> Even if you make the (rather big) assumption that the bible has
> historical accuracy, it does not assert that Methuselah was the oldest
> human, but he is the oldest it mentions, and perhaps the oldest in the
> genealogy leading to Noah, although that's still something of a
> stretch.
Robert Wessel
Mar 6, 2015, 3:45:11 AM3/6/15
to
Just hanging around the middle east...
En-men-lu-ana, a king of Sumar, reigned for 43,200 years. Presumably
he was alive during that time. There are a bunch of other Sumarian
kings who hung around a really long time.
Aži Dahaka ruled for a thousand years. Just ask the Zoroastrians.
David Brown
Mar 6, 2015, 3:49:49 AM3/6/15
to
thousands of years each. The authors of the books of Moses took a lot
of inspiration from Sumerian stories and legends - they probably copied
the habit of exaggerating lifespans too.
Other old documented humans include some ancient Persian kings, as well
as many characters from India and the far east.
Remember, "documented" does not mean "true" !
Stuart Redmann
Mar 6, 2015, 11:29:44 AM3/6/15
to
JiiPee wrote:
[snip]
> Point being, that if one says that in a struct /class variables must be
> private, then using the same logic ALL the variable should be embedded
> inside a class as a private members and then call them from there, like for float:
>
> class Float
> {
> float get() { return f; }
> private:
> float f;
> };
Actually, that's a Really Good Idea (TM). That's what Ada95 has in
advantage of C++, you can create real number types quite easily. Lot's of
bugs would never have occurred had the program been written in Ada, like
the infamous bug in libTIFF, where the number of bytes to be copied from a
section was computed as int variable. Since the size of the section is
stored in the TIFF file including the 4 bytes of the section header, the
int variable had to be decreased by 4. If a malicious attacker created a
TIFF file, where the section size was stored with a value <4, the int
variable became negative, so that it got interpreted as UINT_MAX. LibTIFF
would then try to copy that many bytes from the TIFF file, which could lead
to stack corruption and privilege escalation.
This would never have happened in an Ada95 program, because the data type
"Integer" is always the last choice for a variable. Unfortunately, C++ did
not offer an equally easy way to define numeric data types (typedef is
insufficient there) :-(
Another thing is the source of many (avoidable) errors is implicit type
conversions. More than one time I shot myself in the foot by passing
inadvertently a float into a parameter that should actually be a bool. That
passes compilation totally unnotized. Had I tried to pass a Float for a
Bool, my folly would have been recognized on the spot.
I know that it is easily possible to create a matching type system in C++,
but unfortunately the C++ "mindset" has already been poisoned with the
wide-spread usage of the native data types like int and float.
Just my 2cents.
Stuart
PS: Please don't mistake me for a C++ hater. I love it heartily. I just
wish that it wouldn't spring so many traps.
[snip]
> Point being, that if one says that in a struct /class variables must be
> private, then using the same logic ALL the variable should be embedded
> inside a class as a private members and then call them from there, like for float:
>
> class Float
> {
> float get() { return f; }
> private:
> float f;
> };
Actually, that's a Really Good Idea (TM). That's what Ada95 has in
advantage of C++, you can create real number types quite easily. Lot's of
bugs would never have occurred had the program been written in Ada, like
the infamous bug in libTIFF, where the number of bytes to be copied from a
section was computed as int variable. Since the size of the section is
stored in the TIFF file including the 4 bytes of the section header, the
int variable had to be decreased by 4. If a malicious attacker created a
TIFF file, where the section size was stored with a value <4, the int
variable became negative, so that it got interpreted as UINT_MAX. LibTIFF
would then try to copy that many bytes from the TIFF file, which could lead
to stack corruption and privilege escalation.
This would never have happened in an Ada95 program, because the data type
"Integer" is always the last choice for a variable. Unfortunately, C++ did
not offer an equally easy way to define numeric data types (typedef is
insufficient there) :-(
Another thing is the source of many (avoidable) errors is implicit type
conversions. More than one time I shot myself in the foot by passing
inadvertently a float into a parameter that should actually be a bool. That
passes compilation totally unnotized. Had I tried to pass a Float for a
Bool, my folly would have been recognized on the spot.
I know that it is easily possible to create a matching type system in C++,
but unfortunately the C++ "mindset" has already been poisoned with the
wide-spread usage of the native data types like int and float.
Just my 2cents.
Stuart
PS: Please don't mistake me for a C++ hater. I love it heartily. I just
wish that it wouldn't spring so many traps.
Jorgen Grahn
Mar 10, 2015, 2:18:03 PM3/10/15
to
On Wed, 2015-03-04, Geoff wrote:
> On Wed, 04 Mar 2015 13:46:38 +0000, JiiPee <n...@notvalid.com> wrote:
>
> [snip]
>>
> On Wed, 04 Mar 2015 13:46:38 +0000, JiiPee <n...@notvalid.com> wrote:
>
> [snip]
>>
>>Peter: But what fundamental difference is there with age and coordinate
>>variables? Why the other one should be hidden
>>as a private and the other one not?? Tell me....
>
>>variables? Why the other one should be hidden
>>as a private and the other one not?? Tell me....
>
> The question you seem to be asking, in a long and tortuous way, is:
> At what point does an object become complex enough to deserve being a
> class?
What is a class, then? They are all types: structs/classes, various
> At what point does an object become complex enough to deserve being a
> class?
built-in types, enums (old and new) ...
I think you really mean "At what point should I create a new, distinct
type for this thing I'm modelling, rather than let it join and mingle
with the other happy integers?"
> Answer: it depends on the abstraction of the object and the design
> goals for that object.
manage in my code", like age or coordinate.
Then I agree.
> In the case of an integer or any of the intrinsic types, they are
> probably not complex enough to deserve a class or the usage of the
> object would be more cumbersome as a class that it is as a naked
> object.
been how useful it is to make up distinct types for things which could
have been represented as an int. And how few the drawbacks are.
- You can document the type.
- You can restrict operations to things which make sense.
- You can avoid accidentally mixing it with other integers.
- You can overload on the type.
- You can select how it's formatted on a std::ostream.
- etc
In general, if you think of something as a distinct thing, it probably
deserves its own type. That's what they're there for, and that's what
C++ is really good at.
For example, I once maintained a code base with something like
struct Statistics {
unsigned long rx;
unsigned long tx;
unsigned rx_err;
// a dozen more
};
We constantly forgot to initialize them all to zero in the constructor,
until I realized that the right thing to do was to create an
Accumulator<T> which initialized itself to 0, and only supported
operator++() and printing itself.
Then there was the incident with the sequence numbers (my side, the
remote side's, the data plane's) which were mixed up in one odd code
path, and almost sent me to India to troubleshoot. Next time, I
created types LocalSeqno, RemoteSeqno, ... and that bug became
impossible.
> One wouldn't write a class for unsigned int age but one would
> write a class for object Student, possessing attributes, age, grade,
> sex, GPA, ID_Number, etc.
>
> It's a design choice that is dictated by the scope of the program and
> it's goals.
age". If ages are important to the problem you're solving, make Age a
type. If it's just an unimportant property of a Student and not
really used elsewhere, keep it as an int.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Message has been deleted
Reinhardt Behm
Mar 10, 2015, 10:39:49 PM3/10/15
to
Stefan Ram wrote:
> »A class is a user-defined type.« - Bjarne Stroustrup
> { int x;
> ^ Warning: Raw int used. (Raw ints will be deprecated in C++2z.)
And at the highest warning level:
** Warning you are writing a program. It might contain errors.
--
Reinhardt
> »A class is a user-defined type.« - Bjarne Stroustrup
>
>>I think you really mean "At what point should I create a new, distinct
>>type for this thing I'm modelling, rather than let it join and mingle
>>with the other happy integers?"
>
> You seem to agree with Bjarne!
>>I think you really mean "At what point should I create a new, distinct
>>type for this thing I'm modelling, rather than let it join and mingle
>>with the other happy integers?"
>
>
>>I find that untrue. One of the eye-openers for me over the years has
>>been how useful it is to make up distinct types for things which could
>>have been represented as an int. And how few the drawbacks are.
>
> int main()
>>I find that untrue. One of the eye-openers for me over the years has
>>been how useful it is to make up distinct types for things which could
>>have been represented as an int. And how few the drawbacks are.
>
> { int x;
> ^ Warning: Raw int used. (Raw ints will be deprecated in C++2z.)
And at the highest warning level:
** Warning you are writing a program. It might contain errors.
--
Reinhardt
Jorgen Grahn
Mar 11, 2015, 1:59:17 PM3/11/15
to
>>What is a class, then?
>
>
> »A class is a user-defined type.« - Bjarne Stroustrup
>
>
>>I think you really mean "At what point should I create a new, distinct
>>type for this thing I'm modelling, rather than let it join and mingle
>>with the other happy integers?"
>
>>type for this thing I'm modelling, rather than let it join and mingle
>>with the other happy integers?"
>
> You seem to agree with Bjarne!
Partly, I suspect, because a adopted his use of the word "type".
But yes, he also writes somewhere in TC++PL that working with a lot of
what he calls "concrete types" is important, and I agree fully with
that.
0 new messages