This is the mail archive of the mailing list for the libstdc++ project.

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

Re: PR3042

>>>>> Gabriel Dos Reis writes:

Gabriel> To make the whole discussion sensible, I would like you read and
Gabriel> understand what it means for an object to be a static data member in
Gabriel> C++.  Mark's proposal isn't to make "static" stop working.  Please,
Gabriel> take a look at what "static data member" means in C++.  The core
Gabriel> issue isn't about "static", it is about implicit instantiation
Gabriel> implementation.  That is orthogonal to "static" semantics.  Confusing
Gabriel> the two notions will at best confuse the discussion.

	Mark's proposal is "define nowhere" -- to quote Mark.  To be

  static int i = 7;

allocates storage.

  static int i;

does not allocate storage, only a reference to the symbol.

	Not only would Mark's change affect behavior with shared
libraries, but it would have the same effect for the normal case of static
archives and linking.

	If COMMON symbols in objects and shared libraries are merged (as
they are for ELF-based systems and the other non-AIX systems and AIX using
the linker -brtl option), then the above example will behave the same on
AIX for both cases without Mark's change.  This will be the same behavior
as on other platforms.

	I believe that "static" must allocate storage.

	Mark separately is arguing that templates do not allocate storage
and a definition on systems without support for WEAK symbols (to merge
together data section blocks, as opposed to COMMON bss section blocks).
Because templates need to be instantiates on all of those platforms (not
AIX), then static should behave the same way.

	Developers are used to the vagueries of template instantiation.
Beyond that, G++ and other compilers provide options like
-fno-implicit-instantiation.  I do not care whether the C++ standard
thinks about that option.  No one is jumping up and down that this is a
horrible, incompatible G++ extension that must be removed.  Many
developers seem to accept that as a viable way to program and to
explicitly control template instantiation in their program.  Until AIX
supports WEAK symbols, AIX requires some form of single instantiation
(-fno-implicit-instantiation, -frepo, etc.)

	Additionally, if implicit template instantiation could be handled
by using many COMMON symbols which were merged by the linker and
initialized once at runtime (instead of many WEAK symbols), then implicit
template instantiation would behave the same as static class members and
would work on AIX and other systems without WEAK symbols.  In other words,
make implicit template instantiation COMDAT support more like static class
members, instead of vice-versa.


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