Brane, Thanks for clarifications, I mistakenly thought that smart pointers were introduced only in C++11. If they are already in C++03 of course we should take advantage of them.
On Wed, May 20, 2015 at 12:08 PM, Branko Čibej <br...@apache.org> wrote: > On 20.05.2015 09:47, Vladimir Ozerov wrote: > > I do not think we will sacrifice anything. C++11 has lots new features > such > > as smart pointers and lamdas, but I do not see where we can use them on > our > > public API. > > I would definitely recommend using C++03 (or C++98; the only differences > are in the standard library). I would also very strongly recommend not > depending on Boost unless it's absolutely unavoidable: Boost is lovely > if you need it, but a huge albatross around the neck if you don't. > > C++03 is C++98+TR1 and does have both std::shared_ptr and std::weak_ptr > whereas C++98 does not. Both have smart pointers (std:auto_ptr is a > smart pointer). > > Note that C++98/03 is not completely source-compatible with C++11. You > have to be very aware of that. For example: > > #define X " world" > "Hello"X; > > > is valid C++98 (and valid C as well), but not valid C++11 where the X is > interpreted as a custom string suffix. So in order to maintain forward > compatibility, you have to write > > "Hello" X; > > > instead. This can be extremely painful to do in legacy code. > > > For example, both Hazelcast and GigaSpaces has the following API for > cache > > GET: > > boost::shared_ptr<MyVal> val = cache<MyKey, MyVal>.get(); > > Ahem. This is not valid C++. > > > Boost contributed smart poitners to C++11 > > To C++03. > > > and we can implement it as > > follows now: > > std::shared_ptr<MyVal> val = cache<MyKey, MyVal>.get(); > > > > I.e., with pure C++11 and no dependency on Boost. But in my opinion > > returning smart pointer from cache GET doesn't add any value comparing to > > returning unmanaged pointer, which user can wrap into smart pointer later > > if he really needs it: > > MyVal* val = cache<MyKey, MyVal>.get(); > > And this is a memory leak. You can't just wrap a raw pointer in a shared > pointer and go happily coding, expecting that you've got your memory > problems solved. Let's say you do this: > > std::shared_ptr<MyVal> smartval(val); > > * When smartval goes out of scope, it deletes the value, making the > reference inside the cache invalid. > * When the value is ejected from the cache, smartval's pointer becomes > invalid. > > > Either return by value, or return a smart pointer: a constant shared_ptr > if you're returning references to objects in the cache, or either > auto_ptr or shared_ptr if you're returning copies allocated on the heap. > Anything else is an accident waiting to happen. > > > I think having less dependencies and greater backward compatibility > > outweight features like this. > > Having working code outweighs having more dependencies any day. And I'm > already extremely happy that I won't have to review, fix or use that C++ > code. :) > > -- Brane > >
