# dumb things about smart ptrs [rant]

This topic is 4810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

These should be standard for ALL smart pointer types:
// should be valid for every type of smart ptr!!
SmartPointerType<T> ptr = new T();

// so should this!

void fn(SmartPointerType<T> &ptr);

.
.
.

fn(new T());


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]

##### Share on other sites
Quote:
 Original post by Verg// so should this!void fn(SmartPointerType &ptr);...fn(new T());

Erm no, even if the constructor was not declared explicit you should never assign a literal or temporary to non-constant reference infact most modern C++ compilers prevent compilation if you try to do so.

Quote:
 Original post by VergThe above is how Loki::SmartPtr currently works; but (apparently) none of the boost smart ptr classes operate this way.....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. >:-(

Then i would consider it a flaw of Loki's smart pointer, the reason why boost's smart pointers (even std::auto_ptr does too) have explicit constructors is to enforce RAII & exception safety, read this to understand the danger you cannot prevent no matter how careful you are, also read the boost::shared_ptr "Best Practices" section of this for further insight.

##### Share on other sites
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!

##### Share on other sites
[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.

##### Share on other sites
Quote:
 Original post by VergThe "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].

Quote:
 Original post by VergI say "gimme the garbage collection", and let me hang myself with that rope!

Knock yourself out Hans-Boehm's Garbage collector for C and C++, another alternative you could use C++/CLI instead.

##### Share on other sites
Quote:
Original post by snk_kid
Quote:
 Original post by VergThe "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]

##### Share on other sites
Quote:
 Original post by Vergsnk_kid; this probably gets your blood boiling, then [censored for evilness]

[flaming]

[lol]

##### Share on other sites
[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]

##### Share on other sites
Quote:
Original post by snk_kid
Quote:
 Original post by Vergsnk_kid; this probably gets your blood boiling, then [censored for evilness]

[flaming]

[lol]

lmao

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

Smart pointers use this method for very good reasons.

1. 1
2. 2
3. 3
4. 4
frob
15
5. 5

• 12
• 12
• 20
• 12
• 13
• ### Forum Statistics

• Total Topics
632152
• Total Posts
3004466

×