Who's pathetic, me or C++ compilers?
John Hickin
>
> ^
>
> Only Borland 5.5 compiles the code.
>
aCC too except for the following gotcha: if I modify the bottom part to
read
#include <iostream.h>
// or some other header that defines NULL
#ifdef GOTCHA
# ifdef NULL
# undef NULL
# endif
#endif
void f(int) { cout << "f(int)\n"; }
void f(int*) { cout << "f(int*)\n"; }
int main()
{
f(NULL);
}
How does Borland handle the situations where you compile with vs.
without -DGOTCHA?
Regards, John.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Scott Meyers
published a template-based way to create a NULL that would convert only to
pointer types. (I did it in the first edition of EC++ as an example of
what would NOT work, because member templates were specifically disallowed
by the ARM.) Based on recent reader mail, I submitted my latest approach
to five compilers, and four of them rejected it. Here's the code (copied
straight off my CD, available at fine technical bookstores everywhere :-}),
with enough context to exercise it:
const // this is a const object...
class {
public:
template<class T> // convertible to any type
operator T*() const // of null non-member
{ return 0; } // pointer...
template<class C, class T> // or any type of null
operator T C::*() const // member pointer...
{ return 0; }
private:
void operator&() const; // whose address can't be
// taken (see Item 27)...
} NULL; // and whose name is NULL
void f(int);
void f(int*);
int main()
{
f(NULL);
}
MSVC 6.4 sez this:
null.cpp
null.cpp(16) : error C2627: member function defined in unnamed class
null.cpp(23) : error C2665: 'f' : none of the 2 overloads can convert
parameter 1 from type 'const class '
g++ 295.2 sez this:
null.cpp:16: uninitialized const `NULL'
MWCW 5.3 sez this:
# 5: operator T*() const // of null non-member
# Error: ^^^^^^^^
# declaration syntax error
# 6: { return 0; } // pointer...
# Error: ^
# declaration syntax error
# 9: operator T C::*() const // member pointer...
# Error: ^^^^^^^^
# declaration syntax error
# 10: { return 0; }
# Error: ^
# declaration syntax error
# 12: private:
# Error: ^^^^^^^
# declaration syntax error
# 13: void operator&() const; // whose address can't be
# Error: ^^^^^
# illegal 'operator' declaration
# 16: } NULL; // and whose name is NULL
# Error: ^
# declaration syntax error
Comeau C++ 4.2.43 Beta #1 (which I believe is EDG-based) sez this:
"8723.c", line 16: error: const variable "NULL" requires an initializer --
class "class <unnamed>" has no explicitly declared default
constructor
} NULL; // and whose name is NULL
^
Only Borland 5.5 compiles the code.
Either my code is invalid or this is pretty darn pathetic. Which is it?
Thanks,
Scott
Jerry Coffin
sme...@aristeia.com says...
[ ... ]
> Comeau C++ 4.2.43 Beta #1 (which I believe is EDG-based) sez this:
>
> "8723.c", line 16: error: const variable "NULL" requires an initializer --
> class "class <unnamed>" has no explicitly declared default
> constructor
> } NULL; // and whose name is NULL
> ^
This is strange -- Comeau 4.2.42 accepts the code with no problesm.
Intel C++ 4.0 also compiles the code.
> Either my code is invalid or this is pretty darn pathetic. Which is it?
The code looks valid to me. Since the release version of Comeau
accepts it, I wouldn't be surprised if it does again by the time beta
testing is done, though it's obviously hard to say for sure.
--
Later,
Jerry.
The universe is a figment of its own imagination.
w...@fastdial.net
sme...@aristeia.com (Scott Meyers) wrote:
> const // this is a const object...
> class {
> public:
> template<class T> // convertible to any type
> operator T*() const // of null non-member
> { return 0; } // pointer...
>
> template<class C, class T> // or any type of null
> operator T C::*() const // member pointer...
> { return 0; }
>
> private:
> void operator&() const; // whose address can't be
> // taken (see Item 27)...
>
>
> void f(int*);
>
> int main()
> {
> f(NULL);
> }
>
>
> null.cpp:16: uninitialized const `NULL'
>
>
> "8723.c", line 16: error: const variable "NULL" requires an
initializer --
> class "class <unnamed>" has no explicitly declared default
> constructor
> } NULL; // and whose name is NULL
> ^
>
it?
The two compilers I left in the quotation above got it right.
See 8.5p9:
If no initializer is specified for an object, and the
object is of (possibly cv-qualified) non-POD class type
(or array thereof), the object shall be default-
initialized; if the object is of const-qualified type,
the underlying class type shall have a user-declared
default constructor. Otherwise, if no initializer is
specified for an object, the object and its subobjects,
if any, have an indeterminate initial value; if the
object or any of its subobjects are of const-qualified
type, the program is ill-formed.
Your code falls into the second part ("Otherwise...") because
it's a POD-struct. Even though there's no data, the
Standard still requires it to have an initializer. To fix
it, just change it to read "NULL = {};" (see 8.5.1p8 for
empty aggregate initializers).
The other error diagnostics are not correct.
Note core issue 78, however; if the proposed resolution is
adopted, your code will be well-formed as written. (The
resolution applies the requirement for initialization to
non-static objects only, which is what was intended.)
--
William M. Miller, w...@fastdial.net
Vignette Corporation (www.vignette.com)
Sent via Deja.com http://www.deja.com/
Before you buy.
Phil Edwards
Scott Meyers <sme...@aristeia.com> wrote:
+ g++ 295.2 sez this:
+
+ null.cpp:16: uninitialized const `NULL'
I think I may have started a monster. :-)
After this was reported to the gcc-bugs list, I remembered the email
and started poking around. I found that [8.5]/9 says
# ...if the object is of const-qualified type, the underlying class
# type shall have a user-declared default constructor.
^^^^^^^^^^^^^
which the magical NULL doesn't have. Is this paragraph germane?
Phil
Scott Meyers
> How does Borland handle the situations where you compile with vs.
> without -DGOTCHA?
This command line
bcc32 -c -DGOTCHA null.cpp
compiles cleanly. Compiling without the -D option also works.
Scott
Scott Meyers
> The two compilers I left in the quotation above got it right.
> See 8.5p9:
>
> If no initializer is specified for an object, and the
> object is of (possibly cv-qualified) non-POD class type
> (or array thereof), the object shall be default-
> initialized; if the object is of const-qualified type,
> the underlying class type shall have a user-declared
> default constructor. Otherwise, if no initializer is
> specified for an object, the object and its subobjects,
> if any, have an indeterminate initial value; if the
> object or any of its subobjects are of const-qualified
> type, the program is ill-formed.
I swear, this language is going to drive me to Java or C#. Or maybe back
to Pascal and Basic. Can somebody please explain to me why I am required
to provide an initializer when my object has zero data members?
> Note core issue 78, however; if the proposed resolution is
> adopted, your code will be well-formed as written. (The
> resolution applies the requirement for initialization to
> non-static objects only, which is what was intended.)
But even if the proposed resolution is adopted, programmers will be
required to provide initializers or explicit default constructors for some
objects/classes containing no data. THIS MAKES NO SENSE. Sigh.
Scott
PS - Thanks for explaining why those compilers were saying what they were
saying.
John Hickin
>
>
> I swear, this language is going to drive me to Java or C#. Or maybe back
> to Pascal and Basic. Can somebody please explain to me why I am required
> to provide an initializer when my object has zero data members?
>
In the case of POD type copying should be possible; indeed the standard
somewhere says that the type sits in contiguous memory and can be moved
using a bitwise copy operation. Again, somewhere else, it says that the
object can't be of size 0 so its representation has at least 1 byte. If
we copy an indeterminate value I think that we may run into trouble on
some architectures.
This still leaves room to complain. If there are no data members and we
have a POD type then I believe that the standard could require it to be
automatically initialized in any fashion that permits a copy to be made
safely.
In your case, NULL is an instance of an unnamed class and the chances
that somebody writes code that takes a value copy is small. Why, indeed,
should an initializer be needed?
You have prevented NULL's address from being taken which seems to rule
out any raw copying at all. It is hard, however, to force compilers to
be able to make a decision based on this last piece of information.
Regards, John.
w...@fastdial.net
sme...@aristeia.com (Scott Meyers) wrote:
> I swear, this language is going to drive me to Java or C#. Or maybe
back
> to Pascal and Basic. Can somebody please explain to me why I am
required
> to provide an initializer when my object has zero data members?
>
> > adopted, your code will be well-formed as written. (The
> > resolution applies the requirement for initialization to
> > non-static objects only, which is what was intended.)
>
> But even if the proposed resolution is adopted, programmers will be
> required to provide initializers or explicit default constructors for
some
> objects/classes containing no data. THIS MAKES NO SENSE. Sigh.
It's not particularly defensible, but I imagine that the idea
that there might be a useful const automatic object with no
data members just didn't occur to people as this requirement
was being written, so nobody thought to make an exception to
the general rule for this particular case. (You have to admit
that the number of lines of code affected by this particular
idiosyncrasy is very tiny; I'm not sure how many zeroes I'd
need to give it a percentage... :-)
I'll bring it up with the Committee to see if people would
like to make an exception for objects with no data members
while we're fixing the static/non-static glitch.
--
William M. Miller, w...@fastdial.net
Vignette Corporation (www.vignette.com)
Sent via Deja.com http://www.deja.com/
Before you buy.
---
w...@fastdial.net
"John Hickin" <hic...@nortelnetworks.com> wrote:
> In the case of POD type copying should be possible; indeed the
standard
> somewhere says that the type sits in contiguous memory and can be
moved
> using a bitwise copy operation. Again, somewhere else, it says that
the
> object can't be of size 0 so its representation has at least 1 byte.
If
> we copy an indeterminate value I think that we may run into trouble on
> some architectures.
This extra byte is no different from the padding that may be
inserted into objects for alignment purposes -- it must be
copyable. The Standard makes provision for that: the unsigned
char type is required not to have any bit patterns that will
prevent it from being accessed (3.9.1p1), so memcpy and kin can
be written safely and portably using unsigned char to fetch and
store the data, even if it's uninitialized. Of course, an
implementation can do whatever it chooses to the padding.
Greg Comeau
>[ ... ]
>
>> Comeau C++ 4.2.43 ....
>> "8723.c", line 16: error: const variable "NULL" requires an initializer --
>> class "class <unnamed>" has no explicitly declared default
>> constructor
>> } NULL; // and whose name is NULL
>
>
>Intel C++ 4.0 also compiles the code.
Not too strange. Yes, Comeau C++ will accept the code with no
problems, just like it accepts lots of dialects, however, when
you specify -A for the Standard C++ dialect, it will reject it.
>> Either my code is invalid or this is pretty darn pathetic. Which is it?
>
>The code looks valid to me. Since the release version of Comeau
>accepts it, I wouldn't be surprised if it does again by the time beta
>testing is done, though it's obviously hard to say for sure.
Oh, testing *is* done, and Comeau C++ 4.2.43 is shipping on some
platforms, so it's a release version too. In fact, 4.2.44 is
being prepared and will be "on the streets" quite shortly. Anyway,
the code is not valid and does get rejected in strict -A mode.
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
Scott Meyers
> It's not particularly defensible, but I imagine that the idea
> that there might be a useful const automatic object with no
> data members just didn't occur to people as this requirement
> was being written, so nobody thought to make an exception to
> the general rule for this particular case.
I'm sure that's that's what happened. I know that the committee works very
hard to produce a good specification, and it's easy to understand how this
kind of problem could arise. What's frustrating is that C++ made a
deliberate decision to part with C in allowing dataless classes (structs),
so it seems to me that anytime a rule was debated that affected classes,
somebody should have asked, "Does this make sense for dataless classes?"
On the other hand, I never joined the committee, so perhaps it's my own
fault that I wasn't there volunteering to ask the question. It's easy for
me to throw stones. Which may explain why I do. I mean, there's a big
pile of them just sitting here... :-)
I also have to point out that this is one of those cases where C++ seems to
part from it's "trust the programmer" philosophy. So many things in C++
are, as I term them, "legal but stupid" (e.g. having a function return a
reference to a local auto object) that it's especially galling when
something that not stupid *is* illegal.
> I'll bring it up with the Committee to see if people would
> like to make an exception for objects with no data members
> while we're fixing the static/non-static glitch.
That would be nice. Thank you.
Scott
Greg Comeau
Scott Meyers <sme...@aristeia.com> wrote:
>On Wed, 12 Jul 2000 04:47:29 CST, w...@fastdial.net wrote:
>> It's not particularly defensible, but I imagine that the idea
>> that there might be a useful const automatic object with no
>> data members just didn't occur to people as this requirement
>> was being written, so nobody thought to make an exception to
>> the general rule for this particular case.
>
>I'm sure that's that's what happened. I know that the committee works very
>hard to produce a good specification, and it's easy to understand how this
>kind of problem could arise. What's frustrating is that C++ made a
>deliberate decision to part with C in allowing dataless classes (structs),
>so it seems to me that anytime a rule was debated that affected classes,
>somebody should have asked, "Does this make sense for dataless classes?"
It's easy to feel that such a question should have been asked,
but, well, it's just the nature of the beast Scott.
That said, are you sure that C doesn't allow dataless structs?
I seem to recall that it doesn't allow zero sized structs, which
sounds similar, and may be related, but may not be the same thing.
IOWs, whereas these may be no good:
struct xyz1 { };
struct xyz2 { ; };
I _seem_ to recall these are ok:
...
struct xyz2 { struct Sometag; };
struct xyz3 { typedef int i; };
struct xyz3 { enum blah { etor}; };
struct xyz3 { int : 0; };
...
Or am I thinking of something else?
>On the other hand, I never joined the committee, so perhaps it's my own
>fault that I wasn't there volunteering to ask the question. It's easy for
>me to throw stones. Which may explain why I do. I mean, there's a big
>pile of them just sitting here... :-)
Er, yes! :)
>I also have to point out that this is one of those cases where C++ seems to
>part from it's "trust the programmer" philosophy. So many things in C++
>are, as I term them, "legal but stupid" (e.g. having a function return a
>reference to a local auto object) that it's especially galling when
>something that not stupid *is* illegal.
But people have been, and are listening, so it's not like
it's totally hopeless :)
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
---
Greg Comeau
Scott Meyers <sme...@aristeia.com> wrote:
>....I submitted my latest approach
>to five compilers, and four of them rejected it. Here's the code (copied
>straight off my CD, available at fine technical bookstores everywhere :-}),
>with enough context to exercise it:
>
> class {
> } NULL; // and whose name is NULL
>
> null.cpp(16) : error C2627: member function defined in unnamed class
> null.cpp(23) : error C2665: 'f' : none of the 2 overloads can convert
>parameter 1 from type 'const class '
>
>g++ 295.2 sez this:
>
> # declaration syntax error.........
> # illegal 'operator' declaration
> # 16: } NULL; // and whose name is NULL
> # Error: ^
> # declaration syntax error
>
> class "class <unnamed>" has no explicitly declared default
> constructor
> } NULL; // and whose name is NULL
>
>
IMO, the code is invalid, therefore, IMO, us (Comeau C++) and g++
are correct, whereas the others are wrong. BTW, you can use
"= { }" as an empty initializer to pacify Comeau C++, and perhaps g++,
although it looks like the others won't accept other aspects about
your code even if you add this. BTW, did Borland accept it in strict mode?
Scott Meyers
> your code even if you add this. BTW, did Borland accept it in strict mode?
I compiled it without any special switches, and I don't know what Borland's
default mode is. I generally proceed on the assumption that a C++ compiler
defaults to compiling standard C++, even though I know that's not always true.
Scott
Greg Comeau
Scott Meyers <sme...@aristeia.com> wrote:
>On Wed, 12 Jul 2000 20:52:02 CST, Greg Comeau wrote:
>> your code even if you add this. BTW, did Borland accept it in strict mode?
>
>I compiled it without any special switches, and I don't know what Borland's
>default mode is. I generally proceed on the assumption that a C++ compiler
>defaults to compiling standard C++, even though I know that's not always true.
Perhaps you're probably thinking that's pathetic too, but IMO,
that's too much to ask for. That is, IMO, the default is whatever
you set it to. And so, as such, folks should operate under the
assumption that there is _no_ default for their compiler.
I can't tell you how many Comeau customers don't keep track of
what mode they are in. This is so _whether or not_ we ship with
strict or relaxed. It is also so, even when they change it themselves.
Furthermore, I cannot tell you how many students I've taught
who get their HWs wrong over something like this, with all compilers.
FWIW, with Comeau C++ 4.2.43, we now emit a message that comes up
with the copyright notice informing the user what mode/dialect
that they are in.
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
---
Jeremy M. Jancsary
>
> On Wed, 12 Jul 2000 20:52:02 CST, Greg Comeau wrote:
> > your code even if you add this. BTW, did Borland accept it in strict mode?
>
> I compiled it without any special switches, and I don't know what Borland's
> default mode is.
The default mode is 'Borland extensions'. This mode is necessary to
compile Borland's framework, the VCL.
If you want to use the strict ANSI mode, you have to use the -A
command-line switch.
> I generally proceed on the assumption that a C++ compiler
> defaults to compiling standard C++, even though I know that's not always true.
Hm, I don't think that many compilers default to using their ANSI mode.
Visual C++ doesn't.
Borland C++ doesn't.
GCC doesn't.
Maybe others do, I don't know.
--
Regards,
------------------------------------------------------
| Jeremy M. Jancsary | Open Source Enthusiast |
| Republic of Austria | C++ Programmer |
| jer...@jancsary.org | http://jeremy.jx.st |
------------------------------------------------------
Scott Meyers
> that's too much to ask for. That is, IMO, the default is whatever
> you set it to. And so, as such, folks should operate under the
But if you set it, it's not the default :-)
Scott
Rene van Oostrum
>> The two compilers I left in the quotation above got it right.
>> See 8.5p9:
>>
>> If no initializer is specified for an object, and the
>> object is of (possibly cv-qualified) non-POD class type
>> (or array thereof), the object shall be default-
>> initialized; if the object is of const-qualified type,
>> the underlying class type shall have a user-declared
>> default constructor. Otherwise, if no initializer is
>> specified for an object, the object and its subobjects,
>> if any, have an indeterminate initial value; if the
>> object or any of its subobjects are of const-qualified
>> type, the program is ill-formed.
Scott Meyers responded:
Scott> I swear, this language is going to drive me to Java or C#.
So when is "Effective C#" to be expected? :-)
Scott> Can somebody please explain to me why I am required to
Scott> provide an initializer when my object has zero data members?
Or, for that matter, when the object only has data members that take
care of themselves:
struct C {
std::string s;
};
int main() {
const C c;
}
If I read the first sentence of 5.5p9 (quoted above) correctly, then
this program is ill-formed. I find that counter-intuitive.
Basically, this means that when you design a class and you want to
have it a default constructor, you should always provide it yourself,
*even if you're perfectly happy with the implementation-defined
one*. Otherwise, a user of your class can never declare const objects
of your class.
Note: 3.1p4 says that the above definition of struct C is *equivalent*
to a version with a default constructor, a copy constructor, an
assignment operator, and a destructor, since an implementation is
required to implicitly define these members in this example. But
according to 8.5p9, a (class with an) implementation-defined default
constructor is *not equivalent* to a class with a user-declared
default constructor.
So there seems to be an inconsistency between 3.1p4 and 8.5p9.
Rene
Michiel Salters
> >> See 8.5p9:
> >> If no initializer is specified for an object, and the
> >> object is of (possibly cv-qualified) non-POD class type
> >> (or array thereof), the object shall be default-
> >> initialized; if the object is of const-qualified type,
> >> the underlying class type shall have a user-declared
> >> default constructor. Otherwise, if no initializer is
> >> specified for an object, the object and its subobjects,
> >> if any, have an indeterminate initial value; if the
> >> object or any of its subobjects are of const-qualified
> >> type, the program is ill-formed.
[ SNIP]
> Or, for that matter, when the object only has data members that take
> care of themselves:
> struct C {
> std::string s;
> };
> int main() {
> const C c;
> }
>
> If I read the first sentence of 5.5p9 (quoted above) correctly, then
> this program is ill-formed. I find that counter-intuitive.
But you either didn't read it correctly, or failed to notice that
std::string isn't a POD, by extension C isn't a POD, and therefore
c is an object of cv-qualified (namely const) non-POD class type;
therefore c shall be default-initialized.
If an object has only data members that take care of themselves, these
data members have constructors, are non-PODs and the conatining
object cannot be of POD-class-type itself. Thus (provided the class
doesn't have a constructor) they are always covered by the first
clause.
Michiel Salters
Greg Comeau
Scott Meyers <sme...@aristeia.com> wrote:
>On Thu, 13 Jul 2000 04:52:16 CST, Greg Comeau wrote:
>> that's too much to ask for. That is, IMO, the default is whatever
>> you set it to. And so, as such, folks should operate under the
>
>But if you set it, it's not the default :-)
I see your smiley, but I know people who'd be quite upset
to accept that view. To them the default is whatever it is,
not what it started with, if not, the likes of environment
variables, .ini's and /etc/defaults(!) are being thrown
out the window.
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
---
James Kuyper
>
> In article <MPG.13d685e3f...@news.supernews.com>,
> Scott Meyers <sme...@aristeia.com> wrote:
> >On Thu, 13 Jul 2000 04:52:16 CST, Greg Comeau wrote:
> >> that's too much to ask for. That is, IMO, the default is whatever
> >> you set it to. And so, as such, folks should operate under the
> >
> >But if you set it, it's not the default :-)
>
> I see your smiley, but I know people who'd be quite upset
> to accept that view. To them the default is whatever it is,
> not what it started with, if not, the likes of environment
> variables, .ini's and /etc/defaults(!) are being thrown
> out the window.
So what is the default value of the default - the one that gets used
when the user never does anything to choose between the different
possible defaults? That's what I'd call the true default.
Rene van Oostrum
>> struct C {
>> std::string s;
>> };
>>
>> int main() {
>> const C c;
>> }
>>
>> If I read the first sentence of 5.5p9 (quoted above) correctly, then
>> this program is ill-formed. I find that counter-intuitive.
Michiel Salters replied
Michiel> But you either didn't read it correctly, or failed to
Michiel> notice that std::string isn't a POD, by extension C isn't a
Michiel> POD, and therefore c is an object of cv-qualified (namely
Michiel> const) non-POD class type; therefore c shall be
Michiel> default-initialized.
Michiel> If an object has only data members that take care of
Michiel> themselves, these data members have constructors, are
Michiel> non-PODs and the conatining object cannot be of
Michiel> POD-class-type itself. Thus (provided the class doesn't
Michiel> have a constructor) they are always covered by the first
Michiel> clause.
I may indeed have misread it; in that case, I still do, so I'll try to
explain how I read it:
Yes, I did notice that C isn't a POD, and that the first clause
(quoted below) applies: '[...] shall be default-initialized
[...]'. This part applies to *all* non-PODs for which no initializer
is specified, whether they are cv-qualified or not. In particular, it
applies to my 'const C c'. Conclusion: c shall default-initialized.
So far, everything is fine.
But doesn't the part after the semi-colon place an *additional*
requirement on const-qualified objects (of non-POD type, for which no
initializer is specified): 'if the object is of const-qualified type,
the underlying class type shall have a user-declared default
constructor.' As I read this, this *also* applies to my 'const C c'.
Conclusion: C shall have a user-declared default constructor. (But it
hasn't, so my program is ill-formed.)
For completeness, here the whole relevant part again:
8.5p9:
If no initializer is specified for an object, and the object is of
(possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of
const-qualified type, the underlying class type shall have a
user-declared default constructor.
I really hope someone can clear this up for me, since this has been
bugging me for a long time.
Thanks,
Rene
w...@fastdial.net
Rene van Oostrum <re...@cs.ust.hk> wrote:
> But doesn't the part after the semi-colon place an *additional*
> requirement on const-qualified objects (of non-POD type, for which no
> initializer is specified): 'if the object is of const-qualified type,
> the underlying class type shall have a user-declared default
> constructor.' As I read this, this *also* applies to my 'const C c'.
> Conclusion: C shall have a user-declared default constructor. (But it
> hasn't, so my program is ill-formed.)
>
> bugging me for a long time.
Yes, that's how I read it, too. I've made a note to include
your comment about this situation in the discussion of when
initializers or constructors are required at the next
Committee meeting. I can't promise what, if anything, will
be done about it, but it will at least be mentioned.
--
William M. Miller, w...@fastdial.net
Vignette Corporation (www.vignette.com)
Sent via Deja.com http://www.deja.com/
Before you buy.
---
Ken Bloom
news:396FB78E...@wizard.net...
> Greg Comeau wrote:
> >
> > In article <MPG.13d685e3f...@news.supernews.com>,
> > Scott Meyers <sme...@aristeia.com> wrote:
> > >On Thu, 13 Jul 2000 04:52:16 CST, Greg Comeau wrote:
> > >> that's too much to ask for. That is, IMO, the default is whatever
> > >> you set it to. And so, as such, folks should operate under the
> > >
> > >But if you set it, it's not the default :-)
> >
> > I see your smiley, but I know people who'd be quite upset
> > to accept that view. To them the default is whatever it is,
> > not what it started with, if not, the likes of environment
> > variables, .ini's and /etc/defaults(!) are being thrown
> > out the window.
>
> So what is the default value of the default - the one that gets used
> when the user never does anything to choose between the different
> possible defaults? That's what I'd call the true default.
There is essentially the case where you set the default during installation.
On Windows, you'd set a radio button in the installer. If you want them to
choose, you can set it so that NO radio button is selected by default (or
make them click a push button to set the default, etc...). There's plenty of
ways to have _no_ default by that definition.
I think this is an acceptable view and that users should know what their
defaults are. Especially if the users are programmers.
--
Ken Bloom
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M/AT/U d- s++:--- a--- C++ UL P++ L+ E----
W+++ N++ ?o ?K w++ !O M++>$ V- PS PE Y-- PGP- t+
5 X++ R--- tv-- b++ DI+ D-- G e- !h r--@ y?
------END GEEK CODE BLOCK------
Joerg Barfurth
> Rene van Oostrum wrote:
>
> > >> See 8.5p9:
>
> > >> If no initializer is specified for an object, and the
> > >> object is of (possibly cv-qualified) non-POD class type
> > >> (or array thereof), the object shall be default-
> > >> initialized; if the object is of const-qualified type,
> > >> the underlying class type shall have a user-declared
> > >> default constructor.
[ SNIP]
> > Or, for that matter, when the object only has data members that take
> > care of themselves:
>
> > struct C {
> > std::string s;
> > };
>
> > int main() {
> > const C c;
> > }
> >
> > If I read the first sentence of 5.5p9 (quoted above) correctly, then
> > this program is ill-formed. I find that counter-intuitive.
>
> But you either didn't read it correctly, or failed to notice that
> std::string isn't a POD, by extension C isn't a POD, and therefore
> c is an object of cv-qualified (namely const) non-POD class type;
> therefore c shall be default-initialized.
unless it "is of const-qualified type", in which case
"the underlying class type shall have a user-declared
default constructor".
Read the last phrase I left in of 8.5p9 again. Rene was referring to
that, while you stopped reading early.
--
Jörg Barfurth jbar...@vossnet.de
--------------- using std::disclaimer; ------------------
Software Engineer joerg.b...@germany.sun.com
Star Office GmbH http://www.sun.com/staroffice
Greg Comeau
James Kuyper <kuy...@wizard.net> wrote:
>Greg Comeau wrote:
>> In article <MPG.13d685e3f...@news.supernews.com>,
>> Scott Meyers <sme...@aristeia.com> wrote:
>> >On Thu, 13 Jul 2000 04:52:16 CST, Greg Comeau wrote:
>> >> that's too much to ask for. That is, IMO, the default is whatever
>> >> you set it to. And so, as such, folks should operate under the
>> >
>> >But if you set it, it's not the default :-)
>>
>> I see your smiley, but I know people who'd be quite upset
>> to accept that view. To them the default is whatever it is,
>> not what it started with, if not, the likes of environment
>> variables, .ini's and /etc/defaults(!) are being thrown
>> out the window.
>
>So what is the default value of the default - the one that gets used
>when the user never does anything to choose between the different
>possible defaults? That's what I'd call the true default.
Which still doesn't help in many cases. For instance, for some
compilers you must set the default when you install. On others,
you can override it, and that problem is that often "you" is
somebody else. This only comes full circle in enough cases
because the user may not do anything yet get something, and
perhaps differently so.
- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: com...@comeaucomputing.com / WEB: http://www.comeaucomputing.com
---