you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time.
Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release.
5) Initial support for C++11/14
This package includes an initial implementation of the C++11/14 proposal,
presented at DVCon Europe 2016 ("Moving SystemC to a new C++ Standard").
This includes the addition of two new preprocessor symbols:
- IEEE_1666_CPLUSPLUS (read-only)
This symbol indicates the availability of certain SystemC features
which depend on a particular version of the ISO C++ standard (see below).
- SC_CPLUSPLUS (overridable)
By default, the most recent supported version of the C++ standard for the
current platform/compiler is automatically detected and reflected by the
Users can override (i.e. usually downgrade) the assumed C++ standard to an
earlier version for compatiblity. The value of this macro has to be set
consistently across the SystemC library build and all linked models
The values of these macros follow the values defined by the C++ standards.
Currently supported versions are:
- 199711L (C++03, ISO/IEC 14882:1998, 14882:2003)
- 201103L (C++11, ISO/IEC 14882:2011)
- 201402L (C++14, ISO/IEC 14882:2014)
The following features currently require a dedicated C++ standard version
beyond ISO/IEC 14882:2003 (aka C++03):
- C++11 (IEEE_1666_CPLUSPLUS==201103L)
o explicit sc_bitref_r<>::operator bool() const
Restricts direct boolean conversion of bitvector element references
to explicit boolean contexts (e.g. `if` expressions).
Use the `to_bool()` function on earlier setups.
In the future, further language features depending on modern C++ language
constructs may be added.
* SC_CPLUSPLUS -
Override automatically detected C++ standard support
This setting allows downgrading the assumed version of the
underlying C++ standard on the current platform. By default,
the latest supported version is chosen.
Supported values are
* SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003)
* SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011)
* SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014)
Note: This symbol needs to be consistently defined in the library
and any application linking against the built library.
Especially the last note in the RELEASENOTES is relevant to your question:
In order to reduce the complexity of all the different C++ language support differences across compiler versions, the LWG decided to at least enforce a consistent selection of the C++ baseline in the proof-of-concept implementation. Of course, other vendors may chose to allow more flexibility here, although sometimes even a consistent compiler version selection is mandated.
With this decision, the implementation does not have to worry about binary compatibility across different (C++ standard dependent) feature sets in the future. As of today, the (currently internal) classes sc_type_index, sc_string_view differ depending on the platform's C++ standard support. Future extensions might change other classes as well. Not worrying about the ABI compatibility is a helpful simplification here.
As described above, you can set -DSC_CPLUSPLUS=... consistently on the compiler command-line to build a single library build across several GCC versions. If supported by your platform/compiler, you can still use the different -std=c++XY flags (or their defaults) from the compilers, provided that they generate compatible code across the selected C++ standard version.
Hope that clarifies the rationale behind the current implementation.
Greetings from Duisburg,