public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ted Byers <r.ted.byers@rogers.com>
To: Vincent Mayeski <mayeski@gmail.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: how to pass params to inline functions by reference or value?
Date: Thu, 10 Apr 2008 14:45:00 -0000	[thread overview]
Message-ID: <659773.60570.qm@web88305.mail.re4.yahoo.com> (raw)
In-Reply-To: <1207832200.12695.22.camel@vm-laptop>

--- Vincent Mayeski <mayeski@gmail.com> 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

  reply	other threads:[~2008-04-10 13:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-10  5:55 VM
2008-04-10 13:32 ` Ted Byers
2008-04-10 13:37   ` Vincent Mayeski
2008-04-10 14:45     ` Ted Byers [this message]
2008-04-10 15:11     ` Eljay Love-Jensen
2008-04-10 15:37       ` Vincent Mayeski
2008-04-10 21:39         ` Tony Wetmore
2008-04-10 15:33 ` John Fine
2008-04-11 11:57   ` Brian Dessent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=659773.60570.qm@web88305.mail.re4.yahoo.com \
    --to=r.ted.byers@rogers.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=mayeski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).