Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Are additional constructors for standard containers allowed?

Reply
Thread Tools

Are additional constructors for standard containers allowed?

 
 
Juha Nieminen
Guest
Posts: n/a
 
      09-05-2010
Niels Dekker - no reply address <(E-Mail Removed)> wrote:
> What do you mean by "possibly a const"? The following is still
> ambiguous, according to the current Working Draft (N3126):
>
> const int zeroConst = 0;
> // bitset(unsigned long long) or bitset(const char*)?
> std::bitset<5> bits(zeroConst);


Why would a const int be confused with a const char* by the compiler?
They are completely unrelated types.
 
Reply With Quote
 
 
 
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      09-05-2010
* Juha Nieminen, on 05.09.2010 21:06:
> Niels Dekker - no reply address<(E-Mail Removed)> wrote:
>> What do you mean by "possibly a const"? The following is still
>> ambiguous, according to the current Working Draft (N3126):
>>
>> const int zeroConst = 0;
>> // bitset(unsigned long long) or bitset(const char*)?
>> std::bitset<5> bits(zeroConst);

>
> Why would a const int be confused with a const char* by the compiler?
> They are completely unrelated types.


Because a compile-time const integer of value 0, any integer type, converts
implicitly to nullpointer of any type.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
 
 
 
Niels Dekker - no reply address
Guest
Posts: n/a
 
      09-06-2010
>> Hope you like the proposed resolution
>> http://www.open-std.org/jtc1/sc22/wg...3133.html#1325


Alf P. Steinbach /Usenet wrote:
> No. It doesn't support NULL as nullptr_t, and it has incorrect casts.


Personally I find it acceptable if std::bitset<N>(NULL) might yield a
compile error on some implementations. (But I'm unhappy about the fact that
the Working Draft (N3126) allows undefined behavior in this case.) Thanks
though, for your Wrapped<unsigned long long> based workaround.

Are those the casts, charT('0'), charT('1'), merely a problem for the EBCDIC
character encoding? I have to admit I don't know much about EBCDIC. Are
there any upcoming C++0x implementations expected to support EBCDIC?

Did the C++03 std::bitset support EBCDIC?

Kind regards,

Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center


 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-07-2010
Alf P. Steinbach /Usenet <(E-Mail Removed)> wrote:
> * Juha Nieminen, on 05.09.2010 21:06:
>> Niels Dekker - no reply address<(E-Mail Removed)> wrote:
>>> What do you mean by "possibly a const"? The following is still
>>> ambiguous, according to the current Working Draft (N3126):
>>>
>>> const int zeroConst = 0;
>>> // bitset(unsigned long long) or bitset(const char*)?
>>> std::bitset<5> bits(zeroConst);

>>
>> Why would a const int be confused with a const char* by the compiler?
>> They are completely unrelated types.

>
> Because a compile-time const integer of value 0, any integer type, converts
> implicitly to nullpointer of any type.


That sounds like a potential source of lots of problems. Who thought
it would be a good idea?

An int is not a pointer, even if that int happens to have the value 0.
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      09-07-2010
* Juha Nieminen, on 07.09.2010 21:14:
> Alf P. Steinbach /Usenet<(E-Mail Removed)> wrote:
>> * Juha Nieminen, on 05.09.2010 21:06:
>>> Niels Dekker - no reply address<(E-Mail Removed)> wrote:
>>>> What do you mean by "possibly a const"? The following is still
>>>> ambiguous, according to the current Working Draft (N3126):
>>>>
>>>> const int zeroConst = 0;
>>>> // bitset(unsigned long long) or bitset(const char*)?
>>>> std::bitset<5> bits(zeroConst);
>>>
>>> Why would a const int be confused with a const char* by the compiler?
>>> They are completely unrelated types.

>>
>> Because a compile-time const integer of value 0, any integer type, converts
>> implicitly to nullpointer of any type.

>
> That sounds like a potential source of lots of problems.


Not only potential...

And most everybody agree, and that's why 'nullptr_t' and 'nullptr' are
introduced in C++0x.

But of course, not without problems of its own, in particular backward
compatibility for the cases where NULL worked as /integer/ in earlier C++ code.


> Who thought it would be a good idea?


The blame of original sin probably belongs to Dennis Ritchie.

At least, he originally developed C, and this conversion was there (although
only formally specified for the literal 0, of int type) already in early C.

K&R "The C Programming Language" 1976 Appendix A "C Reference Manual" 7.14:
"However, it is guaranteed that assignment of the constant 0 to a pointer will
produce a null pointer distinguishable from a pointer to any object".


> An int is not a pointer, even if that int happens to have the value 0.


Hm.


Cheers,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-07-2010
Alf P. Steinbach /Usenet <(E-Mail Removed)> wrote:
>> That sounds like a potential source of lots of problems.

>
> Not only potential...
>
> And most everybody agree, and that's why 'nullptr_t' and 'nullptr' are
> introduced in C++0x.


But there's a difference between:

someFunction(0)

and:

const int zero = 0;
someFunction(zero);

The latter is unambiguously an int, not a pointer.
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      09-07-2010
* Juha Nieminen, on 07.09.2010 21:59:
> Alf P. Steinbach /Usenet<(E-Mail Removed)> wrote:
>>> That sounds like a potential source of lots of problems.

>>
>> Not only potential...
>>
>> And most everybody agree, and that's why 'nullptr_t' and 'nullptr' are
>> introduced in C++0x.

>
> But there's a difference between:
>
> someFunction(0)
>
> and:
>
> const int zero = 0;
> someFunction(zero);
>
> The latter is unambiguously an int, not a pointer.


Yes, I agree: the original sin was compounded in C++.

What to do about it?

Various kludgy workarounds.


Cheers,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-08-2010
On Sep 7, 8:59 pm, Juha Nieminen <(E-Mail Removed)> wrote:
> Alf P. Steinbach /Usenet <(E-Mail Removed)> wrote:


> >> That sounds like a potential source of lots of problems.


> > Not only potential...


> > And most everybody agree, and that's why 'nullptr_t' and 'nullptr' are
> > introduced in C++0x.


> But there's a difference between:


> someFunction(0)


> and:


> const int zero = 0;
> someFunction(zero);


> The latter is unambiguously an int, not a pointer.


No more so than the first. The argument in both cases is
a constant expression having type int, and evaluating to zero.

Of course, a compiler *could* do something special, depending on
the spelling. G++ does: if you use NULL in a context where an
integral type is expected, g++ generates a warning. (But it
doesn't warn if you use 0 in a context where a pointer is
expected.)

--
James Kanze
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-08-2010
James Kanze <(E-Mail Removed)>, on 08/09/2010 03:49:48, wrote:

> On Sep 7, 8:59 pm, Juha Nieminen<(E-Mail Removed)> wrote:
>> Alf P. Steinbach /Usenet<(E-Mail Removed)> wrote:

>
>>>> That sounds like a potential source of lots of problems.

>
>>> Not only potential...

>
>>> And most everybody agree, and that's why 'nullptr_t' and 'nullptr' are
>>> introduced in C++0x.

>
>> But there's a difference between:

>
>> someFunction(0)

>
>> and:

>
>> const int zero = 0;
>> someFunction(zero);

>
>> The latter is unambiguously an int, not a pointer.

>
> No more so than the first. The argument in both cases is
> a constant expression having type int, and evaluating to zero.
>
> Of course, a compiler *could* do something special, depending on
> the spelling. G++ does: if you use NULL in a context where an
> integral type is expected, g++ generates a warning. (But it
> doesn't warn if you use 0 in a context where a pointer is
> expected.)


That should depend on how you're compiling the source. At least in
MinGW, compiling in C++ mode, NULL is perfectly fine assigned to an int,
because NULL is defined as 0. Compiling in C mode it's another matter,
because NULL is defined as ((void*)0).

Interestingly, Stroustrup wrote that this is a case where the type
checking system in C is stricter than in C++.

[citation off the top of my head, it should be somewhere in the
"Siblings' rivalry" paper]

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-08-2010
On Sep 8, 12:08 pm, "Francesco S. Carta" <(E-Mail Removed)> wrote:
> James Kanze <(E-Mail Removed)>, on 08/09/2010 03:49:48, wrote:
> > On Sep 7, 8:59 pm, Juha Nieminen<(E-Mail Removed)> wrote:
> >> Alf P. Steinbach /Usenet<(E-Mail Removed)> wrote:


> >>>> That sounds like a potential source of lots of problems.


> >>> Not only potential...


> >>> And most everybody agree, and that's why 'nullptr_t' and
> >>> 'nullptr' are introduced in C++0x.


> >> But there's a difference between:


> >> someFunction(0)


> >> and:


> >> const int zero = 0;
> >> someFunction(zero);


> >> The latter is unambiguously an int, not a pointer.


> > No more so than the first. The argument in both cases is
> > a constant expression having type int, and evaluating to zero.


> > Of course, a compiler *could* do something special,
> > depending on the spelling. G++ does: if you use NULL in
> > a context where an integral type is expected, g++ generates
> > a warning. (But it doesn't warn if you use 0 in a context
> > where a pointer is expected.)


> That should depend on how you're compiling the source.


There might be an option to turn it off. With no options, I get
the warning from g++ 4.1.1 (under Linux, the only version I have
handy at present).

> At least in
> MinGW, compiling in C++ mode, NULL is perfectly fine assigned to an int,
> because NULL is defined as 0. Compiling in C mode it's another matter,
> because NULL is defined as ((void*)0).


Then MinGW have modified g++ or the libraries somehow. Try the
following program:

#include <stddef.h>
#include <iostream>

#define S1(s) #s
#define S(s) S1(s)

int f(int i)
{
return i;
}

int
main()
{
std::cout << "NULL = \"" << S(NULL) << "\"\n";
std::cout << f(NULL) << '\n';
return 0;
}

Compiling (with simply g++ nullptr.cc) gives me:
nullptr.cc: In function 'int main()':
nullptr.cc:22: warning: passing NULL to non-pointer argument 1 of
'int f(int)'

And running:
NULL = "__null"
0

The C and C++ standards are actually fairly close in this
respect: the macro NULL must be defined as something specifying
a null pointer constant. And a null pointer constant is an
integral constant expression evaluating to 0; C also allows the
null pointer constant to be such an expression explicitly
converted to void*, but that's an innovation of the
C standard---in traditional C, and on most platforms I've seen,
NULL has been #define'd to 0 in C. (Of course, it can be
#define'd to anything that is a null pointer constant: "(1-1)",
"'\0'", "0L"... or even something like "__null", provided the
compiler ensures that __null is treated as a null pointer
constant.)

> Interestingly, Stroustrup wrote that this is a case where the
> type checking system in C is stricter than in C++.


I'd be surprised by that. The reason ((void*)0) is not allowed
as a null pointer constant in C++ is because unlike in C,
a void* doesn't implicitly to any other pointer type. (It's not
really a valid reason, since int's require compiler magic to
work as well; that compiler magic could have been extended to
((void*)0) as well.)

--
James Kanze
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are sequence containers not a subset of general containers? Sebastian Mach C++ 5 10-06-2012 07:54 PM
Containers of iterators vs. containers of references clark.coleman@att.net C++ 7 01-25-2008 01:37 PM
Copy constructors, de/constructors and reference counts Jeremy Smith C++ 2 08-02-2006 11:25 PM
How do the STL containers interact with destructors/constructors? velthuijsen C++ 3 02-13-2004 02:52 PM
Constructors that call other Constructors Dave Rudolf C++ 12 02-06-2004 03:26 PM



Advertisments