From -1061378058800684496
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,fbd36da46c3cc7a0
X-Google-Attributes: gidf78e5,public
From: scorp@btinternet.com (Dave Harris)
Subject: Re: Discussion: type_info
Date: 1999/11/27
Message-ID: <memo.19991126195718.59965A@btinternet.com>#1/1
X-Deja-AN: 553578412
X-NNTP-Posting-Host: host212-140-50-131.btinternet.com
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <81ecdl$pq$1@nnrp1.deja.com>
X-UID: 0000000001
X-Status: $$$T
Organization: Burry Holms Research
X-URL: http://www.ameol.com
X-News-Software: Ameol2
Reply-To: brangdon@cix.co.uk
Newsgroups: comp.std.c++
Originator: clamage@taumet


sirwillard@my-deja.com () wrote:
> 1.  Useage of type_info within an associative container is so common
> that the designers went the extra mile to allow it by including
> type_info::before for collating, yet they didn't design the class with
> copy construction capabilities.  There are techniques that would have
> allowed this and gauranteed that slices would not have been created.
> The simplest of these is the "pimpl" idiom (which is basically what my
> adaptor does).  Why wasn't this done?

Presumably a matter of not paying for what you don't use. "before()" ought 
to be trivial to implement. If a vendor can at least manage unique names 
they can use those to provide the ordering, which has minimal cost. Using 
"pimpl" has a cost per type_info.


> 2.  If collation capabilities were so important that it was added to
> the design, why were natural collation operations not provided?  Why
> type_info::before instead of type_info::operator<?

Perhaps because of potential confusion with type_info::sub_class_of(). 
Although sub-class testing isn't yet part of type_info, it's something 
that might be added by a future version of the standard, and possibly as a 
non-portable extension today. If we have:
     type_info::before();
     type_info::sub_class_of();
     type_info::operator<();

users might be confused over which operator<() actually did.


> 3.  The C++ language has a boolean type, bool, yet the native class
> type_info uses int returns instead.  Why?

This one looks like a mistake to me.


> 4.  Why was there no thought put into providing some state within
> type_info that could be portably used for hashing functions?  I realize
> this would have been more complex, but surely it would be possible.

Use type_info::name(). I would think any implementor who was able to 
provide a good hashing value would also be able to provide unique names.

Recall also that the STL doesn't provide hashing anywhere, as far as I can 
see. Type_info is being consistent with that. When hashing gets added, as 
I hope it will be in 5 or 10 years time, it will presumably come with a 
bunch of conventions about the name of the hash function, the type of the 
hashed value, etc. Type_info is right to avoid pre-empting those 
decisions.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]