Re: passing ref to ptr again as ref to ptr....
On Apr 24, 11:53 pm, "Bo Persson" <b...@gmb.dk> wrote:
osama...@gmail.com wrote:
[...]
Does that mean references and templates are not to be mixed?
No, they work very well together. I think the void* is the
problem here, and that you are trying too hard to optimize the
code.
I would trust my compiler here, and just write
template<class T>
class GenericQueue
{
bool Pop(T&);
};
Given that he requires pointer semantics, and copying a pointer
cannot throw, there's no reason not to just use
T* pop() ;
in the generic interface.
if that is the interface needed (it probably is not - take a
look at std::queue and std::stack).
There's a slight difference. The standard containers are
designed to store values, not (only) pointers. So the
alternatives are:
-- return a T, but not be thread safe,
-- take a reference as a parameter, requiring the client to
define (and construct) and instance before hand, or
-- separate accessing the object and removing it, putting them
in two separate functions.
Globally, I think the first alternative was dismissed because of
the lack of thread safety (although I think it was what was used
in the original STL); of the latter two, the last seems to offer
the most flexibility, and was chosen.
If you limit elements in the container to types which cannot
throw when being copied, then the first is the obvious solution.
The compiler knows which types (pointers or not) are of the
same size, and can compile that to identical code.
Almost none do.
And that's not the only point---you don't want to load your
header files with complicated implementations, increasing
coupling and compile times. In the absense of export, you may
want to factorize the implementation into a non-generic part
simply to reduce coupling.
And is that why STL containers do not store references to
objects?
Many containers will have to copy some of their contents when
inserting or erasing members. References cannot be copied.
More to the point, the STL uses value semantics by default (as
does the rest of C++). If the STL stored a reference, would
that mean that the client code would have to ensure the
lifetime of the object? I don't think storing references is a
good idea, myself.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34