c++ binding and C++11

[aconway <ac...@redhat.com>]

For the proton C++ binding there are a bunch of features in modern C++
(c++11) that are relevant (lambdas, std::function, threading and async
support etc. etc.) The binding to date is written to work with c++03.

In terms of strategy going forward I would like to suggest the
following: 

1. We keep a core binding (equivalent to what is there now) that works
with c++03. 

2. For new features beyond that, if c++11 provides a much better way to
solve the problem we should use it without attempting to retrofit a
solution for c++03 PROVIDED that you can still build the core binding
with c++03 (where extended features are in separate .hpp files or are
deleted by #ifdefs)

The idea here is to keep a usable binding for c++03 but not to tie
ourselves to the development cost of maintaining backwards compat for
every new feature in perpetuity. Of course we can change the policy if
there is a storm of protest from c++03 developers (or conversely drop
c++03 entirely if there isn't :)

Cheers
Alan.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: c++ binding and C++11

[Robbie Gemmell <ro...@gmail.com>]

On 5 October 2015 at 09:42, Gordon Sim <gs...@redhat.com> wrote:
> On 10/02/2015 10:19 PM, aconway wrote:
>>
>>
>> For the proton C++ binding there are a bunch of features in modern C++
>> (c++11) that are relevant (lambdas, std::function, threading and async
>> support etc. etc.) The binding to date is written to work with c++03.
>>
>> In terms of strategy going forward I would like to suggest the
>> following:
>>
>> 1. We keep a core binding (equivalent to what is there now) that works
>> with c++03.
>>
>> 2. For new features beyond that, if c++11 provides a much better way to
>> solve the problem we should use it without attempting to retrofit a
>> solution for c++03 PROVIDED that you can still build the core binding
>> with c++03 (where extended features are in separate .hpp files or are
>> deleted by #ifdefs)
>>
>> The idea here is to keep a usable binding for c++03 but not to tie
>> ourselves to the development cost of maintaining backwards compat for
>> every new feature in perpetuity. Of course we can change the policy if
>> there is a storm of protest from c++03 developers (or conversely drop
>> c++03 entirely if there isn't :)
>
>
> +1, makes sense to me!
>

Sounds like a reasonable approach to me (though adding disclaimer that
I have no idea what the differences between the versions actually
are..).

Robbie

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: c++ binding and C++11

[Gordon Sim <gs...@redhat.com>]

On 10/02/2015 10:19 PM, aconway wrote:
>
> For the proton C++ binding there are a bunch of features in modern C++
> (c++11) that are relevant (lambdas, std::function, threading and async
> support etc. etc.) The binding to date is written to work with c++03.
>
> In terms of strategy going forward I would like to suggest the
> following:
>
> 1. We keep a core binding (equivalent to what is there now) that works
> with c++03.
>
> 2. For new features beyond that, if c++11 provides a much better way to
> solve the problem we should use it without attempting to retrofit a
> solution for c++03 PROVIDED that you can still build the core binding
> with c++03 (where extended features are in separate .hpp files or are
> deleted by #ifdefs)
>
> The idea here is to keep a usable binding for c++03 but not to tie
> ourselves to the development cost of maintaining backwards compat for
> every new feature in perpetuity. Of course we can change the policy if
> there is a storm of protest from c++03 developers (or conversely drop
> c++03 entirely if there isn't :)

+1, makes sense to me!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org