libstdc++/5133: Problems with toupper
Pete Ratzlaff
rpete@legs.harvard.edu
Fri Nov 22 05:11:00 GMT 2002
The following reply was made to PR libstdc++/5133; it has been noted by GNATS.
From: Pete Ratzlaff <rpete@legs.harvard.edu>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc: paolo@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sat, 16 Nov 2002 00:17:10 -0500
I realize this PR is closed, but don't agree with the conclusion that
mixing linkages in this case is ill-formed. There's is nothing to
preclude the template argument from being a function with C
linkage. Here is what the standard has to say:
template<class InputIterator, class OutputIterator,
class UnaryOperation>
OutputIterator
transform(InputIterator first, InputIterator last,
OutputIterator result, UnaryOperation op);
1- Effects: Assigns through every iterator i in the range [result,
result + (last1 - first1)) a new corresponding value equal to
op(*(first1 + (i - result))
In other words, anything that can have an () appended and follows the
rules for template parameters is fair game for the 3rd template
argument in this case.
All I can guess is that Martin was thinking of the std::ptr_fun and
std::pointer_to_unary_function templates, whose argument (and ctor)
are explicitly pointers to function (with C++ linkage).
I cannot see anything that keeps one from using the toupper/tolower
from <cctype> with transform, and the fact that gcc won't allow it
should be considered a bug.
Although it certainly doesn't prove my point, I would just note that
Comeau's compiler seems to concur.
Cheers,
-Pete
More information about the Gcc-prs
mailing list