ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Choosing C++ version for interop.
Date Wed, 20 May 2015 09:08:45 GMT
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"

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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message