Why standard code?_问答_开发者_运维开发者技术经验分享

Often I see peopl开发者_StackOverflow中文版e arguing about the code not being standard. what do they really mean?

for example if I would say:

itoa() to convert an integer to character and they would ignore it by implying the "code is non-standard!".

Some implementations of the C++ standard allow certain things that aren't supposed to be allowed.

If you use these features one may say that your code is not standards compliant.

An example is the following:

int x = 5;
char arr[x];

The above code is not allowed in C++03 standard but it is allowed in C99. That being said some compilers who claim to be implementing C++03 allow you to use that code in a C++ program.

Standard code means, code that has well-defined behaviour according to the Standard of the language in question. Most compilers implement many extensions depending on their user-base. Code that depends on these extensions is non-Standard. Easy examples are enum scopes or __uuidof(T) in MSVC. I'm not terribly familiar with enough other compilers to comment but I know that they have their own extensions.

Perhaps they mean "not conforming to the ANSI C/C++ standards." But it's impossible to tell from the wording of your question and the code you didn't post.

There are varing degrees of 'non-standard'.

There's code that's well defined on a particular compiler, but isn't standard because it uses extensions. The problem with this is that it makes the code less portable (which depending on the problem might be something you have to live with). This is one of the issues with itoa() - it's not standard, so it might be a problem on systems other than the one you're using.

Generally, many programmers feel that if you have an option to do something in a portable/standard way you should opt for that rather than an equivalent non-standard method. Particularly when posting on a place like Stackoverflow where an answer might be viewed by people working on a wide variety of platforms, a standards-compliant answer probably has the widest audience. For the case of itoa), the snprintf() function is one way to get results similar to itoa() using a standard function.

There are times when standards compliance is brought up in an answer when dealing with for undefined behavior, where things may seem to work in a particular test, but according to the standard there's no promise of how the construct should behave. This is an issue of more than just portability; undefined behavior that seems to work is quite dangerous, because that 'working' behavior can change to something that crashes or causes a subtle bug to occur. That change can occur for any reason.

A similar, but less drastic, situation occurs for unspecified behavior (where the compiler can chose one of several options for how the program should work) or implementation defined behavior which is where the compiler can choose one of several options, but has to document what it does. In these scenarios, even though a program might be conforming to the standard, portability can still be an issue.

Another thing that people mean about "standard" C++ is not only just using features of the compiler that are part of the standard, but also only utilizing the standard library. So like if you go to comp.lang.c++ the only questions that are on-topic are those that are "standard C++". This means no UI and such.

Frankly, pure, standard C++ is almost completely useless. If you're going to do anything but the smallest of utility programs and academic exercises, you HAVE to use some libraries that provide non-standard functionality. You should try to stick to the standard as much as you can though because otherwise you'll have that much more work to do when you try to cross implementations, including simple upgrades.

There are standards documents that govern the structure and behavior of C and C++ programs. Online versions are available for each, although these are technically working papers and not the "official" standards documents (the official documents are not free for download); however, they're good enough for most purposes:

C language standard, draft n1256
C++ language standard, draft n1905

Both standards define their language's syntax, semantics, and core libraries. Individual implementations such as gcc or MSVC are free to add their own extensions to both the language grammar and the libraries; itoa is one such library extension.

The problem is that if you write your code to use those extensions, it won't compile under a different compiler. This isn't necessarily a problem if you only intend for your code to run on Windows or Linux, but if you want it to run on both you have to restrict yourself to what's defined by the language standard (or else isolate the platform-specific extensions in modules that can easily be swapped out).

The C and C++ languages are defined as ISO standards. These standard documents describe how C and C++ code should be executed, what is valid and what isn't, and everything else about the language.

As long as your code relies only on what is guaranteed by these standards, then you can assume that your code will work with any compiler, on any platform.

However, most compilers also support some "extras", in the form of functions that aren't mentioned in the standard (for example itoa), or perhaps special syntax, or a slightly different meaning of certain constructs. (For example, if you use Microsoft's C++ compiler, then volatile has some additional effects beyond what is described in the standard)

When you rely on such extensions, your code is no longer portable. You can't compile it on another compiler and expect it to just work. Taking the itoa function you mentioned as an example, the function might not exist depending on my choice of compiler, and so my code would break if I tried to compile it there.

Therefore, it is often preferable to stick with what is guaranteed by the language standard. If a function isn't guaranteed by the standard to exist, then you shouldn't assume it'll exist if you want your code to be portable.

Well, for itoa() this is the Posix (unix) name as opposed to the 'standardized' ISO name _itoa(), and this has to do, as jalf said, with portability.

One weirdest feature I have seen on compiler that comes with UBuntu is you can dereference an uninitialized pointer. And this just happened to use memory in my program space.

I don't know which version of UBuntu but myself and my professor were very much puzzled to see this. And I remember that in such a case result is 1.