--- Vincent Mayeski <mayeski@xxxxxxxxx> wrote:
> Thanks Ted.
>
> I see your point. I should have included the const
> in the first version
> of the function. So we would have:
>
> inline int
> sum(const atype_t *x)
> {
> return x->a + x->b;
> }
>
> and
>
> inline int
> sum(atype_t x)
> {
> return x.a + x.b;
> }
>
> Now these two functions are semantically identical I
> believe.
No, not quite. Think about your function that takes
pointers. What is constant? The pointer, or the
object it points to, or both?
In the version that takes the argument by value, what
is constant? The address of the object, the object,
or both?
Now, extend your consideration to assume that the data
members 'a' and 'b' are instances of classes that are
members of an inheritance tree, and that there are
virtual functions involved. Which implementation of
these virtual functions SHOULD be called, and which
WILL be called?
> As you
> say, the second implementation suggests that the arg
> needs to be copied.
> However, IF the function is inlined, no copying
> should actually take
> place because the arg is not modified within the
> function. My guess is
> that these will produce identical code.
>
How is this assumption clear from the body of the
function? We don't know what the data members 'a' and
'b' are, or what operator+() does to them. Yes, if
they are pods, arg is not modified, but if they are
not, almost anything goes? And if you call functions
in your inline function, and they call other
functions, which in turn call other functions, you can
not know that the objects passed as an argument are
not modified by the function, unless you have complete
and correct specification of const through your entire
codebase. And this raises the question of WHICH
codebase. The code in question may well be part of a
library used in a variety of projects, and the data
members accessed in your function may be wrappers for
implementing classes, so the wrappers' member
functions may well all be inlined, but the
implementing classes may or may not guarantee that
accessor functions or operators defined for the class
guarantee that the object won't be changed. And none
of this affects whether or not the function could or
should be inlined.
I am not sure I'd want a compiler to analyse all that
in order to figure out whether or not to copy an
argument passed by value when deciding to inline a
function.
> If the compiler generated different code for each,
> then the second
> implementation should be faster because there is no
> dereferencing
> needed.
>
> Is this correct?
>
No!
Unless someone who has developed the compiler code
that handles inlining can tell us that there is a way
for the compiler to guarantee that the argument passed
by value is not changed without doing the copy, it
must be assumed that the copy is done regardless of
whether the function is inlined or not.
HTH
Ted
