---

Hej!

Jeg har en klasse med denne constructor:

template <class T>
MinVector<T>::MinVector(int size): vectoren(size)
{
}

og denne datamember:
vector<T> vectoren;

Ovenstående er et eksempel, som nok ikke kan bruges til noget i praksis.

Mine spørgsmål er nu:
- Om der bliver allokeret memory på stakken eller på heap'en.
- Om det er nødvendigt at delete vectoren i destructoren for at undgå memory
leaks.
- Om det er nødvendigt at implementere copy constructor og assignment
operator.

På forhånd tak!


---------------------------------------------
Thomas Sejr Jensen
Thomassj@worldonline.dk
www.worldonline.dk/~thomassj
---------------------------------------------

---

Den Tue, 24 Apr 2001 22:59:03 +0200 skrev Thomas Sejr Jensen:
>Hej!
>
>Jeg har en klasse med denne constructor:
>
>template <class T>
>MinVector<T>::MinVector(int size): vectoren(size)
>{
>}
>
>og denne datamember:
>vector<T> vectoren;
>
>Ovenstående er et eksempel, som nok ikke kan bruges til noget i praksis.
>
>Mine spørgsmål er nu:
>- Om der bliver allokeret memory på stakken eller på heap'en.
>- Om det er nødvendigt at delete vectoren i destructoren for at undgå memory
>leaks.
>- Om det er nødvendigt at implementere copy constructor og assignment
>operator.

Det lyder meget som skoleopgaver... Prøv at spørge din lærer, eller
læse i bogen.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

"Kent Friis" <leeloo@mailandnews.com> skrev i en meddelelse
news:9c4rg9$pom$1@sunsite.dk...
> Den Tue, 24 Apr 2001 22:59:03 +0200 skrev Thomas Sejr Jensen:
> >Hej!
> >
> >Jeg har en klasse med denne constructor:
> >
> >template <class T>
> >MinVector<T>::MinVector(int size): vectoren(size)
> >{
> >}
> >
> >og denne datamember:
> >vector<T> vectoren;
> >
> >Ovenstående er et eksempel, som nok ikke kan bruges til noget i praksis.
> >
> >Mine spørgsmål er nu:
> >- Om der bliver allokeret memory på stakken eller på heap'en.
> >- Om det er nødvendigt at delete vectoren i destructoren for at undgå
memory
> >leaks.
> >- Om det er nødvendigt at implementere copy constructor og assignment
> >operator.
>
> Det lyder meget som skoleopgaver... Prøv at spørge din lærer, eller
> læse i bogen.

Det er rigtig nok en skole opgave, er det forbudt at stille spørgsmål
omkring dem, når man ikke efterlyser færdig kode (hvilket jeg ikke ligefrem
gjorde)?
Min bog (c++ from the ground up, som ellers er god) skriver ikke meget om
emnet udover hvornår de forskellige ting bliver kaldt.
>
> Mvh
> Kent
> --
> http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

Den Wed, 25 Apr 2001 00:13:39 +0200 skrev Thomas Sejr Jensen:
>
>"Kent Friis" <leeloo@mailandnews.com> skrev i en meddelelse
>news:9c4rg9$pom$1@sunsite.dk...
>> Den Tue, 24 Apr 2001 22:59:03 +0200 skrev Thomas Sejr Jensen:
>> >Hej!
>> >
>> >Jeg har en klasse med denne constructor:
>> >
>> >template <class T>
>> >MinVector<T>::MinVector(int size): vectoren(size)
>> >{
>> >}
>> >
>> >og denne datamember:
>> >vector<T> vectoren;
>> >
>> >Ovenstående er et eksempel, som nok ikke kan bruges til noget i praksis.
>> >
>> >Mine spørgsmål er nu:
>> >- Om der bliver allokeret memory på stakken eller på heap'en.
>> >- Om det er nødvendigt at delete vectoren i destructoren for at undgå
>memory
>> >leaks.
>> >- Om det er nødvendigt at implementere copy constructor og assignment
>> >operator.
>>
>> Det lyder meget som skoleopgaver... Prøv at spørge din lærer, eller
>> læse i bogen.
>
>Det er rigtig nok en skole opgave, er det forbudt at stille spørgsmål
>omkring dem, når man ikke efterlyser færdig kode (hvilket jeg ikke ligefrem
>gjorde)?

Det lød som nogle af de der spørgsmål, som er i slutningen af hvert
kapitel i mange bøger, for at se om man har forstået emnet. Ikke som
en egentlig kodeopgave.

Specielt det første spørgsmål går på lige præcis den compiler-
implementation der bliver brugt i bogen - C++ garanterer SVJV intet om
hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man
fx. så vidt muligt både parametre og lokale (og globale) variable i
registre, for helt at undgå memoryreferencer. Specielt de såkaldte
"register-window" arkitekturer, hvor man har måske 128 eller 256
registre, hvoraf en funktion har adgang til fx. 32.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

On Tue, 24 Apr 2001 22:34:18 +0000 (UTC),
Kent Friis <leeloo@mailandnews.com> wrote:

>Specielt det første spørgsmål går på lige præcis den compiler-
>implementation der bliver brugt i bogen - C++ garanterer SVJV intet om
>hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man
>fx. så vidt muligt både parametre og lokale (og globale) variable i
>registre, for helt at undgå memoryreferencer. Specielt de såkaldte
>"register-window" arkitekturer, hvor man har måske 128 eller 256
>registre, hvoraf en funktion har adgang til fx. 32.

Hvilke arkitekturer har den feature?

--
Anders Bo Rasmussen mailto:fuzz01@spamfilter.dk
Frimestervej 42 1.tv http://www.fuzz.dk
2400 Kbh. NV
Denmark

---

Den Wed, 25 Apr 2001 21:22:14 +0200 skrev Anders Bo Rasmussen:
>On Tue, 24 Apr 2001 22:34:18 +0000 (UTC),
>Kent Friis <leeloo@mailandnews.com> wrote:
>
>>Specielt det første spørgsmål går på lige præcis den compiler-
>>implementation der bliver brugt i bogen - C++ garanterer SVJV intet om
>>hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man
>>fx. så vidt muligt både parametre og lokale (og globale) variable i
>>registre, for helt at undgå memoryreferencer. Specielt de såkaldte
>>"register-window" arkitekturer, hvor man har måske 128 eller 256
>>registre, hvoraf en funktion har adgang til fx. 32.
>
>Hvilke arkitekturer har den feature?

Nogle RISC-CPU'er, bl.a. Sparc (iflg. min bog), men ikke MIPS.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

"Anders Bo Rasmussen" <fuzz01@spamfilter.dk> wrote in message
news:slrn9ee8v6.203.fuzz01@localhost.localdomain...
> On Tue, 24 Apr 2001 22:34:18 +0000 (UTC),
> Kent Friis <leeloo@mailandnews.com> wrote:
>
> >hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man
> >fx. så vidt muligt både parametre og lokale (og globale) variable i
> >registre, for helt at undgå memoryreferencer. Specielt de såkaldte
> >"register-window" arkitekturer, hvor man har måske 128 eller 256
> >registre, hvoraf en funktion har adgang til fx. 32.
>
> Hvilke arkitekturer har den feature?

F.eks. Intel Itanium

Venlig hilsen

Mogens Hansen

---

"Kent Friis" <leeloo@mailandnews.com> wrote in message
news:9c4v1a$86i$1@sunsite.dk...
> Den Wed, 25 Apr 2001 00:13:39 +0200 skrev Thomas Sejr Jensen:
>
> Specielt det første spørgsmål går på lige præcis den compiler-
> implementation der bliver brugt i bogen - C++ garanterer SVJV intet om
> hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man

Konceptuelt kan der allokeres objekter 3 steder i C++:
* globalt (static storage)
* på stakken (automatic storage)
* på heapen (dynamic storage)
det er velspecificeret under hvilke omstændigheder objekter placeres hvor,
og hvilken levetid de har. Se C++ Standarden §3.7.
Der er givetvis noget spillerum for hvordan compilerne vil løse den opgave.
F.eks. er der mulighed for at placere konstante globale objekter i ROM (Read
Only Memory) - men det er ikke et krav.


> fx. så vidt muligt både parametre og lokale (og globale) variable i
> registre, for helt at undgå memoryreferencer. Specielt de såkaldte
> "register-window" arkitekturer, hvor man har måske 128 eller 256
> registre, hvoraf en funktion har adgang til fx. 32.

Kan man forestille sig situationer, hvor det er væsentligt for programmet at
vide hvordan arkitekturen implementerer "automatic allocation" ?

Venlig hilsen

Mogens Hansen

---

Den Thu, 26 Apr 2001 08:48:41 +0200 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@mailandnews.com> wrote in message
>news:9c4v1a$86i$1@sunsite.dk...
>> Den Wed, 25 Apr 2001 00:13:39 +0200 skrev Thomas Sejr Jensen:
>>
>> Specielt det første spørgsmål går på lige præcis den compiler-
>> implementation der bliver brugt i bogen - C++ garanterer SVJV intet om
>> hvor tingene bliver placeret. På nogle CPU-arkitekturer placerer man
>
>Konceptuelt kan der allokeres objekter 3 steder i C++:
> * globalt (static storage)
> * på stakken (automatic storage)
> * på heapen (dynamic storage)
>det er velspecificeret under hvilke omstændigheder objekter placeres hvor,
>og hvilken levetid de har. Se C++ Standarden §3.7.
>Der er givetvis noget spillerum for hvordan compilerne vil løse den opgave.
>F.eks. er der mulighed for at placere konstante globale objekter i ROM (Read
>Only Memory) - men det er ikke et krav.
>
>
>> fx. så vidt muligt både parametre og lokale (og globale) variable i
>> registre, for helt at undgå memoryreferencer. Specielt de såkaldte
>> "register-window" arkitekturer, hvor man har måske 128 eller 256
>> registre, hvoraf en funktion har adgang til fx. 32.
>
>Kan man forestille sig situationer, hvor det er væsentligt for programmet at
>vide hvordan arkitekturen implementerer "automatic allocation" ?

Skriver standarden "på stakken", eller blot "automatic allocation"? Det
kan implementationsmæssigt være en stor forskel (fx. på architekturer
hvor stakken er begrænset i størrelse).

Det kan godt være en fordel for programmøren at vide, om de fleste
variable ligger på stakken eller i registre - man kan normalt ikke lave
en pointer til et register, så her må compileren enten lave noget
hokuspokus, eller tvinge variablen til at ligge på stakken. Det kan SVJV
nemt tage fire gange så lang tid at tilgå stakken som et register på en
RISC-maskine. Men det vil aldrig være _nødvendigt_ for programmøren at
vide, for compileren skjuler det.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

Hej Kent,
"Kent Friis" <leeloo@mailandnews.com> wrote in message
news:9cb654$lt9$1@sunsite.dk...
> Den Thu, 26 Apr 2001 08:48:41 +0200 skrev Mogens Hansen:
> >
> >
> >Kan man forestille sig situationer, hvor det er væsentligt for programmet
at
> >vide hvordan arkitekturen implementerer "automatic allocation" ?
>
> Skriver standarden "på stakken", eller blot "automatic allocation"? Det
> kan implementationsmæssigt være en stor forskel (fx. på architekturer
> hvor stakken er begrænset i størrelse).

I den sammenhæng vi taler om her benyttes udtrykket "Automatic storage
duration".

Ordet "stack" bruges i forbindelse med:
* class std::stack
* stack unwinding i forbindelse med exception

>
> Det kan godt være en fordel for programmøren at vide, om de fleste
> variable ligger på stakken eller i registre - man kan normalt ikke lave
> en pointer til et register, så her må compileren enten lave noget
> hokuspokus, eller tvinge variablen til at ligge på stakken. Det kan SVJV
> nemt tage fire gange så lang tid at tilgå stakken som et register på en
> RISC-maskine. Men det vil aldrig være _nødvendigt_ for programmøren at
> vide, for compileren skjuler det.

Sådan som jeg har forstået beskrivelsen af Intel Itanium, laver den et
"rullende register vindue" som faktisk mapper ud til main-memory (og
undervejs spiller cachen en rolle for performance) og dermed har objekter i
registre en adresse. Det må formodentlig også betyde at type, som er mere
komplekse end int og pointer, kan placeres i "CPU registre" ?

Men nu har jeg ikke lige min Itanium kørende til at påvise det :)

Venlig hilsen

Mogens Hansen

---

Den Fri, 27 Apr 2001 11:39:01 +0200 skrev Mogens Hansen:
>Hej Kent,
>"Kent Friis" <leeloo@mailandnews.com> wrote in message
>news:9cb654$lt9$1@sunsite.dk...
>> Den Thu, 26 Apr 2001 08:48:41 +0200 skrev Mogens Hansen:
>> >
>> >
>> >Kan man forestille sig situationer, hvor det er væsentligt for programmet
>at
>> >vide hvordan arkitekturen implementerer "automatic allocation" ?
>>
>> Skriver standarden "på stakken", eller blot "automatic allocation"? Det
>> kan implementationsmæssigt være en stor forskel (fx. på architekturer
>> hvor stakken er begrænset i størrelse).
>
>I den sammenhæng vi taler om her benyttes udtrykket "Automatic storage
>duration".

Så siger standarden reelt heller ikke noget om hvad der skal ligge
på stakken -> det afhænger af implementationen.

>Ordet "stack" bruges i forbindelse med:
> * class std::stack

Som sandsynligvis er implementeret vha. en kædet liste på head'en, bare
for at gøre forvirringen total.

> * stack unwinding i forbindelse med exception

Mon ikke det er for at forklare hvad der skal ske - så det er irrelevant
om det reelt ligger på stakken, eller er implementeret på en anden måde.

>> Det kan godt være en fordel for programmøren at vide, om de fleste
>> variable ligger på stakken eller i registre - man kan normalt ikke lave
>> en pointer til et register, så her må compileren enten lave noget
>> hokuspokus, eller tvinge variablen til at ligge på stakken. Det kan SVJV
>> nemt tage fire gange så lang tid at tilgå stakken som et register på en
>> RISC-maskine. Men det vil aldrig være _nødvendigt_ for programmøren at
>> vide, for compileren skjuler det.
>
>Sådan som jeg har forstået beskrivelsen af Intel Itanium, laver den et
>"rullende register vindue" som faktisk mapper ud til main-memory (og
>undervejs spiller cachen en rolle for performance) og dermed har objekter i
>registre en adresse.

Dvs. man får ikke hastighedsfordelen af register-operationer.

>Det må formodentlig også betyde at type, som er mere
>komplekse end int og pointer, kan placeres i "CPU registre" ?

Det afhænger vel mere af størrelsen af "registrene" end af hvor de
ligger.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

* Thomas Sejr Jensen

> template <class T>
> MinVector<T>::MinVector(int size): vectoren(size)


s/int/vector::size_type

evt.

size_t

(det skulle virkelig forundre meg om disse to var forskjellige, men
alt kan jo hende).


> {
> }
>
> og denne datamember:
> vector<T> vectoren;
>
> Ovenstående er et eksempel, som nok ikke kan bruges til noget i praksis.
>
> Mine spørgsmål er nu:
> - Om der bliver allokeret memory på stakken eller på heap'en.


Det er _ytterst_ irrelevant for annet enn implementasjonen. Why do you
care?


> - Om det er nødvendigt at delete vectoren i destructoren for at
> undgå memory leaks.


[quote, 23.1, p 1]

Containers are objects that store other objects. They control
allocation and deallocation of these objects through constructors,
destructors, insert and erase operations.

[/quote]

[quote Table 65]

expression   return type   assert/note         complexity
   
(&a)->~X();   void      note: the destructor is      linear
            applied to every element
            of a; all the memory is
            dellocated.

[/quote]

Dagens trivia: hvorfor gidder man å bruke std::vector framfor T*?


> - Om det er nødvendigt at implementere copy constructor og
> assignment operator.


Det er umulig å svare på før man ser hele klassen.





ivr
--
The only "intuitive" interface is the nipple. After that, it's all learned.
(Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc, on X interfaces.)