ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Choosing C++ version for interop.
Date Wed, 20 May 2015 09:57:26 GMT
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 <brane@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
>
>

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