turtle icon indicating copy to clipboard operation
turtle copied to clipboard

Roadmap for C++14

Open Flamefire opened this issue 6 years ago • 4 comments

Are there any plans for C++11/C++14 inside the framework? I believe quite some trickery and macros can be removed which makes the code cleaner to understand and use. Furthermore override and noexcept shall be supported too (see #49) which is hard to impossible without raising the minimum requirements.

We recently switched to C++14 too and most of the boost code used basically vanished and code is now easier to read an test.

Suggestion:

  • Mark the current state as a release with C++98 compatibility
  • Declare C++11 or 14 as minimum requirement (IMO most compilers used for C++11 also support C++14 as this is a rather small step but reduces a lot of boilerplate [e.g. std::trait_t instead of typename std::trait::type])
  • Remove workarounds and boost usages used for compatibility

Flamefire avatar Jan 19 '19 12:01 Flamefire

I wouldn't mind moving to C++14, but I really don't have the time or opportunity to handle this myself (I don't work with C++ anymore). Of course if you or anyone were to open pull requests, I'll be happy to merge them :)

mat007 avatar Jan 22 '19 09:01 mat007

I'd like to create a bulk PR moving from Boost compatibility stuff like Boost.Move, Boost.SmartPtr, Boost.Bind to the C++11 versions to reduce dependencies especially as Boost 1.73 throws warnings with current usage of Boost.Bind. To not waste any effort: In what granularity do you want the PR(s)? It is mostly a Search&Replace so I'd put everything that can be done by S&R into 1 PR, likely in different commits per Boost lib. Is that fine?

Oh and: C++11 or C++14? See above for mostly typename boilerplate. I wouldn't use to much C++14 to keep MSVC happy but the alias-usings of the stdlib are very nice to have and supported by VS for ages (MSVC 2015 IIRC, maybe 2013)

Flamefire avatar Jul 04 '20 10:07 Flamefire

Yes I think both are fine: C++14 and one PR.

Thanks for doing this!

mat007 avatar Jul 04 '20 10:07 mat007

While doing this I came upon the format/serialize/stream stuff (log.hpp, stream.hpp, format.hpp) There are many functions and they still don't cover everything. An alternative would be to use a single operator<< for the stream which forwards to a trait class which can be specialized by users. Like template<class T> struct serialize{ stream& serialize(const T&); }; and a macro to help implement this. This would allow collapsing every collection (begin and end members) into a single specialization This can't be done with functions because it would lead to ambiguous ones due to the catch-all template template< typename T > void serialize( stream& s, const T& t )

Not sure if it is worth it, just wanted to mention it to not forget

Flamefire avatar Jul 11 '20 12:07 Flamefire