The library definitely has to support C++11. The original choice for C++98 was motivated by maximum compatibility and the hope to be useful for many existing codes. Yet, backwards compatibility becomes more and more an issue, and I have the impression that many actively developed codes are using C++11 by now.
I consider the switch to C++11 a major change (from the user's perspective), which should be communicated clearly. Suggestion: move the current C++98 state to a side branch (which will be developed further or not, depending on the needs) and fully switch master to C++11. The C++98 branch could simply be called 0.9.x, and we add a note to the readme that a C++98 version exists. This would imply a number of changes to the code (which appear not so difficult), e.g., switching to properly deleted copy constructors.
As a benefit, we avoid cumbersome #if __cplusplus macros and mixed code.
The library definitely has to support C++11. The original choice for C++98 was motivated by maximum compatibility and the hope to be useful for many existing codes. Yet, backwards compatibility becomes more and more an issue, and I have the impression that many actively developed codes are using C++11 by now.
I consider the switch to C++11 a major change (from the user's perspective), which should be communicated clearly. Suggestion: move the current C++98 state to a side branch (which will be developed further or not, depending on the needs) and fully switch master to C++11. The C++98 branch could simply be called 0.9.x, and we add a note to the readme that a C++98 version exists. This would imply a number of changes to the code (which appear not so difficult), e.g., switching to properly deleted copy constructors.
As a benefit, we avoid cumbersome
#if __cplusplus
macros and mixed code.