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

--- VM <mayeski@gmail.com> wrote:
> Hello,
> 
> I'm trying to decide on the best way to pass
> parameters to inline
> function. For example, the two functions below:
> 
> inline int
> sum(atype_t *x)
> {
>   return x->a + x->b;
> }
> 
> and
> 
> inline int
> sum(atype_t x)
> {
>   return x.a + x.b;
> }
> 
> Since the function is inline, my guess is that the
> compiler will
> generate identical code for both. So there should be
> no performance
> difference.
> 
> Is this assumption correct?
> 

No!  

Ignore, for the moment, that you are merely advising
the compiler that you want the function inlined. 
Unless things have changed since last I looked, there
is no guarantee that the compiler will inline a
function you have asked to be inlined.

Your bigger problem is that you have ignored the
semantics associated with passing an argument by
reference, pointer and value.

The first version of your function passes a pointer
argument.  Always the same size, and since you don't
say the pointer, or the object to which it is
pointing, is const, any change made to the object
within the function remains after the function
finishes and is visible to the calling code.  In the
second, you pass by value, so the copy constructor
must be called.  And any change made to that object
within the function is lost when the function
completes, and is never visible to the calling code
(unless you return the object, which again will
require invoking the copy constructor).

I would recommend you base your decisions about
whether to pass by reference or by value on what the
function needs to do to, or with, the argument object,
rather than idle speculation about what the compiler
may do IF it inlines your function.  If the compiler
isn't broken, it will not change the semantics of the
function.  Therefore, if you pass an object by value,
it has to be copied so that IF your function makes
changes to it, those changes are not visible to the
calling code and cease to exist once the function
completes.  I would not expect inlining the function
to change that.  And it gets more complicated.  For
example, is there polymorphism involved, and if so,
which version of the virtual function used do you need
in the context of your function?  The bottom line is
that there is no one best way to pass arguments since
what you do depends on what is needed, irrespective of
whether or not the function you're analyzing ought to
be inlined.

HTH

Ted

  reply	other threads:[~2008-04-10 12:20 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 [this message]
2008-04-10 13:37   ` Vincent Mayeski
2008-04-10 14:45     ` Ted Byers
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=676074.17361.qm@web88301.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).