Re: Iterators and ints get confused in template parameter
On Jul 21, 1:13 am, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
The code in question is filled with names starting with _ and
__, for example:
typedef typename std::__is_integer<_InputIterator>::__type _Integral;
This seems to be telling me that this is not standard library code,
Why?
Does the C++ standard really specify templates like std::__is_integer?
The C++ standard does not specify how any of the standard
containers are implemented. It does require the implementation
to discriminate between integral types and other types in the
two iterator template member functions.
If not, then the code above is specific to the library in
question and thus not portable all in itself.
Obviously, such code is specific to the library. That doesn't
mean that it uses compiler extensions, and isn't "portable"
(except that user code doesn't have the right to use names
beginning with __). It's quite possible to write something like
__is_integer in portable C++, and I'd be fairly surprised if the
implementation in the g++ library wasn't in portable C++ (again,
modulo the fact that the names aren't legal in user code).
It's part of the implementation, so it's bound to use funny
names. But it's part of the implementation of the standard
library.
My point is: I want to replicate the functionality, but I
can't just copy it verbatim from gcc's library because it uses
non-standard types like the ones in the above example line.
And my point is: I don't see your point. Why can't you copy
__is_integer, changing the names, and use it?
but code specific to gcc (or whatever STL library it's using).
Thus it wouldn't probably be very portable to try to copy this
implementation verbatim.
Maybe, maybe not.
Unless the C++ standard specifies things like
std::__is_integer, the answer is no.
Why? I'm pretty sure that the answer is yes.
The only thing I could do is to copy the functionality of that
type (and whatever it might use) into my code, but I was
wondering if there isn't any easier way.
Well, rather than copying, the actual code isn't too difficult
to understand, so it might be worth implementing it yourself,
for pedagogical reasons. Otherwise, there are implementations
of it in Boost, and doubtlessly elsewhere as well; the Boost
implementation is part of TR1, if I'm not mistaken, and will be
part of the next standard. (But I don't follow the library
issues too closely, so I could be wrong here.)
It's possible that the g++ library uses some special g++
extensions here, but somehow I doubt it. And it certainly
can be done in standard C++. (The standard requires it be
done somehow, of course.)
I don't think you really understood what I meant.
The standard says that when one of the two iterator template
functions is instantiated, if the instantiation type is an
integral type (and thus, not an iterator), the instantiation
should behave as if the corresponding non-template function
taking a size_t as its first argument was called. That means
that every implementation must somehow make it work.
At the time this clause was adopted, it was done so because it
was clear to the authors that it could be done in standard C++,
without any compiler tricks.
template<>
struct IntegerDiscriminator< int >
{
typdef True Type ;
}
Doesn't that only take care of the case where the parameter is
of type 'int'? What about unsigned int, long, unsigned long,
short, unsigned short, char, signed char, unsigned char, long
long, unsigned long long...
Obviously. I thought I'd put a ... after it, to indicate that
you needed to extend it.
But you only have to do it once. You can use
IntegerDiscriminator for all such functions.
Or something like that. For all the details, see the
Vandevoorde and Josuttis.
I didn't understand that.
If you're doing anything but the simplest templates, you should
definitely read " C++ Templates - The Complete Guide", by David
Vandevoorde and Nicolai Josuttis (ISBN 0-201-73484-2). It is
the reference for everything concerning templates, and it has
a complete chapter concerning just such problems. It's one of
those musts, without which your technical library isn't
complete.
--
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