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
