Re: Problem with <algorithm> transform
On Jan 6, 11:15 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Erik Wikstr=F6m:
On 2008-01-06 21:45, Andrew Koenig wrote:
transform(s.begin(), s.end(),s.begin(), toupper);
Something seems seriously wrong but I can't figure it.
Alas, toupper is a macro so you can't pass it as an argument.
Are you sure? In C99 it is a function specified as int
toupper(int c) (section 7.4.2.2, "The toupper function") and
in C++98 table 45 it is also listed as a function.
The reference you give is correct, and means that Andrew
Koenig made a mistake.
Surprisingly.
To the OP: the code you posted compiled and ran fine with
MSVC++ so I am not sure why it did not work for you.
Ironically, the error seems to be due to Koenig lookup... :-)
Not really, but see my other postings.
However, adding an include of <locale> does not reproduce the
error with MSVC 7.1.
Are you kidding? (I just tried it with VC++ 8, and I get the
same results. Could it be that Dinkumware uses some form of
concept checking to exclude functions here which can't be called
with only one argument? Or?)
I haven't tried it, but he did have a "using namespace std;" in
there, so everything in <locale> should be visible. In theory
at least---and probably in practice, including <ctype.h> (*NOT*
<cctype>), and specifying ::toupper (to block any chance of
finding the functions in <locale>) should allow the code to
compile.
As Newton puportedly said, I frame no hypothesis.
However there is also a toupper() function in C++ declared
in the <locale> header which might work (i.e. replace
<cctype> with <locale> and try again).
No, that one is a bit different: it suffers from the usual
standard library (except STL parts) unusability and
complexity, taking a locale argument as second argument.
Which is not a problem for occasional use.
What you really need is some sort of functional object, however,
which will get the ctype facet once from the locale, and use the
toupper of the facet.
A cure for the immediate problem is to write
::toupper
but this may be a compiler-specific cure (I'm not sure).
If he includes <ctype.h>, the resulting code is guaranteed to
compile.
[...]
So to sum up, the Josuttis book example may be correct for the
given data (only ASCII characters), but not for an arbitrary
input string, and, g++ apparently does something funny.
One of the C++ headers he's included probably includes <locale>
in the g++ implementation. The standard clearly says that this
is unspecified (even though it can cause no number of
portability problems).
Anyway, I'd be very interested in hearing from someone familiar
with the VC++ implementation, explaining why the original code
still compiles when you include <locale>. Like you, I can't
explain it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34