Choosing C++ version for interop.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Choosing C++ version for interop.

Vladimir Ozerov
Igniters,

We need to decide which C++ version to use in interop. Currently wide
developer community is in progress of adopting C++11. But if we choose it,
users might have problems if their CPP projects using older C++ revisions
which are still very common.

I think we should stick to C++03 revision for now. Thoughts?

Vladimir.
Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

dsetrakyan
On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> We need to decide which C++ version to use in interop. Currently wide
> developer community is in progress of adopting C++11. But if we choose it,
> users might have problems if their CPP projects using older C++ revisions
> which are still very common.
>
> I think we should stick to C++03 revision for now. Thoughts?
>

If we stick to this version, what are the consequences for users who run
C++ 11?


>
> Vladimir.
>
Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

Vladimir Ozerov
C++11 users can use C++03 projects, but not vice-versa.

On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > We need to decide which C++ version to use in interop. Currently wide
> > developer community is in progress of adopting C++11. But if we choose
> it,
> > users might have problems if their CPP projects using older C++ revisions
> > which are still very common.
> >
> > I think we should stick to C++03 revision for now. Thoughts?
> >
>
> If we stick to this version, what are the consequences for users who run
> C++ 11?
>
>
> >
> > Vladimir.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

dsetrakyan
On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov <[hidden email]>
wrote:

> C++11 users can use C++03 projects, but not vice-versa.
>

Are we sacrificing any features? (sorry, my C++ knowledge is limited).


> On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Igniters,
> > >
> > > We need to decide which C++ version to use in interop. Currently wide
> > > developer community is in progress of adopting C++11. But if we choose
> > it,
> > > users might have problems if their CPP projects using older C++
> revisions
> > > which are still very common.
> > >
> > > I think we should stick to C++03 revision for now. Thoughts?
> > >
> >
> > If we stick to this version, what are the consequences for users who run
> > C++ 11?
> >
> >
> > >
> > > Vladimir.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

Vladimir Ozerov
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.

For example, both Hazelcast and GigaSpaces has the following API for cache
GET:
boost::shared_ptr<MyVal> val = cache<MyKey, MyVal>.get();

Boost contributed smart poitners to C++11 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();

I think having less dependencies and greater backward compatibility
outweight features like this.

On Wed, May 20, 2015 at 10:28 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > C++11 users can use C++03 projects, but not vice-versa.
> >
>
> Are we sacrificing any features? (sorry, my C++ knowledge is limited).
>
>
> > On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> > > On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov <
> [hidden email]>
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > We need to decide which C++ version to use in interop. Currently wide
> > > > developer community is in progress of adopting C++11. But if we
> choose
> > > it,
> > > > users might have problems if their CPP projects using older C++
> > revisions
> > > > which are still very common.
> > > >
> > > > I think we should stick to C++03 revision for now. Thoughts?
> > > >
> > >
> > > If we stick to this version, what are the consequences for users who
> run
> > > C++ 11?
> > >
> > >
> > > >
> > > > Vladimir.
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

Branko Čibej
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

Reply | Threaded
Open this post in threaded view
|

Re: Choosing C++ version for interop.

Vladimir Ozerov
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 <[hidden email]> 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
>
>