> Tom Fogal wrote:
>
> >>I'm just interested in hearing about whether one is more appropriate
> >>than the other in some contexts. Thanks.
> >
> >
> > Generally, I would use #defines for anything but function parameters.
> > Passing things as a constant reference (const type &val) is a good way to
> > avoid passing a large value without the overhead of actual passing it.
>
> I understand what you are saying, about passing a reference to something
> rather than passing the thing itself. My understanding is that this is
> because the value of a reference is a memory address, which is usually
> smaller than say, some large value (please correct me if this is
> incorrect). But why does it have to have "const" placed there? This
> seems like it should prevent the value from being modified in the body
> of the function somehow, but is it required or are you suggesting it as
> good practice?
The bit about memory addresses instead of some large value is entirely correct.
Practically however, this will only be better when passing a value larger than
the register size of the architecture you are on. For instance, on ix86 linux,
all pointers are 32-bit integers. Thus passing a constant reference to another
integer still means you have to pass an integer to the function, thus saving
nothing.
This is commonly used when you have a large record or object.
The const is purely optional; you could just as easily remember yourself that
'hey, i dont want to change that value in this function' and simply not do it.
The justification i was given for such usage is that someone who is not you
can quickly look at the function header/prototype and see, 'oh, this value is
const, it wont change when i pass it to the function'.
Also, supposedly it prevents you from 'forgetting' you didnt mean to change it,
and doing so on accident. IMHO though, if you can't remember you didn't want
to change a fqn parameter, you're functions are waaaay to long, or you aren't
cut out for the programming vocation :P
Btw, a similar gain can be obtained via pointers, so C programmers aren't
left out =).
> > Unfortunately, references do not exist in C alone (they were introduced in
> C++)
>
> I seem to be confused about the difference between references and a
> type's address. Are you saying that
>
> &val
>
> is a reference, and that this is different from the address of 'val'? I
> thought that this meant "the address of 'val'".
Oh yes, this is a source of much confusion. You see, C++ introduced this idea
called a 'reference', which, for all intents and purposes is a pointer, but
you dont have to dereference it as such. thus if i have a procedure that wants
to change its integer parameter to 5, i could do the following in C++:
void change_int(int &changeme) { changeme = 5; }
C programmers would flip at such a statement - 'Youll screw everything up! That
makes changeme have whatever is in memory location "5"! That could be
ANYTHING!' etc etc.
Well, thats true. In C, &changeme means 'the address of changeme'. In C++, the
&changeme could mean EITHER 'the address of changeme' OR 'a reference to
changeme'. I've never had a good explanation as to how one could tell which
is meant. It seems to me that if its passed as a function parameter, it is a
reference. Within a function, it means 'address of'. Don't quote me on that.
Another CS major concurs with my interpretation, acutally.. perhaps I got it
right...
In any case, when programming in C only you don't need to worry about such
unwarranted complications (although i'm a bit biased in that i dislike C++ :).
> Thanks everyone for contributing to this discussion.
np, my pleasure =)
-tom
>
> Erik
_______________________________________________
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
