Draft C++0x has special rules regarding overloading resolution that mention
a specific library type:  std::initializer_list.  (The special rules affect
the handling of brace initializers used to initialize non-aggregates.)  In
other words, the behavior of the core language takes into account a specific
user-defined type in the library.  Are there other cases where the core
language does this, i.e., has behavior dependent on a specific type (or
template) in the standard library?  I'm interested in non-typedef cases, so
e.g., language rules dependent on std::size_t don't count, because size_t is
just a synonym for a built-in type, not a user-defined type.

Thanks,

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers <NeverRead@aristeia.com> writes:

> Draft C++0x has special rules regarding overloading resolution that mention
> a specific library type:  std::initializer_list.  (The special rules affect
> the handling of brace initializers used to initialize non-aggregates.)  In
> other words, the behavior of the core language takes into account a specific
> user-defined type in the library.  Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?  I'm interested in non-typedef cases, so
> e.g., language rules dependent on std::size_t don't count, because size_t is
> just a synonym for a built-in type, not a user-defined type.

type_info, bad_cast, va_arg comes immediately to mind (va_arg is very
similar to std::initializer_list in intend and interaction between the
library and the language).  I may be missing some things more recent.

Yours,

--
Jean-Marc

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 18 Dec, 03:42, Scott Meyers <NeverR...@aristeia.com> wrote:
>
> Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?
>

Library types std::type_info, std::bad_cast, and std::bad_typeid are
used by core language constructs (typeid, dynamic_cast).

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 17, 5:42 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
> Draft C++0x has special rules regarding overloading resolution that mention
> a specific library type:  std::initializer_list.  (The special rules affect
> the handling of brace initializers used to initialize non-aggregates.)  In
> other words, the behavior of the core language takes into account a specific
> user-defined type in the library.  Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?  I'm interested in non-typedef cases, so
> e.g., language rules dependent on std::size_t don't count, because size_t is
> just a synonym for a built-in type, not a user-defined type.
>
> Thanks,
>
> Scott

std::nullptr_t is the only other type I can think of, since all values
of type std::nullptr_t are null pointer constants, and thus do all
sorts of magic.

Sean


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 17 dez, 22:42, Scott Meyers <NeverR...@aristeia.com> wrote:
> Draft C++0x has special rules regarding overloading resolution that mention
> a specific library type:  std::initializer_list.  (The special rules affect
> the handling of brace initializers used to initialize non-aggregates.)  In
> other words, the behavior of the core language takes into account a specific
> user-defined type in the library.  Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?  I'm interested in non-typedef cases, so
> e.g., language rules dependent on std::size_t don't count, because size_t is
> just a synonym for a built-in type, not a user-defined type.

Is the type of nullptr user-defined?

--
  P.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pedro Lamar   o wrote:
> Is the type of nullptr user-defined?

Not really. The type is std::nullptr_t, but look how draft C++0x specifies it:

> nullptr_t is defined as follows:
> namespace std {
> typedef decltype(nullptr) nullptr_t;
> }
> The type for which nullptr_t is a synonym has the characteristics described in 3.9.1 and 4.10.

Scott


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <NeverRead@aristeia.com> wrote in message
news:hge1hl$blh$1@news.albasani.net...
> Draft C++0x has special rules regarding overloading resolution that
> mention
> a specific library type:  std::initializer_list.  (The special rules
> affect
> the handling of brace initializers used to initialize non-aggregates.)  In
> other words, the behavior of the core language takes into account a
> specific
> user-defined type in the library.  Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?  I'm interested in non-typedef cases,
> so
> e.g., language rules dependent on std::size_t don't count, because size_t
> is
> just a synonym for a built-in type, not a user-defined type.

Many of the magic library types like va_arg, initalizer_list, type_info, and
nullptr_t effectively are built-in types, since they require special
compiler support in their implementation.

You then have those that are typedefs for builtins that have other names,
such as std::size_t.

Lastly you have a few types that can be truly user defined, and really only
special in terms of the name, like the execptions that the core language can
throw.




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> Draft C++0x has special rules regarding overloading resolution that mention
> a specific library type:  std::initializer_list.  (The special rules affect
> the handling of brace initializers used to initialize non-aggregates.)  In
> other words, the behavior of the core language takes into account a specific
> user-defined type in the library.  Are there other cases where the core
> language does this, i.e., has behavior dependent on a specific type (or
> template) in the standard library?  I'm interested in non-typedef cases, so
> e.g., language rules dependent on std::size_t don't count, because size_t is
> just a synonym for a built-in type, not a user-defined type.

I had compiled a list of such core language features depending on the
library here back in 2002 -- definitely for C++98:
http://groups.google.com/group/comp.std.c++/msg/424d1e1473c5ef6a

Many of them have been mentioned in this thread, but a few, such as
bad_exception, haven't yet.

--
Seungbeom Kim

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Seungbeom Kim" <musiphil@bawi.org> wrote:
> I had compiled a list of such core language features depending on the
> library here back in 2002 -- definitely for C++98:
> http://groups.google.com/group/comp.std.c++/msg/424d1e1473c5ef6a
>

I must dispute at least std::nothrow.

That functionality is completely part of the library, even if that is not
clear by the wording of the standard.

It is implemented as roughly the following.

>struct nothrow_t {}; //defined in namespace std
>void* operator new (size_t size, const std::nothrow_t &){
>try {return operator new(size);}
>catch(...) { return 0;}
>}
>extern const nothrow_t nothrow;

operator new is not magical, only the new operator is magical, since it
brings an object into existsance.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 21, 11:09 am, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
> Many of the magic library types like va_arg, initalizer_list, type_info, and
> nullptr_t effectively are built-in types, since they require special
> compiler support in their implementation.

I disagree with putting va_list (I assume you meant that and not
va_arg) and type_info here. While they are part of the language
support, there's nothing really special about them as far as their use
in code. type_info in particular could be implemented as conformant C+
+ generated by the compiler as it processes the source and then
compiled as the last step. I'd also argue that va_list isn't really
much more special than FILE; both require some magic in their
implementation, but there's no need it be provided by the compiler
(assuming, in the case of va_list, a consistent calling convention).

Sean


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]