if i'm building library assume "clients" of library may using c++11, can compile library using c++14 internals? there api/abi/link compatibility issues versus c++11? safe implement , build library c++14 long avoid new features in public api, , if so, must avoid? or inherently incompatible mix c++11 , c++14 within final software project?
it's cross-platform library, btw, i'll need build on linux, osx, , windows.
if i'm building library assume "clients" of library may using c++11, can compile library using c++14 internals?
yes, in general should possible.
i gcc's implementation of filesystem ts. <experimental/filesystem>
header written in pure c++11 , can included c++11 clients, implementation in libstdc++fs.a
written in c++14.
are there api/abi/link compatibility issues versus c++11?
there no changes between c++11 , c++14 require implementations break link-time compatibility. doesn't mean implementations won't break it, aren't required to.
for gcc believe c++11 , c++14 entirely api , abi compatible, except constexpr
, sized-deallocation issues mentioned below.
is safe implement , build library c++14 long avoid new features in public api, , if so, must avoid?
it depends on compiler, in theory it's possible.
obviously avoid c++14 language features aren't valid in c++11 (such function return type deduction, or generic lambdas auto
parameters, or variable templates) , c++14 library entities, std::make_unique
, std::integer_sequence, or
std::shared_timed_mutex`.
a list of changes in c++14 can found in sd-6.
one thing watch out meaning of non-static constexpr
member function changed between c++11 , c++14. in c++11 member function const
:
struct x { constexpr int foo(); };
in c++14 non-const. compatible both c++11 , c++14 should explicitly qualify const
:
struct x { constexpr int foo() const; };
that means same thing in both c++11 , c++14.
another caveat in c++11 , c++14 operator means different:
void operator delete(void*, std::size_t);
if c++11 client code defines function library compiled in c++14 could end calling instead of usual operator delete(void*)
, presumably wrong thing. probably uncommon , not problem in real code, it's possible. g++ , clang allow compile c++14 code -fno-sized-deallocation
disable new feature, c++14 library code never call version of operator delete
.
Comments
Post a Comment