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. |
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. > |
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. > > > |
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. > > > > > > |
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. > > > > > > > > > > |
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 |
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 > > |
Free forum by Nabble | Edit this page |