Templates, Structs and Invalid Pointers - where did it go wrong

[courpron]

Understanding how standardization works and understanding the realities
of the compiler market enables one to make intelligent judgments rather
than vague assertions, without citing supporting evidence, about "good
practice" and "concensus".

That has nothing to do with "Understanding how standardization works
and the realities of compiler market ".
The fact that C headers won't be removed any time *soon* depends more
on the fact that a lot of current systems (especially low level
systems) and their interfaces are coded in C ; if that was not the
case, I guess that every standard library (with C++ or C headers)
would have been included in the std namespace without any exception.

Good practice is following the standard and avoid features listed as
deprecated (if possible). This is a general good practice that applies
to any programming language, and should be evident to any programmer.
That good practice directly comes from the definition of "deprecated".
Your opinion is interesting but is not following the *current*
standard (and is not listed as a core issue).

Alexandre Courpron.

 

[courpron]

* anon:

[...]

I am sure you know all this,

Pete Becker is secretary of the international C++ standardization committee's
library group.

That doesn't prevent him to make wrong statements like "<stdio.h> is a
C header and a C++ header."
We are not robots. Errare humanum est.

He's not.

He's just countering your misguided views, and extremely patiently.

"anon" is not misguided in this particular aspect of the C++03
language. Now you can tell him your opinion about the future evolution
of C headers. That does not mean he is currently wrong.

That said, with C++0x there will IMO not be much reason to use the <x> instead
of <x.h> headers: about the only reason would be where you absolutely want to
use a "std::" prefix. That's because C++0x will acknowledge the current reality
that an <x> header may introduce the names in the global namespace. So it's then
better, in my view, if the code says straight out that this does or may very
well introduce names in the global namespace, and besides, it's the simplest.

In a header file, including a C++ header ( <iostream> for example )
and using right away "using namespace std;" is bad practice. But, in
an implementation file, it's a correct usage under certain
circumstances. The same thing can be applied to C headers, but there
is one difference :

#include <stdio.h> may denote a C compatibility, whereas using :

#include <cstdio>
using namespace std;

tells to the reader that this is a C++ program only.


Moreover, when you are developping a C++ library, limiting or even
avoiding any name to be inserted in the global namesapce is a
reasonnable goal. If you use a lot of C headers in your own headers,
you pollute the global namespace with countless names, and you have to
resort to tricks like wrapping the C headers inclusion in a namespace
region. You don't have this problem with C++ headers like <cstdio>.

So, yes, there are good reasons to keep C++ headers à la <cstdio>, and
to avoid the use of C headers if possible.


Alexandre Courpron.

 

[courpron]

* (e-mail address removed):


[...]

That has nothing to do with "Understanding how standardization works
and the realities of compiler market ".
The fact that C headers won't be removed any time *soon* depends more
on the fact that a lot of current systems (especially low level
systems) and their interfaces are coded in C ; if that was not the
case, I guess that every standard library (with C++ or C headers)
would have been included in the std namespace without any exception.

Good practice is following the standard and avoid features listed as
deprecated (if possible). This is a general good practice that applies
to any programming language, and should be evident to any programmer.
That good practice directly comes from the definition of "deprecated".
Your opinion is interesting but is not following the *current*
standard (and is not listed as a core issue).

Alexandre Courpron.

If you wonder about the rationales etc. of the standard (which you should do)
then Pete's the man.

The rationale behind "listing C headers as a deprecated feature" is
obviosuly not the one displayed by Pete Becker.
He has an opinion about C headers (which is different than the opinion
of the writters of this part of the language), and he has the right to
have such opinion. That's all.

In general.

Is that so darned difficult to understand, that you're talking to guy who's
writing the standard?

Take a look at your copy of the C++0x draft, first page.

For Pete's sake. <g>

If someone is part of the standard C++ comittee or afiliated with it,
that doesn't mean he participated to the redaction of the *whole
current* C++ standard. That also does not mean that he knows every bit
of the C++ standard.


Alexandre Courpron.

 

[courpron]

No, the basis for the fact that the <xxx.h> forms of the standard
headers won't go away is that they're used extensively.

One of the intention of the writters of this part of the C++ standard
(concerning C headers) was clearly to preserve C compatibility. This
intention can be seen in 17.4.1.2 (fn 160) :
" The ".h" headers dump all their names into the global namespace,
whereas the newer forms keep their names in namespace std. Therefore,
the newer forms are the preferred forms for all uses except for C++
programs which are intended to be strictly compatible with C."

Alexandre Courpron.

 

[courpron]

That's one definition, but not the only possible one.


The *current* standard says that the <xxx.h> forms of the headers for
the C library are part of the standard; every implementation that
conforms to the standard must provide them. There is a warning that
they might go away sometime in the future, and interpreting that
warning requires more than superficially saying "it's deprecated, so it
shouldn't be used." These forms won't go away. They're too widely used.
There's even talk of "undeprecating" them. (Etymologically, I think the
inverse of "deprecate" is "approcate", but that coinage seems to
express a somewhat different sentiment)

That's interesting, but until that happens, I won't change my coding
guidelines (as if anyone here cares anyway).
But I think my position is a reasonnable one. If I'm not sure about
the "C headers" deprecation or 'undeprecation', I stay with what the
current standard says.


Alexandre Courpron.

 

[anon]

Um, I haven't seen anyone make that claim in this thread that people
should use the <xxx.h> forms of the standard C++ headers for the C
library. What I have defended is someone else's choice to do that.

Sorry, I must have misunderstood something somewhere. That is another
issue, cause I understood you are promoting use of C headers instead of
C++ headers

There is no technical benefit from using the <cxxx> forms rather than
the <xxx.h> forms. The former are required to put the names into
namespace std, and the latter are required to put the names into
namespace std and hoist them into the global namespace. In fact, for
most implementations, both forms put the names into both namespaces.
C++0x will acknowledge this reality, and allow both. While some people
may have coding guidelines that require using the <xxx.h> forms only for
C compatibility, that's not a technical reason, but a stylistic one;
there's plenty of room to disagree about style guidelines.

I didn't know this, because there are many c++ online pages saying to
use <cxxx> instead of <xxx.h> for c++ programs.

 

[courpron]

Gosh, and here I thought my responsibility as Project Editor was the
redaction of the whole C++ standard.

The redaction (what I mean was more "elaboration and redaction",
instead of pure writing) is a matter of a team. And I am pretty sure
that each person of the team doesn't know equally well the standard,
and certainly doesn't know every bit of it.

And, with all due modesty, I know
it far better than you do.

That's why you were wrong about the denomination of "C headers", and I
was right.

Well, that's a bold statement and you may find that I have a very
*precise* knowledge of the current C++ specification concerning its
core, so, it is probable that you can't surpass me on that aspect. On
the other hand, concerning 1) the functionnalities of the C++
libraries and 2) the design and evolution of C++, my knowledge is
probably more limited than yours.

However, I have a very wide knowledge of programming languages and
compilers writing (although both of these are not my speciality).

You are specialized in C++, but you should take into account the
opinion of someone who can judge objectively what the current C++
standard is [ Of course compared to other programming languages
standards (or references if the language is not standardized), the C++
standard is objectively a mess , but it is inherent to its complex
nature, and is reflected by the difficulty to write a C++ compiler. ]

I can say that it is not a good practice to use a deprecated feature.
If that feature will be undeprecated then wait for the next version of
C++ before using the (un)deprecated feature.

Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce new
keywords that won't enter in conflict with existing programs, not the
other way around).
When you say to "anon" that there's no good reason not to use C
headers, this is not coherent with what the *current* C++ standard
says.

But I can understand your view while you talk about the intention and
future of C++.

This reminds me a rather recent discussion here on a specific aspect
of the C++ language where W. M. Miller said that "upon strict reading"
I was right but "it was not the intent". Here the message that
includes the whole discussion to see that you are not alone:
http://groups.google.fr/group/comp.lang.c++/msg/b6a19dd3b12485ac


Sorry I can't help it, I read a lot of technical specifications. I
said earlier "we are not robots", but I act like one when I read
them.

I guess the two positions( strict reading, and intent of the wording)
are complementary. After all , which of the following compilers is
standard-compliant ? the one that strictly follows the wording of the
standard or the one that follows the "intents" ?

Alexandre Courpron.

 

[Default User]

DaveJ wrote:

if(m_Str != m_Buf)
should be
if (m_Str != &m_Buf[0])

Why?

m_Buf is an array

So? What happens when the name of an array is used in most contexts,
outside of the sizeof or address-of (&) operators?




Brian

 

[courpron]

Um, you talked about "he", not "they".

I used the "team working" argument to emphasize that noone can have a
perfect knowledge of C++, because there is inevitable disparities of
knowledge amongst individuals of a team ( which is inherent to the
human nature ).

No, because you switched context. When I mentioned C++ headers, I was
referring to the headers prescribed by the C++ standard. You
misinterpreted that to refer to the title of a section in the C++
standard.

As I said I am precise, and when you say "<stdio.h> is a C header and
a C++ header.", this is wrong, according to the C++ standard.
You should have said something like "<stdio.h> is a standard header in
C++", because "C header" and "C++ header" have precise meaning in the
standard. However, I think I could have been more diplomatic instead
of just saying this was wrong, and should have clarified that only the
"form" of your wording was wrong, not the underlying meaning.

[...]

Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce new
keywords that won't enter in conflict with existing programs, not the
other way around).

But "deprecated" is precisely about possible future evolutions of the
language. If programmers shouldn't care about possible future
evolutions, they should not care about deprecated.

Deprecation means that you should not use the deprecated feature.
Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.


Alexandre Courpron.

 

[Kai-Uwe Bux]

Deprecation means that you should not use the deprecated feature.

That is not the technical definition given in the standard.

Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.

That seems overly optimistic: features not deprecated now can become
deprecated in the future. All that deprecated means is that the feature is
not guaranteed to be part of the next version of the standard. Conversely,
non-deprecated features can be assumed to be normative in the next version,
but they might be deprecated in that version and missing in the version
thereafter. E.g. std::auto_ptr could be deprecated in C++0X since
unique_ptr is considered a superior alternative. So a programmer using the
not-currently-deprecated std::auto_ptr still has to worry about future
evolutions of the language.

I think, the currently deprecated C-library headers are probably more stable
than the currently not deprecated std::auto_ptr.


Best

Kai-Uwe Bux

 

[courpron]

Programming advice entails far more than intricately parsing the C++ standard.

Indeed but a precise terminology is nonetheless necessary.

I'm not aware of any rule that every term used in discussions in this
forum must be used in precisely the sense in which it is defined by the
C++ standard.

I agree with this, but the wording "C headers" is special in C++, so
clarifying the precise meaning is never a bad thing I guess.
Kinda like someone that is using "defined" instead of "declared", I
know the intent but I could bring some precision.

But you are right that no rule forces you to employ a precise
terminology. and this is fortunate because I, for example, am not as
precise as what I would like to be, because of my limited vocabulary
in english.


Alexandre Courpron.

 

[courpron]

Its definition is in Annex D, paragraph 2: "Normative for the current
edition of the Standard, but not guaranteed to be part of the Standard
in future revisions." Nothing more, nothing less.

Deprecation is implicitely accompanied with a recommandation. That is
the intention.

A very clear and precise definition of "deprecation" :
http://en.wikipedia.org/wiki/Deprecation

You may say : "now he is talking about the intention of the standard"
Well, deprecation is a common term used in many programming languages,
and I'm pretty sure that the intention of listing a feature as
deprecated invariably means that you should not use this feature
unless you are forced to, in some exceptionnal circumstances.

The intention behind listing C headers as a deprecated feature was to
discourage their uses, unless a C compatibility was desired. Maybe the
terms of the problem have changed now, but this was the original
intent ( that or I'm mad ).

There's no guarantee that a future revision  of a standard won't
deprecate some feature. So this programmer who does not have to worry
about possible future evolutions of the language now has to worry about
future evolutions of the language.

This problem concerns the standardization commitee (which should care
about compatibility issues when deprecating some features). Those
future evolutions should not concern the developer who is currently
writing a program.

To minimize disruption, it's far
easier to wait until something is removed to stop using it.

I disagree with this. In any programming language, I would recommend
to avoid the use of deprecated features whenever possible. We have
conflicting views on the subject , but since those are just
"recommandations", noone is absolutely wrong or right ( naturally, I
think my position is wiser ).

Alexandre Courpron.

 

[courpron]

(e-mail address removed) wrote:

[snip]

Deprecation means that you should not use the deprecated feature.

That is not the technical definition given in the standard.

Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.

That seems overly optimistic: features not deprecated now can become
deprecated in the future. All that deprecated means is that the feature is
not guaranteed to be part of the next version of the standard. Conversely,
non-deprecated features can be assumed to be normative in the next version,
but they might be deprecated in that version and missing in the version
thereafter. E.g. std::auto_ptr could be deprecated in C++0X since
unique_ptr is considered a superior alternative. So a programmer using the
not-currently-deprecated std::auto_ptr still has to worry about future
evolutions of the language.

I think, the currently deprecated C-library headers are probably more stable
than the currently not deprecated std::auto_ptr.

I answer to all of this in my previous reply to Pete becker.

I would like to add that in the discussion about deprecation (and the
concern of a programmer about the future evolutions of his programming
language), Pete Becker and you are focusing too much on your C++
language experience.

When I say that a deprecated feature should be avoided, this is based
on an experience in a wide range of languages with different
programming paradigm, and in all of them "deprecation" has a constant
meaning.

Of course, you are not forced to follow my recommandation, I just
share my views with you.

Alexandre Courpron.

 

[courpron]

On 2008-08-29 15:32:30 -0400, (e-mail address removed) said:

[...]

Deprecation is implicitely accompanied with a recommandation. That is
the intention.

Okay. The words in the standard don't mean what they say when they
don't fit your world view.

A very clear and precise definition of "deprecation" :
http://en.wikipedia.org/wiki/Deprecation

Okay. Now we should look to wikipedia to be precise, even when the
standard explicitly defines what "deprecate" means, because the
definition in the standard doesn't fit your world view.

No I say that the C++ definition of deprecation necessarily should
imply a recommandation of not using them. If it is not, then your view
and the C++ standard committe view of what is "deprecation" is not
matching the standard definition of "deprecation" in other programming
languages.

That's what I'm saying, and that's why I provided the wikipedia link.

Of course. We should ignore the clear words in the standard because
they don't match what you want "deprecation" to mean.




Okay, if you say so. I must have missed it, despite actually being part
of the discussion.

You said yourself that it was a wishful thinking made 10 years ago.
That was the original intention behind listing C headers in deprecated
features, even if today, the way of thinking have changed apparently.


Alexandre Courpron.

 

[courpron]

Of course. Actual experience with C++ and the C++ standard and the C++
standards committee doesn't count against your general experience in
other languages.

Relying on his C++ language experience to judge general programming
practices and common term definition is IMHO a bad idea. Using any
functionnal language background seems to be a better choice in that
aspect.

Saying that you can freely use a deprecated feature until it has been
actually removed in the standard is a overall bad practice. The good
practice is to avoid deprecated features when possible.

Alexandre Courpron.



Alexandre Courpron.

 

[Ian Collins]

Saying that you can freely use a deprecated feature until it has been
actually removed in the standard is a overall bad practice. The good
practice is to avoid deprecated features when possible.

gets() anyone?

 

[courpron]

gets() anyone?

That's a good example of a deprecated feature in C that should be
avoided when possible ; using gets() is bad practice.


Alexandre Courpron.

 

[courpron]

Not because it's deprecated, however.

Yes, you are right here.

It was bad practice before it was deprecated. This case happens
sometimes for a language construct that, from the experience of the
community, is considered bad practice : it might not be simply removed
from the next standard because it is used in too much programs but it
is qualified as deprecated to "normalize" the fact that it should be
avoided.

Alexandre Courpron.

 

[courpron]

Right: it's known to be harmful (although the risk is usually
overstated). But, unfortunately, sometimes things are deprecated
because they don't match someone's idea of good style. Which is why the
label "deprecated" in C++ doesn't mean much.

Well, access declarations, for example, should be avoided, not because
they are harmful, but because they are not very known ; using them in
a program may challenge a number of C++ programmers reading it. And,
in practice, programs using access declarations should be very rare.

Now I can understand that C headers are still used widely, even if it
is a deprecated feature. But I see this as an exception rather than
the rule.
Therefore, saying that "you can freely use C headers" happens to be
right (which I didn't know before this discussion) , but saying that,
"as a general rule, you should avoid deprecated features" is also
right, and is a safe practice IMO. As such, it seems to be coherent to
think about "undeprecating" C headers.

Alexandre Courpron.

 

[James Kanze]

* anon:

Pete Becker is secretary of the international C++
standardization committee's library group.

He's also the project editor, which means that he is the person
who has the final responsibility for the actual wording in the
standard.

He's not.

He's just countering your misguided views, and extremely
patiently.

He's doing it in Pete Becker style. I happen to actually
like his style, even when it's one of my own postings he's
criticizing. But it's largely a matter of personal taste what
style one likes or doesn't.

In practice, the C++ committee, in the C++98 standard, exercised
a fair amount of wishful thinking in its definition of the
headers inherited from C. To the point where no implementation
(or almost none) was compliant. C++0x, recognizing reality, has
relaxed the rules, with the results that there is practically no
real difference between <cxxxxx> and <xxxxx.h>. Historically, a
number of people took the C++98 at its word, without realizing
the fact that it was practically impossible to implement in
certain environments (most, in fact), and went overboard in
insisting that everyone use <cxxxxx> etc., instead of <xxxxx.h>;
g++ even went so far as to issue a warning for <xxxxx.h> (even
though its implementation of <cxxxxx> wasn't conform). Others
(including myself), faced with the reality of actual compilers,
recommended sticking with <xxxxx.h>, since at least there, we
more or less knew what we were getting. Both are, of course,
fully standard, and the choice of one form or the other depends
on house rules, etc.

That said, with C++0x there will IMO not be much reason to use
the <x> instead of <x.h> headers: about the only reason would
be where you absolutely want to use a "std::" prefix. That's
because C++0x will acknowledge the current reality that an <x>
header may introduce the names in the global namespace. So
it's then better, in my view, if the code says straight out
that this does or may very well introduce names in the global
namespace, and besides, it's the simplest.

Well, that's always been my point of view. But I'm willing
to admit that points of view can vary here (and may depend on
which compilers you have to compile with). In the meantime, the
fact that the standard has actually been changed so that
implementations are conform, and so you more or less know what
you're getting, removes the major motivation I had for not using
<cxxxxx>; in my most recent code, I've adopted the newer style
headers for two reasons: 1) I can use the std:: prefix, e.g. to
distinguish the standard function from a similarly named one in
anonymous namespace, and 2) doing so suppresses the warning from
g++ (which is a compiler I have to support).