Strange Article on C++ casts

[peter koch]

Grizlyk skrev:

I can not prove my opinion, that "some old compilers required all
constructors defined if they are declared", but I can say, that the
evil tidings "to define private member as throw error" among me is
existing for my classes at least for 10 years (from 2000 year). Yes, I
do not use C++ intensively for all the years (there was many years,
when i never see not a line of C++ code), but after the time I forgot
the cause to do like this, just copying it

Right. This confirms my suspicion that you really ought to learn C++
(and stop having those bad habits of copying code around "just
because").
[snip]

I saw the examples, but all of them can be easy treated as "does not
matter" and Glassborow objections _looks_ just like "game with words".

Game with words? Kalev did demonstrate that he had a less than solid
understanding of C++.

I agree, that man (Danny Kalev) who describe standard must be more
pedantic than pedanctic, but can repeat again - Glassborow was not
convincing, he just not listed very ugly obvious errors.

If that level is what you call "pedantic"

All Glassborow examples less than 5% of size of his note, other about
him and comitee. Most engeneers ignore results, if value is less than
10% of other value All Glassborow examples is strange shortest parts
of unknown code, without any sence and original context.

That line just demonstrates that your ability to do arithmetic is on
par with your coding skills. Reread the review and you'll find that
about 40% of the review is about faults in the book.
[snip]

/Peter

 

[Grizlyk]

Right. This confirms my suspicion that you really ought to learn C++
(and stop having those bad habits of copying code around "just
because").

Yes, you are right, we all always must learning, even Stroustup, i
think.

By the way, I am remembering a real situation in my life. Many days
ago, I first time saw C/C++. I open "incude" directory with headers and
take first file by random way. It was "obsolete.h"! At the moment one
man passed near and ask me: "hey, what the hell are you doing"? "I try
to learn C++" - I sad. ( the cause to laugh that I did not know what
the english word "obsolete" means ). The accident probably the cause of
all my problems - start define all process.

But return to you. In general, it will be better, if you will remain
your _suspicions_ for your internal usage, and here you can easy prove
your words by writing concrete examples, to show how the examples will
produce some of set of hard errors, for example, due to my "error style
declarations".

Sorry me, but without any suspicions, i can easy say, that you just can
_not_ do it, prefer instead of it declare many words of suspicions.

If that level is what you call "pedantic"

I sad, that any man (in the case it was Danny Kalev) must be pedantic,
if he is going to describe standard ("more
pedantic than pedanctic" is logical solid adjective).

That line just demonstrates that your ability to do arithmetic is on
par with your coding skills. Reread the review and you'll find that
about 40% of the review is about faults in the book.

About 40%? This is strange. The text is public.

This is full of Glassborow text [2414]:
[q]
I wish the publishers had not stated that the author is a member of the
ISO/ANSI C++ Standards Committees as it lends more authority to his
work than it deserves. To the best of my knowledge the author has never
attended a meeting of WG21 & J16. That is not to say that there is no
justification for the statement. Kalev is listed as an observer and is
entitled to participate in any of the C++ Standards reflectors that he
wishes to, however his is not a name that springs to mind as an active
participant (I do take almost all the C++ Standards reflectors and
think I am reasonably familiar with the active participants). I am only
mentioning this because I think readers should ignore this part of the
information on the back cover. On the other hand two of the three
members of the Technical Validation Group (TVG) are active members of
the C++ Standards Committees so you can be reasonably certain that the
technical content is basically sound (though not perfect). For example
the author seems to believe that implicit int is deprecated, it is not
because we actually removed it from the language (as did C in its
latest version).
There are other places that leave me less than happy. For example on
page 76 I find the following constructor definition:


Person(const char* name = NULL , int
age = 0) {}Look at that line carefully. That is more than a typo, and
the faults (one fatal and the other contrary to all texts on C++ style)
suggest very strongly to me that the TVG never looked at the text in
detail. In other words you would be wrong to assume that the text
carries the full endorsement of the members of the TVG. If you think I
am being picky, on the same page in a section titled Blocking Object
Copying he shows that he does not understand the full method because he
provides inline definitions (not just declarations) for the private
access copy constructor and assignment operator.
The end result is that we have a book that is very much a curates egg
(good in parts and rotten elsewhere). I am afraid that wipes it out for
its target readership. If you know enough to know the good from the
bad, you know enough not to need this book. I strongly recommend that
the publishers get the book fully technically reviewed and then publish
a substantially rewritten second edition. There is enough good to be
worth salvaging but there is too much bad mixed with it to justify its
price.
[/q]

This is useful part of Glassborow text [53]:
[q]
Person(const char* name = NULL , int
age = 0) {}
[/q]

Persent of useful text: (100 /*%*/ /2414)*53 = 2.196 /*%*/

No one (excluding Glassborow or you) can understand Glassborow's text:
1.
[q]
Person ...
[/q]
What is Person? Why are "name" and "age" present but never used?

2.
[q]
inline definitions (not just declarations) for the private access copy
constructor and assignment operator
[/q]
What is it? What kind of the "definitions" and where?

3.
[q]
implicit int is deprecated, it is not because we actually removed
[/q]
Yes, "deprecated" word used as "obsolete and produced warnings, not
errors, is not recommended to use in new programs, remained for
backward compatibility". There are differences between "deprecated" and
"removed", but maybe not in real compilers. And as context is absent,
it is ablsolutely not clear what the conclusion have been done by Kalev
for using "implicit int" in programs.

And even Kalev realy wrote, that "implicit int is deprecated and can be
used", and he never run compiler (gcc for example, which print exactly
"error: ISO C++ forbids declaration of 'var' with no type") it is not
_fatal_ error. In most cases is really does not metter - do not use
deprecated.

All others by random selection:
[q]
"best of my knowledge "
" C++ Standards reflectors "
"I am only mentioning "
" Technical Validation Group "
[/q]
evidently are not explanations.

Repeat third time - it is possible, that book of Kalev is set of
errors, but no one was listed by Glassborow and of course by you.

 

[Alf P. Steinbach]

* Grizlyk:

[snip]
No one (excluding Glassborow or you) can understand Glassborow's text:
1.
[q]
Person ...
[/q]
What is Person?

Glassborow mentions that this is a constructor definition, hence
"Person" is class name.

Why are "name" and "age" present but never used?

Those are constructor arguments.

That's what Glassborow's pointing out: the constructor doesn't construct
a valid object, it constructs an object with indeterminate member values
(which leads to Undefined Behavior if used).

2.
[q]
inline definitions (not just declarations) for the private access copy
constructor and assignment operator
[/q]
What is it? What kind of the "definitions" and where?

Private copy constructor and assignment operator is used to prevent
copying. When they're never used they don't need to be defined. The
common idiom is to declare them but not define them; defining them shows
a lack of familiarity with idiomatic C++ as well as C++ requirements.

3.
[q]
implicit int is deprecated, it is not because we actually removed
[/q]
Yes, "deprecated" word used as "obsolete and produced warnings, not
errors, is not recommended to use in new programs, remained for
backward compatibility". There are differences between "deprecated" and
"removed", but maybe not in real compilers. And as context is absent,
it is ablsolutely not clear what the conclusion have been done by Kalev
for using "implicit int" in programs.

A compiler must support use of a deprecated feature, and must flag use
of a non-existent feature (such as implicit int) as an error.


[snip]

Repeat third time - it is possible, that book of Kalev is set of
errors, but no one was listed by Glassborow and of course by you.

See above.

 

[Grizlyk]

No one (excluding Glassborow or you) can understand Glassborow's text:
1.
[q]
Person ...
[/q]
What is Person?

Glassborow mentions that this is a constructor definition, hence
"Person" is class name.

It can be guessed.

Those are constructor arguments.

That's what Glassborow's pointing out: the constructor doesn't construct
a valid object, it constructs an object with indeterminate member values
(which leads to Undefined Behavior if used).

No reason to think so, because class Person do was not printed by
Glassborow.

Unknown class Person may just has no any data, but the class can be
Adapter design pattern, so ctor of the class can has unused parameters.


The example of Person can only describe declaration of default
parameters so class Person can be not existed in nature.

I only can not understand the name usage:

Person(const char* name = NULL , int age = 0) {}
must be at least, to avoid warnings
Person(const char* /*name*/ = NULL , int /*age*/ = 0) {}

2.
[q]
inline definitions (not just declarations) for the private access copy
constructor and assignment operator
[/q]
What is it? What kind of the "definitions" and where?

Private copy constructor and assignment operator is used to prevent
copying. When they're never used they don't need to be defined. The
common idiom is to declare them but not define them; defining them shows
a lack of familiarity with idiomatic C++ as well as C++ requirements.

Do you not allow defining "copy constructor and assignment operator to
prevent
copying" as private and throwing error? Can it give error? When?

Do you see, that the Kalev define empty body of private members, from
Glassborow text?

3.
[q]
implicit int is deprecated, it is not because we actually removed
[/q]
Yes, "deprecated" word used as "obsolete and produced warnings, not
errors, is not recommended to use in new programs, remained for
backward compatibility". There are differences between "deprecated" and
"removed", but maybe not in real compilers. And as context is absent,
it is ablsolutely not clear what the conclusion have been done by Kalev
for using "implicit int" in programs.

A compiler must support use of a deprecated feature, and must flag use
of a non-existent feature (such as implicit int) as an error.

Do you see, that the Kalev advised to use deprecated feature, from
Glassborow text?
If even he did it (assume without provement) if is it _fatal_ error,
that prevent all other?

See above.

Not convincing.

 

[Old Wolf]

This article is complete and utter rubbish and you should ignore it.

Ok great. I just got confused cause he's a published guy who worked on
the the C++ standards committee. But I guess that don't necessarily
mean much

Anybody can sit in on a standards committee meeting, and anybody can
publish a book. Obviously that isn't any indication of skill with C++!

The most grating thing about that article is that early on, he
criticizes the new cast operators, which were designed to
help programmers avoid unintended effects of casts, by saying:

"If the programmer made a mistake here, that's too bad but C
and C++ have always practiced the 'trust the programmer' idiom."

Then, further down, he notes that a poor programmer might write:
int n = * reinterpret_cast<int *>(&d);

and then he criticizes the new cast operators for trusting the
programmer -- exactly the opposite of his earlier criticism!

Obviously he includes himself in the "poor programmer" category.
It is obvious to everyone but him that:
* reinterpret_cast<int *>(&d)

will have the same effect as:
*(int *)(&d)

and then he goes on to criticise reinterpret_cast because it did not
have the same effect as:
(int)d

Unbelievable.

His crap about const_cast is all extremely naive as well. His example:
unsigned int *lp;
(int *) lp; //cast lp to int *

is in fact a great example of the success of the new casts. Any code
that uses this cast is probably broken (if the new pointer is
dereferenced and the value of *lp were greater than MAX_INT, the
behaviour is undefined). The use of reinterpret_cast is supposed to
be ugly and it is supposed to tell you that you are writing poor code.

The example about the function taking a non-const parameter is
horrible as well. This is another great example of the success of
the new casts. Using the old casts, you could inadvertently cast
a parameter to the wrong type, causing havoc. But using const_cast,
the only thing it lets you do is add or remove the const.

Furthermore, any sane programmer would write a wrapper that
allows the old API to be accessed as if the parameter were
const, so that no special effort is needed to call it. For example:

inline void improved_func( int const *p )
{ poorly_written_func( const_cast<int *>(p) ); }

or even

#define poorly_written_func(p) poorly_written_func( const_cast<int
*>(p) )

 

[Jorgen Grahn]

peter koch wrote: ....

.... [and NOT this]

No, not of course, do like this:
private:
myclass(myclass const& )throw(Myerror&) { throw Terr_private(
typeid(*this).name() ); }

What on earth are you talking about? Joking?

In what way is that preferrable to the idiomatic way, quoted near the top?

/Jorgen

 

[Grizlyk]

What on earth are you talking about? Joking?

On earth? ogogo, Shure, most people on ther earth do not treat "throw"
as "Joking".

In what way is that preferrable to the idiomatic way, quoted near the top?

What?

 

[Jorgen Grahn]

Jorgen Grahn wrote: ....

What?

'Idiomatic' means roughly "the normal way", "the simplest correct way", "the
way that most people use and recognize" and "the way the language encourages".

/Jorgen

 

[Grizlyk]

'Idiomatic' means roughly "the normal way", "the simplest correct way", "the
way that most people use and recognize" and "the way the language encourages".

I know what means 'Idiomatic', I do not undestand "who" quoted "what"
and "where"?