Return pointers or references?

[Gama Franco]

Hi,

I'm designing an interface for a shared library, and I would like to
know if there is a standard about how to return an object to the user. I
will use exceptions to report errors, so there are at least four ways to
do it.

For example if we have a method named M, that receives a reference to
parameter p and returns object o.

1 - virtual o& M(p& parameter) throw(Exception 1, Exception2...

2 - virtual o* M(p& parameter) throw(Exception 1, Exception2...

3 - virtual void M(p& parameter, o& returnVal) throw(Exception 1,
Exception2...

4 - virtual void M(p& parameter, o* returnVal) throw(Exception 1,
Exception2...
Probably there is no convention about it and is only a mater of taste,
but I would like to know some opinions.

Best regards,
Gama Franco

[Victor Bazarov]

Daniel T. wrote:

[...] Try returning the object by
const value first, [...]

Top-level const qualifiers are meaningless in most situations. And
I mean

const int foo();
void foo(const int);

V

[E. Robert Tisdale]

Niels Dybdahl wrote:

Use

virtual o M(const p& parameter) const;

instead. Pass by *const* reference and return by value.

I forgot to mention something very important.
One of the requisites is efficiency.
I mean, the API should run as fast as possible
(it deals with scientific data aquisition).
As mentioned virtual o M(...) is the most elegant solution.
Often the implemention is that the caller allocates the memory for o
and M initializes it with its return statement,
which often defaults to a simple copy operation.

No.
A good optimizing C++ compiler should implement
the Named Return Value Optimization (NRVO).
When a function returns the value of a local variable
the optimizing compiler interprets the local variable
as a reference to the return value and initializes it directly --
*no* copy is required!
Return by value costs no more than any of the other options
that Gama Franco listed.

If your compiler does not implement the NRVO,
you must not be concerned about efficiency or performance
or you should be shopping for a better optimizing C++ compiler.
If you want to get rid of the construction, copying and
destruction of the object for each call,
you [must] use method 3 or 4. They are equal in terms of efficiency.
Whether you use pointer or reference does not matter in terms of effiency.
I prefer using references to emphasize, that it is not an array.

This probably isn't a good idea.

In-place operations (functions that modify objects)
should be of the form:

o& o::M(const p& parameter);

and return a reference to the object.

[Gama Franco]

E. Robert Tisdale wrote:

Niels Dybdahl wrote:

Use

virtual o M(const p& parameter) const;

instead. Pass by *const* reference and return by value.
I forgot to mention something very important. One of the requisites
is efficiency. I mean, the API should run as fast as possible (it
deals with scientific data aquisition).

As mentioned virtual o M(...) is the most elegant solution. Often the
implemention is that the caller allocates the memory for o and M
initializes it with its return statement, which often defaults to a
simple copy operation.

No.
A good optimizing C++ compiler should implement
the Named Return Value Optimization (NRVO).
When a function returns the value of a local variable
the optimizing compiler interprets the local variable
as a reference to the return value and initializes it directly --
*no* copy is required!
Return by value costs no more than any of the other options
that Gama Franco listed.

If your compiler does not implement the NRVO,
you must not be concerned about efficiency or performance
or you should be shopping for a better optimizing C++ compiler.

If you want to get rid of the construction, copying and
destruction of the object for each call, you [must] use method 3 or
4. They are equal in terms of efficiency. Whether you use pointer or
reference does not matter in terms of effiency. I prefer using
references to emphasize, that it is not an array.

This probably isn't a good idea.

In-place operations (functions that modify objects)
should be of the form:

o& o::M(const p& parameter);

and return a reference to the object.

Hi,

I do I know if my compiler does that kind of optimization?
The code will compile in a great number of versions of g++, and probably
also in the default compiler of Solaris.
The program will be used for data aquisition, dealing with data in the
order of hundreds of megabytes per second. Since we are dealing with the
refractoring of an existing API, I really would like to make a
consistent choice without affecting the efficiency of the existing code.
If most of the compilers use that kind of optimization, probably return
by value may be the best choice, since the object will get destroyed
when the variable gets out of scope.

Best regards,
Gama Franco

[E. Robert Tisdale]

Gama Franco wrote:

I do I know if my compiler does that kind of optimization?
The code will compile in a great number of versions of g++,
My compiler:
g++ --version g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

does it.
and probably also in the default compiler of Solaris.
Later versions of the Solaris C++ compiler do it too.
The program will be used for data aquisition, dealing with data in the
order of hundreds of megabytes per second. Since we are dealing with the
refractoring of an existing API, I really would like to make a
consistent choice without affecting the efficiency of the existing code.
If most of the compilers use that kind of optimization,
probably return by value may be the best choice,
It *is* the best choice.
Most modern C++ compilers support the NRVO
but what matters is that there is at least one
good optimizing C++ compiler for each target platform.
You can do your development with whatever compiler is most convenient
and then recompile with your best optimizing C++ compiler
just before you distribute the production release.
since the object will get destroyed when the variable gets out of scope.

[Daniel T.]

Victor Bazarov <v.********@com Acast.net> wrote:

Daniel T. wrote:

[...] Try returning the object by
const value first, [...]

Top-level const qualifiers are meaningless in most situations. And
I mean

const int foo();

When it comes to basic types like 'int' I agree, but not with user
defined types. For example if we have:

value foo();

Then clients can do:

value myValue = foo().modify();

Then changing to 'const value&' will break the program. Better is to
return 'const value' so that clients can't modify the temporary (making
user defined types more like basic types) thus allowing us to change to
a 'const value&' without having to modify any client code.