"Bo Persson" wrote:
> I was more curious on how the C++ standard addresses
> compilers were pointers are longer than all of the int types. Using a
> C99 type seems like cheating! :-)

Ben Hutchings <do-not-spam-benh@bwsint.com> wrote:
> There's nothing inherently wrong with that.  However, for implementations
> iwith a flat memory model it makes sense for ptrdiff_t and size_t to be
> the same size as pointers, and I think those types are required to be
> typedefs for standard integer types.

Well, if that requirment is indeed true, and the compiler has 64-bit
pointers with no standard interger type being bigger than 32-bits,
then there are two options.  One is to make ptrdiff_t and size_t 32-bit
and so restrict the size of any single object to be 4Gb.  The second is
to not claim Standard C++ compiliance.  I believe Microsoft chose the
second option for VC++.

btw. with GCC the size of long is dependent on the target OS.  So a Win64
version of GCC (if it exists) would use a 32-bit long (and 64-bit size_t).

      Ross Ridge

--
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/u/rridge/
 db  //

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

do-not-spam-benh@bwsint.com (Ben Hutchings) wrote in message news:<slrnbhdt3k.1ik.do-not-spam-benh@tin.bwsint.com>...
...
> > I was more curious on how the C++ standard addresses
> > compilers were pointers are longer than all of the int types. Using a
> > C99 type seems like cheating! :-)
>
> There's nothing inherently wrong with that.  However, for implementations
> with a flat memory model it makes sense for ptrdiff_t and size_t to be
> the same size as pointers, and I think those types are required to be
> typedefs for standard integer types.

The C++ standard doesn't specify that directly, apparantly deferring
that issue to the C standard. The current C++ standard
cross-references the C90 standard, and I don't have a copy of that. I
do, however, have a copy of the C99 standard, which specifies that
ptrdiff_t must be a signed integer type, and that size_t must be an
unsigned integer type. In C99, the signed integer types are explicity
defined as including both standard integer types and extended
(implementation-defined) integer types.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kuyper <kuyper@wizard.net> wrote:
>The C++ standard doesn't specify that directly, apparantly deferring
>that issue to the C standard. The current C++ standard
>cross-references the C90 standard, and I don't have a copy of that. I
>do, however, have a copy of the C99 standard, which specifies that
>ptrdiff_t must be a signed integer type, and that size_t must be an
>unsigned integer type. In C99, the signed integer types are explicity
>defined as including both standard integer types and extended
>(implementation-defined) integer types.

I don't have the C90 standard handy either, but I'm pretty sure that's
new for C99.  I remember POSIX having a similiar issue because it said
some types were arithmetic types and deferred to the C90 standard for
the definition of what an arithmetic type was.

      Ross Ridge

--
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/u/rridge/
 db  //

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cxl@volny.cz ("Mirek Fidler") writes:

>> > According to the standard, std::vector<X>::size_type is required
>> > to be std::size_t.  For all types T (except maybe bool).
>>
>> Oh, yes. The weasel rules in 20.1.5/4 :-)
>
>     If that is true then it might have negative performance impact on
> e.g. AMD64 platform - as all indices will be stored as 64-bit values
> (that is what I expect size_t to be), while native int size is 32-bits.


It isn't true.  A conforming library implementation is permitted to
assume that size_type is size_t, but it is also allowed to be smarter
and allow for different size_type's.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Mirek Fidler"" <cxl@volny.cz> skrev i meddelandet
news:bej7m0$5edj2$1@ID-198693.news.dfncis.de...
> > > According to the standard, std::vector<X>::size_type is required
to
> be
> > > std::size_t.  For all types T (except maybe bool).
> >
> > Oh, yes. The weasel rules in 20.1.5/4 :-)
>
>     If that is true then it might have negative performance impact
on
> e.g. AMD64 platform - as all indices will be stored as 64-bit values
> (that is what I expect size_t to be), while native int size is
32-bits.

Or not...

>From what I have seen, compilers like  MSVC and gcc seems to keep int
and long at 32 bits, even though a pointer is 64 bits. How is this
solved for the standard library?



Bo Persson
bop2@telia.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <RZ_Pa.16087$mU6.15403@newsb.telia.net>, "Bo Persson" wrote:
>
> ""Mirek Fidler"" <cxl@volny.cz> skrev i meddelandet
> news:bej7m0$5edj2$1@ID-198693.news.dfncis.de...
>> > > According to the standard, std::vector<X>::size_type is required
>> > > to be std::size_t.  For all types T (except maybe bool).
>> >
>> > Oh, yes. The weasel rules in 20.1.5/4 :-)
>>
>>     If that is true then it might have negative performance impact
>> on e.g. AMD64 platform - as all indices will be stored as 64-bit
>> values (that is what I expect size_t to be), while native int size
>> is 32-bits.
>
> Or not...
>
> From what I have seen, compilers like  MSVC and gcc seems to keep int
> and long at 32 bits, even though a pointer is 64 bits. How is this
> solved for the standard library?

GCC doesn't do this; for 64-bit architectures it uses 32-bit ints and
64-bit longs.  VC++ behaves as you say.  It doesn't even support C99's
long long!  Instead it has non-standard types called (signed|unsigned)
__int64 and uses these to define size_t and ptrdiff_t for 64-bit
architectures.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ben Hutchings" <do-not-spam-benh@bwsint.com> skrev i meddelandet
news:slrnbhamo5.1dc.do-not-spam-benh@tin.bwsint.com...
> In article <RZ_Pa.16087$mU6.15403@newsb.telia.net>, "Bo Persson"
wrote:
> >
> > ""Mirek Fidler"" <cxl@volny.cz> skrev i meddelandet
> > news:bej7m0$5edj2$1@ID-198693.news.dfncis.de...
> >> > > According to the standard, std::vector<X>::size_type is
required
> >> > > to be std::size_t.  For all types T (except maybe bool).
> >> >
> >> > Oh, yes. The weasel rules in 20.1.5/4 :-)
> >>
> >>     If that is true then it might have negative performance
impact
> >> on e.g. AMD64 platform - as all indices will be stored as 64-bit
> >> values (that is what I expect size_t to be), while native int
size
> >> is 32-bits.
> >
> > Or not...
> >
> > From what I have seen, compilers like  MSVC and gcc seems to keep
int
> > and long at 32 bits, even though a pointer is 64 bits. How is this
> > solved for the standard library?
>
> GCC doesn't do this; for 64-bit architectures it uses 32-bit ints
and
> 64-bit longs.

ok.

>VC++ behaves as you say.  It doesn't even support C99's
> long long!  Instead it has non-standard types called
(signed|unsigned)
> __int64 and uses these to define size_t and ptrdiff_t for 64-bit
> architectures.

Well, in version 7.1 it actually has a long long (as a synonym for its
own __int64). I was more curious on how the C++ standard addresses
compilers were pointers are longer than all of the int types. Using a
C99 type seems like cheating! :-)


Bo Persson
bop2@telia.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <lIjRa.20594$dP1.38797@newsc.telia.net>, "Bo Persson" wrote:
>
> "Ben Hutchings" <do-not-spam-benh@bwsint.com> skrev i meddelandet
> news:slrnbhamo5.1dc.do-not-spam-benh@tin.bwsint.com...
<snip>
>>VC++ behaves as you say.  It doesn't even support C99's long long!
>>Instead it has non-standard types called (signed|unsigned) __int64 and
>>uses these to define size_t and ptrdiff_t for 64-bit architectures.
>
> Well, in version 7.1 it actually has a long long (as a synonym for its
> own __int64).

It's well hidden in the documentation.  I have found it now, but it isn't
where I expected.

> I was more curious on how the C++ standard addresses
> compilers were pointers are longer than all of the int types. Using a
> C99 type seems like cheating! :-)

There's nothing inherently wrong with that.  However, for implementations
with a flat memory model it makes sense for ptrdiff_t and size_t to be
the same size as pointers, and I think those types are required to be
typedefs for standard integer types.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > According to the standard, std::vector<X>::size_type is required to
be
> > std::size_t.  For all types T (except maybe bool).
>
> Oh, yes. The weasel rules in 20.1.5/4 :-)

    If that is true then it might have negative performance impact on
e.g. AMD64 platform - as all indices will be stored as 64-bit values
(that is what I expect size_t to be), while native int size is 32-bits.

Mirek


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <x0qIa.221$rn2.20@newsfep3-gui.server.ntli.net>,
 on Fri, 20 Jun 2003 19:41:53 +0000 (UTC),
 gibsonj@hotmail.com ("James Gibson") wrote:

> Is std::vector<X>::size_type required to be the same type as
> std::vector<Y>::size_type for all types X, Y?

No, although I'm not aware of an implemention where they differ (assuming
use of the default allocator, as in this case). (And ignoring the
<em>evil</em> std::vector<bool>...)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1056143084.995486@master.nyc.kbcfp.com>...
> James Gibson wrote:
> > Is std::vector<X>::size_type required to be the same type as
> > std::vector<Y>::size_type for all types X, Y?
>
> No.
>

But really it is size_t in all implementations I've seen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message
news:<1056374893.400495@master.nyc.kbcfp.com>...
> James Kanze wrote:
> > According to the standard, std::vector<X>::size_type is required to
> > be std::size_t.  For all types T (except maybe bool).

> Oh, yes. The weasel rules in 20.1.5/4 :-)

So I was right after all:-).  (I was actually thinking of the types in
the standard allocator used by vector<X>, but not necessarily by all
instantiations of std::vector.  And has been pointed out, the standard
does not require size_type of a container to be that of its allocator.)

On the other hand, given the weasel rules (as you so rightly call them),
what's the point of having allocators anyway?

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:
>
> On the other hand, given the weasel rules (as you so rightly call them),
> what's the point of having allocators anyway?
>

That's a bit of an overstatement. Allocators can be used to provide
alternative allocation strategies to provide, for example, caching and
thread synchronization. The weasel rules apply to the nested typedefs
pointer and reference and they are, indeed, pointless.

Originally their purpose was to mask differences in pointer and
reference types that were needed to support non-standard memory models.
You could, for example, write an allocator that managed data in the far
heap, even though you built your application in small model (if you
remember the good old days of 16-bit Intel processors). Somewhere along
the path to standardization that goal got lost, and there was talk of
object databases and such. With no clear design goal the result was
something that is nearly useless because the standard allows
implementations to give these typedefs no meaningful semantics. (Our
library takes allocator::pointer and allocator::reference seriously)

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gennaro_prota@yahoo.com (Gennaro Prota) wrote in message
news:<4fvbfv8g4hp5ek0nv8ufg9ni4aondjmefg@4ax.com>...
> On Sun, 22 Jun 2003 17:52:27 +0000 (UTC), kanze@alex.gabi-soft.fr
> (James Kanze) wrote:

> >According to the standard, std::vector<X>::size_type is required to
> >be std::size_t.  For all types T (except maybe bool).

> >Perhaps you were thinking of the case where a user specific allocator
> >is used.

> But are you sure? I can't see any requirement for the vector's
> size_type to be the same as its allocator's size_type (there's for
> basic_string, instead).

Good point.  For std::vector, in fact, the requirement is that it be the
unsigned correspondant for the iterator's difference_type.

Wierd why string and vector would be different here.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:
>
> Good point.  For std::vector, in fact, the requirement is that it be the
> unsigned correspondant for the iterator's difference_type.
>
> Wierd why string and vector would be different here.
>

They're on different branches of the evolutionary bush.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Is std::vector<X>::size_type required to be the same type as
std::vector<Y>::size_type for all types X, Y?

TIA,

James.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Gibson wrote:
> Is std::vector<X>::size_type required to be the same type as
> std::vector<Y>::size_type for all types X, Y?

No.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) writes:

|>  James Gibson wrote:
|>  > Is std::vector<X>::size_type required to be the same type as
|>  > std::vector<Y>::size_type for all types X, Y?

|>  No.

According to the standard, std::vector<X>::size_type is required to be
std::size_t.  For all types T (except maybe bool).

Perhaps you were thinking of the case where a user specific allocator
is used.

--=20
James Kanze                                  mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                      Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  Tel. +33 1 41 89 80 93

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 22 Jun 2003 17:52:27 +0000 (UTC), kanze@alex.gabi-soft.fr
(James Kanze) wrote:

>According to the standard, std::vector<X>::size_type is required to be
>std::size_t.  For all types T (except maybe bool).
>
>Perhaps you were thinking of the case where a user specific allocator
>is used.

But are you sure? I can't see any requirement for the vector's
size_type to be the same as its allocator's size_type (there's for
basic_string, instead).


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
> According to the standard, std::vector<X>::size_type is required to be
> std::size_t.  For all types T (except maybe bool).

Oh, yes. The weasel rules in 20.1.5/4 :-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]