"James Kanze" <james.kanze@gmail.com> wrote in message
news:cb0f1497-14d8-4b15-b3b6->bf71ebb48b26@k30g2000yqf.googlegroups.com...
On Aug 13, 5:15 pm, "Hicham Mouline" <hic...@mouline.org> wrote:
... my colleague says.
I disagree on the "Never".
Opinions about this "rule of thumb" welcome.
It's one of the stupidest rules I've heard of. The rule should
be just the opposite: "never use a smart pointer when a raw
pointer will do the job". But even that's stupid, in a
way---smart pointers and raw pointers are different beasts, and
generally not interchangeable. Generally, if a smart pointer
will do the job, a raw pointer can't, and vice versa (unless you
have some very stupid and useless smart pointers).
In practice, in most application level software (at least in the
domains I've worked in), most pointers will be raw, because a
smart pointer would not do the job---at least not correctly.
But most is not all, and there will almost always be some cases
where the smart pointer is more appropriate as well.
It is interesting to see so many different opinions about this.
Perhaps, the discussion can be fine tuned if I put down the use case
(trivial one) here:
We have a 3rd party application that accepts to load shared dynamic
libraries, this is on windows.
The application requires a number of entry points into the DLL. These are
"exported" functions, 2 of these
are
// with C linkage convention (ie , they use C and not C++)
int initialize(some_type* f);
void finalize();
1 translation unit where we implement this requirement looks like
extern "C" {
static const our_adapter* adapter=0; // global static raw pointer
int initialize(const some_type* f)
{
if (f==0)
{
return failure; /// 3rd application will ignore this dll
}
adapter = new our_adapter(*f); /// ctor never fails. If new fails, the
3rd party application crashes (we decided it's ok)
}
//// we axiomatize that initialize() is called once before finalize() and
that the 3rd party application calls these just once
void finalize()
{
delete adapter;
}
// other required function
int other_function()
{
adapter->do_something();
}
}
I would have had as a global variable the our_adapter itself, but its ctor
requires the "f", so I used a pointer instead.
Because of the exisiting symmetry between initalize and finalize, new'ing
and deleting seem to me appropriate.
My colleague insists I should use auto_ptr<our_adapter> instead of a raw
pointer here, and then said as a general rule,
never use a raw pointer when the smart pointer will work, hence the post.
could I have opinions about this particular case?
singleton-with-arguments. Both of which are quite complex.
Anyway, in the above about the only thing a smart pointer could help with would
preference),. You would instead provide a higher level interface (inline in a
header) that gives the 3rd party application a smart pointer. So the example is