Re: The use of const reference instear of getter
On Aug 6, 5:09 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <a04e37a8-a709-40f6-ba20-7a783640d3bf@
79g2000hsk.googlegroups.com>, james.ka...@gmail.com says...
[ ... ]
There _may_ be compilers for which this is true (I
certainly can't test with every one) but a quick test
shows that it's not necessarily the case. I put together a
quick bit of test code that created a const reference to a
public variable, and compared the code generated for
accessing the variable directly and via the const
reference. Unless I misread the code, there was on
difference between the two.
I'm curious which compiler you tested. A very quick test
showed that the extra reference increased the size of the
object with Sun CC, g++ and VC++.
I tested with g++ and VC++. I didn't look at the size of the
object file, but at the generated code -- the size of the
object file can be affected by all sorts of things unrelated
to the actual code.
I didn't look at the size of the object file. I looked at the
size of the object. In an array. Basically:
class A1
{
public:
int const& r ;
A1( int i ) : r( myI ), myI( i ) {}
private:
int myI ;
} ;
class A2
{
public:
A2( int i ) : myI( i ) {}
int r() const { return myI ; }
private:
int myI ;
} ;
On all of my machines, sizeof( A2 ) is 4. Depending on the
machine, sizeof( A1 ) is either 8 or 16.
For occasional use, it doesn't matter, but if you've got a large
array of the things, it could make a significant difference.
Most of the time, too, I don't have intermodule optimization
turned on, so if the constructor isn't inline, and the compiler
can't see what the reference was initialized with, it will have
to generate an additional level of indirection for each access.
(If the constructor is inline, of course, it shouldn't be too
difficult for the compiler to opimize, but it wouldn't surprise
me either if some didn't.)
[ ... ]
The idea is
interesting, however: attribute access should always use
variable access syntax, even if it means introducing some sort
of proxy.
I'll admit that sometimes it may be more work than it's worth -- but I
think the use of an accessor function should be recognized for what it
really is. Accessor functions represent a compromise in which you make a
class easier to implement at the expense of being more difficult (and
ugly) to use. That's directly contrary to (what I'd see as) the basic
point of using objects to start with though -- that it's worthwhile to
do extra work in implementing a class to make it easier to use.
Yes. In many ways, and accessor function can be considered a
hack around language constraints. If the element is logically
considered to be an attribute; of course.
[A number of interesting considerations deleted...]
In the end, I guess, it's a question of making the rules simple
(either none or all of the data is public), and following
general practice (which isn't that bad), even though there are
better (cleaner, more elegant) solutions.
(In our case, we use functions for access even in our pure data
classes. Justified in this particular case by the fact that the
actual data class itself is automatically generated, with code
to support marshalling and data base accesses, but without any
code to support constraints, etc. The access functions are
virtual, and the actual code derives from the generated class to
implement the additional constraints. I'm not sure how to make
that work with your idea using proxies.)
--
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