[C / C++] De grootte van een array

[Anoniem: 47113]

Hoi,

Onderstaand stukje code gaat het om:

code:

int array_aantal[];
double array_prijs[];
int prijsPerStuk = 0;
int soortenArtikelen;

cout << "Hoeveel verschillende soorten artikelen zijn er: ";
cin >> soortenArtikelen;
cout << endl;

De array moet de grote krijgen van de variabele soortenArtikelen (voert de gebruiker in) Alleen hoe moet ik dat aangeven???

[whoami]

Je zult het mbhv pointers moeten doen:

code:

int* array_aantal
int soortArtikelen;
cin >> soortArtikelen;
array_aantal = new int[soortArtikelen];

Op die manier alloceer je dynamisch het benodigde aantal geheugen. Je mag wel niet vergeten dat je dat geheugen terug vrij moet geven als je het niet meer nodig hebt.
Dit doe je met het delete statement.

code:

delete[] array_aantal

[Janoz]

int array_aantal[];
is hetzelfde als
int * array_aantal;

Het enige wat je nog moet doen is het alloceren van wat geheugen voor die array. In C doe je dat met malloc, en in c++ doe je dat met new.

[Glimi]

In C++ zou je eigenlijk gewoon helemaal niet meer met een primitieve array moeten werken. Gebruik ajb een geparameteriseerde Vector.

[whoami]

[nohtml]

Janoz schreef op 04 oktober 2002 @ 14:34:
int array_aantal[];
is hetzelfde als
int * array_aantal;

Wordt

code:

int array_aantal[];

niet op de stack gealloceerd en

code:

int* array_aantal;

op de heap?

En geeft dat niet als gevolg dat je bij int array[] al bij de declaratie de grootte moet opgeven en die niet meer kunt veranderen?

[D2k]

whoami: volgens mij heb jij gelijk

[Anoniem: 13700]

Bovendien is dit wel echt afschuwelijk ongestructureerd. Zet gegevens die bij elkaar horen in een struct of class:

C++:

struct Artikel {
  int    aantal;
  double prijs;
};

Dan hoef je maar één array te gebruiken:

C++:

std::cout << "Geef het aantal artikelen: ";
std::size_t len;
std::cin >> len;
Artikel *artikelen= new Artikel[len];
artikelen[0].aantal= 3;
artikelen[0].prijs= 3.25;

[matthijsln]

whoami schreef op 04 oktober 2002 @ 14:37:
[nohtml]
Wordt

int array_aantal[];

niet op de stack gealloceerd en

int* array_aantal;

op de heap?

Nee. array_aantal is in beide gevallen een pointer naar een array van ints. De array waar de pointer naar wijst kan op de heap (met new/malloc()) en op de stack (met alloca()) gealloceerd worden.

En geeft dat niet als gevolg dat je bij int array[] al bij de declaratie de grootte moet opgeven en die niet meer kunt veranderen?

int array_aantal[10];

zou inderdaad wel op de stack komen.

[Anoniem: 35845]

In C++ zou je eigenlijk gewoon helemaal niet meer met een primitieve array moeten werken. Gebruik ajb een geparameteriseerde Vector.

Waarom niet? Als je er toch alleen maar primitives in stopt... Scheelt ook fors in de code en is toch een stukje duidelijker dan wanneer je ALLE arrays maar omzet naar vectors. Voor complexe objecten geef ik je groot gelijk maar voor een simpele array van integers oid?

[marcusk]

Anoniem: 35845 schreef op 04 oktober 2002 @ 16:49:
Waarom niet? Als je er toch alleen maar primitives in stopt... Scheelt ook fors in de code en is toch een stukje duidelijker dan wanneer je ALLE arrays maar omzet naar vectors. Voor complexe objecten geef ik je groot gelijk maar voor een simpele array van integers oid?

array:

C++:

int * blaat;
...
blaat = new int[aantal];
...
// en natuurlijk:
delete[] blaat;

vector:

C++:

std::vector<int> blaat;

kost juist minder code

bovendien is het in dit geval beter om een Artikel struct/class te maken zoals mietje aangaf.

[whoami]

matthijsln schreef op 04 oktober 2002 @ 15:51:
[...]

Nee. array_aantal is in beide gevallen een pointer naar een array van ints. De array waar de pointer naar wijst kan op de heap (met new/malloc()) en op de stack (met alloca()) gealloceerd worden.

[...]

int array_aantal[10];

zou inderdaad wel op de stack komen.

Dat bedoelde ik eigenlijk.
int array_aantal[n] op de stack
en int* array_aantal; op de heap.

[Primal]

marcusk schreef op 04 oktober 2002 @ 17:10:
[...]

array:

C++:

int * blaat;
...
blaat = new int[aantal];
...
// en natuurlijk:
delete[] blaat;

vector:

C++:

std::vector<int> blaat;

kost juist minder code

bovendien is het in dit geval beter om een Artikel struct/class te maken zoals mietje aangaf.

Dit is wel errug kort door de bocht. Je vergeet even de onderliggende stukken code. Het feit dat jij 1 regel C/C++ code in je source hebt staan wil niet per definitie zeggen dat dit ook minder code in je uiteindelijke gecompileerde applicatie is. Een C/C++ functie is geen machine-instructie. Wat denk je dat er gebeurt als je de functie new aanroept? Bekijk het eens zou ik zeggen.

Een klein voorbeeldje voor marcusk nu ik toch zwaar off-topic aan het gaan ben. Stel de volgende code:

C++:

RELEASE_MEMORY(pPointer) {if (pPointer != NULL){delete pPointer; pPointer = NULL;}}

Ik heb hier een macro gedefinieerd. Welk van de onderstaande 2 voorbeelden gebruikt uiteindelijk de minste code in je gecompileerde applicatie?

1)

C++:

RELEASE_MEMORY(pMyArray1);
RELEASE_MEMORY(pMyArray2);

2)

C++:

if (pMyArray1 != NULL)
{
  delete pMyArray1;
  pMyArray1 = NULL;
}

if (pMyArray2 != NULL)
{
  delete pMyArray2;
  pMyArray2 = NULL;
}

This shouldn't be too hard.

Anyway, voor zulke simpele data zou ik het gewoon lekker bij een array van structs houden zoals mietje ook al aangaf. Bovendien heb je op die manier ook minder overhead voor dit eenvoudige probleem.

Opmerking : Mocht je dit allemaal weten, heb je ik post niet goed begrepen en/of was het meer als een grap bedoeld wat je zei, vergeet deze post dan maar

[marcusk]

Primal schreef op 04 oktober 2002 @ 22:57:
[...]
Dit is wel errug kort door de bocht. Je vergeet even de onderliggende stukken code. Het feit dat jij 1 regel C/C++ code in je source hebt staan wil niet per definitie zeggen dat dit ook minder code in je uiteindelijke gecompileerde applicatie is. Een C/C++ functie is geen machine-instructie. Wat denk je dat er gebeurt als je de functie new aanroept? Bekijk het eens zou ik zeggen.

DUH (ik ben momenteel met een compilertje bezig, dus dat weet ik wel ja )

Opmerking : Mocht je dit allemaal weten, heb je ik post niet goed begrepen en/of was het meer als een grap bedoeld wat je zei, vergeet deze post dan maar

Ik wil toch ff zeggen dat ik persoonlijk (gecompileerde) code-size volledig ondergeschikt vind aan duidelijkheid en leesbaarheid van de source-code. Vandaar dat ik in de meeste gevallen zeker zou kiezen voor een vector ipv een array

[Primal]

marcusk schreef op 04 oktober 2002 @ 23:09:
Ik wil toch ff zeggen dat ik persoonlijk (gecompileerde) code-size volledig ondergeschikt vind aan duidelijkheid en leesbaarheid van de source-code. Vandaar dat ik in de meeste gevallen zeker zou kiezen voor een vector ipv een array

Dat ben ik met je eens ja. Ik vind persoonlijk dat de source-code duidelijk leesbaar en helder opgezet moet zijn. Daarom kies ik in de meeste gevallen ook voor "verkorte"/schonere-source-code wegen, onder andere door het gebruik van macro's etc. De grote van de applicatie zou me ook niet zo heel erg veel uitmaken, performance is een ander verhaal (afhankelijk van wat voor applicatie je schrijft natuurlijk ).

[farlane]

Primal schreef op 04 oktober 2002 @ 22:57:
[...]

C++:

RELEASE_MEMORY(pPointer) {if (pPointer != NULL){delete pPointer; pPointer = NULL;}}

Ik heb hier een macro gedefinieerd. Welk van de onderstaande 2 voorbeelden gebruikt uiteindelijk de minste code in je gecompileerde applicatie?

Ze hebben iig beide een memory leak als je ze voor arrays gebruikt.

[matthijsln]

whoami schreef op 04 oktober 2002 @ 17:45:
[...]
int* array_aantal; op de heap.

Even muggenziften maar dit is alleen zo indien je een pointer verkregen dmv malloc() of new etc. aan array_aantal hebt toegewezen. De pointer kan net zogoed de waarde NULL of 1234567 hebben of naar static data, de stack, of de stack van een eventuele andere thread wijzen (van deze opsomming wil je er een aantal natuurlijk vermijden :-).

[matthijsln]

[oeps, dat was niet de edit-knop]

[Primal]

farlane schreef op 05 oktober 2002 @ 03:11:
[...]


Ze hebben iig beide een memory leak als je ze voor arrays gebruikt.

En daar gebruik je ze natuurlijk ook niet voor

[Glimi]

Anoniem: 35845 schreef op 04 oktober 2002 @ 16:49:
Waarom niet? Als je er toch alleen maar primitives in stopt... Scheelt ook fors in de code en is toch een stukje duidelijker dan wanneer je ALLE arrays maar omzet naar vectors. Voor complexe objecten geef ik je groot gelijk maar voor een simpele array van integers oid?

Omdat je daarna een datastructuur hebt die bij fout gebruik segfaults kan opleveren en niet meer kan groeien. Waarom zou je dat risico nemen, zelfs bij simpele structuren. Vergeet ook niet dat simpele structuren later de neiging hebben om te groeien naar niet-zo-simpele structuren.

[farlane]

Primal schreef op 04 oktober 2002 @ 22:57:
[...]

C++:

RELEASE_MEMORY(pPointer) {if (pPointer != NULL){delete pPointer; pPointer = NULL;}}

Overigens, delete aanroepen op een nullpointer heeft geen gevolgen. Maw, de test op pointer!=NULL is een beetje overbodig.

[MSalters]

Primal schreef op 04 oktober 2002 @ 22:57:

C++:

RELEASE_MEMORY(pPointer) {if (pPointer != NULL){delete pPointer; pPointer = NULL;}}

Ik heb hier een macro gedefinieerd. Welk van de onderstaande 2 voorbeelden gebruikt uiteindelijk de minste code in je gecompileerde applicatie?

1)

C++:

RELEASE_MEMORY(pMyArray1);
RELEASE_MEMORY(pMyArray2);

2)

C++:

if (pMyArray1 != NULL)
{
  delete pMyArray1;
  pMyArray1 = NULL;
}

if (pMyArray2 != NULL)
{
  delete pMyArray2;
  pMyArray2 = NULL;
}

of 3)

code:

delete pMyArray1;
pMyArray1 = 0;
delete pMyArray2;
pMyArray2 = 0;

_{Wat farlane dus schreef}

[Primal]

farlane schreef op 05 oktober 2002 @ 12:23:
[...]


Overigens, delete aanroepen op een nullpointer heeft geen gevolgen. Maw, de test op pointer!=NULL is een beetje overbodig.

Daar heb je inderdaad helemaal gelijk in. Maar ja, dit is een oud aangeleerd gebruik voor zoveel situaties dat je het wel moet doen en dan is afleren moeilijk hé. Als je "waaaay back in the really old DOS-days " geprogrammeerd hebt, dan weet je overigens wel waarom ik dit nog steeds doe . Anders kreeg je een vette "klapband" . Tegenwoordig doet de functie delete of C-style free het voor jou, you are completely correct.

[Anoniem: 29256]

Het verbaast me dat nog niemand heeft opgemerkt dat containers (en andere resource-gebruikende classes) die hun cleanup in de destructor afhandelen vrijwel onmisbaar zijn bij het schrijven van exception-safe code..

[MSalters]

Primal schreef op 05 oktober 2002 @ 16:59:
[...]


Daar heb je inderdaad helemaal gelijk in. Maar ja, dit is een oud aangeleerd gebruik voor zoveel situaties dat je het wel moet doen en dan is afleren moeilijk hé. Als je "waaaay back in the really old DOS-days " geprogrammeerd hebt, dan weet je overigens wel waarom ik dit nog steeds doe . Anders kreeg je een vette "klapband" . Tegenwoordig doet de functie delete of C-style free het voor jou, you are completely correct.

Vreemd. Vanaf K&R C (1978) checkte free( ) al voor de NULL pointer, en in de eerste C++ implementaties was delete nog een wrapper rondom free( ). Dus in waaay waaay back voordat DOS bestond hoefde het al niet.

[Anoniem: 35845]

Omdat je daarna een datastructuur hebt die bij fout gebruik segfaults kan opleveren en niet meer kan groeien. Waarom zou je dat risico nemen, zelfs bij simpele structuren. Vergeet ook niet dat simpele structuren later de neiging hebben om te groeien naar niet-zo-simpele structuren.

Ik chargeer even : dus jij bent ook tegen het gebruik van character pointers? Dat zijn ook arrays van primitives. Volgens jou zou ik dus in mijn string classes geen char * maar een std::vector<char> moeten gebruiken...

Het is natuurlijk waar dat je als je verwacht de code fors te gaan uitbreiden/veranderen/compliceren je beter een std::vector kunt gebruiken, don't worry ik ga er dan ook vanuit dat iedere zichzelf respecterende programmeur dit wel begrijpt. Er zijn alleen situaties waar het gebruik van een std::vector gewoon zware overkill is...

En laten we het dan maar niet hebben over hastables. Die zijn altijd op basis van arrays dus die heb je wel degelijk nodig soms

[Anoniem: 35845]

Het verbaast me dat nog niemand heeft opgemerkt dat containers (en andere resource-gebruikende classes) die hun cleanup in de destructor afhandelen vrijwel onmisbaar zijn bij het schrijven van exception-safe code..

C++:

int *piIets = new int[100];
try
{
  doe_iets_wat_exception_kan_gooien(piIets);
  delete piIets;
}
catch(...)
{
  delete piIets;
}

[Anoniem: 47174]

Glimi schreef op 04 oktober 2002 @ 14:35:
In C++ zou je eigenlijk gewoon helemaal niet meer met een primitieve array moeten werken. Gebruik ajb een geparameteriseerde Vector.

dit is echt weer iets wat ik echt niet in zie. wat er mis met de oude vertrouwde array? Veel minder overhead dan zo'n vector ding, die ongetwijfeld zelf ook weer een array gebruikt (of misschien een linked listje, geen idee).
In ieder geval, ik kan geen nadeel bedenken aan een array. Je moet gewoon weten waar je mee bezig bent.

[Reptile209]

Anoniem: 35845 schreef op 06 oktober 2002 @ 15:28:
[...]

C++:

int *piIets = new int[100];
try
{
  doe_iets_wat_exception_kan_gooien(piIets);
  delete piIets;
}
catch(...)
{
  delete piIets;
}

Volgens mij kent C++ geen finally zoals Delphi, maar dan zou ik dus die delete achter het catch blok gooien... Dit is een beetje dubbelop

[Soultaker]

Wat Reptile zegt, klopt natuurlijk. NOG beter is om hiervoor een auto-pointer te gebruiken; een auto-pointer variant voor arrays heeft natuurlijk elke C++ programmeur liggen (hoe kun je zonder?!)
.

C++:

auto_array<int> piIets(new int[100]);
doe_iets_wat_exception_kan_gooien(piIets);

[ Voor 0% gewijzigd door Soultaker op 06-10-2002 17:09 . Reden: tyfusnewlines ]

[.oisyn]

Anoniem: 35845 schreef op 06 oktober 2002 @ 15:28:
[...]

C++:

int *piIets = new int[100];
try
{
  doe_iets_wat_exception_kan_gooien(piIets);
  delete piIets;
}
catch(...)
{
  delete piIets;
}

imho beetje nutteloos op die manier, die delete kun je net zo goed onder het try/catch block huisvesten, aangezien ie toch in alle gevallen gedelete wordt

[MSalters]

Anoniem: 35845 schreef op 06 oktober 2002 @ 15:28:

C++:

int *piIets = new int[100];
try
{
  doe_iets_wat_exception_kan_gooien(piIets);
  delete piIets;
}
catch(...)
{
  delete piIets;
}

Kijk, en daarom is std::vector<int> nou zo handig. Dan hoef je het verschil tussen delete en delete[] niet te weten.

[MSalters]

Soultaker schreef op 06 oktober 2002 @ 17:09:
Wat Reptile zegt, klopt natuurlijk. NOG beter is om hiervoor een auto-pointer te gebruiken; een auto-pointer variant voor arrays heeft natuurlijk elke C++ programmeur liggen (hoe kun je zonder?!)

Simpel; je gebruikt std::vector< > of std::deque< > ipv een auto_array.

[.oisyn]

Beetje offtopic, maar toch weer niet helemaal: waarom kun je de grootte van een met new gealloceerde array niet opvragen De grootte is wel bekend aangezien de destructors ook weer moeten worden aangeroepen bij array deletion

ja, natuurlijk kun je de grootte zelf ook bijhouden, maar mijn vraag is waarom je het niet kunt opvragen als het toch al wordt bijgehouden op een een of andere implementatie-specifieke manier... lijkt mij alleen maar handig

[marcusk]

volgens mij wordt de lengte op index -1 opgeslagen (of iig 4 bytes voor het begin), maar weet het niet zeker

[Soultaker]

marcusk schreef op 06 oktober 2002 @ 22:47:
volgens mij wordt de lengte op index -1 opgeslagen (of iig 4 bytes voor het begin), maar weet het niet zeker

Dat zal maar net van je implementatie afhangen. Het zou veel handiger zijn geweest als er één portable manier was geweest om de grootte op te vragen.

[.oisyn]

marcusk schreef op 06 oktober 2002 @ 22:47:
volgens mij wordt de lengte op index -1 opgeslagen (of iig 4 bytes voor het begin), maar weet het niet zeker

dat hangt maar net van de implementatie af, zoals Soultaker ook zei. Er staat ook iets over in de standaard:

32) It is not the direct responsibility of operator new[](std::size_t) or operator delete[](void*) to note the repetition count or element size of the array. Those operations are performed elsewhere in the array new and delete expressions. The array new expression, may, however, increase the size argument to operator new[](std::size_t) to obtain space to store supplemental information.

Soultaker schreef op 06 oktober 2002 @ 22:51:
[...]

Dat zal maar net van je implementatie afhangen. Het zou veel handiger zijn geweest als er één portable manier was geweest om de grootte op te vragen.

dat was idd hoe ik mijn vraag ook bedoelde. Feit is dat de grootte opvraagbaar is, er is alleen geen taalfeature voor... maar waarom niet?

[Anoniem: 37864]

dat was idd hoe ik mijn vraag ook bedoelde. Feit is dat de grootte opvraagbaar is, er is alleen geen taalfeature voor... maar waarom niet?

Er is ook geen manier om achter de grootte van een met 'malloc' gereserveerd stuk geheugen te komen, en toch kan je 't weggooien met 'free' zonder de grootte mee te moeten geven...

Er is trouwens een OS waar dat wel anders is: AmigaOS. AllocMem gebruikte je daar om geheugen te reserveren en (zo uit 't hoofd) gebruikte je FreeMem met 2 parameters om 't weer vrij te geven. De 1e parameter is de pointer van 't blok wat je kreeg, en de 2e parameter is de grootte van 't blok... Als je dat niet goed deed viel 't hele OS om, dus onhandig was het wel

[.oisyn]

Anoniem: 37864 schreef op 06 oktober 2002 @ 23:03:
[...]

Er is ook geen manier om achter de grootte van een met 'malloc' gereserveerd stuk geheugen te komen, en toch kan je 't weggooien met 'free' zonder de grootte mee te moeten geven...

idd, en vroeger vond ik het weleens vervelend dat ik niet kon zien hoe groot een met malloc gealloceerd blok was

ik heb ooit eens eigen alloc functies geschreven, en daar had ik dus wel de feature om de blokgrootte op te vragen er ook bij gedaan

[marcusk]

.oisyn schreef op 06 oktober 2002 @ 22:58:
dat hangt maar net van de implementatie af, zoals Soultaker ook zei. Er staat ook iets over in de standaard:

oeps, ik begreep juist dat je ook genoegen nam met een implementatie-specifieke oplossing

dat was idd hoe ik mijn vraag ook bedoelde. Feit is dat de grootte opvraagbaar is, er is alleen geen taalfeature voor... maar waarom niet?

ik heb wel een vermoedden: een dergelijke taalfeature zou dan (als de lengte zo opgeslagen wordt als ik zei) een pointer naar het begin van een array moeten krijgen, en dan de waarde die 32 bits ervoor staat terug geven. Hij kan echter niet weten of de pointer inderdaad naar het begin wijst -> nogal foutgevoelig.

code:

void f(int * x) {
    int c = length(x);
    for (int i = 0; i < c; i++)
        cout << x[i] << " ";
}

int * bla = new int[10];
...
f(bla + 2); // oei

[Soultaker]

marcusk schreef op 06 oktober 2002 @ 23:17:
Hij kan echter niet weten of de pointer inderdaad naar het begin wijst -> nogal foutgevoelig.

Tja, we zijn wel met C/C++ bezig, he. Het is de verantwoordelijkheid van de programmeur om te zorgen dat alles goed werkt. In navolging van jou voorbeeld gaat dit ook fout:

C++:

void g(int *x)
{
    delete x;
}
int * bla = new int[10];
g(bla + 2); // ieks!

Dan zou 'delete' ook onveilig zijn.

[curry684]

farlane schreef op 05 oktober 2002 @ 03:11:
Ze hebben iig beide een memory leak als je ze voor arrays gebruikt.

Zoals dat zo mooi heet: Depends on compiler implementation. BCB doet er niet moeilijk over bijvoorbeeld, maar als je CodeGuard erbij draait klaagt die er juist wel over. VC heeft er voor zover ik weet ook geen probleem mee.

[ Voor 0% gewijzigd door curry684 op 07-10-2002 11:38 . Reden: Typo ]

[marcusk]

Soultaker schreef op 06 oktober 2002 @ 23:27:
Tja, we zijn wel met C/C++ bezig, he. Het is de verantwoordelijkheid van de programmeur om te zorgen dat alles goed werkt. In navolging van jou voorbeeld gaat dit ook fout:
...
Dan zou 'delete' ook onveilig zijn.

Klopt, daar heb ik ook aan gedacht. Het verschil is echter dat een dergelijke length-functie totaal niet meer bruikbaar is als de gegeven pointer gegarandeerd naar het begin van de array moet wijzen.

[farlane]

curry684 schreef op 06 oktober 2002 @ 23:29:
[...]

Zoals dat zo mooi heet: [/b]Depends on compiler implementation[/b]. BCB doet er niet moeilijk over bijvoorbeeld, maar als je CodeGuard erbij draait klaagt die er juist wel over. VC heeft er voor zover ik weet ook geen probleem mee.

Betekent dat ook dat al het gereserveerde geheugen wordt teruggegeven ?

[madwizard]

Bij VC hangt het ervanaf wat je in de array stopt. Als de inhoud onbelangrijk voor VC zelf is is er geen verschil tussen delete en delete[]. Een array van int's is gewoon een stuk geheugen van 4*length bytes (in geval van 32-bit int's natuurlijk). Bij het deleten is het enige dat moet gebeuren het blok weer dealloceren.

Het wordt anders als je bijvoorbeeld object (pointers) erin gaat stoppen. Dan moet bij het deleten ook bij alle objecten de destructors aangeroepen worden. Hiervoor moet VC weten hoeveel objecten er in de array staan en daarom wordt het memory block dat ervoor gereserveerd wordt ook iets anders. In VC 6 wordt voor de array een extra dword gezet die het aantal elementen in de array bevat. De pointer die je terugkrijgt van new[] verwijst gewoon naar het eerste element, de lengte van de array staat er dus voor.

Als je nu delete zou aanroepen zijn er twee problemen: a) de destructors worden niet aangeroepen, en b) de pointer is ongeldig omdat het geheugenblok eigenlijk op (adres-4) begint (vanwege de extra DWORD). Zo krijg je dus wel memory leaks en bij een heap manager die niet tegen verkeerde pointers bestand is ook crashes.
Delete[] leest ook die eerste dword, voert een x aantal keer een destructor uit, en geeft dan delete de pointer-4 door om het geheugenblok te wissen.

Hoewel het voor int's dus niet veel zou uitmaken is dit niet gegarandeerd dus gebruik gewoon altijd de goede delete, de compiler gebruikt toch delete ipv delete[] wanneer dat mogelijk/noodzakelijk is.

[.oisyn]

madwizard schreef op 07 oktober 2002 @ 11:23:
Het wordt anders als je bijvoorbeeld object (pointers) erin gaat stoppen.

een pointer is ook een primitive, maakt niet uit naar welk type. Ze hebben ook geen zinnige destructor

Het maakt pas uit als je een array van objecten aanmaakt die ook daadwerkelijk een aanroep naar de destructor nodig hebben

Ik sta er trouwens wel van te kijken dat VC.net (2003 beta 1, maar ik denk de vorige versies ook) totaal geen rekening houdt met alignment. Als ik een klasse maak met een double en een int, dan is de grootte van een instantie van die klasse 16 bytes (dus wel rekening houdend met alignment). Alloceer ik een array, dan alloceert ie 16 * count + 4 bytes, en de count komt aan het begin te staan. De double in de klasse is dan niet meer gealigned op 8 bytes

_{.edit: hmm kan ik gelijk gebruik maken van mijn beta ID om die 'bug' te submitten}

[curry684]

.oisyn schreef op 07 oktober 2002 @ 12:26:
VC.net (2003 beta 1) _<...knip...>

Huh, wasnuweer het idee achter VC.net 2003? Gaan ze nu in plaats van eens in de 4 jaar plots 1 Visual Studio per jaar uitbrengen of zo?

* curry684 loopt achter

[.oisyn]

curry684 schreef op 07 oktober 2002 @ 13:35:
[...]

Huh, wasnuweer het idee achter VC.net 2003? Gaan ze nu in plaats van eens in de 4 jaar plots 1 Visual Studio per jaar uitbrengen of zo?

* curry684 loopt achter

de nieuwe C++ compiler produceert (volgens eigen zeggen) 20% snellere code voor floating point berekeningen, en hij is enorm ANSI compliant (partial template specialization, al die rare MS oddities zijn eruit gesloopt, etc). Ze hebben echt veel aandacht besteed aan die compliance...

[Anoniem: 13700]

madwizard schreef op 07 oktober 2002 @ 11:23:
Bij VC hangt het ervanaf wat je in de array stopt. Als de inhoud onbelangrijk voor VC zelf is is er geen verschil tussen delete en delete[].

Onzin. Volgens de standaard hoor je objecten die zijn gealloceerd met new[] verwijderen met delete[], en objecten gealloceerd met new verwijderen met delete. new + delete[] of new[] + delete gebruiken geeft "undefined results". VC mag er dan wel soep van trekken, maar dat maakt het nog geen legale C++: het is gewoon fout.

[.oisyn]

Anoniem: 13700 schreef op 07 oktober 2002 @ 14:49:
[...]

Onzin.

hij zei "voor VC zelf"
Je hebt idd gelijk, maar dat maakt de stelling van madwizard niet minder waar

[Glimi]

offtopic:
Jongens, op zulk soort reply's zit de topicstarter toch niet te wachten!
Ik gelukkig wel

[madwizard]

.oisyn schreef op 07 oktober 2002 @ 12:26:
een pointer is ook een primitive, maakt niet uit naar welk type. Ze hebben ook geen zinnige destructor. Het maakt pas uit als je een array van objecten aanmaakt die ook daadwerkelijk een aanroep naar de destructor nodig hebben.

Helemaal gelijk, ik bedoelde een object array .

Anoniem: 13700 schreef op 07 oktober 2002 @ 14:49:
Onzin. Volgens de standaard hoor je objecten die zijn gealloceerd met new[] verwijderen met delete[], en objecten gealloceerd met new verwijderen met delete. new + delete[] of new[] + delete gebruiken geeft "undefined results". VC mag er dan wel soep van trekken, maar dat maakt het nog geen legale C++: het is gewoon fout.

Ik zei ook niet dat het goed was, alleen dat het in VC in *sommige* gevallen niet uitmaakt. delete[] en delete geven bij een int array precies dezelfde code geloof ik.
Maar ik ben het helemaal met je eens dat je het gewoon moet gebruiken zoals het hoort, er is geen enkele garantie dat het goed gaat als je het niet doet (idd undefined results).

[Anoniem: 35845]

Tjeez, het was maar een stom voorbeeldje om iets aan te tonen...
Ten eerste : het deleten van de pointer IN de try en catch doe ik eigenlijk altijd i.v.m. het feit dat ik nogal gewend ben vanuit catch() de exception verder te gooien (al dan niet 'augmented')
Ten tweede : ja stom natuurlijk [] vergeten achter delete volgende keer iets minder snel op "verstuur bericht" klikken...

Met betrekking tot de controleerbaarheid van geheugenallocatie : als je daar echt zelf controle op wil uitoefenen zal je eigen functies moeten schrijven voor alloceren/dealloceren. Dat heb ik al wel eens gedaan, gewoon om een stuk memory te beheren. Denk dan aan een blok in een shared datasegment van een DLL of een stukje 'emergency' geheugen voor als er te weinig geheugen is (zodat je in ieder geval nog een beetje reserve hebt om netjes je programma te verlaten en een foutmeldinkje weg te schrijven, etc..)

[Glimi]

Anoniem: 35845 schreef op 06 oktober 2002 @ 15:25:
Ik chargeer even : dus jij bent ook tegen het gebruik van character pointers? Dat zijn ook arrays van primitives. Volgens jou zou ik dus in mijn string classes geen char * maar een std::vector<char> moeten gebruiken...

Ten eerste mijn excuus dat ik zo laat reageer

Ik zal even uitleggen waarom ik dus tegen char*/ array's ben, binnen een OO taal.

Bekijk het verschil even tussen C en C++. C++ is een uitbreiding op C zodat de procedurele taal C OO mogelijkheden krijgt. De compibaliteit tussen C en C++ is behouden, zodat met C++ zowel prodedureel als OO te programmeren is. Echter dat neemt niet weg dat C++ eigenlijk volledig OO is! Voor zover niets nieuws voor u

Je zit dus te werken binnen het OO paradigma. Dit houdt in dat je classes maakt, die horen fungeren als een black box. Een class zou ik graag definieëren als een verzaming variabelen die een 'ding/iets' representeren. De class staat op zichzelf en is verantwoordelijk voor de staat van zijn variabelen en _niemand anders_

Natuurlijk schieten primitieven hier weer buiten, het zou ook niet. Primitieven zie ik als noodzakelijk kwaad. Ze zijn nodig om de boel wat meer peper in z'n kont te geven, echter het bijhouden en verantwoordelijkheden ontbreken geheel, die zijn overgelaten aan de compiler.

Arrays kan ik in dit verhaal indelen bij de classes. Array's zijn immers variabelen die bij elkaar horen. Wat Array dus wel missen is de black box functionaliteit. Ik moet _alles_ gaan bijhouden voor die array wat ie zelf zou moeten doen! Als ik element 3 vraag en die outOfBounds dan moet niet het systeem over z'n nek gaan! Dat kan ik niet bij blackbox functionaliteit indelen iig.

Echter soms zijn array's gewoon noodzakelijk kwaad. Soms zijn ze nodig voor snelheid omdat een wrapper te veel overhead veroorzaakt. Tja, dan moet het nou eenmaal Soms gaat snelheid voor design/veiligheid, maar die tendens is toch al aan het omslaan Men schrijft meer in patronen dan ooit. Dit omdat de software steeds groter, steeds on-onderhoudbaarder wordt en de computers toch steeds sneller en dus de overhead niet echt merkbaar is

Het is natuurlijk waar dat je als je verwacht de code fors te gaan uitbreiden/veranderen/compliceren je beter een std::vector kunt gebruiken, don't worry ik ga er dan ook vanuit dat iedere zichzelf respecterende programmeur dit wel begrijpt. Er zijn alleen situaties waar het gebruik van een std::vector gewoon zware overkill is...

Gelukkig maar. Ga er trouwens maar van uit dat je code gaat bloaten, het is iig geen uitzondering. Echter ik wil er echt nogmaals roepen dat er tegenwoordig niet echt vaak meer een reden is om array's te gebruiken, als je niet in de wereld van kernel's, highspeed 3D ed. zit. De meeste programma's zijn zo low level niet meer dat safety van code meer voorop staat dan raw speed.

En laten we het dan maar niet hebben over hastables. Die zijn altijd op basis van arrays dus die heb je wel degelijk nodig soms

Maar hashtables zijn wel safe! Hashtabels hebben een array gewrapt zodat je geen array hoeft te gebruiken. Feitelijk doen ze hetzelfde als vector, namelijk een safe datastructure bieden, maar dan net ff anders. Kijk als jij er elke keer voor wilt kiezen array ZELF te wrappen, be my guest, maar ik neem aan dat dit niet je levensdoel is

[Anoniem: 35845]

Maar hashtables zijn wel safe!

Ik bedoelde dus meer in de trant van : als je zelf een hashtable implementatie maakt...
Maar goed
En ik probeer zeker niet altijd mijn array zelf te wrappen : ik kijk wel link uit... Als je veel win32 system code schrijft heb je alleen erg vaak met non-object progs te maken (ja ik mag nou eenmaal niet alles ontwerpen sommige dingen zijn gewoon al 3 jaar oud BTW)

edit:
Je mag in een CreateFile() ook geen std::array<char> stoppen. Character pointers zijn dus gewoon noodzaak

[Glimi]

Anoniem: 35845 schreef op 09 oktober 2002 @ 00:47:
Ik bedoelde dus meer in de trant van : als je zelf een hashtable implementatie maakt...
Maar goed

Tja, maar dan wrap je je array nog wel zelf. Plus dat ik niet begrijp dat je zelf een hashtable gaat schrijven, er is toch al een mooie

En ik probeer zeker niet altijd mijn array zelf te wrappen : ik kijk wel link uit... Als je veel win32 system code schrijft heb je alleen erg vaak met non-object progs te maken (ja ik mag nou eenmaal niet alles ontwerpen sommige dingen zijn gewoon al 3 jaar oud BTW)

Tja, dat houdt je erin met legacy code he. Alles moet maar compatible zijn met versie X. Daarom kies ik er ook al voor om waar het enigzins kan, een wrapped array te gebruiken, met oog op de toekomst, liefst geïmplementeerd dmv een interface zoals het java collection framework

edit:
Je mag in een CreateFile() ook geen std::array<char> stoppen. Character pointers zijn dus gewoon noodzaak

Tja, eigenlijk zou je er gewoon een string in moeten stopppen, maar dat is echt weer zo'n erfenis uit C, die char *

[johnwoo]

Glimi schreef op 09 oktober 2002 @ 08:10:
[...]
Tja, eigenlijk zou je er gewoon een string in moeten stopppen, maar dat is echt weer zo'n erfenis uit C, die char *

Punt is natuurlijk wel dat de Win32 API enigszins taalonafhankelijk moet zijn, dus als jij in C++ een string erin wilt gooien dan zullen er voor iedere taal aparte import libs geschreven moeten worden De char* geeft je meteen al ondersteuning voor C èn C++, en is makkelijk te gebruiken door andere compilers (VB/Delphi/...).

[Anoniem: 35845]

Tja, eigenlijk zou je er gewoon een string in moeten stopppen, maar dat is echt weer zo'n erfenis uit C, die char *

Je mag er ook een string instoppen, als die dan maar casting operator implementeert
Het wordt pas echt vervelend als je er geen const char * maar gewoon een char * in moet stoppen... Dan wordt het werken met strings heel lastig. En er zijn gewoon veel functies waar je een bufferadres aan moet meegeven. Dat wordt dan dus toch weer een pointer (al dan niet impliciet geconverteerd van een wrapper class).
Al die win32 code is al met al dus niet erg geschikt voor het OO paradigma, maar je moet wat. Een OO variant van win32 is er eigenlijk niet (MFC maar die gaat lang niet op alle punten ver genoeg). En wat betreft compatibiliteit : als de klant met pakket X werkt, zal het daarop moeten werken ja... dat is geen keuze die ik kan maken. Helaas heeft de keuze van het OS en het toepassingsgebied van een applicatie vaak gevolgen voor de keuze die je kan maken m.b.t. te gebruiken programmeertaal / paradigma. En ook onderhoud op bestaande software betekent veel procedureel proggen, 90% van alle code van bestaande applicaties (zo niet meer) is gewoon procedureel, en er is niemand die er voor wil betalen om dat om te zetten naar OO omdat de developer dat prettiger vind proggen. Jammer, maar zo is de harde realiteit nou eenmaal

[Anoniem: 35845]

Punt is natuurlijk wel dat de Win32 API enigszins taalonafhankelijk moet zijn, dus als jij in C++ een string erin wilt gooien dan zullen er voor iedere taal aparte import libs geschreven moeten worden De char* geeft je meteen al ondersteuning voor C èn C++, en is makkelijk te gebruiken door andere compilers (VB/Delphi/...).

Dat is natuurlijk afhankelijk van de VB/Delphi/etc. compiler. Voor win32 support moeten nu char *, int * etc. gesupport worden, anders is het formaat ietsje anders en heb je object libs nodig voor die talen. VB/Delphi zijn ook OO-capable talen hoor! Zo boeiend is het 'plat' houden van de win32 interface dus nou ook weer niet...

[.oisyn]

Anoniem: 35845 schreef op 09 oktober 2002 @ 11:07:
VB/Delphi zijn ook OO-capable talen hoor! Zo boeiend is het 'plat' houden van de win32 interface dus nou ook weer niet...

Dat het een OO taal is wil nog niet zeggen dat ze zomaar met elkaar kunnen interfacen. Een delphi- en zeker een VB-object zit totaal anders in eklaar dan een C++ object

En Glimi: C++ is een hybride taal, niet een pure OO taal. Bovendien vind ik jouw gezwam te puristisch (no offence)

[Anoniem: 13700]

johnwoo schreef op 09 oktober 2002 @ 10:39:
De char* geeft je meteen al ondersteuning voor C èn C++, en is makkelijk te gebruiken door andere compilers (VB/Delphi/...).

offtopic:
Ik weet niet veel van Delphi, maar ik dacht dat dat een opgeleukte Pascal was. En van Pascal weet ik nog dat daar geen zero-terminated strings in zaten, maar strings met een lengtebyte. Als dat bij Delphi nog zo is, moet Delphi of per string een byte extra verspillen om C-compatible te zijn, of strings copieren/casten naar een char* als dat nodig is.

[LordLarry]

Anoniem: 35845 schreef op 09 oktober 2002 @ 10:48:
[...]
Al die win32 code is al met al dus niet erg geschikt voor het OO paradigma, maar je moet wat. Een OO variant van win32 is er eigenlijk niet (MFC maar die gaat lang niet op alle punten ver genoeg).

Borland heeft met zn VCL framework bewezen dat een OO structuur maken van de platte win32 heel goed mogelijk is en zeker stukke beter kan als MFC. De VCL bestaad al vanaf Delphi 1 (win3.11) en met BCB kan je het ook met de C++ taal kan. Dat de win32 api van je afgeschermd is betekend overgens niet dat je m niet al dan niet gemixed kan gebruiken met de VCL. Heel makkelijk zelfs.

Ook .Net is nog grootendeels gebouwd bovenop de win32 api en ook die is OO en ook die heeft de win32 api aardig weten af te schermen. Ik denk dat steeds meer onderdelen van windows .Net worden en zo langzamerhand de win32 api overnemen. Natuurlijk zal er low level nog wel een soort platte api bestaan, maar die is dan nauwelijks nog interresant voor de programmeurs. Zie hoe vroeger iedereen interrupts gebruikten om het OS (DOS 21h) te benaderen en de programmeurs van nu nauwelijks weten wat DOS is, laat staan een interrupt.

[.oisyn]

Anoniem: 13700 schreef op 09 oktober 2002 @ 11:39:
[...]

offtopic:
Ik weet niet veel van Delphi, maar ik dacht dat dat een opgeleukte Pascal was. En van Pascal weet ik nog dat daar geen zero-terminated strings in zaten, maar strings met een lengtebyte. Als dat bij Delphi nog zo is, moet Delphi of per string een byte extra verspillen om C-compatible te zijn, of strings copieren/casten naar een char* als dat nodig is.

Delphi kent een PChar, wat eigenlijk gewoon een pointer naar char is, net als in C, en is ook compatible met de C string (zero-terminated dus)

[.oisyn]

Anoniem: 35845 schreef op 09 oktober 2002 @ 10:48:
Al die win32 code is al met al dus niet erg geschikt voor het OO paradigma, maar je moet wat. Een OO variant van win32 is er eigenlijk niet (MFC maar die gaat lang niet op alle punten ver genoeg)

COM, .NET en GDI+
MFC hoort niet echt in dat rijtje thuis omdat het gewoon een laagje is aan de applicatiekant (is ook vrijwel MSVC only), en is verder ook niet in de platform SDK beschreven

[Alarmnummer]

.oisyn schreef op 09 oktober 2002 @ 11:20:

[...]

En Glimi: C++ is een hybride taal, niet een pure OO taal. Bovendien vind ik jouw gezwam te puristisch (no offence)

Dat puristische zal wel komen omdat hij te veel een javahova is Ik ben op dit moment bezig met Nice en dat is een taal die nog veel puurder is dan Java. Oa het verschil tussen primitieve types en object types is al voor een groot deel komen te vervallen. En het is misschien daardoor iets minder snel op dit moment, maar het programmeert wel erg eenvoudig. De compilers en de runtime omgeving gaan in de toekomst steeds krachtiger worden. Vooral de runtime omgeving die zal steeds meer kunstmatige intelligentie gaan bevatten en uiteindelijk zal dit veruit superieur zijn aan de mens. De runtime omgeving die kan runtime bepalen hoe en wat er geoptimaliseerd moet worden. Zodoende kunnen de programmeurs zich bezig houden met de essentie, ipv alle onzinnige zaken er omheen.

[LordLarry]

Anoniem: 13700 schreef op 09 oktober 2002 @ 11:39:
[...]

offtopic:
Ik weet niet veel van Delphi, maar ik dacht dat dat een opgeleukte Pascal was. En van Pascal weet ik nog dat daar geen zero-terminated strings in zaten, maar strings met een lengtebyte. Als dat bij Delphi nog zo is, moet Delphi of per string een byte extra verspillen om C-compatible te zijn, of strings copieren/casten naar een char* als dat nodig is.

Pascal had inderdaad geen c strings, maar strings met een lengte byte. In Delphi zijn dat short strings geworden en worden deze nauwelijks nog gebruikt. (Ansi)Strings zijn reference counted en null terminated, maar hebben nogsteeds een lengte byte omdat dat nu eenmaal pascal is. Een strings bezet daarom wat meer geheugen intern, maar maakt je level wel een stuk makkelijker dan c strings

PChar(AStringVar);
of
'Dit kan ook een c string zijn'

is genoeg om van een String een C string te maken en andersom werkt ook. WinAPI's zijn daarom vrij goed en type safe te gebruikken binnen Delphi.

BCB heeft ook AnsiStrings en daarmee dezelfde voordelen onder C++.

[MSalters]

Pascal has officieel geen variabele-lengte string. je effectief alleen char arrays, met fixed lengte. Ongeveer iedere implementor ontdekte dat dat niet werkte.

[Anoniem: 13700]

MSalters schreef op 09 oktober 2002 @ 11:51:
Pascal has officieel geen variabele-lengte string. je effectief alleen char arrays, met fixed lengte. Ongeveer iedere implementor ontdekte dat dat niet werkte.

Mja, maar Pascal was dan ook eigenlijk niet bedoel als taal voor productiedoeleinden. Wirth ontwikkelde het naar eigen zeggen als een taal voor educatiedoeleinden.

[.oisyn]

Alarmnummer schreef op 09 oktober 2002 @ 11:45:
Ik ben op dit moment bezig met Nice en dat is een taal die nog veel puurder is dan Java. Oa het verschil tussen primitieve types en object types is al voor een groot deel komen te vervallen. En het is misschien daardoor iets minder snel op dit moment, maar het programmeert wel erg eenvoudig.

grappig, in C++ is er feitelijk geen verschil (primitive is als object te benaderen (constructor, destructor, pointer en reference), en object is als primitive te benaderen (operator overloading)), en toch is het snel

[Anoniem: 35845]

COM, .NET en GDI+
MFC hoort niet echt in dat rijtje thuis omdat het gewoon een laagje is aan de applicatiekant (is ook vrijwel MSVC only), en is verder ook niet in de platform SDK beschreven

hmmm ja... Ik had het dus niet over 'echte applicaties', maar meer over platform integratie & middleware (denk aan unattended installatie van printers at logon, softwaredistributie), dan heb je aan COM nog steeds weinig (werk niet met .NET want target platform = NT), GDI+ ken ik helemaal niet.
En dat MFC niet in dat rijtje thuis hoort : dat ligt dan aan jouw rijtje Ik gaf een voorbeeld van een OO implementatie van win32 (als wrapper om de platte win32 in het geval van MFC), dat jij dan een rijtje maakt waar ie vervolgens niet in thuis hoort... MFC hoort ook niet in {boom,roos,vis}

edit:
even nog een reactietje op .Oysins laatste reactie

Ik prog nog steeds veel in C++. Het is gewoon enorm flexibel. Dat maakt dat je dus wel goed moet weten waar je mee bezig bent. Maar ik ben gewoon erg gewend/gehecht aan de mogelijkheden van C++ m.b.t. pointers/procedurele zaken/operator overloading. Het KAN, maar het MOET niet! Prachtig motto imho

[.oisyn]

Anoniem: 35845 schreef op 09 oktober 2002 @ 13:52:
[...]


hmmm ja... Ik had het dus niet over 'echte applicaties', maar meer over platform integratie & middleware (denk aan unattended installatie van printers at logon, softwaredistributie), dan heb je aan COM nog steeds weinig (werk niet met .NET want target platform = NT), GDI+ ken ik helemaal niet.
En dat MFC niet in dat rijtje thuis hoort : dat ligt dan aan jouw rijtje Ik gaf een voorbeeld van een OO implementatie van win32 (als wrapper om de platte win32 in het geval van MFC), dat jij dan een rijtje maakt waar ie vervolgens niet in thuis hoort... MFC hoort ook niet in {boom,roos,vis}

ah ok, misschien begrepen we elkaar verkeerd. Ik was namelijk onder de indruk dat we het over de Win32 API hadden, en dat dat niet OO was zodat het met veel talen overweg kan. Echter behoren COM, .NET en GDI+ wel tot de Win32 API, en dat zijn dus OO API's
MFC is imho niet een platform API, maar gewoon een wrapper, net als VCL dat is, en in mindere mate libs als Qt. Dat zijn gewoon tools om het leven makkelijker te maken, het is niet iets wat het 'windows platform' aanbiedt

[Anoniem: 35845]

Echter behoren COM, .NET en GDI+ wel tot de Win32 API

Mijn 'windows platform' biedt ook geen .NET aan hoor... Volgens mijn zijn dit meer extensies op de win32 API dan dat ze er echt onderdeel van uit maken. Of ze moeten gewoon een win32 API versie xxx gedefinieerd hebben, kan natuurlijk ook. Het hele verkeerd begrijpen zou dus best wel eens een defenitiekwestie kunnen zijn...

[.oisyn]

Anoniem: 35845 schreef op 10 oktober 2002 @ 00:21:
[...]

Mijn 'windows platform' biedt ook geen .NET aan hoor...

dat is omdat het nog net in z'n schoenen staat, Win XP wordt nog niet standaard geshipped met .NET. Bij de volgende windows zal dat wel het geval zijn (en GDI+ API wordt ook pas sinds Win XP ondersteund, maar je kunt voor de andere windows versies dacht ik wel uitbreidingen downloaden)