Pointer dangling or not

Well... no one is certainly forcing you to use const correctness. The thing is, even reasonably intelligent people will screw up: while you can make a char pointer reference a string literal it is not a wise idea in practice, since there are many ways to make the pointer invalid. While the code in my earlier post does not reflect this part of life (as I did it purposefully), it can happen.

I believe this was Corned Bee's intent. In fact, it's probably an argument for using const pointers to const char, but that's an assumption.

CornedBee's intention was, I presume, to say that a non-const pointer should never be initialised so it points at a string literal (which is of type n const char *).

He's right in one way, and wrong in another.

The relationship between string literals and pointers to char has been an anomaly in the language, almost since Adam was a boy. Initialising a pointer to char with a string literal is the only means supported by C or C++ by which a pointer can be initialised (effectively) with an array of elements. The reason it was introduced into C in (during the 1970s IIRC: definitely well before the standards were written) was as a convenience for lazy programmers who did not want to create a pointer, create a string literal, and then assign the pointer to point at the string literal. It was a fairly common use case, and programmers whined about having to use two lines of code;

Code:

    char x[] = "Hello";   /*   string literal to support a char array */
    char *px = x;

when they were thinking it could be done in one, i.e.

Code:

    char *px = "Hello";

Hence the initialisation of a char pointer with a string literal was born. In those days, the const keyword was not part of the language, so there was no const attribute. However, in practice, compilers placed string literals into some form of read-only memory, so modifying a string literal tended to result in a program crash.

During the development of the C standard (which was ratified in 1989 by ANSI, and then adoped in 1990 by ISO) the const keyword was born. String literals, however, did not wind up with a const attribute, and initialisation of pointers using a string literal was still allowed in the interests of backward compatibility. This was because of the large amount of legacy code initialising non-const char pointers with string literals (obviously lazy programmers who whine are widespread). In both C standards, a string literal is an array of char.

Along came the C++ standardisation process, which made a string literal into an array of const char and flagged initialisation of a non-const pointer with a const string literal as a "bad thing". They marked it as a deprecated feature (deprecating is a means by which a standards committee can state that use of a feature is considered bad practice, and that it will be removed from some future version of the standard). The reason they did this is that they were required to support backward compatibility to C (the 1989 standard). The end result of that is that C++ compilers are required to allow use of a string literal to initialise a non-const pointer. Deprecating means it is recognised as bad practice and (in fact) a fair few C++ compilers give non-fatal warnings (i.e. they complain about it, but let it compile anyway) when code uses this feature. While compiler vendors are free to choose not to support deprecated features, they often do because they must deal with programmers whining when they get fatal errors when compiling legacy code - the path of least resistance for compiler vendors is often to support deprecated features.

The end result of that is, literally, that CornedBee is both right and wrong. He is right in the sense that initialising a non-const pointer with a string literal is bad practice, and that it may be removed from a future version of the C++ standard. He is wrong in the sense that it is a feature which is used very commonly in legacy C and C++ code, so the majority of compilers support it.