Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
30 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to General and Gameplay Programming

Redeeming qualities of auto_ptr?

Started by
30 comments, last by Emmanuel Deloget 17 years, 1 month ago
Quote:Original post by MaulingMonkey
Quote:Original post by Sneftel
Quote:Original post by Replicon
I'd call it 'dangerous' before 'strange' though, and depending on where the issue is encountered, it can yield behaviour that is very... misdirecting?

I wouldn't call it dangerous. Dangerous is something that works 98% of the time, or 100% on your particular computer and 50% on other people's, etc. Something that never works is easy to detect, and something that's easy to detect is easy to fix.


It's no weapon of mass conternation, but it is still dangerous to one's time in the hands of the underinformed or the mentally disturbed. It's unlocked, implicit behavior, also sets dangerous precident in terms of interface design to the impressionable.

I look forward to the implementation of std::unique_ptr as a sane, complete replacement of std::auto_ptr, which I've had reason to use in some scenarios.


Quote:Goooooooooooogle
Your search - std::unique_ptr - did not match any documents.


:( References (pun intended) please?

@Julian: Interesting. I'll play around with it and see if it works, and if it's possible to get rid of the extra pointer. :)
Advertisement
Zahlman:

Quote:Original post by Sharlin
Fortunately, C++0x will allow us to replace auto_ptr with the goodness that is unique_ptr.


;P
Quote:Original post by Sharlin
Zahlman:

Quote:Original post by Sharlin
Fortunately, C++0x will allow us to replace auto_ptr with the goodness that is unique_ptr.


;P


Further:

Google Search: unique_ptr (about 468 results)
Oh, wait, I just remember: if you need to perform a deep copy of an object, why do you store it in a smart pointer anyway (as opposed to, say, keep an instance of the object)? That sounds weird. If your concern is about stack memory vs. heap memory, one can easily create objects that stores data on the heap, while the object themselves are on the stack (the way std::vector works).

So: what would be a typical use of such feature? (let's call it copyable_ptr<>)
-- Emmanuel D. [blog, in French] [blog, very bad googlized translation]
Quote:Original post by Emmanuel Deloget
Oh, wait, I just remember: if you need to perform a deep copy of an object, why do you store it in a smart pointer anyway (as opposed to, say, keep an instance of the object)?


This was already asked:

Quote:Original post by Zahlman
Quote:Original post by jpetrie
Perhaps I'm misunderstanding the functionality you want, but why not just use a non-pointer if you need operator= to "copy the thing?"


Polymorphism, Pimpls, virtual clone idiom etc. (If you can standardize the name of the clone() function, it should be possible to use SFINAE introspection to make use of it?)
Quote:Original post by Nitage
Quote:
The question: Does auto_ptr have ANY redeeming properties, that would excuse it and make it worthy of being in the standard still? Once std::tr1 goes out, and all the "boost::*_ptr" stuff ends up being part of it, will there be ANY reason at all to ever use auto_ptr? Will it stay in the standard for any reason other than backwards compatibility?

Yes. It implements transfer of sole-ownership semantics, which none of the boost ptrs offer.


Nitpick: All of boost::*_ptr<T> implement boost::*_ptr<T>::swap( ... ), which is bidirectional transfer of ownership. None of them have unidirectional (aka uncompensated theft) transfer-of-ownership semantics though.
Quote:Original post by MaulingMonkey
Quote:Original post by Emmanuel Deloget
Oh, wait, I just remember: if you need to perform a deep copy of an object, why do you store it in a smart pointer anyway (as opposed to, say, keep an instance of the object)?


This was already asked:

Quote:Original post by Zahlman
Quote:Original post by jpetrie
Perhaps I'm misunderstanding the functionality you want, but why not just use a non-pointer if you need operator= to "copy the thing?"


Polymorphism, Pimpls, virtual clone idiom etc. (If you can standardize the name of the clone() function, it should be possible to use SFINAE introspection to make use of it?)


I had some kind of reading deficiency yesterday. I guess this was partly due to the Chianti I drank earlier...
-- Emmanuel D. [blog, in French] [blog, very bad googlized translation]
Quote:Original post by Emmanuel Deloget
I had some kind of reading deficiency yesterday. I guess this was partly due to the Chianti I drank earlier...


That would do it ;-)
incase anyones interested heres the final copy_ptr that i came up with
template<typename BaseType>struct copy_ptr;template<typename BaseType>struct copyable_base{private:    friend struct copy_ptr<BaseType>;    virtual copyable_base<BaseType>* clone() = 0;};template<typename BaseType, typename T>struct copyable : public T, public copyable_base<BaseType>{    copyable(T* ptr) : T(*ptr) { }private:    copyable_base<BaseType>* clone()    {        return new copyable(*this);    }};template<typename BaseType>struct copy_ptr{    template<typename T>    copy_ptr(T* ptr): ptr(new copyable<BaseType, T>(ptr))    { }    copy_ptr(copy_ptr<BaseType> rhs)    {        delete ptr;        ptr = rhs.ptr->clone();    }    template<typename T>    copy_ptr<BaseType>& operator=(T* rhs)    {        delete ptr;        ptr = new copyable<BaseType, T>(rhs);        return *this;    }    copy_ptr<BaseType>& operator=(copy_ptr<BaseType> rhs)    {        delete ptr;        ptr = rhs.ptr->clone();    }    BaseType& operator*()    {        return *ptr;    }    BaseType* operator->()    {        return ptr;    }private:    copyable_base<BaseType> ptr;};


Enjoy :)
Random Link
Quote:Original post by Julian90
incase anyones interested heres the final copy_ptr that i came up with
*** Source Snippet Removed ***

Enjoy :)


Shouldn't that be
template<typename BaseType, typename T>struct copyable : public T, public copyable_base<BaseType>{    copyable(T* ptr) : T(*ptr) { }private:    copyable_base<BaseType>* clone()    {        return new copyable(this); // remove "*"    }};

I'm not particularly fond of this design. I would have prefered composition instead of heritance in this case - because the effect you introduce prevent you to use inherited classes of T (for example, in a copy_ptr_dynamic_cast<>() function that would have roughly the same effect than the tr1::shared_ptr one).
-- Emmanuel D. [blog, in French] [blog, very bad googlized translation]

This topic is closed to new replies.

Advertisement

Popular Topics

Aybe One
How do you manage yourself and your time as years pass on? GDNet Lounge
Jikoob
Too many managers? General and Gameplay Programming
ReignOnU
Do your part to stop global warming and climate change GDNet Lounge
aigan
The promise of freedom in story games Game Design and Theory
robertrobert
Facebook Ads for sales on steam, does it work? Games Business and Law
AliAbdulKareem
Understanding the wavy-like shape in alpha-testing magnification for text rendering Graphics and GPU Programming
Advertisement

Recommended Tutorials

Myopic Rhino
Postmortem: Heretic II Game Design and Theory
Myopic Rhino
Direct3D 9.0 with Allegro General and Gameplay Programming
Unlock Audio
Altering Ambience Character & Intensity using FMOD Music and Sound FX
Gaiiden
Autodesk Previews a Games Production Solution Visual Arts
GameDev.net
OpenGL 4.0: Using Uniform Blocks and Uniform Buffer Objects Graphics and GPU Programming

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top