These should be standard for ALL smart pointer types: The above is how Loki::SmartPtr currently works; but (apparently) none of the boost smart ptr classes operate this way. 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() !! 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. 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. --- The reason I'm b!tching 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... --- Looks like we'll have to (temporarily) use pure, bald pointers for our functor objects now; and we'll have to delete them the old fashioned way [rolleyes] ---- It's just plain-as-the-nose-on-my-face DUMB to have a "smart pointer" act like anything other than a "pointer", or to require special handling and methods be used with it... it may as well be another class in the heirarchy if a smart pointer is going to be so intrusive on the code... Everywhere that normal pointer conversions take place in an application, if you want to convert to boost::shared_ptr, must now use "reset()" or use the services of a temporary shared_ptr, so that an assignment can be made. ---- I realize there are those who probably feel just as strongly the other way about Boost's smart pointers; just had to get it off my chest [smile]

my_life:          nop          jmp my_life

The "best practices" explain that if you do this:

void fn(new PointedAt(), blah blah blah...)

that a compiler won't necessarily evaluate "new PointedAt()" first, and "blah blah blah" might throw... in which case, the "new PointedAt()" would not get evaluated.

Fine.

Bald pointers are dangerous if you don't know what you're doing. If you do know what you're doing, you should be allowed to do so. Crippling a "smart pointer" because somebody may misuse it is a dumb thing to do, IMO.

I say "gimme the garbage collection", and let me hang myself with that rope!

my_life:          nop          jmp my_life

[smile]

Oh, and as far as the memory leaking in the examples you gave...

... constructors are going to fail now and again. As far as I'm concerned, that has nothing to do with my ugly little pointer objects [smile]

---

snk_kid; this probably gets your blood boiling, then

vector<T *> v;

v.push_back(new T());

[grin]

But I see that all the time.

my_life:          nop          jmp my_life

Quote:Original post by snk_kid

Quote:Original post by Verg
The "best practices" explain that if you do this:

void fn(new PointedAt(), blah blah blah...)

that a compiler won't necessarily evaluate "new PointedAt()" first, and "blah blah blah" might throw...

Somebody is having a bad day today [lol].

Just feeling a little arch.

Or is it "dodgy"? That's a cool Brit word

[wink]

Thanks for your replies.

my_life:          nop          jmp my_life

[razz]

Really the point of this thread is that...

pointers can be (by their nature) dangerous;

I guess we just need to define "how" smart we want our pointers?

Do we want absolutely no chance of anything going wrong? Or would we be willing to trade some of the more stiff "safety" features for functionality? That's why the opinion on smart pointers... make 'em like reg'lar pointers with garbage collection.

That's why Loki's approach appeals; you can define policies for your smart pointers and pretty much have your own way.

(naturally, others will prefer the higher safety of "boost's" pointers)

...

Trouble is (on a personal note)... Loki's on the operating table right now... :-/

Oh well. Bald pointers for all!

[smile]

my_life:          nop          jmp my_life

Quote:Original post by snk_kid

Quote:Original post by Verg
snk_kid; this probably gets your blood boiling, then

[censored for evilness]

[flaming]


[lol]

lmao

my_life:          nop          jmp my_life

Sorry Verg, I'm afraid that you're missing the point on this one [smile].

Smart pointers use this method for very good reasons.