Le 15/03/2016 09:52, paul Fultz a écrit :
On Tuesday, March 15, 2016 2:59 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
I was wondering if Boost.Fit shouldn't be a library as Boost.Hana,
a library that makes use of the last C++ version and avoids as much portability issues as possible.
I think portability is important, especially for a boost library. And since there is already Hana, I think there is room for a portable library, as well.
I can understand your portability need. However I believe that we should raise the bar in Boost.
Which C++14 features will make the library simpler? There really isn't any C++14 features that would simplify the library.
Which C++11 features are needed and missing on some C++11 compilers? has the last C++11 version of those compilers fixed the issues?
Which adopted C++17 features will make the library simpler? Inline variables and constexpr lambdas will help simplify the static function macros. Also, fold expressions might be useful as well.
Do you mind to elaborate how inline variables could help?
Which other C++ features would be missing? Well, it doesn't need features, whats really missing is better diagnostics from the compiler.
Would Concepts help here or is there something else?
Paul I guess that you are using a C++11 compiler and want to support this version, could you confirm?
Yes I am. Furthermore, there may be other library authors who would like to utilize the functionality in Fit, that may need the same level of portability as well. So they would have to rewrite some of whats done in Fit if I were to due away with portability, which kind of defeats the purpose of reusability with a library.
If you need a C++11 library, which compilers/versions do you want to support that need workarounds?
Also, the work for portability has already been done, so it seems foolish to just throw it away. I don't think portability is hugely detrimental to the library. It is important to note that the ideal solution is chosen on the better compilers(which is usually clang). Furthermore, I plan to take advantage of C++17 features in the library when they become ready as well.
My concern was that there were some comments, something like "there are too much macros in the implementation". From my bad experience (with Boost.Chrono/Thread), I really believe that we should provide libraries for compilers supporting a specific C++ version. Adding workarounds doesn't help on the long run and could give a false impression of portability. I can understand however that you want it with old compiler versions, as not anyone can upgrade to compilers supporting more recent versions. Vicente