Re: 64 bit C++ and OS defined types
On Apr 5, 2:34 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Apr 3, 10:31 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Juha Nieminen:
[...]
Suggesting to avoid using "get" in a getter method is as
superfluous here as suggesting eg. that one should use
reverse polish notation or how many spaces should be used
for indentation. It's a matter of style, not a matter of
whether it's a standard C++ feature.
It is bad style in C++ precisely because C++ doesn't have
any language feature to make use of it (Java does have such
a feature).
I'm not sure what you mean by "feature" here.
Introspection. Which makes it possible to create tools that
depend on a certain naming convention, tools that let you
treat a "component" class very generally, including e.g.
design time manipulation. With support from the class!
And the original convention for that in Java was called "Java
beans".
Quoting Wikipedia on beans: "The class properties must be
accessible using get, set, and other methods (so-called
accessor methods and mutator methods), following a standard
naming convention. This allows easy automated inspection and
updating of bean state within frameworks, many of which
include custom editors for various types of properties.".
Yes, but the "convention" existed and was documented by Sun
before Java supported introspection. And all introspection
really requires is a convention, not any specific convention
(but it would be somewhat difficult to implement if there were
no specific prefix).
As I see it,
there are two alternatives:
int size() const ;
void size( int newSize ) ;
and
int getSize() const ;
void setSize( int newSize ) ;
Both work, and both result in readable code. I prefer the
first, but the difference isn't enormous.
And both work equally well in Java as in C++. (And in
beginning, the Java library was sometimes inconsistent in its
choice as well.)
Actually you're right that I did put things to a point. I
personally prefer a mixture, with the "set" prefix.
In other words, the worst of both worlds:-).
Seriously, I mentionned the two (and not more) because those are
the only two I've seen in any actual programming guidelines, or
in real code. It's probably a reasonable argument to say that
the two functions do different things, so deserve different
names. In that case, however, it's just as reasonable to insist
that the names reflect what they do, i.e. get and set. And I
find it just as reasonable (if not more) to consider that these
aren't really "functions", despite the syntax; they "expose" (in
a controlled way) a data member, and should thus have the public
name of the data member.
A third solution, of course, would be to have:
int size() const ;
IntProxy size() ;
so you could write:
int a = x.size() ;
x.size() = a ;
In many ways, this is the most elegant. But it just seems more
work than necessary (to me anyway) to implement all of those
proxies, and C++ programmers don't really expect it.
That's because of a preference for readability and my very
subjective opinion of what constitutes readability, he he. :)
And that ties in with that one practical and very C++ specific
benefit of avoiding the prefixes has only to do with "get",
not with "set".
Namely, to supporting letting the client code choose to
manually optimize (awkward notation) or not (especially when
the compiler does it), by doing
void getPopulationData( Container& c )
{
Container result;
...
result.swap( c );
}
Container populationData()
{
Container c;
getPopulationData( c );
return c;
}
Here client code will preferentially use "populationData",
relying on RVO for the cases where efficiency matters.
If it turns out that the compiler isn't up to the task and
measurements show that efficiency of these calls do matter a
lot, then client code can fall back to using
getPopulationData, in the place or places where it affects
performance.
How does this change anything with regards to the choice above?
If you use get/set prefixes, overload resolution will come into
play for the selection of the get function. If you use no
prefixes, then the get name is still available for use as above.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34