🚀 go-pugleaf

In article <4e8r8a$9ir@bmtlh10.bnr.ca> "john (j.d.) hickin"
<hickin@bnr.ca> writes:

> From the October draft (I think); the basic_string class interface has these
> declarations:
> 
>    typedef typename Allocator::size_type       size_type;
>    ...
>    static const size_type npos = -1;
> 
> It is my understanding that the Allocater::size_type should be an unsigned
> flavour.  If this is indeed the case, are we to interpret nops as having the
> value (size_type)(-1) ?

Yes.  And the various definitions of arithmetic on unsigned types means
that in fact, this must be the largest value that the given unsigned
type can contain.

At least, the above is true for the built-in unsigned types.  I'm
intreged by the idea that size_type could conceivably be a user defined
type.  In particular, consider an extensible unsigned type, conceptually
unbound (and in reality only bound by available memory).  Presumably, it
will have a constructor for unsigned; the compiler will convert -1 to
(unsigned)(-1); on a 16 bit machine, 65536.  If the purpose of using
this special type is precisely to obtain the extended range, we have a
problem.

I suspect that the requirement should be: size_type must be an unsigned
type with a conversion from int for which -1 results in the largest
possible value.  An extensible unsigned type, as above, would require a
constructor which takes an int (as well as the one with unsigned), and
handle -1 by converting to some sort of special `infinity'.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]