Quote:Original post by Verg
These should be standard for ALL smart pointer types:
Your opinion, which I disagree with ^_^. Prehaps something like:
boost::shared_ptr< int > foo;
foo = boost::share( new int );
Or something of similar shorterness that autopromotes a raw pointer to an auto pointer (so that when you have a shared_ptr to huge_name_with< multiple< template_parameters < etc < etc < etc< pie > > > > > you don't have so much to type). But personally I prefer the safety that comes with disallowing direct assignment (foo = new int). It makes this all too easy:
int * foo = new int;boost::shared_ptr< int > bar;//...bar = foo;//...delete foo;//when bar goes out of scope, it too will attempt to delete bar!!!Quote:My opinion is: with the exception of the lack of "garbage collection", a smart pointer should act like a pointer. I don't want the smart pointer to have its own methods which are called through the dot (.) resolution operator. How retarded to have both this:
ptr->hi()
and this!
ptr.ref_count()
!!
How retarded is it to care? Seriously, if you don't want to use the functions available through the dot operator, just don't use them. Of course this means you won't be using std::auto_ptr<>'s .release() member, or any similar extra optional functionality provided by smart pointers...
Quote:And if I can't make a simple assignment from bald pointer to smart pointer, I have to either set the smart pointer in the containing class's initializer list (not always practical), or use the retarded "reset()" method through the dot operator. >:-(
I realize the designers of the boost::smart_ptr libraries are trying to make the world safe for pointers; but by disallowing both of the above, they're giving us basically a glorified wrapper with an overridden -> operator. What's the use? May as well use reference variables, if you can't do simple pointer assignment.
The use is simply eliminating the need to do reference variables. It's little extra typing, but tracking it for every object can be impractical - especially if you don't have access to the class definition itself (std::string, etc). The fact that boost::invasive_ptr supports allowing you to do your own reference counting emphisizes this point.
Quote:IMO you shouldn't have to accomodate the smart pointer class (by using SmartPointerType<T>::reset() or something to assign a pointer)... the smart pointer class should (relatively) easily take the place of a bald pointer.
Easy? Sure, as long as it's not "Easy to shoot off your foot with". Direct assignment is this as far as I'm concerned - with shared_ptr anyways.
Quote:The reason I'm b!tching
For gods sake, either say bitching or don't.
Quote:at all is that there is a bug in Loki's "FixedAllocator" class which causes an assert failure when storing a Loki::Functor pointer inside a Loki::SmartPtr. The CVS has apparently fixed that bug; but I (on my wee little lonesome) came across a new bug in the CVS which causes a different assert... so now the application code has ground to a halt.
We tried temporarily defining "__LOKI_REPAIR__" and RE-defining all "functor ptr types" in the app, based on that define... to use boost::shared_ptr... and naturally, those conversions (shown above) weren't going to happen...
Do loki pointers do intrusive reference counting? If so, you may have a friend in boost::intrusive pointer. If you look at the documentation on it, you'll notice this little ball of joy:
intrusive_ptr(T * p, bool add_ref = true);
Is _NOT_ marked explicit. This is perfectly legal:
some_object * foo = new some_object;
boost::intrusive_ptr< some_object > bar;
bar = foo;
Quote:It's just plain-as-the-nose-on-my-face DUMB to have a "smart pointer" act like anything other than a "pointer"
By that argument, it's dumb to have a pointer that automatically deletes what's pointed to once it goes out of scope. That is, it makes anything that looks like a pointer but isn't "DUMB". Thus, I disagree - the differences are what make smart pointers BETTER than raw pointers. If the goals focused on in a given implementation are not the same as your own, that's your problem.
The problem for you is that boost::shared_ptr is meant to be fairly lightweight. There's no hidden manager with a hash map of pointers - this will cause multiple deletion:
boost::shared_ptr< int > a ( new int );
boost::shared_ptr< int > b ( a.get() ); //Constructs B from a raw pointer.
The only time assigning a shared_ptr to a raw pointer makes sense IMHO is if you yourself are allocating it, in which since it makes more sense to never have a raw pointer in the first place. E.g. you don't do:
int * foo = new int;
...
boost::shared_ptr< int > bar( foo );
...
//here is where a programmer who skimming the code missed the decleration of bar, will think foo is being leaked, and thus add:
delete foo;
//here is where the program will delete foo a second time.
You do:
boost::shared_ptr< int > foo( new int );
...
boost::shared_ptr< int > bar( foo );
...
//here is where nobody will add delete foo, because they realize off the bat foo is a smart pointer.
Just adding some defence for shared_ptr. HTH, and again, try looking into intrusive_ptr. It's there for more reasons than just optimization, you know...
