Selection of a newer C++ version for a software build variant with CMake
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Menu
▾
▴
I have tried something out for the Cppcheck software once more. I would like to use functionality like “
std::make_unique” which is supported by the version “2014” of the programming language “C++”. Thus I tried to specify corresponding compilation parameters for the build system generation by the tool “CMake 3.12.0-1.1”.But I noticed then that compilation commands were constructed which contain the parameter “
std=gnu++11” at the end. Now I wonder about the source for this specification and I hope that such a setting can be omitted somehow.How do you think about to use a different build configuration there occasionally?
I want it to be possible to compile cppcheck on old systems. There are lots of users that run Cppcheck on old systems.
The current requirements are:
* gcc 4.6
* msvc 2013
Can you use std::make_unique on a system that is 5-7 years old? With those C++ libraries that existed at that time.
I recently updated the requirements so we will likely have those requirements for a few years.
Such an expectation is generally fine.
This class template could eventually be provided in special development versions.
How do you think about to use an alternative smart pointer implementation like “
QScopedPointer” instead?(A software build option could offer the selection between these programming interfaces.)
std=gnu++11” can be set in a build variable by a script like “/usr/share/cmake/Modules/Compiler/GNU-CXX.cmake”.Would you like to clarify the circumstances any further around the position of such a setting within the parameter list for the desired compilation command?
I would say it's ok to use QScopedPointer in the GUI but not in the CLI. I am not sure if I want to use an alternative implementation since there is a standard method coming..
Where would you use shared pointers? Do you have an example? I don't see an obvious usage for it.
Under which circumstances will you get into the mood to reactivate my account for your issue tracker so that remaining development topics can be clarified in a more structured way?
We are not using the full c++11 yet. I'd guess that the most useful c++17 features will be ok to use in ~5 years or so.
don't reopen closed tickets over and over.
Last edit: Daniel Marjamäki 2018-09-03
How much do you care for the possibility to use recent functionality also with the provided software build systems?
This action can occasionally happen if there are disagreements for desired software evolution.
Will the issue tracker be extended anyhow so that account reactivations (or password resets) can be achieved by involved users directly?
the more backwards compatible we can be the better. So I think the question is rather if we can support older cmake versions than we do now.
Backwards compatibility can be desirable.
But can you get into the mood as a software developer to try current techniques out?
Yes of course.