---

Davs,

jeg modtager nogle data fra en socket, og disse ville jeg gerne have
ind i en STL container uden for megen kopiering (da der er tale om
store datamængder).

Jeg kunne tænke mig at bruge noget lig (jeg kender size i forvejen)

vector<char> memory(size);
recvfrom(fd, &memory[0], size, ...);

men jeg er usikker på hvilke garantier der stilles omkring
elementernes placering med de forskellige containers. Derfor bruger
jeg lige nu

char* memory = new char[size];
recvfrom(fd, size, ...);

og det betyder jo så at jeg skal huske delete, hvilket jeg helst var
fri for. Men er der en standardiseret container, som opfylder mine behov?


Anders.

---

"Anders Melchiorsen" <anders@kalibalik.dk> wrote

>
> Jeg kunne tænke mig at bruge noget lig (jeg kender size i forvejen)
>
> vector<char> memory(size);
> recvfrom(fd, &memory[0], size, ...);
>

Det kan du roligt gøre.

> men jeg er usikker på hvilke garantier der stilles omkring
> elementernes placering med de forskellige containers.

I den oprindelige C++ Standard var det ikke specificeret at man kan gøre som
du foreslår, selvom det var meningen.
Det var et af de tidligste fejl i C++ Standarden som blev anerkendt.
Det er garanteret at elementerne i std::vector ligger fortløbende i
hukommelsen, og at element 0 ligger på den laveste adresse.
Der var ikke på det tidspunkt nogen udbredt implementeringer af std::vector
(hvis nogen overhovedet), som ikke overholdt denne garanti.
Det er i dag garanteret til at virke.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> I den oprindelige C++ Standard var det ikke specificeret at man kan gøre som
> du foreslår, selvom det var meningen.
> Det var et af de tidligste fejl i C++ Standarden som blev anerkendt.
> Det er garanteret at elementerne i std::vector ligger fortløbende i
> hukommelsen, og at element 0 ligger på den laveste adresse.
> Der var ikke på det tidspunkt nogen udbredt implementeringer af std::vector
> (hvis nogen overhovedet), som ikke overholdt denne garanti.
> Det er i dag garanteret til at virke.

Kan du fortælle mig hvor i standarden det står?

Ivan Johansen

---

"Ivan Johansen" <NG@Padowan.dk> wrote
>
> Kan du fortælle mig hvor i standarden det står?
>

Formodentligt ISO C++ Standard $23.2.4, og fejlrapporten står som item 69 på
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1292.html

Så i øvrigt
http://anubis.dkuug.dk/jtc1/sc22/wg21/
generelt - det kan være interessant.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> "Ivan Johansen" <NG@Padowan.dk> wrote
>>Kan du fortælle mig hvor i standarden det står?
> Formodentligt ISO C++ Standard $23.2.4, og fejlrapporten står som item 69 på
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1292.html


Det står ikke i den version jeg har, men det står ganske rigtigt i
fejlrapporten, hvilket må være lige så godt.

> Så i øvrigt
> http://anubis.dkuug.dk/jtc1/sc22/wg21/
> generelt - det kan være interessant.

Tak for linket. Det er en meget interessant side.

Ivan Johansen

---

"Ivan Johansen" <NG@Padowan.dk> wrote in message
news:3C36187D.5040005@Padowan.dk...
>
> Det står ikke i den version jeg har, men det står ganske rigtigt i
> fejlrapporten, hvilket må være lige så godt.
>

Jeg var måske lidt uklar i min formulering.
Mig bekendt findes der ikke mere end een udgave af ISO C++ Standarden, hvor
det ikke er et krav at hukommelsen i std::vector skal være een samlet blok
og at elementet med index 0 ligger på laveste adresse.
Der findes så vidt jeg ved et Technical Corrigendum (eller noget i den
stil), som indeholder fejlrettelser. Jeg har dog ikke set det.
På den baggrund mener jeg at man roligt kan basere sin kode på at
std::vector opfører sig som Anders Melchiorsen efterspurgte.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> Jeg var måske lidt uklar i min formulering.
> Mig bekendt findes der ikke mere end een udgave af ISO C++ Standarden, hvor
> det ikke er et krav at hukommelsen i std::vector skal være een samlet blok
> og at elementet med index 0 ligger på laveste adresse.
> Der findes så vidt jeg ved et Technical Corrigendum (eller noget i den
> stil), som indeholder fejlrettelser. Jeg har dog ikke set det.

Jeg troede faktisk at der var lavet opdaterede udgaver af standarden.

> På den baggrund mener jeg at man roligt kan basere sin kode på at
> std::vector opfører sig som Anders Melchiorsen efterspurgte.

Jeg kan heller ikke se hvorfor man skulle implementere std::vector
anderledes.

Ivan Johansen

---

"Ivan Johansen" <NG@Padowan.dk> wrote
>
> Jeg kan heller ikke se hvorfor man skulle implementere std::vector
> anderledes.
>

Nej, og derfor findes der heller ikke udbredte implementeringer af
std::vector som gør det anderledes.

Der er dog en formel forskel, nemlig at det ifølge ISO C++ Standarden var
_tilladt_ at lave en en std::vector, som overholdt alle kravene (f.eks.
performance), men ikke kunne bruges som Anders Melchiorsen spurgte om. Det
kunne gøre ved at lade elementet med index 0 ligge på den højeste adresse.
Dette er ikke tilladt i henhold til rettelsen.
Hvis rettelsen (Technical Corrigendum) ikke i var foretaget, ville det ikke
have været tilladt at gøre som Anders Melchiorsen spurgte om.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev:

> Hvis rettelsen (Technical Corrigendum) ikke i var foretaget, ville
> det ikke have været tilladt at gøre som Anders Melchiorsen spurgte om.

Anders Melchiorsen takker for det fyldige og opmuntrende svar.



Anders.

---

[ Anders Melchiorsen ]

[ snip ]

> men jeg er usikker på hvilke garantier der stilles omkring
> elementernes placering med de forskellige containers.


I tillegg til det Mogens skrev: de samme garantiene gjelder vel for
std::string (som er kanskje litt mer gunstig å bruke?)

[ snip ]





ivr
--
The UNIX Guru's View of Sex:
# nslookup girl; rdate girl; cd $HOME; unzip ; strip ; touch ; finger ;
mount ; fsck ; more ; yes ; umount ; sleep

---

igorr@ifi.uio.no (Igor V. Rafienko) wrote on 04-Jan-02:

> [ Anders Melchiorsen ]
>
> > men jeg er usikker på hvilke garantier der stilles omkring
> > elementernes placering med de forskellige containers.
>
> I tillegg til det Mogens skrev: de samme garantiene gjelder vel for
> std::string (som er kanskje litt mer gunstig å bruke?)

Jeg har nu erfaret, at std::string::reserve() ikke fungerer som
forventet med min gcc 2.96 (men dog med 3.0.1), så det gør den nok
lidt ugunstig at bruge.


Nyt spørgsmål: Jeg formoder at string::reserve() blot angiver et
minimum, men at implementeringen har lov at reservere mere plads, fx
for at undgå fragmentering? Altså:

string buffer;
buffer.reserve(17);
assert(buffer.capacity() == 17); // ?




Hvilken bog skal jeg i øvrigt have fat i for at få svarene på
spørgsmål som dem, jeg har stillet her for nylig? Der må være et godt
STL værk - eller skal jeg have fat i selve standarden for at få klar
besked om den slags pedantiske detaljer?


Venlig hilsen,
Anders.

---

[ Anders Melchiorsen ]

[ snip ]

> Jeg har nu erfaret, at std::string::reserve() ikke fungerer som
> forventet med min gcc 2.96 (men dog med 3.0.1), så det gør den nok
> lidt ugunstig at bruge.


Det er ingen grunn til å forkaste std::string dersom du sitter med en
defekt implementasjon av standardbiblioteket. Oppgrader til gcc-3.0.2
og vær lykkelig (hvis det ikke hjelper, finnes det en haug av
kommersielle alternativer).


> Nyt spørgsmål: Jeg formoder at string::reserve() blot angiver et
> minimum, men at implementeringen har lov at reservere mere plads, fx
> for at undgå fragmentering?


Ja, det stemmer:

"After reserve(), capacity() is greater or equal to the argument of
reserve. [Note: Calling reserve() with a res_arg argument less than
capacity() is in effect a non-binding shrink request...]"


> Altså:
>
> string buffer;
> buffer.reserve(17);
> assert(buffer.capacity() == 17); // ?


Kan feile.


> Hvilken bog skal jeg i øvrigt have fat i for at få svarene på
> spørgsmål som dem, jeg har stillet her for nylig? Der må være et
> godt STL værk - eller skal jeg have fat i selve standarden for at få
> klar besked om den slags pedantiske detaljer?


Pedantiske detaljer er nok beskrevet i standarden (og det er ingen
andre dokumenter som er like autoritative). Matt Austern har skrevet
en bok som forklarer grunnideene i STL (dog, en diger del av boken er
bare en beskrivelse av STL containere, og det er mildt sagt sløsing
med papir).





ivr
--
Ehh... I'll have a McRudolf menu, please.

---

Anders Melchiorsen wrote:

> Hvilken bog skal jeg i øvrigt have fat i for at få svarene på
> spørgsmål som dem, jeg har stillet her for nylig? Der må være et godt
> STL værk - eller skal jeg have fat i selve standarden for at få klar
> besked om den slags pedantiske detaljer?


The Standard C++ Library (A tutorial and reference) af Nicolai M. Josuttis.

- Morten.