Geek Answers Handbook

Standardly specify C ++ standard in source

The standard compatible C ++ compilers define the __cplusplus macro, which can be checked during preprocessing to determine by what standard the file compiled for example:

 #if __cplusplus < 201103L #error "You need a C++11 compliant compiler." #endif #include <iostream> #include <vector> int main(){ std::vector<int> v {1, 2, 3}; for (auto i : v){ std::cout << i << " "; } std::cout << std::endl; return 0; }

My question is:

  • Is there a standard way to specify which standard source the file should be compiled with <

This will allow the build tools to check the sources before compilation to determine the appropriate argument for -std= (see shebang, which can specify the language / version of the scripts: #!/usr/bin/env python3 ).

The non-standard and fragile way that I can think of is looking for __cplusplus preprocessing checks, but in the above example I could also write:

 #if __cplusplus <= 199711L #error "You need a C++11 compliant compiler." #endif

hence spelling, for example. regex would be pretty tricky to catch all the options.

EDIT:

While I sympathize with @Gary's answer, which suggests relying on the build system, it suggests that we really have a build step.

But you can already today:

  • use an interpreter to run a C ++ program, using, for example, CINT
  • or use the source to translate the source, for example, rosecompiler

My question is also to indicate that the source is C ++ and what version it was intended for (imagine someone digs my code after 70 years when C ++ can be as popular as Cobol today).

I assume the equivalent thing I would be looking for is the C ++ equivalent for HTML: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

+7
c ++ c ++ 11 compilation
source share
1 answer

C ++ standards are somewhat similar to development against a library. In this sense, libraries usually evolve in such a way that they slowly erase old functions when accessing new functions. A typical way is to introduce new methods or signatures while accessing old ones.

As a simple example, for example, you can create an iPhone app that will be backward compatible with iOS 4 and above. You cannot choose which specific versions you want to support. This is good, because otherwise you open the code evolution to a matrix of possibilities, which makes your code more difficult to understand and maintain.

Alternatively, you can enter preprocessor instructions to conditionally create specific parts depending on the version or flag of some type. However, these are temporary measures and should be removed as the code evolves.

So, I think that to answer this question, as it is, the best question is to ask yourself in this situation, what will add something like this in reality, and whether it will add unnecessary complexity (one of the code smells poor design)?

In this situation and from experience, I personally think that you better adhere to one standard. I think you will find yourself trying to distinguish standards by sprinkling various #ifdef and #ifndefs preprocessors to realize that your code base is hard to understand and manage. Even if you have one include file with a definition of which version is allowed, which is included by all other files, it becomes another file for management ... not to mention when you change it, you need to recompile everything that includes his.

If you are worried that someone is building your code base with the wrong standard, use a build system that does not require developers to enter this information. For example Make, Ant, cmake. This simplifies the creation of your software and clearly defines how the project should be compiled in a repeatable way. If you go along this route, you will see that trying to protect the code from compilation incorrectly becomes a problem without problems.

In addition, if they go astray and compile with the wrong standard, they will be met with a lot of compiler errors =)

+3
source share

More articles:


All Articles