[C++] Invalidated geheugen?

[ChessSpider]

Ik ben nu bezig met het leren van C++ en ik heb een vraag over alloceren op de stack en de heap. In het boek dat ik heb wordt dit niet duidelijk genoeg uitgelegd.
Eigenlijk is het een kort ja/nee vraagje..

C++:

#include <iostream>
#include "windows.h"

int _tmain(int argc, _TCHAR* argv[])
{
    char *toSearchFor;
    for(int i = 0; i < 100000; i++)
    {
        switch( i % 4 )
        {
        case 0:
            { char* token = "StukTest"; toSearchFor = token; }
            break;
        case 1:
            { char* token = "12345678"; toSearchFor = token; }
            break;
        case 2:
            {   char* token = "AndereDa";   toSearchFor = token; }
            break;
        case 3:
            { char* token = "TaKomtHi"; toSearchFor = token; }
            break;
        case 4:
            { char* token = "erStaan!"; toSearchFor = token; }
            break;
        }
        std::cout << toSearchFor << std::endl;
        Sleep(20);
    }
    system("pause");
    return 0;
}

• Komt de tekst op de stack terecht?
• Als ik het op regel 27 std::cout doe, is het geheugen invalidated -- dat het werkt is het puur toeval?

[NC83]

Ja de char* token declaratie staan allemaal op de stack en na het verlaten van het block wordt dat dus allemaal weggegooid.

[ Voor 38% gewijzigd door NC83 op 09-07-2010 16:08 ]

[.oisyn]

Nee, je definieert een pointer die wijst naar een string literal. Die string staat niet op de stack, maar ook niet op de heap - ze staan feitelijk in geheugen dat gereserveerd is voor je executable, en vrijgeven zal dan ook niet kunnen. De pointer zelf staat wel op de stack die daarna wordt weggegooid, maar de inhoud (de verwijzing dus) kopieer je naar een andere variabele die een langere lifetime heeft dus dat is niet erg.

Het zou anders zijn als je char token[] = "StukTekst"; zou doen. Dan definieer je namelijk een array op de stack die je initialiseert met die 10 tekens (9 van de string en een trailing \0). En ja, dat geheugen is eigenlijk niet meer aanspreekbaar op regel 27, al zal het in de praktijk nog wel werken (maar daar moet je niet vanuit gaan! Ook voor types met een destructor is de destructor op dat moment al uitgevoerd)

[ Voor 13% gewijzigd door .oisyn op 09-07-2010 16:33 ]

[ChessSpider]

.oisyn schreef op vrijdag 09 juli 2010 @ 16:10:
Nee, je definieert een pointer die wijst naar een string literal. Die string staar niet op de stack, maar ook niet op de heap - ze staan feitelijk in geheugen dat gereserveerd is voor je executable, en vrijgeven zal dan ook niet kunnen. De pointer zelf staat wel op de stack die daarna wordt weggegooid, maar de inhoud (de verwijzing dus) kopieer je naar een andere variabele die een langere lifetime heeft dus dat is niet erg.

Betekend dat dat dit stukje code correct is? Dus geen gebruik van invalidated geheugen op regel 27, memory leaks of andere undefined behaviour?

[ Voor 7% gewijzigd door ChessSpider op 09-07-2010 16:29 ]

[.oisyn]

Correct

[bobo1on1]

Die laatste case wordt trouwens nooit gehaald

[ChessSpider]

.oisyn schreef op vrijdag 09 juli 2010 @ 16:32:
Correct

Sorry dat snap ik niet helemaal.

Heb je misschien een paar keywords voor mij waarmee ik kan opzoeken wat er gebeurd?

En zou je aan mij kunnen uitleggen waarom de geheugenlocatie van toSearchFor tijdens elke iteratie hetzelfde blijft?

C++:

std::cout << &toSearchFor << std::endl;

Geeft bij mij dezelfde geheugenlocatie terug.

[.oisyn]

ChessSpider schreef op vrijdag 09 juli 2010 @ 17:07:
[...]

Sorry dat snap ik niet helemaal.

Wat snap je dan precies niet?

En zou je aan mij kunnen uitleggen waarom de geheugenlocatie van toSearchFor tijdens elke iteratie hetzelfde blijft?

C++:

std::cout << &toSearchFor << std::endl;

Geeft bij mij dezelfde geheugenlocatie terug.

Waarom zou dat niet het geval zijn? Het blijft toch dezelfde variabele? Waarom zou die steeds een andere geheugenlocatie moeten hebben? Natuurlijk, hij heeft wel elke iteratie een andere waarde, maar zijn eigen geheugenlocatie, wat je opvraagt met de & operator, blijft gelijk.

Wat jij volgens mij nodig hebt is gewoon een duidelijk beeld van wat een pointer nou precies is: Wikipedia: Pointer (computing)

[ Voor 12% gewijzigd door .oisyn op 09-07-2010 17:18 ]

[Verwijderd]

Een objdump -s -j .rodata a.out onder linux/unix (ELF formaat) zal je laten zien dat de teksten onder de .rodata section vallen. Dus niet op de stack.

Zie:
http://wiki.osdev.org/ELF

Het converteren van een string constant naar een char* is deprecated. Gebruik van een const char* zal hierop geen compile time warning geven.

[ChessSpider]

.oisyn schreef op vrijdag 09 juli 2010 @ 17:17:
[...]

Waarom zou dat niet het geval zijn? Het blijft toch dezelfde variabele? Waarom zou die steeds een andere geheugenlocatie moeten hebben? Natuurlijk, hij heeft wel elke iteratie een andere waarde, maar zijn eigen geheugenlocatie, wat je opvraagt met de & operator, blijft gelijk.

Wat jij volgens mij nodig hebt is gewoon een duidelijk beeld van wat een pointer nou precies is: Wikipedia: Pointer (computing)

Touché

.oisyn schreef op vrijdag 09 juli 2010 @ 17:17:
[...]

Wat snap je dan precies niet?

Waar de string literal word opgeslagen, waarom en onder welke omstandigheden.

@rdv_, en onder windows?

Mijn boek komt dus gewoon niet verder dan de stack en de heap.

[farlane]

ChessSpider schreef op zaterdag 10 juli 2010 @ 14:58:
Waar de string literal word opgeslagen, waarom en onder welke omstandigheden.

Is niet een algemeen antwoord op te geven: het zou zelfs in ROM terecht kunnen komen als het platform dat ondersteunt.

Hier een kleine opsomming van de verschillende segmenten:
http://www.gotw.ca/gotw/009.htm

[ Voor 21% gewijzigd door farlane op 11-07-2010 10:53 ]