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

[James Kanze]

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

And as Pete has explained, in this case, the deprecation was
based on wishful thinking. In practice, your company should
establish some sort of rule for its internal use, based on the
standard, but also on the reality of compiler implementations,
etc. (Based on the standard, the obvious recommendation for
templates is to declare them all export, and put the
implementations in a separate source file, like the authors of
the standard intended. The coding guidelines where I work,
however, clearly say that "export" shall not be used.)

 

[James Kanze]

(e-mail address removed) wrote:

[snip]
Conversely, non-deprecated features can be assumed to be
normative in the next version,

Even that is not really true. I don't see anything in the
current standard that deprecates the use of nullptr or constexpr
as a user defined symbol in the current standard, but that
doesn't mean that code which uses them won't be broken by the
next version of the standard.

This whole business of "deprecated" seems to be playing word
games to me. In practice, a competent programmer will analyse
the complete situation, and take whatever steps he thinks are
necessary to provide for the future, depending on the
requirements at hand. The fact that the standard declares some
feature deprecated is certainly a significant bit of
information, but it is not, in itself, an absolute; in the case
of the <xxxxx.h> headers, I think that those of us with
experience in implementing libraries tended to take a "wait and
see" attitude, not being convinced that the arguments and
decisions of the committee would actually be transformed into
reality. And time has shown us to be right.

 

[James Kanze]

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

You missed his point. It's a misfeature of C, which should be
avoided, despite the fact that it hasn't been deprecated.
Deprecation is just one data point to be taken into
consideration when establishing your rules.

 

[courpron]

And as Pete has explained, in this case, the deprecation was
based on wishful thinking.  In practice, your company should
establish some sort of rule for its internal use, based on the
standard, but also on the reality of compiler implementations,
etc.

That can't be false, but I'd say that depends on the language. That
fact concerns more C++ programmers than about any other programming
languages since the current C++ compilers are far from being standard-
compliant. While programming, a SML developer, for example, should
care less about the reality of compilers, and more on the language
specification.

Alexandre Courpron.

 

[courpron]

You missed his point.  It's a misfeature of C, which should be
avoided, despite the fact that it hasn't been deprecated.
Deprecation is just one data point to be taken into
consideration when establishing your rules.

The point can be multiple here. It can means :

1) gets() should be avoided despite the fact that it is not
deprecated.

=> This is off-topic, that doesn't invalidate the fact that a
deprecated feature should be avoided when possible.


2) gets() is (now) a deprecated feature that should be avoided

=> OK, that confirms the "deprecation is also a recommandation"
meaning.


3) gets() went deprecated because it was a harmful feature

=> That even more confirms that deprecation is seeing as a
recommandation of not using the deprecated feature.

My simple answer was taking into account all those possible meanings.


Alexandre Courpron.

 

[kwikius]

Pete Becker wrote:

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.

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.

Just out of interest, how many deprecated features of C++ have been
removed ? None AFAIK

regards
Andy Little

 

[Old Wolf]

You may be seeing a g++ bug that was fixed at some version but then
resurfaced at a later version. We had a similar issue when we
initialized arrays of such self-referencing types. g++ would
incorrectly do a memberwise copy as if the type did not have a user-
specified copy constructor:

But a member-wise copy is the mandated behaviour
for compiler-generated copy constructors, which is
what you get if you don't specify one.

SelfRef a[] = { SelfRef("one"), SelfRef("two") };

The arrays would be initialized with incorrectly-copied copies of the
temporaries. As a result, the objects' members would not be pointing
to their own members.

This would be a bug in the code, rather than a bug
in the compiler; if I am reading the C++ standard
correctly, then a[0] and a[1] are copy-constructed
from the two temporaries in the brace list.

 

[anon]

anon wrote:

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?

Isn't it an undefined behavior?

 

[courpron]

Just out of interest, how many deprecated features of C++ have been
removed ? None AFAIK

Indeed. However, a deprecated feature may imply that the feature is
just scarecely use and then should be avoided to follow common
practices (we saw, however, that it was not the case with C headers).

I analyze the fact that deprecated features are not (currently)
removed, with the following 2 points :

1) C++ is a well-established language that is widely use for years
2) One of the goal of the C++ standard commitee is to provide backward
compatibility

The funny thing is that the new C++0x headers (amongst a few other
things) will break backward compatibility (at least in theory, less in
practice), while one reason to maintain C headers as a deprecated
feature was to provide backward compatibility with C.


Alexandre Courpron.

 

[Default User]

Default User wrote:
anon wrote:

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?

Isn't it an undefined behavior?

Isn't what undefined behavior? To use the name of an array? No.

When the name of an array is used in most contexts, such as the right
side of an assignment or with the [] operator, or in a comparison, it
is converted to a pointer to the first element. Yhat's both value and
type.




Brian

 

[James Kanze]

* James Kanze:

Uh, which warning?

I'm aware of warning for pre-standard iostreams, but that's all.

I'm not sure, actually. I know that in the past, when I
regularly used "deprecated" headers, I got warnings from g++.
Maybe they were only for strstream; I'm not really sure. But
since I've switched to not using the deprecated headers, they've
gone away. (For all I know, it might just be that g++ fixed
this stupidity---I've also upgraded the compiler since then.)