Section: 31.7.5.2.4 [istream.sentry] Status: NAD Submitter: Matt McClure and Dietmar Kühl Opened: 2000-01-01 Last modified: 2021-06-06
Priority: Not Prioritized
View all other issues in [istream.sentry].
View all issues with NAD status.
Discussion:
27.6.1.1.2 Paragraph 4 states:
To decide if the character c is a whitespace character, the constructor performs ''as if'' it executes the following code fragment:
const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc()); if (ctype.is(ctype.space,c)!=0) // c is a whitespace character.
But Table 51 in 22.1.1.1.1 only requires an implementation to provide specializations for ctype<char> and ctype<wchar_t>. If sentry's constructor is implemented using ctype, it will be uninstantiable for a user-defined character type charT, unless the implementation has provided non-working (since it would be impossible to define a correct ctype<charT> specialization for an arbitrary charT) definitions of ctype's virtual member functions.
It seems the intent the standard is that sentry should behave, in every respect, not just during execution, as if it were implemented using ctype, with the burden of providing a ctype specialization falling on the user. But as it is written, nothing requires the translation of sentry's constructor to behave as if it used the above code, and it would seem therefore, that sentry's constructor should be instantiable for all character types.
Note: If I have misinterpreted the intent of the standard with respect to sentry's constructor's instantiability, then a note should be added to the following effect:
An implementation is forbidden from using the above code if it renders the constructor uninstantiable for an otherwise valid character type.
In any event, some clarification is needed.
Rationale:
It is possible but not easy to instantiate on types other than char or wchar_t; many things have to be done first. That is by intention and is not a defect.