Topic: Abandonment of aggregate types
Author: kuyper@wizard.net
Date: Fri, 25 Aug 2006 11:53:17 CST Raw View
SuperKoko wrote:
> kuyper@wizard.net wrote:
> > Frederick Gotham wrote:
> > > posted:
> > >
> > > > There are two plausible expectations for the meaning of "int *p, q;"
> > >
> > >
> > > One either knows C++ well, or they don't. If one doesn't know the meaning of
> > > that definition, then one is less-than-excellent.
> >
> > Yes, and every programmer I've ever met, or whose code I've ever had to
> > maintain, have been less-than-excellent, myself certainly included.
> >
> Must I understand that nowadays, programmers don't learn the syntax of
> their language!
Sure. They learn the syntax well enough to pass tests, and to write
code which, after using the compiler to identify the problems it can
identify, is likely to work properly. However, it takes time for new
programmers to progress to the point where they never get confused by
the syntax of the language. From my personal experience, I'm almost
always learning at least one new language that I'm not yet an expert
in; after 30 years of programming, that's a couple of dozen languages,
but the only one I'm a complete master of is C. For many people,
including myself, one of the languages they haven't completely mastered
yet is C++. For me, that lack of mastery is mainly due to the fact that
I've been employed for the last decade on a project where C++ isn't one
of the languages permitted in delivered code, by our contract with our
client.
> That's a shame either due to incompetence of programmers or of books &
> manuals (I think that any good manual should contain a syntax summary
> in BNF or EBNF form as annex).
> But I guess that reading the manual is only good for old experienced
> programmers...
> Or does this mean that C++ manuals are so big that nobody can read
> them?
C++ is a moderately complicated language with a very complicated
standard library. If you know anyone who's completely familiar with
every feature of both the language and the library, that person
probably has had quite a few years of real-world experience using them.
He didn't get it just from reading the manuals.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: giecrilj@stegny.2a.pl ("K i tof elechovski")
Date: Sat, 26 Aug 2006 20:22:54 GMT Raw View
> Your way of doing it gives a false impression -- it implies that the
> asterisks and ampersands are part of the type's name. This leads to a the
> beginner naively making the following definition:
>
> (T*) &p_t
>
Does not if the beginner knows that a type designator, once parenthesized,
ceases designating a type and starts to designate a C-style cast operator.
You cannot place parntheses around everything you like even though it would
sometimes improve readability. Sorry.
Chris
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Sun, 27 Aug 2006 17:03:48 GMT Raw View
"K=F8i=B9tof =AEelechovski" posted:
>> Your way of doing it gives a false impression -- it implies that the
>> asterisks and ampersands are part of the type's name. This leads to a
>> the beginner naively making the following definition:
>>
>> (T*) &p_t
>>
>=20
> Does not if the beginner knows that a type designator, once
> parenthesized, ceases designating a type and starts to designate a
> C-style cast operator. You cannot place parntheses around everything yo=
u
> like even though it would sometimes improve readability. Sorry.
Are you saying sorry to me, or to Bo? I'm the one who pointed out that:
(T*)&p_t
is a syntax error (in the context of a declaration).
Whether Bo likes it or not, the grammar of C++ is such that the asterisks=
,=20
ampersands, function parentheses and square brackets appear as if they're=
a=20
part of the object/function's name, as evident from:
int (*&Func())[5]
{
int static arr[5] =3D {};
int static (*p)[5] =3D &arr;
return p;
}
--=20
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: bop@gmb.dk ("Bo Persson")
Date: Mon, 28 Aug 2006 14:02:38 GMT Raw View
"Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
news:6geIg.13162$j7.326777@news.indigo.ie...
> Whether Bo likes it or not, the grammar of C++ is such that the
> asterisks,
> ampersands, function parentheses and square brackets appear as if
> they're a
> part of the object/function's name, as evident from:
>
> int (*&Func())[5]
> {
I see that you are trying to get in shape for the next Obfuscated C
Contest. :-)
May I present another piece of evidence:
void f(int x);
void g(int const*const&y);
Do you claim that the functions f and g both take int parameters, with
just different parameter names?
I believe the parameter's names are x and y, and that their types are
different.
I can write, for example
typedef int x_type;
typedef int const*const& y_type;
void f(x_type x);
void g(y_type y);
Doesn't the typedef name the type, and not the object? How could * and
& sometimes be part of the type, and sometimes be part of the object's
name? It simply cannot!
Bo Persson
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Mon, 28 Aug 2006 10:18:49 CST Raw View
Frederick Gotham wrote:
> Whether Bo likes it or not, the grammar of C++ is such that
> the asterisks, ampersands, function parentheses and square
> brackets appear as if they're a part of the object/function's
> name,
I'm sorry, but it just isn't so. Grammatically, they are part
of the declarator, but that doesn't change the fact that in:
T*& rpt ;
1) there is no object or function being declared, but a
reference,
2) the name of the reference is rpt, and that name contains no
punctuation, and
3) the type of rpt is reference to pointer to T, in other words:
T*&.
This is one place where the grammar is counter-intuitive; the
grammar groups one way, and the semantic another. But in C++, a
name cannot contain punctuation, other that "::" (in which case,
it is a qualified name, which is not just a name).
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Mon, 28 Aug 2006 11:33:05 CST Raw View
SuperKoko wrote:
> kuyper@wizard.net wrote:
> > Frederick Gotham wrote:
> > > posted:
> > > > There are two plausible expectations for the meaning of
> > > > "int *p, q;"
> > > One either knows C++ well, or they don't. If one doesn't
> > > know the meaning of that definition, then one is
> > > less-than-excellent.
> > Yes, and every programmer I've ever met, or whose code I've
> > ever had to maintain, have been less-than-excellent, myself
> > certainly included.
> Must I understand that nowadays, programmers don't learn the
> syntax of their language!
No. It means that programmers are human beings, and far from
perfect. And that on typical projects, you need a wide variety
of programmers. I couldn't write 90% of what programmers here
write; I don't have the banking knowledge. On the other hand,
most of the bank specialists don't know all of the subtilities
of C++ (or of threading, or of any number of other technical
issues). We work together, to produce what I think is
relatively good code, but it's still far from perfect. And
anything we can do to make it easier for the banking experts to
avoid silly C++ errors, we do it. And statements like the
above, which make me stop and have to think (and I've 25 years
of experience in C and C++), are simply banned. If I can't
understand it without having to think about it, the others
certainly won't be able to either.
[...]
> I agree with the fact that it's better to use the One True
> Style form, but I thought that any sensible C++ programmer can
> understand both form!
I suspect that most of the C++ programmers here have never seen
a declaration with two variables in it, and many are probably
unaware that it exists. Thus, they would never write it, and if
they encountered it in foriegn code, they would come to me for
an explination. And I'd have to teach them some totally
worthless trivia just so that the could understand it.
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: themattfella@xxyyyzzzz.com (Matt)
Date: Wed, 23 Aug 2006 03:45:10 GMT Raw View
Francis Glassborow wrote:
> In article <Mh8Gg.8014$oa1.7930@news02.roc.ny>, Matt
> <themattfella@xxyyyzzzz.com> writes
>
>> Frederick Gotham wrote:
>>
>>> ===================================== MODERATOR'S COMMENT:
>>> The C++ FAQ (you did read the FAQ before posting the first time,
>>> didn't you?) has a great deal of information about the C++ Committee
>>> and how to join.
>>>
>>> ===================================== END OF MODERATOR'S COMMENT
>>
>>
>> Where is the mentioned "C++ FAQ"? I don't see it at
>> http://www.faqs.org/faqs/by-newsgroup/comp/
>> Or maybe you meant the FAQ for some group other than comp.std.c++.
>
> Read the last line of the comp.std.c++ banner that appears at the foot
> of every post here.
>
Aha, well, thanks.
Some community-minded individual who knows how should arrange to have
the link listed for comp.std.c+++ at www.faqs.org, thus making that
pointer a static member, so to speak.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: bop@gmb.dk ("Bo Persson")
Date: Wed, 23 Aug 2006 04:58:33 GMT Raw View
"Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
news:YviGg.12900$j7.325124@news.indigo.ie...
> Dave Steffen posted:
>
>> T::T( (T*)& p_t) { p_t = this }
>>
>> (e.g. pass a reference to a pointer to T)
>
> In a declaration, asterisks, ampersands, square brackets, etc. are
> part of
> the object or function's name, NOT part of the type's name,
> therefore:
I am surprised that the moderation process would let this blasfemy
pass. Don't listen to the false profet!
>
> (T*) &p_t
>
> is a syntax error.
No, it is not. It is an expression with a type cast, which is not
allowed in a parameter list. In other places it is ok.
> You want:
>
> T *&p_t
No, you definitely want
T*& p_t
>
> The following forms which contain redundant parentheses are also
> valid:
>
> typedef int T;
>
> T *p;
T* p;
>
> T *&p0 = p;
T*& p0 = p;
>
> T *(&p1) = p;
T*& (p1) = p; // What's the big deal?
>
> T (*&p2) = p;
T*& (p2) = p;
>
> T (*(&p3)) = p;
T*& ((p3)) = p;
T*& ((((((((((p4)))))))))) = p; // Almost as good as LISP!
If you use the One True Style(tm), there is never a problem with
declarations. You first fully specify the type, and then the name.
Don't forget the three spaces in between. :-)
Bo Persson
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "SuperKoko" <tabkannaz@yahoo.fr>
Date: Wed, 23 Aug 2006 09:34:11 CST Raw View
"Bo Persson" wrote:
> "Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
> news:YviGg.12900$j7.325124@news.indigo.ie...
> > Dave Steffen posted:
> >
> >> T::T( (T*)& p_t) { p_t = this }
> >>
> >> (e.g. pass a reference to a pointer to T)
> >
> > In a declaration, asterisks, ampersands, square brackets, etc. are
> > part of
> > the object or function's name, NOT part of the type's name,
> > therefore:
>
> I am surprised that the moderation process would let this blasfemy
> pass. Don't listen to the false profet!
>
> >
> > (T*) &p_t
> >
> > is a syntax error.
>
> No, it is not. It is an expression with a type cast, which is not
> allowed in a parameter list. In other places it is ok.
>
mhhh, It seems obvious to me that the statement of Frederick Gotham
applied in the context of a parameter declaration.
>
> > You want:
> >
> > T *&p_t
>
> No, you definitely want
>
> T*& p_t
>
What's the difference? Whitespaces are optionnal here. It's only a
stylistical difference.
> >
> > The following forms which contain redundant parentheses are also
> > valid:
> >
> > typedef int T;
> >
> > T *p;
>
> T* p;
>
> >
> > T *&p0 = p;
>
> T*& p0 = p;
>
> >
> > T *(&p1) = p;
>
> T*& (p1) = p; // What's the big deal?
>
> >
> > T (*&p2) = p;
>
> T*& (p2) = p;
>
> >
> > T (*(&p3)) = p;
>
> T*& ((p3)) = p;
>
> T*& ((((((((((p4)))))))))) = p; // Almost as good as LISP!
>
>
Why do you want to correct a stylistical issue!
I am neutral on this issue. I don't want to enter a religious war.
> If you use the One True Style(tm), there is never a problem with
> declarations. You first fully specify the type, and then the name.
>
mhhh, so, what's the meaning of:
int* p,q;
For you!
And how do you declare arrays, functions or pointer to functions?
int[42] x; // ??????
> Don't forget the three spaces in between. :-)
>
Why? They're usually optional.
The base type must be specified first (not the full type), then a
comma-separated list of identifiers with type modifiers can be
specified.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: m@remove.this.part.rtij.nl (Martijn Lievaart)
Date: Wed, 23 Aug 2006 16:13:16 GMT Raw View
On Tue, 22 Aug 2006 14:46:22 +0000, Harald van D=C4=B3k wrote:
> And there are legitimate reasons for an object to store a pointer to it=
self
> elsewhere during construction. An easy example is a call to
> parent.insert(this);.
True, but if the object is const *and* the above call makes it possible t=
o
retrieve a non-const pointer to the object, you just showed another
example of the problem.
IMO it *is* a leak in the type system. One that is needed, and useful, bu=
t
a leak nevertheless.
M4
--=20
Redundancy is a great way to introduce more single points of failure.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Wed, 23 Aug 2006 11:14:24 CST Raw View
"Bo Persson" wrote:
> "Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
> news:YviGg.12900$j7.325124@news.indigo.ie...
> > Dave Steffen posted:
> >> T::T( (T*)& p_t) { p_t = this }
> >> (e.g. pass a reference to a pointer to T)
> > In a declaration, asterisks, ampersands, square brackets,
> > etc. are part of the object or function's name, NOT part of
> > the type's name, therefore:
> I am surprised that the moderation process would let this blasfemy
> pass. Don't listen to the false profet!
Moderation does not (or should not) judge technical content.
The statement (in context) is not off topic, and doesn't flame
anyone, so it passes.
In fact, I think I can figure out what Frederick was trying to
say; I think the problem is more one of his using non-standard
(and misleading) vocabulary, rather than a technical error on
his part. In standardese, what he is saying (I think) is that
asterisks, ampersands, square brackets, etc. are part of the
declarator, and not part of the declaration specifier. But I
can easily imagine someone not too familiar with C or C++
falling back on the terms he used, for lack of knowledge of any
more "correct" term.
> > (T*) &p_t
> > is a syntax error.
> No, it is not. It is an expression with a type cast, which is not
> allowed in a parameter list. In other places it is ok.
The C++ grammar isn't context free. In the context where this
token sequence occurred in the posting in question, it was not
an expression with a type cast. It was a syntax error.
You cannot take a token sequence out of context, and say that it
is or is not an expression. If T is not the name of a type, it
is also a syntax error, for example, even in a context where it
would be an expression if T were a type.
This is a well known defect in C++.
> > You want:
> > T *&p_t
> No, you definitely want
> T*& p_t
Which is exactly the same thing. White space between tokens,
when not necessary to separate them, is meaningless in C++.
> > The following forms which contain redundant parentheses are also
> > valid:
No body said otherwise. None of your examples have parentheses
that encompass part of the declaration specifier.
[...]
> If you use the One True Style(tm), there is never a problem
> with declarations. You first fully specify the type, and then
> the name.
I'm not sure I understand what you are saying. C++ doesn't
allow fully specifying the type before the name.
> Don't forget the three spaces in between. :-)
In the One True Style, what is being named is always aligned at
the 20th column to the right of normal indentation:
int i ;
std::vector< int >::const_iterator
vi ;
int (C::* pmf)() ;
and so on. (In some contexts, it may be preferrable to align
the names further to the right. But they are always aligned.)
Makes it simpler to find what is being declared, and to
distinguish between declarations and expressions. (Regretfully,
the compiler doesn't understand such distinctions, and decides
whether something is a declaration or an expression according to
some other, considerably less visible criteria.)
Really cool programmers will also align the semicolons, as I've
done above.
(Lots of :-), of course.)
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Harald van =?UTF-8?B?RMSzaw==?= <truedfx@gmail.com>
Date: Wed, 23 Aug 2006 11:27:55 CST Raw View
Martijn Lievaart wrote:
> On Tue, 22 Aug 2006 14:46:22 +0000, Harald van D k wrote:
>
>> And there are legitimate reasons for an object to store a pointer to
>> itself elsewhere during construction. An easy example is a call to
>> parent.insert(this);.
>
> True, but if the object is const *and* the above call makes it possible to
> retrieve a non-const pointer to the object, you just showed another
> example of the problem.
>
> IMO it *is* a leak in the type system. One that is needed, and useful, but
> a leak nevertheless.
Yes, that was what I was saying as well (except possibly for the "needed"
part). Sorry if I wasn't clear enough.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: bop@gmb.dk ("Bo Persson")
Date: Wed, 23 Aug 2006 17:41:49 GMT Raw View
"SuperKoko" <tabkannaz@yahoo.fr> skrev i meddelandet
news:1156340459.919321.93260@74g2000cwt.googlegroups.com...
>
> "Bo Persson" wrote:
>> "Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
>
>>
>> > You want:
>> >
>> > T *&p_t
>>
>> No, you definitely want
>>
>> T*& p_t
>>
> What's the difference? Whitespaces are optionnal here. It's only a
> stylistical difference.
No, it's a religious thing. :-)
We have always wondered whether to write
int* p; // p is a pointer to an int
or
int *p; // *p is an integer
Or, even more important, do you write
const int i;
or
int const i;
??
Now Frederick said that *&p_t is of type T. I claim that p_t is
_obviously_ a reference to s pointer to T.
What if we add some const specifiers
T const*const&p_t
Now T is a type, and const*const&p_t is the name of the parameter?
Come on!
>
>> If you use the One True Style(tm), there is never a problem with
>> declarations. You first fully specify the type, and then the name.
>>
> mhhh, so, what's the meaning of:
> int* p,q;
I don't know, I would never write anything like that.
First you specify the type, then the name, Why would you have two
names?
>
> And how do you declare arrays, functions or pointer to functions?
> int[42] x; // ??????
std::vector<int> x;
I wouldn't use x as a name anyway, it should be long and descriptive.
And using ProperCase, of course.
>
>> Don't forget the three spaces in between. :-)
>>
> Why? They're usually optional.
So the language standard isn't strict enough. It ought to be!
> The base type must be specified first (not the full type), then a
> comma-separated list of identifiers with type modifiers can be
> specified.
Blasphemy!
(This time I looked the spelling up :-)
Bo Persson
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Wed, 23 Aug 2006 12:43:17 CST Raw View
SuperKoko wrote:
[...]
> mhhh, so, what's the meaning of:
> int* p,q;
That the program doesn't know or care what he is doing, and is
setting a maintenance trap for the people following him. For
historical reasons, C++ allows such declarations, but nothing
requires you do use them.
[...]
> The base type must be specified first (not the full type),
It's a bit more complicated than that. You can add *some* type
modifiers (like const) before the base type, if you want.
(Again, it's not something I would do in practice.)
And of course, once there are typedef's, what does the "base
type" even mean.
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Frederick Gotham <fgothamNO@SPAM.com>
Date: Wed, 23 Aug 2006 14:27:34 CST Raw View
kanze posted:
> SuperKoko wrote:
>
> [...]
>> mhhh, so, what's the meaning of:
>> int* p,q;
>
> That the program doesn't know or care what he is doing, and is
> setting a maintenance trap for the people following him. For
> historical reasons, C++ allows such declarations, but nothing
> requires you do use them.
Depends who he/she expects to maintain their code. If somebody does not what
the following line does:
int *p, *q;
, then they're very unlikely to understand the vast majority of my code.
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Wed, 23 Aug 2006 20:18:43 GMT Raw View
===================================== MODERATOR'S COMMENT:
First of all, as explained in the newsgroup FAQ list, and by a comment from me
in an eariler post, the moderator's job is defined by the newsgroup charter. We
don't reject a post based on the quality of argument or correctness of opinion.
If the post is understandable, is on-topic, and does not contain a personal
attack, it is accepted. The newsgroup participants are capable of pointing out
errors, and are quick to do so.
Secondly, failure of a post to appear does not mean a moderator has fallen down
on the job. The newsgroup FAQ list has several items about lost and delayed
posts, and what to do about them. Please read the FAQ list.
===================================== END OF MODERATOR'S COMMENT
"Bo Persson" posted:
NOTE: I have already replied to this, but for some idiotic reason, it wasn't
let through (or maybe it's another case of my posts showing up three days
later -- either way, the moderators are doing a bad job).
> I am surprised that the moderation process would let this blasfemy
> pass. Don't listen to the false profet!
Your understanding is false. Mine is true, and is re-enforced by the
following:
int *p, *q, r[5], (*s)[5], *t[5], Func(), *Func2();
p is a pointer.
q is a pointer.
r is an array of five.
s is a pointer to an array of five.
t is an array of five pointers.
Func is a function which returns an int.
Func2 is a function which returns a pointer to an int.
>> (T*) &p_t
>>
>> is a syntax error.
>
> No, it is not. It is an expression with a type cast, which is not
> allowed in a parameter list. In other places it is ok.
Ever heard of context? The following is an ill-formed definition:
(T*) &p_t
>> You want:
>>
>> T *&p_t
>
> No, you definitely want
>
> T*& p_t
Convince him.
> If you use the One True Style(tm), there is never a problem with
> declarations. You first fully specify the type, and then the name.
Your way of doing it gives a false impression -- it implies that the
asterisks and ampersands are part of the type's name. This leads to a the
beginner naively making the following definition:
(T*) &p_t
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: v.Abazarov@comAcast.com ("Victor Bazarov")
Date: Wed, 23 Aug 2006 20:49:38 GMT Raw View
SuperKoko wrote:
> "Bo Persson" wrote:
> [..]
>> Don't forget the three spaces in between. :-)
>>
> Why? They're usually optional.
>
Koko, you need to lighten up. Notice the smiley.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: bop@gmb.dk ("Bo Persson")
Date: Wed, 23 Aug 2006 21:10:22 GMT Raw View
"Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
news:DO1Hg.13005$j7.325536@news.indigo.ie...
>
> NOTE: I have already replied to this, but for some idiotic reason,
> it wasn't
> let through (or maybe it's another case of my posts showing up three
> days
> later -- either way, the moderators are doing a bad job).
I think the moderators do a good job - most often my silly remarks are
not let though. :-)
In this case I believe that I have a point though, something about C++
being a multi paradigm language. There really is no One True
Style(tm), it depends on how we use the language, and what paradigm we
subscribe to.
>
>
>> I am surprised that the moderation process would let this blasfemy
>> pass. Don't listen to the false profet!
>
>
> Your understanding is false. Mine is true, and is re-enforced by the
> following:
>
> int *p, *q, r[5], (*s)[5], *t[5], Func(), *Func2();
>
> p is a pointer.
> q is a pointer.
> r is an array of five.
> s is a pointer to an array of five.
> t is an array of five pointers.
> Func is a function which returns an int.
> Func2 is a function which returns a pointer to an int.
I agree that this is allowed by the language because of its
inheritance, but also believe that we should not use it this way -
it's a C-ism. This is where it gets religious! Some things are
possible, but should be avoided anyway. On "moral" grounds perhaps?
>
>>> You want:
>>>
>>> T *&p_t
>>
>> No, you definitely want
>>
>> T*& p_t
>
>
> Convince him.
Convice who? This is what triggered my response.
In my mind, this is similar to "should I be a catholic or a
protestant?". How do we know what is right? Could they both be true?
If I'm a protestant, should I be a baptist, or a member of the
Salvation Army? Don't know.
Perhaps I use C++ very much like "C with classes", because that is how
I once learned programming, in Simula (Algol with classes). There we
had the interesting parameter "modes" pass-by-name, pass-by-value, and
pass-by-reference. I never though of the parameter passing as part of
the type.
>
>> If you use the One True Style(tm), there is never a problem with
>> declarations. You first fully specify the type, and then the name.
>
>
> Your way of doing it gives a false impression -- it implies that the
> asterisks and ampersands are part of the type's name.
And they are. :-)
That's why I used "blasphemy", because we both now that we are right
and the other one is wrong. Perhaps it didn't come out exactly as I
imagined - sarcasm is difficult in your second language.
Bo Persson
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: kuyper@wizard.net
Date: Wed, 23 Aug 2006 21:06:55 CST Raw View
Frederick Gotham wrote:
> kanze posted:
>
> > SuperKoko wrote:
> >
> > [...]
> >> mhhh, so, what's the meaning of:
> >> int* p,q;
> >
> > That the program doesn't know or care what he is doing, and is
> > setting a maintenance trap for the people following him. For
> > historical reasons, C++ allows such declarations, but nothing
> > requires you do use them.
>
>
> Depends who he/she expects to maintain their code. If somebody does not what
> the following line does:
>
> int *p, *q;
>
> , then they're very unlikely to understand the vast majority of my code.
There are two plausible expectations for the meaning of "int *p, q;",
only one of which is correct, and programmers who are only moderately
experienced are occasionally confused as to which one it is. If using
such a declaration is typical of your coding style, then you're
ensuring that no one of that skill level can be relied on to handle
even minor maintenance of your code, unnecessarily increasing the costs
of such maintenance. Highly skilled and experienced programmers are
rare, and correspondingly expensive, and shouldn't be needed for minor
maintenance tasks; code that's written to only be maintained by such
people is essentially "write-once" code.
I speak as someone who has written "write-once" code more often than I
should have; my employer has suffered some unnecessary problems as a
result of that fact.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Thu, 24 Aug 2006 16:33:27 GMT Raw View
posted:
> There are two plausible expectations for the meaning of "int *p, q;"
One either knows C++ well, or they don't. If one doesn't know the meaning of
that definition, then one is less-than-excellent.
> If using such a declaration is typical of your coding style, then you're
> ensuring that no one of that skill level can be relied on to handle even
> minor maintenance of your code, unnecessarily increasing the costs of
> such maintenance.
We discuss C++ here, not business or industry. Perhaps they're should be a
new newsgroup set up, comp.lang.c++.business, where people can discuss all
sorts of magnificent ways to dumb down their code in order to reduce costs.
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Thu, 24 Aug 2006 11:39:59 CST Raw View
Frederick Gotham wrote:
[...]
> NOTE: I have already replied to this, but for some idiotic
> reason, it wasn't let through (or maybe it's another case of
> my posts showing up three days later -- either way, the
> moderators are doing a bad job).
The moderator has already responded to the technical points.
I'd just like to add that I think they are doing a very good
job.
> > I am surprised that the moderation process would let this
> > blasfemy pass. Don't listen to the false profet!
> Your understanding is false. Mine is true,
Not as you expressed it. See my response to this posting: I
think that what you are trying to say is true, but you certainly
got the vocabulary mixed up, resulting in a statement that was
false.
[...]
> >> You want:
> >> T *&p_t
> > T*& p_t
> Convince him.
I think that the simley that came later applied to this as well.
(If I recall right, Stroustrup writes "T* p;", and not "T *p;".)
> > If you use the One True Style(tm), there is never a problem with
> > declarations. You first fully specify the type, and then the name.
> Your way of doing it gives a false impression -- it implies
> that the asterisks and ampersands are part of the type's name.
They do belong to the type's name. The type's name is
"reference to pointer to T", in C++-ese: T*&. They aren't part
of the declaration-spec, however. And for historical reasons,
you can declare symbols with different types (and thus different
type names) is a single declaration. It's a misfeature, but
then, I think the whole declaration syntax is a misfeature
(inherited from C). (And I'm not alone: Bjarne Stroustrup has
characterized the the C declarator syntax as an "experiment that
failed".)
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Thu, 24 Aug 2006 11:39:09 CST Raw View
kuyper@wizard.net wrote:
> Frederick Gotham wrote:
> > kanze posted:
> > > SuperKoko wrote:
> > > [...]
> > >> mhhh, so, what's the meaning of:
> > >> int* p,q;
> > > That the program doesn't know or care what he is doing, and is
> > > setting a maintenance trap for the people following him. For
> > > historical reasons, C++ allows such declarations, but nothing
> > > requires you do use them.
> > Depends who he/she expects to maintain their code. If
> > somebody does not what the following line does:
> > int *p, *q;
> > , then they're very unlikely to understand the vast majority of my code.
> There are two plausible expectations for the meaning of "int *p, q;",
The only one I can see is that the programmer is ignoring all
usual coding guidelines, and unless he changes, he should be
fired. Such code doesn't get through code review, so it doesn't
matter what the compiler thinks of it.
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "SuperKoko" <tabkannaz@yahoo.fr>
Date: Thu, 24 Aug 2006 11:40:56 CST Raw View
"Bo Persson" wrote:
> "SuperKoko" <tabkannaz@yahoo.fr> skrev i meddelandet
> news:1156340459.919321.93260@74g2000cwt.googlegroups.com...
> >
> > "Bo Persson" wrote:
> >> "Frederick Gotham" <fgothamNO@SPAM.com> skrev i meddelandet
> >
> >>
> >> > You want:
> >> >
> >> > T *&p_t
> >>
> >> No, you definitely want
> >>
> >> T*& p_t
> >>
> > What's the difference? Whitespaces are optionnal here. It's only a
> > stylistical difference.
>
> No, it's a religious thing. :-)
>
ok
I respect both religions.
> >
> >> If you use the One True Style(tm), there is never a problem with
> >> declarations. You first fully specify the type, and then the name.
> >>
> > mhhh, so, what's the meaning of:
> > int* p,q;
>
> I don't know, I would never write anything like that.
>
> First you specify the type, then the name, Why would you have two
> names?
>
Ok, I didn't read your post correctly "and then THE name"... It implies
that there is a single name, so you're right if you use the One True
Style(TM).
>
> >
> > And how do you declare arrays, functions or pointer to functions?
> > int[42] x; // ??????
>
> std::vector<int> x;
>
You should have specified : "And don't declare arrays".
Now, I wonder how you declare functions (including member functions)!
I guess that the One True Style(TM) doesn't apply to function
declarations or that you use typedefs... But in the typedef, how do you
declare the function type? :p
(Don't take that religiously, here, I'm joking).
ok, so I guess that it's only for variable declarations.
> I wouldn't use x as a name anyway, it should be long and descriptive.
> And using ProperCase, of course.
>
That was only an example... Nobody names his variables x, y, foo, bar,
foobar, baz... But you can see a lot of code examples using these
names.
> >
> >> Don't forget the three spaces in between. :-)
> >>
> > Why? They're usually optional.
>
> So the language standard isn't strict enough. It ought to be!
>
I don't think so... I don't like that the language impose a particular
style.
And why not imposing the K&R braces style? Or any other particular
indentation style?
>
> > The base type must be specified first (not the full type), then a
> > comma-separated list of identifiers with type modifiers can be
> > specified.
>
> Blasphemy!
>
I didn't give a guideline. I only gave simplified rules of the language
itself. My intent was not at all religious.
In fact, myself, I use the One True Style. I just said that, at least
from a language standard point-of-view, the other styles are
syntaxically valid.
kanze wrote:
> It's a bit more complicated than that. You can add *some* type
> modifiers (like const) before the base type, if you want.
> (Again, it's not something I would do in practice.)
>
Yes I only gave simplified rules to make it the most similar possible
with Bo Persson's description of how type declarations must be done.
There are also storage-class-specifiers, etc.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: kuyper@wizard.net
Date: Thu, 24 Aug 2006 12:38:43 CST Raw View
Frederick Gotham wrote:
> posted:
>
> > There are two plausible expectations for the meaning of "int *p, q;"
>
>
> One either knows C++ well, or they don't. If one doesn't know the meaning of
> that definition, then one is less-than-excellent.
Yes, and every programmer I've ever met, or whose code I've ever had to
maintain, have been less-than-excellent, myself certainly included.
I envy you for working in an evironment where only excellent
programmers are ever hired. But your employer must have a lot of money
to burn if it can afford to hire only excellent programmers. Before
they became excellent, some other employer had to provide them with the
years of experience and training that they needed to become excellent,
and that's where employers with limited budgets come in. In the real
world, employers have a competitive edge if they can figure out how to
make effective use of the less-than-excellent skills of those who
haven't been working long enough to become excellent, or whose native
ability is such that they may never become excellent. And one way to do
that is to promote and enforce coding guidelines designed to make sure
that future less-than-excellent programmers will be able to maintain
your code.
> > If using such a declaration is typical of your coding style, then you're
> > ensuring that no one of that skill level can be relied on to handle even
> > minor maintenance of your code, unnecessarily increasing the costs of
> > such maintenance.
>
>
> We discuss C++ here, not business or industry. Perhaps they're should be a
> new newsgroup set up, comp.lang.c++.business, where people can discuss all
> sorts of magnificent ways to dumb down their code in order to reduce costs.
I agree, this is a place for discussing the standard, not for
discussing best practice. Best practices is only on-topic for this
newsgroup, insofar as the design of the langauge makes it easier or
more difficult to implement those practices. As I understand it, James
Kanze was implying that the way "int *p,q;" is interpreted by C++ is in
fact a feature inherited from C, that gets in the way of good
programming practice, which makes it marginally on-topic. However, I
don't see any point in discussing it further.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dgsteffen@numerica.us (Dave Steffen)
Date: Thu, 24 Aug 2006 18:16:36 GMT Raw View
truedfx@gmail.com (Harald van D=FE=FF_3k) writes:
> Dave Steffen wrote:
> > I hold=20
> > that this is less egregious than many other, much more problematic
> > issues (such as the issues raised by Frank Gotham that started this
> > thread).
>=20
> Frederick, but no argument there.
Whoops, yes, my mistake. My apologies to Frederick, who is clearly
not Frank. :-)
----------------------------------------------------------------------
Dave Steffen, Ph.D. =20
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Thu, 24 Aug 2006 18:26:41 GMT Raw View
kanze posted:
>> There are two plausible expectations for the meaning of "int *p, q;",
>
> The only one I can see is that the programmer is ignoring all
> usual coding guidelines, and unless he changes, he should be
> fired. Such code doesn't get through code review, so it doesn't
> matter what the compiler thinks of it.
Why must so many discussions about programming be dragged down to a
discussion of business?
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Frederick Gotham <fgothamNO@SPAM.com>
Date: Thu, 24 Aug 2006 19:56:57 CST Raw View
kanze posted:
> I think that the simley that came later applied to this as well.
> (If I recall right, Stroustrup writes "T* p;", and not "T *p;".)
Last time I read his book, he also wrote i++ where ++i would have sufficed.
While I acknowledge his skill, I don't like his programming style in places.
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: kuyper@wizard.net
Date: Thu, 24 Aug 2006 19:57:38 CST Raw View
Frederick Gotham wrote:
> kanze posted:
>
> >> There are two plausible expectations for the meaning of "int *p, q;",
> >
> > The only one I can see is that the programmer is ignoring all
> > usual coding guidelines, and unless he changes, he should be
> > fired. Such code doesn't get through code review, so it doesn't
> > matter what the compiler thinks of it.
>
>
> Why must so many discussions about programming be dragged down to a
> discussion of business?
I don't see how that counts as a discussion of business. Coding
guidelines and code reviews are fundamentals of good system development
practices in any environment where many programmers are working
together on the same system, whether or not that system is intended to
be used in a business context. If James Kanze's comment about "he
should be fired" makes you think of business contexts, replace "fired"
with "removed from the project", which could apply equally well to
contexts such as FSF, where people can't be fired because they were
never hired in the first place.
The C++ standard will always be of disproportionate interest to those
who work in the kinds of environments where there are things like
coding guidelines and code reviews, because those guidelines are likely
to refer to the standard, and those reviews are likely to be used to
enforce conformance with the standard. If it bothers you that such
people want C++ to be designed with their needs in mind, I'd recommend
covering your ears and humming to yourself so you won't have to listen
while we discuss such issues. We won't lose interest in such issues
just because of your disapproval.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "SuperKoko" <tabkannaz@yahoo.fr>
Date: Fri, 25 Aug 2006 09:46:59 CST Raw View
kuyper@wizard.net wrote:
> Frederick Gotham wrote:
> > posted:
> >
> > > There are two plausible expectations for the meaning of "int *p, q;"
> >
> >
> > One either knows C++ well, or they don't. If one doesn't know the meaning of
> > that definition, then one is less-than-excellent.
>
> Yes, and every programmer I've ever met, or whose code I've ever had to
> maintain, have been less-than-excellent, myself certainly included.
>
Must I understand that nowadays, programmers don't learn the syntax of
their language!
That's a shame either due to incompetence of programmers or of books &
manuals (I think that any good manual should contain a syntax summary
in BNF or EBNF form as annex).
But I guess that reading the manual is only good for old experienced
programmers...
Or does this mean that C++ manuals are so big that nobody can read
them?
I agree with the fact that it's better to use the One True Style form,
but I thought that any sensible C++ programmer can understand both
form!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Fri, 25 Aug 2006 09:50:58 CST Raw View
Frederick Gotham wrote:
> kanze posted:
> > I think that the simley that came later applied to this as well.
> > (If I recall right, Stroustrup writes "T* p;", and not "T *p;".)
> Last time I read his book, he also wrote i++ where ++i would
> have sufficed.
So. Unlike the ++i vs. i++ issue, there have been no basic
changes to change the convention. (Anyway, my point was only
that there are competent programmers who prefer "T* p".)
> While I acknowledge his skill, I don't like his programming
> style in places.
Realistically, you'll probably never find anyone who agrees with
100% of your program style. (You is meant generically above,
not you personally, but anyone.) There are too many variants.
In this case, I believe I've also seen justifications:
basically, much of the change between C and C++ is about types.
And so while the grammar, for historical reasons, does
otherwise. Thus, the grammar says "T *p", or "T const *p",
or "const T *p", whereas the logical viewpoint, from within
the context of C++, says "T* p", "T const* p", or at the
limit, "const T* p" (although I don't really like the latter).
In the end, of course, if you're writing real applications in
C++, that work, you're part of the team; the team establishes
its standards, and you conform to them. Or try to find work
elsewhere (but who would want to hire someone who cannot work in
a team).
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Fri, 25 Aug 2006 10:54:17 CST Raw View
Frederick Gotham wrote:
> kanze posted:
> >> There are two plausible expectations for the meaning of
> >> "int *p, q;",
> > The only one I can see is that the programmer is ignoring
> > all usual coding guidelines, and unless he changes, he
> > should be fired. Such code doesn't get through code review,
> > so it doesn't matter what the compiler thinks of it.
> Why must so many discussions about programming be dragged down
> to a discussion of business?
Probably because people use the language professionally. And I
believe the intent has always been that the language can be used
in real, professional applications, and not just as some
theoretical toy.
--
James Kanze GABI Software
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Mon, 21 Aug 2006 14:49:49 GMT Raw View
In article <Mh8Gg.8014$oa1.7930@news02.roc.ny>, Matt
<themattfella@xxyyyzzzz.com> writes
>Frederick Gotham wrote:
>> ===================================== MODERATOR'S COMMENT:
>> The C++ FAQ (you did read the FAQ before posting the first time,
>>didn't you?) has a great deal of information about the C++ Committee
>>and how to join.
>>
>> ===================================== END OF MODERATOR'S COMMENT
>
>Where is the mentioned "C++ FAQ"? I don't see it at
>http://www.faqs.org/faqs/by-newsgroup/comp/
>Or maybe you meant the FAQ for some group other than comp.std.c++.
Read the last line of the comp.std.c++ banner that appears at the foot
of every post here.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: truedfx@gmail.com (Harald van =?UTF-8?B?RMSzaw==?=)
Date: Mon, 21 Aug 2006 15:06:38 GMT Raw View
Dave Steffen wrote:
> giecrilj@stegny.2a.pl ("Kristof Zelechovski") writes:
>
>> Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomosci
>> news:qqmwt99pyia.fsf@yttrium.numerica.us...
>> > skaller <skaller@users.sourceforge.net> writes:
>> >
>> >> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
>> >>
>> >> > fgothamNO@SPAM.com (Frederick Gotham) writes:
>> >> > [...]
>> >> > Well, "farce" might be a little harsh. Constructors are clean and
>> >> > built in;
>> >>
>> >> Huh? they actually allow you to break the type system without
>> >> casting (store non-const pointer to const object).
>> >
>> > I'm not sure why you think that breaks the type system. Adding
>> > const-ness to something doesn't break anything IMHO. Do you have an
>> > example?
>> >
>>
>> T::T(T *p_t) { p_t = this; }
>>
>> Were T a const object, its constness would leak.
>
> Uhh... wait a minute.
>
> In that line of code, *this is being constructed, so it's const-ness
> is irrelevent. Since the pointer p_t is passed by value, the
> assignment is meaningless.
Right. When p_t is corrected to be a reference to a pointer, however:
class T {
public:
T(T *&p_t) { p_t = this; }
int m;
};
int main() {
T *p_t;
const T t(p_t);
p_t->m = 0; // oops!
}
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Mon, 21 Aug 2006 15:08:40 GMT Raw View
Dave Steffen posted:
> T::T( (T*)& p_t) { p_t = this }
>
> (e.g. pass a reference to a pointer to T)
In a declaration, asterisks, ampersands, square brackets, etc. are part of
the object or function's name, NOT part of the type's name, therefore:
(T*) &p_t
is a syntax error. You want:
T *&p_t
The following forms which contain redundant parentheses are also valid:
typedef int T;
T *p;
T *&p0 = p;
T *(&p1) = p;
T (*&p2) = p;
T (*(&p3)) = p;
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dgsteffen@numerica.us (Dave Steffen)
Date: Mon, 21 Aug 2006 20:40:34 GMT Raw View
truedfx@gmail.com (Harald van D=FE=FF_3k) writes:
> Dave Steffen wrote:
> > giecrilj@stegny.2a.pl ("Kristof Zelechovski") writes:
> >=20
> >> Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomos=
ci
> >> news:qqmwt99pyia.fsf@yttrium.numerica.us...
> >> > skaller <skaller@users.sourceforge.net> writes:
> >> >
> >> >> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
> >> >>
> >> >> > fgothamNO@SPAM.com (Frederick Gotham) writes:
> >> >> > [...]
> >> >> > Well, "farce" might be a little harsh. Constructors are clean a=
nd
> >> >> > built in;
> >> >>
> >> >> Huh? they actually allow you to break the type system without
> >> >> casting (store non-const pointer to const object).
> >> >
> >> > I'm not sure why you think that breaks the type system. Adding
> >> > const-ness to something doesn't break anything IMHO. Do you have=
an
> >> > example?
[...]
>=20
> class T {
> public:
> T(T *&p_t) { p_t =3D this; }
> int m;
> };
>=20
> int main() {
> T *p_t;
> const T t(p_t);
> p_t->m =3D 0; // oops!
> }
OK, but I still don't see why this is an example of "constructors
breaking the type system". IANALanguageL, but I don't think
that 'const' applies during construction. I would also opine that is
is a silly, or at least strange, piece of code to write. We all know
that most of the protections and restrictions designed into C++ are
designed to guard against Murphy, not against Machiavelli (I'm pretty
sure Dr. Stroustrup said that).
How is this any worse than
int* ip =3D new int(3);
const int* const_ip =3D ip;
*ip =3D 42; // what happened to my const data?
Agreed, your example is less obvious than this example, or the usual
'cast-away-constness-and-lie-to-the-compiler' tricks seen on the
other newgroups so often; but you're reaching into an object during
construction and returning a pointer to its internal data. Don't Do
That.
I continue to refute the statement made earlier by "skaller", in
response to my statement that constructors are clean, where he said
> >> >> Huh? they actually allow you to break the type system without
> >> >> casting (store non-const pointer to const object).
By your example, they only allow this sort of bad behavior when
explicitly told to do so (against all guidelines I know of). I hold
that this is less egregious than many other, much more problematic
issues (such as the issues raised by Frank Gotham that started this
thread).
I'd also ask if you, or skaller, have any suggestions on how to fix
your example; how, for example, would you change the syntax of the
language to dissalow your example?
----------------------------------------------------------------------
Dave Steffen, Ph.D. =20
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: truedfx@gmail.com (Harald van =?UTF-8?B?RMSzaw==?=)
Date: Tue, 22 Aug 2006 14:46:22 GMT Raw View
Dave Steffen wrote:
> truedfx@gmail.com (Harald van D=C3=BE=C3=BF_3k) writes:
>=20
>> Dave Steffen wrote:
>> > giecrilj@stegny.2a.pl ("Kristof Zelechovski") writes:
>> >=20
>> >> Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomo=
sci
>> >> news:qqmwt99pyia.fsf@yttrium.numerica.us...
>> >> > skaller <skaller@users.sourceforge.net> writes:
>> >> >
>> >> >> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
>> >> >>
>> >> >> > fgothamNO@SPAM.com (Frederick Gotham) writes:
>> >> >> > [...]
>> >> >> > Well, "farce" might be a little harsh. Constructors are clean =
and
>> >> >> > built in;
>> >> >>
>> >> >> Huh? they actually allow you to break the type system without
>> >> >> casting (store non-const pointer to const object).
>> >> >
>> >> > I'm not sure why you think that breaks the type system. Adding
>> >> > const-ness to something doesn't break anything IMHO. Do you hav=
e
>> >> > an example?
> [...]
>>=20
>> class T {
>> public:
>> T(T *&p_t) { p_t =3D this; }
>> int m;
>> };
>>=20
>> int main() {
>> T *p_t;
>> const T t(p_t);
>> p_t->m =3D 0; // oops!
>> }
>=20
> OK, but I still don't see why this is an example of "constructors
> breaking the type system". IANALanguageL, but I don't think
> that 'const' applies during construction. I would also opine that is
> is a silly, or at least strange, piece of code to write. We all know
> that most of the protections and restrictions designed into C++ are
> designed to guard against Murphy, not against Machiavelli (I'm pretty
> sure Dr. Stroustrup said that).
>=20
> How is this any worse than
>=20
> int* ip =3D new int(3);
> const int* const_ip =3D ip;
>=20
> *ip =3D 42; // what happened to my const data?
"const int *" essentially means pointer to read-only int, not pointer to
constant int, and your code is valid. The original code modifies an objec=
t
defined as const, and when that happens, the behaviour is undefined.
> Agreed, your example is less obvious than this example, or the usual
> 'cast-away-constness-and-lie-to-the-compiler' tricks seen on the
> other newgroups so often; but you're reaching into an object during
> construction and returning a pointer to its internal data. Don't Do
> That.
>=20
> I continue to refute the statement made earlier by "skaller", in
> response to my statement that constructors are clean, where he said
>=20
>> >> >> Huh? they actually allow you to break the type system without
>> >> >> casting (store non-const pointer to const object).
>=20
> By your example, they only allow this sort of bad behavior when
> explicitly told to do so (against all guidelines I know of).
The same could be said for modifying string literals in C (not
const-qualified); C++ does attempt to not let you modify const objects
without casts, or running into undefined behaviour earlier, right?
Exceptions exist where doing so breaks C compatibility too much, but that
is not a problem for constructors.
And there are legitimate reasons for an object to store a pointer to itse=
lf
elsewhere during construction. An easy example is a call to
parent.insert(this);.
> I hold=20
> that this is less egregious than many other, much more problematic
> issues (such as the issues raised by Frank Gotham that started this
> thread).
Frederick, but no argument there.
> I'd also ask if you, or skaller, have any suggestions on how to fix
> your example; how, for example, would you change the syntax of the
> language to dissalow your example?
It's probably too late to fix it now, but pretending C++ is designed anew=
,
one option is to make constructors just like member functions in that the=
re
can be const and non-const versions, possibility permitting constness to =
be
cast away during construction.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: kuyper@wizard.net
Date: Tue, 22 Aug 2006 22:03:16 CST Raw View
Matt wrote:
> Frederick Gotham wrote:
> > ===================================== MODERATOR'S COMMENT:
> >
> > The C++ FAQ (you did read the FAQ before posting the first time, didn't you?)
> > has a great deal of information about the C++ Committee and how to join.
> >
> >
> > ===================================== END OF MODERATOR'S COMMENT
>
> Where is the mentioned "C++ FAQ"? I don't see it at
> http://www.faqs.org/faqs/by-newsgroup/comp/
> Or maybe you meant the FAQ for some group other than comp.std.c++.
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Take a look at the bottom of any message posted on this forum,
including your own.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Matt <themattfella@xxyyyzzzz.com>
Date: Sun, 20 Aug 2006 21:47:18 CST Raw View
Frederick Gotham wrote:
> ===================================== MODERATOR'S COMMENT:
>
> The C++ FAQ (you did read the FAQ before posting the first time, didn't you?)
> has a great deal of information about the C++ Committee and how to join.
>
>
> ===================================== END OF MODERATOR'S COMMENT
Where is the mentioned "C++ FAQ"? I don't see it at
http://www.faqs.org/faqs/by-newsgroup/comp/
Or maybe you meant the FAQ for some group other than comp.std.c++.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dgsteffen@numerica.us (Dave Steffen)
Date: Mon, 21 Aug 2006 10:00:14 GMT Raw View
giecrilj@stegny.2a.pl ("Kristof Zelechovski") writes:
> Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomosci
> news:qqmwt99pyia.fsf@yttrium.numerica.us...
> > skaller <skaller@users.sourceforge.net> writes:
> >
> >> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
> >>
> >> > fgothamNO@SPAM.com (Frederick Gotham) writes:
> >> > [...]
> >> > Well, "farce" might be a little harsh. Constructors are clean and
> >> > built in;
> >>
> >> Huh? they actually allow you to break the type system without
> >> casting (store non-const pointer to const object).
> >
> > I'm not sure why you think that breaks the type system. Adding
> > const-ness to something doesn't break anything IMHO. Do you have an
> > example?
> >
>
> T::T(T *p_t) { p_t = this; }
>
> Were T a const object, its constness would leak.
Uhh... wait a minute.
In that line of code, *this is being constructed, so it's const-ness
is irrelevent. Since the pointer p_t is passed by value, the
assignment is meaningless.
On the other hand, *p_t can't be constant, because the parameter is
a non-const pointer. Or rather, if *p_t is a constant object,
someone has done a manifestly evil const_cast. (Well, maybe not
manifestly, but certainly evil.)
Maybe you meant
T::T( (T*)& p_t) { p_t = this }
(e.g. pass a reference to a pointer to T) which would expose a
non-const pointer to *this. If T were being declared const, I think
the compiler might be expected to complain about assigning a const
ptr to a non-const ptr. Yes?
I'm happy to admit I might be particularly dense today, but I
understand your example even less than I understand the notion it
was supposed to be an example of.
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: skaller <skaller@users.sourceforge.net>
Date: Tue, 15 Aug 2006 12:06:57 CST Raw View
On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
> fgothamNO@SPAM.com (Frederick Gotham) writes:
> [...]
>> C++ doesn't provide a clean, built-in facility for initialising an
>> aggregate object. This is a farce, and a defect in the language.
>
> Well, "farce" might be a little harsh. Constructors are clean and
> built in;
Huh? they actually allow you to break the type system
without casting (store non-const pointer to const object).
Furthermore, the syntax is disgustingly hard to parse,
ambiguous semantically in the case of copy constructors,
and fails to allow trivial cases like complex numbers with
cartesian and polar coordinates because they use the
type name instead of having their own. And then there
is that 'explicit' hack to try to fix some of the problems ..
This is hardly clean .. especially when you add the issues
raised by Frederick Gotham.
> from what you've written over in comp.lang.c++, I suspect
> you just don't like the syntax... which is OK.
Most of his posts seem to me to address failure to properly
generalise basic concepts in C. If you look at Francis
Glassborow's paper for example .. you'll get an idea
just how messy C++ really is.
--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dgsteffen@numerica.us (Dave Steffen)
Date: Tue, 15 Aug 2006 17:33:52 GMT Raw View
fgothamNO@SPAM.com (Frederick Gotham) writes:
> Dave Steffen posted:
>
> > fgothamNO@SPAM.com (Frederick Gotham) writes:
> > [...]
> >> C++ doesn't provide a clean, built-in facility for initialising an
> >> aggregate object. This is a farce, and a defect in the language.
> >
> > Well, "farce" might be a little harsh. Constructors are clean and
> > built in; from what you've written over in comp.lang.c++, I suspect
> > you just don't like the syntax... which is OK.
>
>
> Giving a constructor to a bare POD such as:
>
> struct Time {
> unsigned hour;
> unsigned minute;
> unsigned second;
> };
>
> makes it no longer an aggregate. It breaks all code such as the following:
>
> Time time = {5,30,6};
Uhh... right. I'm not arguing that point. Yes, aggregates can be
initialized as above, and non-aggregates are initialized by
constructors, which have a completely different syntax. No
arguments there. I was simply opining that "farce" was a little
harsh. AFAIK the difference in initialization syntax doesn't cause
any _fundamental_ problems, it's just annoying. And IMHO there are
far more annoying things to be fixed. :-)
>
> Even if it *didn't* make it no longer an aggregate, we should *not* have to
> go redesigning a type so that we can initialise it properly.
I don't understand this last statement. What can't you initialize
properly?
But again, if you're complaining that you can't initialize things
_properly_ and _with consistent syntax_, you're absolutely right,
and you should head over to those links I posted and read what the
standardization committee has in mind. I think you'll find the
papers (1824, 1919, and 1701) have excellent and complete
discussions of the problem, and the proposed solutions will probably
do exactly what you want.
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Tue, 15 Aug 2006 18:04:36 GMT Raw View
Dave Steffen posted:
> Uhh... right. I'm not arguing that point. Yes, aggregates can be
> initialized as above, and non-aggregates are initialized by
> constructors, which have a completely different syntax. No
> arguments there. I was simply opining that "farce" was a little
> harsh. AFAIK the difference in initialization syntax doesn't cause
> any _fundamental_ problems, it's just annoying. And IMHO there are
> far more annoying things to be fixed. :-)
>
>>
>> Even if it *didn't* make it no longer an aggregate, we should *not*
>> have to go redesigning a type so that we can initialise it properly.
>
> I don't understand this last statement. What can't you initialize
> properly?
An aggregate. (See code sample in my original post.)
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Dave Steffen <dgsteffen@numerica.us>
Date: Tue, 15 Aug 2006 14:59:41 CST Raw View
skaller <skaller@users.sourceforge.net> writes:
> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
>
> > fgothamNO@SPAM.com (Frederick Gotham) writes:
> > [...]
> >> C++ doesn't provide a clean, built-in facility for initialising an
> >> aggregate object. This is a farce, and a defect in the language.
> >
> > Well, "farce" might be a little harsh. Constructors are clean and
> > built in;
>
> Huh? they actually allow you to break the type system without
> casting (store non-const pointer to const object).
I'm not sure why you think that breaks the type system. Adding
const-ness to something doesn't break anything IMHO. Do you have an
example?
> Furthermore, the syntax is disgustingly hard to parse,
> ambiguous semantically in the case of copy constructors,
> and fails to allow trivial cases like complex numbers with
> cartesian and polar coordinates because they use the
> type name instead of having their own. And then there
> is that 'explicit' hack to try to fix some of the problems ..
Well, my opinion that the first several issues are "annoying" and
not "farcial" is just that, an opinion. I don't know what
initialization syntax you'd like to have for complex numbers; one
way or another you have to distinguish between cartesian and polar
coordinates. I don't find 'explicit' to be a hack, or even
particularly annoying.
[...]
> Most of his posts seem to me to address failure to properly
> generalise basic concepts in C. If you look at Francis Glassborow's
> paper for example .. you'll get an idea just how messy C++ really
> is.
Right. That's exactly why I sent the OP over to those papers.
If it matters, I would put several things higher on my list of
"farcical aquatic ceremonies" than initialization syntax, like the
lack of template typedefs (for which there really is no
syntactically clean workaround), or fstream constructors that take
char* and not std::strings. Others might claim that 'export' is
more farcical than anything else in the standard.
But now we're into philosophy and aesthetics, which belong to some
other NG. :-)
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Dave Steffen <dgsteffen@numerica.us>
Date: Tue, 15 Aug 2006 18:09:34 CST Raw View
fgothamNO@SPAM.com (Frederick Gotham) writes:
> Dave Steffen posted:
>
> > Uhh... right. I'm not arguing that point. Yes, aggregates can be
> > initialized as above, and non-aggregates are initialized by
> > constructors, which have a completely different syntax. No
> > arguments there. I was simply opining that "farce" was a little
> > harsh. AFAIK the difference in initialization syntax doesn't cause
> > any _fundamental_ problems, it's just annoying. And IMHO there are
> > far more annoying things to be fixed. :-)
> >
> >>
> >> Even if it *didn't* make it no longer an aggregate, we should *not*
> >> have to go redesigning a type so that we can initialise it properly.
> >
> > I don't understand this last statement. What can't you initialize
> > properly?
>
>
> An aggregate. (See code sample in my original post.)
[From Frederick's original post]
struct Time {
unsigned hour;
unsigned minute;
unsigned second;
};
OK, sorry; I didn't phrase that question accurately. Why can't you
initialize this properly?
Time time (5, 30, 6); // is perfectly well defined
Time time = Time (5, 30, 6) // is also well defined
I claim that you _can_ initialize this properly; you just can't do it
with the {} notation. You're right, in that
Time time = {5,30,6};
is only valid for aggregate types, and I don't argue about this being
annoying, especially if a type previously-known-as-aggregate becomes
non-aggregate and a whole universe of code breaks. :-)
Others, who know far more about C++ than both of us combined, also
agree, which is why there are several proposals before the
standardization committee.
[ I suspect that such constructions are fairly rare in C++, since most
C++'ers would use the constructor syntax anyway. On the other hand,
Stroustrup Himself has said "nobody knows what most C++ programmers
do" (or words to that effect). ]
At any rate, I don't think we disagree on much, except the
farcical-ness of the issue. :-)
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Tue, 15 Aug 2006 23:48:39 GMT Raw View
Dave Steffen posted:
> [From Frederick's original post]
This was the snippet I had in mind:
struct MyStruct {
int i;
double d;
};
class MyClass {
private:
MyStruct const obj;
public:
MyClass() : obj( {5,45.67} ) {}
};
> OK, sorry; I didn't phrase that question accurately. Why can't you
> initialize this properly?
>
> Time time (5, 30, 6); // is perfectly well defined
> Time time = Time (5, 30, 6) // is also well defined
You have had to change the type, and it's no longer an aggregate.
> I claim that you _can_ initialize this properly; you just can't do it
> with the {} notation.
After you've altered the type.
My complaint is that we should be able to initialise an aggregate in such
constructs as:
MyClass::MyClass() : obj({45.4,5,true})
and:
new MyStruct( {45.4,5,true} )
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: v.Abazarov@comAcast.net ("Victor Bazarov")
Date: Wed, 16 Aug 2006 14:54:35 GMT Raw View
Frederick Gotham wrote:
> Dave Steffen posted:
>
>> [From Frederick's original post]
>
>
> This was the snippet I had in mind:
>
> struct MyStruct {
> int i;
> double d;
> };
>
> class MyClass {
> private:
> MyStruct const obj;
>
> public:
> MyClass() : obj( {5,45.67} ) {}
> };
>
>
>> OK, sorry; I didn't phrase that question accurately. Why can't you
>> initialize this properly?
>>
>> Time time (5, 30, 6); // is perfectly well defined
>> Time time = Time (5, 30, 6) // is also well defined
>
>
> You have had to change the type, and it's no longer an aggregate.
Why is it important for it to be an aggregate?
>> I claim that you _can_ initialize this properly; you just can't do
>> it with the {} notation.
>
>
> After you've altered the type.
>
> My complaint is that we should be able to initialise an aggregate in
> such constructs as:
>
> MyClass::MyClass() : obj({45.4,5,true})
>
> and:
>
> new MyStruct( {45.4,5,true} )
And you are able to, using a "constructor function" as you have been
advised already. You keep insisting on this syntax, why?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: giecrilj@stegny.2a.pl ("Kristof Zelechovski")
Date: Wed, 16 Aug 2006 16:29:00 GMT Raw View
Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomosci
news:qqmwt99pyia.fsf@yttrium.numerica.us...
> skaller <skaller@users.sourceforge.net> writes:
>
>> On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
>>
>> > fgothamNO@SPAM.com (Frederick Gotham) writes:
>> > [...]
>> > Well, "farce" might be a little harsh. Constructors are clean and
>> > built in;
>>
>> Huh? they actually allow you to break the type system without
>> casting (store non-const pointer to const object).
>
> I'm not sure why you think that breaks the type system. Adding
> const-ness to something doesn't break anything IMHO. Do you have an
> example?
>
T::T(T *p_t) { p_t = this; }
Were T a const object, its constness would leak.
> Well, my opinion that the first several issues are "annoying" and
> not "farcial" is just that, an opinion. I don't know what
Yes, there are several more annoying issues.
For example, char const (&)[02] (a reference to two constant characters) can
be initialized with char [02] (two characters) but char const (*const *)[02]
cannot be initialized with char const (**) [02].
And the compiler does not report an error when it sees p[01] where p is
class Base * and Base is abstract.
Nor does it report an error when it sees p[01] and p is char[01],
Stay tuned
Chris
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Fri, 11 Aug 2006 17:52:22 GMT Raw View
===================================== MODERATOR'S COMMENT:
The C++ FAQ (you did read the FAQ before posting the first time, didn't you?)
has a great deal of information about the C++ Committee and how to join.
===================================== END OF MODERATOR'S COMMENT
C++ doesn't provide a clean, built-in facility for initialising an
aggregate object. This is a farce, and a defect in the language.
I propose that the following be allowed:
struct MyStruct {
int i;
double d;
};
class MyClass {
private:
MyStruct const obj;
public:
MyClass() : obj( {5,45.67} ) {}
};
int main()
{
MyClass obj;
}
Failing that, compound literals should be brought in:
struct MyStruct {
int i;
double d;
};
class MyClass {
private:
MyStruct const obj;
public:
MyClass() : obj( (MyStruct){5,45.67} ) {}
};
int main()
{
MyClass obj;
}
(In such a case, the compiler should be forbidden from constructing a
intermediate "temporary" object.)
The situation is similar for dynamic allocation via "new":
MyStruct const *const p = new MyStruct const({5,45.67});
How does one apply to serve on the C++ Standard Committee? I might submit
an application in a few years -- they could do with someone who focuses on
basic functionality before moving on to more elaborate features. The first
defects to fix are separate initialisation of array members, and
initialisation of aggregates.
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dgsteffen@numerica.us (Dave Steffen)
Date: Tue, 15 Aug 2006 14:00:18 GMT Raw View
fgothamNO@SPAM.com (Frederick Gotham) writes:
[...]
> C++ doesn't provide a clean, built-in facility for initialising an
> aggregate object. This is a farce, and a defect in the language.
Well, "farce" might be a little harsh. Constructors are clean and
built in; from what you've written over in comp.lang.c++, I suspect
you just don't like the syntax... which is OK. Others have noted the
lack (or, at least, the assymetry between various ways of initializing
variables), and have already written proposals that are under
discussion.
[... proposals elided ...]
Instead of reinventing the wheel, check out what's going on right now
with the C++ Evolution Working Group; this link
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2011.htm>
has AFAIK the most recent summary.
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: fgothamNO@SPAM.com (Frederick Gotham)
Date: Tue, 15 Aug 2006 14:38:56 GMT Raw View
Dave Steffen posted:
> fgothamNO@SPAM.com (Frederick Gotham) writes:
> [...]
>> C++ doesn't provide a clean, built-in facility for initialising an
>> aggregate object. This is a farce, and a defect in the language.
>
> Well, "farce" might be a little harsh. Constructors are clean and
> built in; from what you've written over in comp.lang.c++, I suspect
> you just don't like the syntax... which is OK.
Giving a constructor to a bare POD such as:
struct Time {
unsigned hour;
unsigned minute;
unsigned second;
};
makes it no longer an aggregate. It breaks all code such as the following:
Time time = {5,30,6};
Even if it *didn't* make it no longer an aggregate, we should *not* have to
go redesigning a type so that we can initialise it properly.
--
Frederick Gotham
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]