This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Cauldron: Notes from the C++ ABI BOF


On Wed, Jul 11, 2012 at 02:47:37PM +0200, Michael Matz wrote:
> On Wed, 11 Jul 2012, Ian Lance Taylor wrote:
> 
> > We will modify g++ to support a type attribute indicating the version of 
> > the type, as a string.  This type attribute will be inherited by any 
> > other type that uses it, as a class/struct member or via inheritance.  
> > Type attributes will be concatenated as needed.  This type attribute 
> > will then be used in the mangled name of any function that takes a 
> > parameter of a type with an attribute or returns a type with an 
> > attribute.  The type attribute will also be used in the mangled name of 
> > any global variable whose type has an attribute.
> 
> There are some technical details that need to be decided: Should every 
> type affected have a different tag, or just one common (e.g. all of c++11 
> types that differ would get "_cxx11"?  Then, should the set of these tags 

Multiple types that are changed at the same time (and have the type added to
all of them concurrently) can and should use the same string.
Then there is no way to have new list and old pair together (if you use
unmodified libstdc++ headers at least), either during compilation both will
have "cxx11" string in the new type attribute, or none, so either you are
using a new std::list and std::pair, or the old one (well, std::pair is a
bad example probably, std::string and std::list is good, what other types we
are going to change?).

> if there are multiple be regarded as unordered set?  This would allow 

I'd just sort the collected strings.  The other option is to remember in
some canonical way in what order the various strings have been seen for the
first time.

> The question boils down to what we want to add to the mangled name of a 
> type looking like so (or an function taking the equivalent number of 
> arguments):
> 
> class X {
>   std::list l1;  // all new lists
>   std::list l2;
>   std::list l3;
>   std::list l4;
>   std::pair p1;  // the old pair
> };

Can't happen, unless the libstdc++ headers would allow e.g. preprocessor
macros or compiler options to tweak the type attributes of std::list and
std::pair individually (but, if it allows that, then they must not use the
same string, if it doesn't allow that, then it can).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]