Skip to main content
gamedev.net
🔒 Locked

C++ shared pointer idea

Started by Lode Mar 25, 2009 at 8:44 AM 6 replies 1.6k views
Original Post
Lode
Lode
boost:shared_ptr works pretty great and will soon be in C++0x. But, the notation of it is quite clumsy. And typedeffing them helps but is also clumsy. Since shared_ptr's are so generally useful, wouldn't it be great if they got their own symbol, like a regular pointer has "*". E.g. say the symbol is "#". Then you'd type std::string# s, instead of boost::shared_ptr s. Or something like std::vector objects, looks very nice too. And, instead of a lot of template code in header files doing all the work, the compiler itself could define the implementation. What do you think of this idea? What holds them back from putting something like this in C++0x?
Homepage | LodePNG
alvaro
alvaro
I think the language already has too many symbols that one has to learn, some of which are very confusing. You can often use either a pointer or a reference, and the notation is quite tricky. If we add shared pointers as an extra language-supported construct with its own operators, it will make things even harder for beginners. It would also hide the fact that the shared pointer is an actual non-trivial object, with its potential performance issues.

I'd much rather see std::string become part of the language, so "Hello, world!" stops having type `char *' (which is sooo wrong).
chairthrower
chairthrower
Microsoft's implementation sort of does this for CLI with ^ indicating a reference to a memory resource that is managed by the CLR runtime - it's slightly better than their prior MC extensions that overloaded the ordinary pointer declarator *.

I've not really investigated, but I think c++nn proposes templated typedefs which should ease notion a bit.

I once speculated what a c++ would look like without any raw pointer stuff available globally. The idea being that you would have to request the namespace to get access to low level c style memory manipulation/ pointer arithmetic - perhaps a bit like the detail namespace which is used to hide the ugly or dangerous stuff. Otherwise shared_ptr is a good default, but I am not sure that it warrant's specialised syntax.
phresnel
phresnel
Quote:
Original post by chairthrower
I've not really investigated, but I think c++nn proposes templated typedefs which should ease notion a bit.


How exactly would template typedefs make shared_ptr<> "easier" to use?

edit: I guess I know what you meant. You can also use inheritance to emulate template typedefs at least a bit, but this is not really needed for shared_ptr<>:

// using usingnamespace my_namespace {    using boost::shared_ptr;}// using template typedef emulation// (we have to implement those constructors carefully)namespace my_namespace {        // shared_ptr        template <typename T>        struct shared_ptr : boost::shared_ptr<T> {                // Assimilate constructors.                shared_ptr ()                        : boost::shared_ptr<T> () {}                                explicit shared_ptr (T * v)                        : boost::shared_ptr<T> (v) {}                                shared_ptr (shared_ptr const & v)                        : boost::shared_ptr<T> (v) {}                // The rest is okay via derivation.        };}


Note that the workaround solution is cheap w.r.t. performance, from -O2 on GCC will emit code that is exactly the same for both my_namespace::shared_ptr<> and boost::shared_ptr<>. (other pointers here)
Sneftel
Sneftel
I've long thought that the best solution would be to remove * as a type descriptor, or at least hide it:

void strcpy(char * dest, const char * src);
becomes
void strcpy(ptr dest, const_ptr src);

Basically, removes the one-ish remaining parameterized type that isn't parameterized using templates.
demonkoryu
demonkoryu
I have the idea of a code editor that allows you to define such syntax transformations so that the underlying source file contains shared_ptr, while you type and see XXX#. I was working on a prototype for such an editor, but got distracted with web dev lately. Implementing this should not be a big deal, however most interesting "next-generation" editor projects I'm observing aren't making much progress (e, Intype, Sublime) lately and noone has done something like this AFAIK. [rolleyes] But it should be easy to do this yourself on editors that allow running filter programs on load/save.
phresnel
phresnel
Quote:
Original post by Konfusius
I have the idea of a code editor that allows you to define such syntax transformations so that the underlying source file contains shared_ptr, while you type and see XXX#. I was working on a prototype for such an editor, but got distracted with web dev lately. Implementing this should not be a big deal, however most interesting "next-generation" editor projects I'm observing aren't making much progress (e, Intype, Sublime) lately and noone has done something like this AFAIK. [rolleyes] But it should be easy to do this yourself on editors that allow running filter programs on load/save.


OT: I once though about implementing a sort of preprocessor that would make any variable and member function const by default, and non-const entities would have to be declared explicitly (this would make c++ pretty much a static single assignment language, with the exception of explicit mutables). To be honest, I still think about that approach. (sidenote: there is already a static single assignment variation of the c programming language).
Zahlman
Zahlman
Quote:
Original post by Lode
What do you think of this idea? What holds them back from putting something like this in C++0x?


std::string# x, y; // oops, y is a std::string


If anything, I'd rather see a move in the other direction, with a standard template for a "normal" pointer. (Maybe it could implement range checking, by having a constructor that accepts an array-reference to the pointed-into array, etc.)

Edit: Yeah, like Sneftel said.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.