More C++ feature backporting?


#1

Any plans in backporting some more of the various C++11 (and up) features, such as constexpr and new type traits stuff?

I've wrapped my own version of to std::remove_cv/const/volatile/pointer/reference, mostly for writing custom allocators, but figure if JUCE had it - I nor anybody else here would need to write their own version... Can share it if you (Jules and Co.) got a place for it.

With that, I'm sure there are good uses for finding out types of things at compile time.

Note, slightly unrelated: I noticed that JUCE_COMPILER_SUPPORTS_OVERRIDE_AND_FINAL doesn't define final if it doesn't exist.


#2

Yes, we might add a handful of extra bits and pieces, though TBH there's not too much C++11 syntax that we need in the library itself right now, and if people are working on their own projects that use modern compilers, then they can just use real C++11 directly in their own code. (We use it for all our non-public projects).


#3

If you need C++11 features for non-C++11 compilers in your project, then Boost is your friend! It has practically everything, including boost::remove_cv etc. Most of the new stuff in the C++11 standard library evolved from Boost actually ;-)

Also, I don't quite understand why you would want  JUCE_COMPILER_SUPPORTS_OVERRIDE_AND_FINAL to define final for a compiler that doesn't support the actual final keyword functionality? (and what would you expect to define it to?)


#4

You would define final as nothing, the final and override keywords do nothing for the compiled code they are simply helper keywords really. This way the code can be compiled both on a compiler that supports the keywords and one that doesn't. Also as JUCE defines 'override' as nothing  #if ! JUCE_COMPILER_SUPPORTS_OVERRIDE_AND_FINAL, then why not also define 'final' as nothing? I realise the final keyword isn't used throughout the JUCE library but there are cases where developers generally compile using a compiler that copes with these keywords (therefore they can be useful) but they may also need to build using a compiler that does not fully support them, so stipping them out by defining final as nothing goes a small way to helping the developer compile the code without error. I can't see any harm in this.
 


#5

Anthony Nicholls hit the nail on the head.

I'm well aware of C++11 features being lifted from Boost, but TBH, linking boost for very few features is not worth the effort, and I would much prefer a minimalistic approach to my projects - so, no thanks.


#6

using templates for Juce's FFT would be nice, hopefully moving some logic to compile-time.

-- p