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