Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Strange Article on C++ casts

Reply
Thread Tools

Strange Article on C++ casts

 
 
peter koch
Guest
Posts: n/a
 
      01-16-2007

Grizlyk skrev:
> peter koch wrote:
>
> > > > >Grizlyk skrev:
> > > > >
> > > > > myclass(myclass const& )throw(Myerror&)
> > > > > { throw Terr_private( typeid(*this).name() ); }
> > > >
> > > > That can never be correct. If anything, an abort is in place.
> > > >
> > > What does it ("If anything, an abort is in place") mean? Sorry, I can
> > > not translate it and understand.
> > > If no explanaition exist, I silently will ignore the opinion, for it
> > > contradicts my observations

> >
> > It simply means that if a class is not copy-constructible, you should
> > not write a copy constructor. Writing a copy constructor that throws is
> > simply wrong: C++ exceptions are not for programming errors.

>
> 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 think, that book about details of C++ must be written by C++ expert.
> > > In order to show, that "Danny Kalev" is not, "Francis Glassborow" can
> > > just project the list of many undiscussable hard errors in the book
> > > instead of "he was invisible on our meetings".

> >
> > Glassborow did just that. There were three examples of C++ ignorance in
> > a one page long review.

>
> 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

 
Reply With Quote
 
 
 
 
Grizlyk
Guest
Posts: n/a
 
      01-16-2007
peter koch wrote:

> 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.

> > 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"


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).

> > 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.


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.

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-16-2007
* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
Grizlyk
Guest
Posts: n/a
 
      01-16-2007
Alf P. Steinbach wrote:

> > 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.

> >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).


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.

 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      01-17-2007
charlie wrote:
> > > I found an article on informit.com that talks about C++ casts

> >
> > >http://www.informit.com/guides/conte...eqNum=285&rl=1


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) )

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-19-2007
On 14 Jan 2007 06:03:40 -0800, Grizlyk <(E-Mail Removed)> wrote:
> peter koch wrote:

....
>> If you want to disable e.g. copy constructing, this is defined by
>> having the constructor private and without an implementation:
>> private:
>> myclass(myclass const& );


.... [and NOT this]
>
>> private:
>> myclass(myclass const& ) {}

>
> 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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
 
Reply With Quote
 
Grizlyk
Guest
Posts: n/a
 
      01-19-2007
Jorgen Grahn wrote:

> > 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?


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?

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-20-2007
On 19 Jan 2007 06:11:35 -0800, Grizlyk <(E-Mail Removed)> wrote:
> Jorgen Grahn wrote:

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

>
> 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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
 
Reply With Quote
 
Grizlyk
Guest
Posts: n/a
 
      01-20-2007
Jorgen Grahn wrote:

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

> >
> > 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".


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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
checking casts Dan Upton Java 4 12-01-2005 06:20 PM
Web casts in ASP.Net =?Utf-8?B?Q2hyaXMgRGF2b2xp?= ASP .Net 1 10-19-2005 09:45 PM
Epson colour casts on duotones? Bruce Robbins Digital Photography 5 05-25-2004 03:41 AM
Needless casts? Joona I Palaste Java 15 04-25-2004 10:14 PM
Re: = operator should automatically perform appropriate casts cgbusch Java 2 07-08-2003 03:58 PM



Advertisments