Simple question

Discussion in 'C++' started by Mosfet, Apr 24, 2009.

  1. Mosfet

    Mosfet Guest

    Hi,

    I wanted to know what is pros/cons between this two ways of declaring a
    function :


    std::string GetCurrentPath();
    or
    void GetCurrentPath(const std::string& sCurPath);


    In terms of rapidity, memory , ...
    I supose form 2 is better because there is no copy but is it really
    significant ?

    Thanks
     
    Mosfet, Apr 24, 2009
    #1
    1. Advertising

  2. Mosfet

    peter koch Guest

    On 24 Apr., 18:10, Mosfet <> wrote:
    > Hi,
    >
    > I wanted to know what is pros/cons between this two ways of declaring a
    > function :
    >
    > std::string GetCurrentPath();
    > or
    > void GetCurrentPath(const std::string& sCurPath);
    >
    > In terms of rapidity, memory , ...
    > I supose form 2 is better because there is no copy but is it really
    > significant ?


    In general the first version will be faster. This is the case whenever
    the call will be used directly in the constructor. Anyway, it is more
    ideomatic and certainly saves lots of programmer-time. It is also very
    easy to change from the first version to the second should some inner
    loop demonstrate to be faster using the second version.

    /Peter
     
    peter koch, Apr 24, 2009
    #2
    1. Advertising

  3. Mosfet

    Phlip Guest

    Mosfet wrote:

    > std::string GetCurrentPath();
    > or
    > void GetCurrentPath(const std::string& sCurPath);
    >
    > In terms of rapidity, memory , ...


    Premature optimization is the root of all evil. You should write what works
    best for the programmer - typically the first one.

    C++ will optimize the std::string constructor to synchronize with the
    constructor inside the GetCurrentPath(). They are the same object - that's
    the "return value optimization".

    But you should write the simplest and most readable code possible, even C++
    cannot optimize it. Even if you would get a few extra copies. And you should
    write lots of unit tests. After you have a running application, and you can
    actually time-test it to see where the real bottlenecks are. They are most
    likely not something you would have guessed. These practices free your time
    up to focus directly on the parts of your code that actually need the
    performance boosts...

    --
    Phlip
     
    Phlip, Apr 24, 2009
    #3
  4. Mosfet

    James Kanze Guest

    On Apr 24, 6:44 pm, Jeff Schwab <> wrote:
    > Mosfet wrote:


    > > I wanted to know what is pros/cons between this two ways of
    > > declaring a function :


    > > std::string GetCurreitPath();
    > > or
    > > void GetCurrentPath(const std::string& sCurPath);


    > Those aren't equivalent. Form 1 takes no inputs but has one
    > output, but vice versa for form 2. If you meant to pass the
    > string by non-const reference, then I prefer the former,
    > since:


    > - the latter requires the string to be non-const in the
    > caller, and


    > - the latter can only be used for assignment, not
    > initialization, whereas the former can be used for either.


    As an extension to what you've said: you can't use the second in
    expressions. Things like getCurrentPath() + '/', for example.
    Which is, IMHO, a killer argument.

    It's worth noting, too, that C++ has absolutely no support for
    out parameters. For in parameters, you can use pass by value or
    const reference. For inout, pass by non const reference, but
    for out... You're still required to provide an in value, even
    if the called function doesn't care.

    > > In terms of rapidity, memory , ... I supose form 2 is
    > > better because there is no copy but is it really
    > > significant?


    > There's not necessarily any copy in form 1, either. The
    > compiler is allowed to elide the copy. Form 2 can actually
    > prevent some optimizations, since GetCurrentPath might cache a
    > pointer to the caller's string.


    Not to mention the fact that you've got to construct a string
    before calling the function. Constructing a string immediately,
    to return it, could be quicker constructing it, then assigning a
    value to it.

    But of course, the argument is misplaced. It's hard to imagine
    a case where the difference would be measurable, and when such a
    case occurs, that's the time to fix it. Speculatively fixing
    supposed performance problems before they exist is just stupid.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 25, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    590
  2. Kevin Spencer

    Re: Simple Simple question!!!

    Kevin Spencer, Jun 25, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    697
    Kevin Spencer
    Jun 25, 2004
  3. Daniel Frey

    Simple Question - Simple Answer?

    Daniel Frey, Dec 28, 2004, in forum: XML
    Replies:
    4
    Views:
    873
    Daniel Frey
    Jan 12, 2005
  4. Oli

    simple simple question

    Oli, Jan 26, 2004, in forum: ASP General
    Replies:
    10
    Views:
    393
    Roland Hall
    Jan 26, 2004
  5. Peter Bailey

    simple, simple array question

    Peter Bailey, Apr 8, 2008, in forum: Ruby
    Replies:
    7
    Views:
    238
    Peter Bailey
    Apr 8, 2008
Loading...

Share This Page