Simple question
Mosfet
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
Jeff Schwab
> Hi,
>
> I wanted to know what is pros/cons between this two ways of declaring a
> function :
>
>
> 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.
> 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.
When in doubt, keep each piece of code completely self-contained. That
means functions should require as little from the calling (client) code
as possible.
peter koch
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
James Kanze
> 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:james...@gmail.com
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
Phlip
> 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