ctype callsSection: 28.3.4.2.2 [locale.ctype] Status: C++11 Submitter: Martin Sebor Opened: 2004-07-01 Last modified: 2016-01-28
Priority: Not Prioritized
View all issues with C++11 status.
Discussion:
Most ctype member functions come in two forms: one that operates
on a single character at a time and another form that operates
on a range of characters. Both forms are typically described by
a single Effects and/or Returns clause.
The Returns clause of each of the single-character non-virtual forms suggests that the function calls the corresponding single character virtual function, and that the array form calls the corresponding virtual array form. Neither of the two forms of each virtual member function is required to be implemented in terms of the other.
There are three problems:
1. One is that while the standard does suggest that each non-virtual member function calls the corresponding form of the virtual function, it doesn't actually explicitly require it.
Implementations that cache results from some of the virtual member functions for some or all values of their arguments might want to call the array form from the non-array form the first time to fill the cache and avoid any or most subsequent virtual calls. Programs that rely on each form of the virtual function being called from the corresponding non-virtual function will see unexpected behavior when using such implementations.
2. The second problem is that either form of each of the virtual functions can be overridden by a user-defined function in a derived class to return a value that is different from the one produced by the virtual function of the alternate form that has not been overriden.
Thus, it might be possible for, say, ctype::widen(c) to return one
value, while for ctype::widen(&c, &c + 1, &wc) to set
wc to another value. This is almost certainly not intended. Both
forms of every function should be required to return the same result
for the same character, otherwise the same program using an
implementation that calls one form of the functions will behave
differently than when using another implementation that calls the
other form of the function "under the hood."
3. The last problem is that the standard text fails to specify whether one form of any of the virtual functions is permitted to be implemented in terms of the other form or not, and if so, whether it is required or permitted to call the overridden virtual function or not.
Thus, a program that overrides one of the virtual functions so that it calls the other form which then calls the base member might end up in an infinite loop if the called form of the base implementation of the function in turn calls the other form.
Lillehammer: Part of this isn't a real problem. We already talk about
caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
each other, so users don't know which ones to override to avoid avoid
infinite loops.
This is a problem for all facet virtuals, not just ctype virtuals,
so we probably want a blanket statement in clause 22 for all
facets. The LWG is leaning toward a blanket prohibition, that a
facet's virtuals may never call each other. We might want to do that
in clause 27 too, for that matter. A review is necessary. Bill will
provide wording.
[ 2009-07 Frankfurt, Howard provided wording directed by consensus. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Add paragraph 3 to 28.3.4 [locale.categories]:
-3- Within this clause it is unspecified if one virtual function calls another virtual function.
Rationale:
We are explicitly not addressing bullet item #2, thus giving implementors more latitude. Users will have to override both virtual functions, not just one.