🚀 go-pugleaf

Hallo,

Alexander Ehrler  (ukci@rzstud1.rz.uni-karlsruhe.de) wrote on 01.10.95
about "STL - ueber's Ziel hinaus ?":

> Ich habe gestern die HP Version der STL ausprobiert und siehe da:
>
> 	vector< my_type > v(10);
> 	cout << v[100];
>
> keine Exception, keine "failed assertion", einfach ein satter Absturz.
>
> Aber das muss ja schliesslich so sein, denn (aus der Doku):
> "...just as regular pointers to an array guarantees that there is a pointer
> value pointing past the last element of the array, so for any iterator type
> there is an iterator value that points past the last element of a
> corresponding container..."
>
> Tatsachlich ist der Subskript-Operator so implementiert:
>    vector::operator[](size_type n)
>    {
>        return *(begin() + n);
>    }
>
> wobei begin() einen Iterator liefert. Keine bound checks.

Das darf ja wohl nicht wahr sein! Wozu soll die STL gut sein wenn nicht
einmal triviale bound-checks implementiert wurden? Kann mir das jemand
erklaeren ???
Wenn ich ein normales C-style Array wollte, wuerde ich es als solches
deklarieren und nicht die STL verwenden.
---
Walter Sommergruber
email: wsog@site71.ping.at

wsog@site71.ping.at (Walter Sommergruber) writes:

>Hallo,

>Alexander Ehrler  (ukci@rzstud1.rz.uni-karlsruhe.de) wrote on 01.10.95
>about "STL - ueber's Ziel hinaus ?":

>> Ich habe gestern die HP Version der STL ausprobiert und siehe da:
>>
>> 	vector< my_type > v(10);
>> 	cout << v[100];
>>
>> keine Exception, keine "failed assertion", einfach ein satter Absturz.
>>
>> Aber das muss ja schliesslich so sein, denn (aus der Doku):
>> "...just as regular pointers to an array guarantees that there is a pointer
>> value pointing past the last element of the array, so for any iterator type
>> there is an iterator value that points past the last element of a
>> corresponding container..."
>>
>> Tatsachlich ist der Subskript-Operator so implementiert:
>>    vector::operator[](size_type n)
>>    {
>>        return *(begin() + n);
>>    }
>>
>> wobei begin() einen Iterator liefert. Keine bound checks.

>Das darf ja wohl nicht wahr sein! Wozu soll die STL gut sein wenn nicht
>einmal triviale bound-checks implementiert wurden? Kann mir das jemand
>erklaeren ???

Effizienz. Wenn man in das Array selbst ein bound-checking einbauen
wuerde, dann wuerden alle Programme, die das Array benutzen, langsamer
werden. 

Es gibt aber viele Situationen, wo beim Aufrufer klargestellt wird,
dass der Bereich mit Sicherheit nicht ueberschritten wird. Der
Aufrufer kann dann festlegen, wann ein Check noetig ist und den Check
weglassen, wenn sich aus dem Kontext ergibt, dass bei diesem einen
Zugriff keine Ueberschrietung stattfinden kann (ist bei Iteration
meist der Fall). 

Das Array selbst hat vom Kontext das Aufrufenden keine Ahnung, muss
also *jeden* Zugriff checken und ist damit fuer viele Anwendungen
langsamer.

In C++ soll niemand einen Performancepreis fuer etwas bezahlen, was
er nicht braucht oder nicht benutzt. Bound-checking erhoeht die
Laufzeit von Arrayzugriffe auf das ca. 3-fache. Selbst wenn es nur 10%
mehr waeren, wuerde ich immer noch dagegen sein.

>Wenn ich ein normales C-style Array wollte, wuerde ich es als solches
>deklarieren und nicht die STL verwenden.

Der Sinn der STL liegt gerade darin, dass auch normale C-Arrays
genauso benutzt werden koennen wie die STL-Container. Der STL-Vetor
hat andere Vorzuege.

Darueberhinaus ist es ein wesentliches Merkmal von STL, dass man sehr
einfach andere Container mit STL benutzen kann, und zwar ohen dass man
Subclassing betreiben muesste und ohne dass man STL-Funktionalitaet in
die neuen Container integrieren muesste.

Wenn Du STL also mit Bound-Chechking benutzen willst, dann ist das
sehr einfach moeglich und irgendjemand hat es bestimmt schon getan.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>. No NeXTMail, please.
 Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a 
 private address. At (netless) work programming in data analysis.