Thank you for your response.
I'd prefer to move to C++17. Since it is already 4 years old and most compilers
support it well: C++ compiler support - cppreference.com.
In order to maintain backwards compatibility with the clients, some good
features cannot be used. For example, use of type-safe enums will break the
current clients. Still, it will be very bad if we break backwards compatibility
and require the clients to change the usage. It'll be nice if we make the only
new restriction to be a compiler supporting C++17. I'll be very careful while
changing header files.
I think it will be hard to maintain binary compatibility. But we can offer
"source-level" compatibility. That is, the the user should be able to compile
with the new version of Avro library without requiring any change to their code.
Thanks
Thiru
|
|
|
| | |
|
|
|
| |
C++ compiler support - cppreference.com
|
|
|
On Monday, 1 February, 2021, 11:53:40 am IST, Ismaël Mejía
<[email protected]> wrote:
That's excellent news!
I was just wondering which version of C++ should we target?
Also what are the consequences for our users? I mean do you plan to
keep a backwards compatible public API so users of an older version
can still be able to link with it, or do you plan to use 'new C++
features' there, or in other words is it full modernization also the
target?
On Mon, Feb 1, 2021 at 6:46 AM Thiruvalluvan MG
<[email protected]> wrote:
>
> Hi all,
> In the past 10+ years C++ has evolved to be a very new (and much better)
> language, still maintaining compatibility with the old. Some call it "Modern
> C++". Avro C++ implementation is still mostly in C++03 era.
> I'm planning to send a series of patches to C++ implementation to use the
> modern features.
> Please let me know if there are any concerns.
> Thank you,
> Thiru
>
