Re: The use of const reference instear of getter
On Aug 6, 6:48 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <bf365953-9c04-4c7d-96eb-ba39699472f4
@z66g2000hsc.googlegroups.com>, james.ka...@gmail.com says...
[ ... ]
With most compilers, it will increase the size of the object.
(And since the original poster mentionned performance, I expect
that with most compilers, compared to a getter, it will generate
slower code. Internally, the reference will be implemented as a
pointer, and that ain't good for optimization.)
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++.
The other problem is consistency. When you need to return
something that isn't really a member variable, you use a
function call; for the member variable, you use a reference.
Isn't that exposing internal details which the client code
should not be concerned with?
IMO, you've got things exactly backwards: the user is
accessing something that _is_ a member variable, and forcing
them to access it via a function is exposing an internal
detail with which they should not be concerned.
In fact, the representation as a member variable is itself an
internal detail. If what the client is doing (at least
conceptually) is just accessing some data, then the code to do
so should _look_ like it's just accessing data. The previous
existence of that data vs. generating it on the fly is an
implementation detail that should be hidden.
Well, that is really the question. When I mentionned
consistency, the idea I had in mind is that in many cases, you
will be required to use the functional notation, even if the
thing in question is conceptually an "attribute". Since some
attributes require functional access, consistency says that all
should.
It's true that there are ways around this, as you pointed out.
In practice, I've not seen them used much. The idea is
interesting, however: attribute access should always use
variable access syntax, even if it means introducing some sort
of proxy.
--
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