"Special" library types
Scott Meyers
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...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Jean-Marc Bourguet
> 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...@netlab.cs.rpi.edu]
Nikolay Ivchenkov
>
> 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...@netlab.cs.rpi.edu]
Sean Hunt
> 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...@netlab.cs.rpi.edu]
Pedro Lamarão
> 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...@netlab.cs.rpi.edu]
Scott Meyers
> 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
Joe Smith
"Scott Meyers" <Neve...@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...@netlab.cs.rpi.edu]
Seungbeom Kim
> 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...@netlab.cs.rpi.edu]
Joe Smith
"Seungbeom Kim" <musi...@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.
--
Sean Hunt
> 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