By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,709 Members | 2,116 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,709 IT Pros & Developers. It's quick & easy.

Strange Article on C++ casts

P: n/a
Hi,

I found an article on informit.com that talks about C++ casts

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

The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);

and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.

Does anyone know what he's trying to say???

cheers,
/Charles

Jan 11 '07 #1
Share this Question
Share on Google+
28 Replies


P: n/a
charlie wrote:
The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);
and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.
Does anyone know what he's trying to say???
I'm almost sure that the author tries to say: "C++ sucks, my favorite
language is better"

--
Salu2
Jan 11 '07 #2

P: n/a


On Jan 11, 11:56 am, Julin Albo <JULIANA...@terra.eswrote:
charlie wrote:
The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);
and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.
Does anyone know what he's trying to say???I'm almost sure that the author tries to say: "C++ sucks, my favorite
language is better"

--
Salu2
<grinWell I would agree with you normally but he's a C++ guy. He's
even served on the C++ standards committee. So it seems to be a strange
mistake to make.

Jan 11 '07 #3

P: n/a
charlie wrote:
Hi,

I found an article on informit.com that talks about C++ casts

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

The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);
The code I actually found there was:

int n;
double d=15.95;
int n= static_cast<int(d);

which won't compile as the variable n is defined twice. Having removed
the first definition of n, the code compiles fine and does what it should.
and then he goes on to launch an attack against C++ casts.
Obviously he doesn't know anything about them and won't bother to look
into his textbook.
I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.

Does anyone know what he's trying to say???
Nope. Ignore him.

Regards,
Stuart
Jan 11 '07 #4

P: n/a
charlie wrote:
Hi,

I found an article on informit.com that talks about C++ casts

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

The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);

and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.

Does anyone know what he's trying to say???
That he doesn't know what he is talking about?

--
Ian Collins.
Jan 11 '07 #5

P: n/a


On Jan 11, 12:51 pm, Ian Collins <ian-n...@hotmail.comwrote:
charlie wrote:
Hi,
I found an article on informit.com that talks about C++ casts
http://www.informit.com/guides/conte...eqNum=285&rl=1
The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);
and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.
Does anyone know what he's trying to say???That he doesn't know what he is talking about?

--
Ian Collins.
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 :-)

/Charles

Jan 11 '07 #6

P: n/a

charlie skrev:
Hi,

I found an article on informit.com that talks about C++ casts

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

The strange thing is the author says the following code will *not*
compile:
double d=15.95;
int n= static_cast<int(d);
This snippet is perfectly ok, of course.
>
and then he goes on to launch an attack against C++ casts. I can't see
any reason why it shouldn't work and I tried with the MS and INTEL
compilers and it compiles with nary a problem.

Does anyone know what he's trying to say???
I've read some of the stuff he wrote at informit, and there are several
areas where stuff looked dubious (to be nice). To be nice to Danny
Kalev, there are also some articles that are okay. I believe that
getting on the C++ standards committee is possible even if you are a
far way from being an expert.

/Peter

Jan 11 '07 #7

P: n/a
peter koch wrote:
I believe that
getting on the C++ standards committee is possible even if you are a
far way from being an expert.
All you have to do is pay INCITS for the privelege. There are many
silent members.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Jan 11 '07 #8

P: n/a

Pete Becker skrev:
peter koch wrote:
I believe that
getting on the C++ standards committee is possible even if you are a
far way from being an expert.

All you have to do is pay INCITS for the privelege. There are many
silent members.
I expected something in that direction. How much money are we talking
about?

/Peter

Jan 11 '07 #9

P: n/a
peter koch wrote:
Pete Becker skrev:
>peter koch wrote:
>>I believe that
getting on the C++ standards committee is possible even if you are a
far way from being an expert.
All you have to do is pay INCITS for the privelege. There are many
silent members.

I expected something in that direction. How much money are we talking
about?
Currently, $800 per year. And I should have mentioned that INCITS is the
US organization. Other countries organize things differently.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Jan 11 '07 #10

P: n/a

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

We're all gonna die! Bwahaaaaa... ;)
Jan 11 '07 #11

P: n/a

charlie skrev:
[snip]
<grinWell I would agree with you normally but he's a C++ guy. He's
even served on the C++ standards committee. So it seems to be a strange
mistake to make.
I've been digging some more and found that he is an author of "The
ANSI/ISO C++ Professional Programmer's Handbook" which at accu.org was
reviewed as "Not recommended". Francis Glassborow begins his review
with:
"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)."
The review can be found at
http://accu.org/index.php/book_revie...2154&term=ansi

/Peter

Jan 11 '07 #12

P: n/a
charlie wrote:
I'm almost sure that the author tries to say: "C++ sucks, my favorite
language is better"
<grinWell I would agree with you normally but he's a C++ guy. He's
even served on the C++ standards committee. So it seems to be a strange
mistake to make.
My mistake, I blindly assumed it was some type of joke and don't clicked the
url, sorry.

--
Salu2
Jan 11 '07 #13

P: n/a

peter koch ():
The review can be found at
http://accu.org/index.php/book_revie...2154&term=ansi
"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"

What's ugly wrong with definitions of copy constructor and assignment
operator? They can be called in some cases by the object itself and
what the dangerous?

Jan 14 '07 #14

P: n/a

Grizlyk skrev:
peter koch ():
The review can be found at
http://accu.org/index.php/book_revie...2154&term=ansi

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

What's ugly wrong with definitions of copy constructor and assignment
operator? They can be called in some cases by the object itself and
what the dangerous?
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 as was apparantly done give it a body:
private:
myclass(myclass const& ) {}

/Peter

Jan 14 '07 #15

P: n/a
peter koch wrote:

What's ugly wrong with definitions of copy constructor and assignment
operator? They can be called in some cases by the object itself and
what the dangerous?

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& );
Are you shure, the compiler will not request (as error or warning) to
define "myclass(myclass const& )"? It is good stuff, but as i can
rememver, in old compilers were troubles with it (errors or warnings),
i am not shure.
private:
myclass(myclass const& ) {}
No, not of course, do like this:
private:
myclass(myclass const& )throw(Myerror&) { throw Terr_private(
typeid(*this).name() ); }

Jan 14 '07 #16

P: n/a

Grizlyk skrev:
peter koch wrote:
>
What's ugly wrong with definitions of copy constructor and assignment
operator? They can be called in some cases by the object itself and
what the dangerous?
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& );

Are you shure, the compiler will not request (as error or warning) to
define "myclass(myclass const& )"? It is good stuff, but as i can
rememver, in old compilers were troubles with it (errors or warnings),
i am not shure.
Yes I am sure. What old compilers did or did not is irrelevant here.
>
private:
myclass(myclass const& ) {}

No, not of course, do like this:
private:
myclass(myclass const& )throw(Myerror&) { throw Terr_private(
typeid(*this).name() ); }
That can never be correct. If anything, an abort is in place.

/Peter

Jan 14 '07 #17

P: n/a
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 :)

Look
1. I am not "Danny Kalev".
2. I am not going to buy his book now or in future.

But the notes of "Francis Glassborow" here
http://accu.org/index.php/book_revie...2154&term=ansi

looks like personal attack. "he is just not with Us" - sad "Francis
Glassborow" with long explanations. In general it is not enough to be
wrong.

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

There are tons of thrash, named as "became C++ expert for one our" or
"take our beer, wait just twenty years and you are C++ expert now". It
is possible, some of them were written by people from "C++ Standards
Committees" :)

If the "comettee" does not agreed with the ideas of the book in general
or in concretes cases,
the comettee even can gather and make issue of the note, if "comettee"
may do it and it is important.

If the "Francis Glassborow" care only of honor of the comettee as
private man, he just can say, that ideas of
any private member of "comettee" can not be treated even as unofficial
opinion of the "comettee",
and always better give list of errors.

Jan 15 '07 #18

P: n/a

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.
My (silly) suggestion to call abort was meant to be used in the
unlikely event someone should stumble over a compiler where you were
forced to implement the copy-constructor. But I've never seen or heard
about such a compiler, and considering the trickery involved in
implementing such a beast and the problem to find any real codebase
that would compile, I must say I find that most unlikely to ever
happen.
>
Look
1. I am not "Danny Kalev".
2. I am not going to buy his book now or in future.

But the notes of "Francis Glassborow" here
http://accu.org/index.php/book_revie...2154&term=ansi

looks like personal attack. "he is just not with Us" - sad "Francis
Glassborow" with long explanations. In general it is not enough to be
wrong.

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.
>
There are tons of thrash, named as "became C++ expert for one our" or
"take our beer, wait just twenty years and you are C++ expert now". It
is possible, some of them were written by people from "C++ Standards
Committees" :)
Actually, Danny Kalev was such a member: as noted elsewhere in this
thread it only requires paying a modest fee to your national standard
organisation, at least in the US. While other members might also write
bad books, chances are that they will not make such obvious errors as
generously provided by Kalev.
>
If the "comettee" does not agreed with the ideas of the book in general
or in concretes cases,
the comettee even can gather and make issue of the note, if "comettee"
may do it and it is important.

If the "Francis Glassborow" care only of honor of the comettee as
private man, he just can say, that ideas of
any private member of "comettee" can not be treated even as unofficial
opinion of the "comettee",
and always better give list of errors.
This is not a matter of taste or agreement. The book is simply
objectively wrong and thats it.

/Peter

Jan 15 '07 #19

P: n/a
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 :)

It is possible, "private member as throw error" is ancient error, but
agree, so longlife invisible "error" easy prove, that "error" is not
error. Really, it is does not metter for practiacal use, "to define
private member as throw error" or "to not define private member" (i see
differences), but yes, last is more smart solution and in general
better. I feel a reason to change my tradition :)

The worst way is "defining private member as empty code" or "defining
private member as calling exit() or abort()": both is ugly wrong.
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".
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.

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.
This is not a matter of taste or agreement. The book is simply
objectively wrong and thats it.
It is possible, i do not see the book. And i am not going to do it.

Jan 16 '07 #20

P: n/a

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

Jan 16 '07 #21

P: n/a
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.

Jan 16 '07 #22

P: n/a
* 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?
Jan 16 '07 #23

P: n/a
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.

Jan 16 '07 #24

P: n/a
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) )

Jan 17 '07 #25

P: n/a
On 14 Jan 2007 06:03:40 -0800, Grizlyk <gr******@yandex.ruwrote:
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!
Jan 19 '07 #26

P: n/a
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?

Jan 19 '07 #27

P: n/a
On 19 Jan 2007 06:11:35 -0800, Grizlyk <gr******@yandex.ruwrote:
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!
Jan 20 '07 #28

P: n/a
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"?

Jan 20 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.