From 4537631204432534583 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5cc0e5689db82f7b X-Google-Attributes: gidf78e5,public From: AllanW@my-dejanews.com Subject: Re: Is type_info object static or temporary? Date: 1998/06/14 Message-ID: <6lurbs$7tl$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 362621747 X-NNTP-Posting-Host: 199.125.171.8 Approved: stephen.clamage@sun.com (comp.std.c++) References: <35727d32.0@210.134.196.10> <6kvbv8$o6@engnews1.Eng.Sun.COM> <3580C202.10C45BA@ix.netcom.com> X-Snookums: I love you X-UID: 0000000001 X-Status: $$$T X-Http-User-Agent: Mozilla/4.04 [en] (Win95; I) Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sat Jun 13 21:35:56 1998 GMT Newsgroups: comp.std.c++ Originator: clamage@taumet In article <3580C202.10C45BA@ix.netcom.com>, "Paul D. DeRocco" wrote: > > J. Kanze wrote: > > > > Is the lifetime of the char array pointed to by the return value of > > type_info::name() also so guaranteed. (It's a horrible thought, but > > would it be legal for an implementation to have all calls to > > type_info::name() return a pointer to a static buffer, which got > > overwritten on each call.) > > Any implementation that claims to work in a multi-threaded environment > would have to store all its type names as constant strings. > > It just goes to show you, it's impossible to write a standard in which > every possibility is spelled out in advance. Furthermore, if the implementation were to overwrite a static buffer on each call, it would have to copy the name from somewhere. Conceivably it could keep the type name compressed, and expand it when it overwrote the static buffer, but any savings in the data are likely to be shadowed by the extra code needed to de-compress the data. So here's a case where doing what was intended is FAR simpler than trying to pervert it and yet remain compliant. It does remind me of a different suggestion I recently heard, though, about having a compliant compiler that deliberately does things differently, in order to quickly flag compatibility problems in code that may happen to work locally. There are already real compilers that do this for the limited problem of memory allocation -- i.e. overwriting deleted data with a pattern or making it inaccessible. Doing this for every documented C++ feature seems to be a much bigger problem, perhaps infeasible. I suppose such a compiler would have to twist the RTTI as far as possible; perhaps even by returning class names that can't be easily mapped to the source code names; i.e. at runtime select a unique but random combination of letters and digits. Then on one particular run, the name of int might be "X1", the name of long might be "3UR23", the name of class istream might be "3UR2", etc.! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading [ 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 ]