In article <wmxdtQAihUm1Ew5o@noco.demon.co.uk>,
  Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
> >> >They may not know the actual ammount of memory, but they do know th=
e
> >> >maximum.  If the processor has 16 address bits, you really don't ha=
ve
> >> >to worry about what happens with more than 64K elements.  And of co=
urse,
> >> >a lot of processors have even less.
> >>
> >> External page registers excepted of course.
> >
> >Not really.  Without some very special logic, you can't have objects
> >(vectors, etc.) spanning several pages.  So the problem of an object
> >containing more than 64K elements doesn't occur.
>
> I don't follow you. Objects could easily be (arbitrarily) bigger than
> 64k. The special logic would have to live in the container access
> methods maybe. I don't really know what you mean by this though.

The standard containers don't (or don't have to) have this special
logic.  Not all hardware even supports it; I've worked with embedded
chips with a fixed amount of on chip memory, and no pins to address
anything else.

> People (compiler and emulator vendors I mean) have paged memory support
> for lots of CPUs that have only 64K address spaces. I don't see why not
> C++ ?

If the system has adequate support for paged memory, I suppose that
the vendor would not say that it can only support 64K, and would not
make such assumptions when designing his library.  Not all systems
have adequate support for paged memory -- many single chip processors
don't have the pins to address memory outside of the chip.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6ngo89$lhl$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <wmxdtQAihUm1Ew5o@noco.demon.co.uk>,
>  Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>>
>> >> >They may not know the actual ammount of memory, but they do know the
>> >> >maximum.  If the processor has 16 address bits, you really don't have
>> >> >to worry about what happens with more than 64K elements.  And of course,
>> >> >a lot of processors have even less.
>> >>
>> >> External page registers excepted of course.
>> >
>> >Not really.  Without some very special logic, you can't have objects
>> >(vectors, etc.) spanning several pages.  So the problem of an object
>> >containing more than 64K elements doesn't occur.
>>
>> I don't follow you. Objects could easily be (arbitrarily) bigger than
>> 64k. The special logic would have to live in the container access
>> methods maybe. I don't really know what you mean by this though.
>
>The standard containers don't (or don't have to) have this special
>logic.  Not all hardware even supports it; I've worked with embedded
>chips with a fixed amount of on chip memory, and no pins to address
>anything else.

To derive is human, to override sublime :-)

>> People (compiler and emulator vendors I mean) have paged memory support
>> for lots of CPUs that have only 64K address spaces. I don't see why not
>> C++ ?
>
>If the system has adequate support for paged memory, I suppose that
>the vendor would not say that it can only support 64K, and would not
>make such assumptions when designing his library.  Not all systems
>have adequate support for paged memory -- many single chip processors
>don't have the pins to address memory outside of the chip.

That's not the point I was addressing :-) though.

>James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr


--
Mike Davies
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6nbf8r$pe8$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <b$HHLBA1O9l1EwU2@noco.demon.co.uk>,
>  Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>>
>> In article <6n8g2i$eo3$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
>> writes
>>
>> ...snip...
>>
>> >They may not know the actual ammount of memory, but they do know the
>> >maximum.  If the processor has 16 address bits, you really don't have
>> >to worry about what happens with more than 64K elements.  And of course,
>> >a lot of processors have even less.
>>
>> External page registers excepted of course.
>
>Not really.  Without some very special logic, you can't have objects
>(vectors, etc.) spanning several pages.  So the problem of an object
>containing more than 64K elements doesn't occur.

I don't follow you. Objects could easily be (arbitrarily) bigger than
64k. The special logic would have to live in the container access
methods maybe. I don't really know what you mean by this though.

People (compiler and emulator vendors I mean) have paged memory support
for lots of CPUs that have only 64K address spaces. I don't see why not
C++ ?

--
Mike Davies


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]