Thursday, February 11, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 6 topics

JiiPee <no@notvalid.com>: Feb 11 08:02PM

On 11/02/2016 19:51, Wouter van Ooijen wrote:
> But there are some cases in which IMO public attributes are the bettre
> choice, for instance locations (x,y coordinate pairs)
 
here I have agreed.... My point class has just int x,y; ... i find
it difficult to have: int getX(); I dont like:
center.X();
 
but rather:
 
center.x
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 11 08:32PM

On 11/02/2016 19:58, JiiPee wrote:
>> are a nuisance, and you should instead make the attributes public.
 
> Sutter argues strongly that you should always use functions to get
> access to data members....
 
Strictly speaking only those (non-const) member variables that
contribute to a class's invariant need be kept private. Obviously if
changing the name of a person should be reflected by updating some GUI
widget then you would want to use a setter function.
 
/Flibble
scott@slp53.sl.home (Scott Lurndal): Feb 11 08:48PM

>> }
 
>ok, this has a point.... have to think about....
>So instead of setter, we would always pass the object and the new value.
 
Well, I personally have no problem with getters and setters. I don't
see a need for a specific naming convention, however.
Vir Campestris <vir.campestris@invalid.invalid>: Feb 11 09:18PM

On 11/02/2016 19:41, Alf P. Steinbach wrote:
> function invocations look like data attribute access in Eiffel, so that
> a data attribute could be replaced with a member function or vice versa
> without affecting client source code
 
That's one of the things C# and Java have got right.
 
The good thing about setters instead of exposing data is that you can do
more with them. So I can have
 
void NewAge(int age)
{
#ifdef DEBUG
trace << "Age updated to " << age;
if (age > 127) throw ICBA;
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)