This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 16.4.5.3[reserved.names]Status:CD1Submitter: Judy WardOpened: 1998-12-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [reserved.names].
View all issues withCD1 status.
Discussion:
The original issue asked whether a library implementor couldspecialize standard library templates for built-in types. (This wasan issue because users are permitted to explicitly instantiatestandard library templates.)
Specializations are no longer a problem, because of the resolutionto core issue 259. Under the proposed resolution, it will be legalfor a translation unit to contain both a specialization and anexplicit instantiation of the same template, provided that thespecialization comes first. In such a case, the explicitinstantiation will be ignored. Further discussion of library issue120 assumes that the core 259 resolution will be adopted.
However, as noted in lib-7047, one piece of this issue stillremains: what happens if a standard library implementor explicitlyinstantiates a standard library templates? It's illegal for a programto contain two different explicit instantiations of the same templatefor the same type in two different translation units (ODR violation),and the core working group doesn't believe it is practical to relaxthat restriction.
The issue, then, is: are users allowed to explicitly instantiatestandard library templates for non-user defined types? The status quoanswer is 'yes'. Changing it to 'no' would give library implementorsmore freedom.
This is an issue because, for performance reasons, libraryimplementors often need to explicitly instantiate standard librarytemplates. (for example, std::basic_string<char>) Does givingusers freedom to explicitly instantiate standard library templates fornon-user defined types make it impossible or painfully difficult forlibrary implementors to do this?
John Spicer suggests, in lib-8957, that library implementors have amechanism they can use for explicit instantiations that doesn'tprevent users from performing their own explicit instantiations: puteach explicit instantiation in its own object file. (Differentsolutions might be necessary for Unix DSOs or MS-Windows DLLs.) Onsome platforms, library implementors might not need to do anythingspecial: the "undefined behavior" that results from having twodifferent explicit instantiations might be harmless.
Proposed resolution:
Append to 16.4.5.3[reserved.names] paragraph 1:
A program may explicitly instantiate any templates in the standard library only if the declaration depends on the name of a user-defined type of external linkage and the instantiation meets the standard library requirements for the original template.
[Kona: changed the wording from "a user-defined name" to "the name of a user-defined type"]
Rationale:
The LWG considered another possible resolution:
In light of the resolution to core issue 259, no normative changes in the library clauses are necessary. Add the following non-normative note to the end of 16.4.5.3[reserved.names] paragraph 1:
[Note: A program may explicitly instantiate standard library templates, even when an explicit instantiation does not depend on a user-defined name.--end note]
The LWG rejected this because it was believed that it would make it unnecessarily difficult for library implementors to write high-quality implementations. A program may not include an explicit instantiation of the same template, for the same template arguments, in two different translation units. If users are allowed to provide explicit instantiations of Standard Library templates for built-in types, then library implementors aren't, at least not without nonportable tricks.
The most serious problem is a class template that has writeable static member variables. Unfortunately, such class templates are important and, in existing Standard Library implementations, are often explicitly specialized by library implementors: locale facets, which have a writeable static member variableid. If a user's explicit instantiation collided with the implementations explicit instantiation, iostream initialization could cause locales to be constructed in an inconsistent state.
One proposed implementation technique was for Standard Library implementors to provide explicit instantiations in separate object files, so that they would not be picked up by the linker when the user also provides an explicit instantiation. However, this technique only applies for Standard Library implementations that are packaged as static archives. Most Standard Library implementations nowadays are packaged as dynamic libraries, so this technique would not apply.
The Committee is now considering standardization of dynamic linking. If there are such changes in the future, it may be appropriate to revisit this issue later.