Dynamisches Array ohne new?

[bIce]

Wenn Du kein new nehmen darfst nimmt dann doch malloc()

[Gast]

Geht doch nicht

[Knuddlbaer]

Ahhhhh jetzt ja Ok ich habs mit ironie nich so

[operator void]

malloc ist genauso viel oder wenig eine Bibliothek wie vector. Ich würde auch sagen, dass es ohne die beiden nicht portabel geht. Stack-Arrays mit variabler Größe gehen nur in C99, nicht in C++98.

[TeeJay]

Moin.

Wie oben genannt könntest du das auf dem Stack anlegen. Jedoch hast du dann das Problem das das Array nur innerhalb dieser einen Funktion nutzbar ist.

Am besten du umschreibst deine Aufgabe mal etwas genauer. Sprich was darfst du verwenden, welches OS usw.

[Irgendwer]

I vermute mal, dass inline ASM auch verboten ist, denn damit wäre es leicht ein Array auf dem Stack anzulegen.

Fals nicht würde ich da eine Methode kennen eine linked List auf dem Stack anzulegen:

struct Item{
    int val;
    Item*next;
    Item*pre;
};
int size=8;
int count=0;
void list()
{

     Item i;

     static Item*inter_func_pre=0;
     static Item*bottom=0;
     static Item*top=0;
     i.pre=inter_func_pre;
     if(i.pre)
         i.pre->next=&i;
     else
         bottom=&i;
     i.next=0;
     inter_func_pre=&i;
     top=&i;

     if(count<size)
     {
         count++;
         list();
     }
     else
     {
         //use your list
     }
}

Allerdings sobald du die Funktion wieder verlässt ist die List weg, und nicht vergessen Stackoverflow Gefahr!

[TeeJay]

Moin.

Das mit der linked List wird so nicht klappen.
Normal benutzt man da ja auch new.
Dies umgehst du ja hier indem du bei jedem Aufruf eine lokale Variable i erstellst.
Diese wird ja aber indirekt beim verlassen der Funktion wieder gelöscht, da sie ja auf dem Stack ist.
Solltest du also zwischendrin noch ne andere Funktion aufurfen, dann wird i auf dem Stack überschrieben.

Also denke ich nicht das es so geht.

EDIT: UPS sorry hatte den letzten Satz zu spät gelesen *G*.

Und das er ASM nich nutzen darf hat er ja nicht gesagt.

Aber trotzdem sollte er mal genau beschreiben was da am Ende rauskommen soll.

[test2004]

Warum sollte
...
int i;
std::cin >> i;
...
int var[i];
...

nicht gehen ?

[Mis2com]

Weil bei der Initialisierung eines Arrays in [] nur Konstanten erlaubt sind.

[Gast]

Hat das eigentlich technische Gründe? Das kann doch dem Stack so &§$%egal sein, wieviel Speicher er jetzt für das Array reservieren muss.

[Bashar]

In C99 geht das ja. Ich denke aber, dass es auch in C++0x nicht übernommen werden wird, weil es einen Haufen zusätzlicher Schwierigkeiten mit sich bringt, z.B. weil sizeof dann nicht mehr generell zur Compilezeit ausgewertet werden kann.
Und dann wär da noch alloca. Sowas wie malloc, nur dass der Speicher vom Stack genommen wird, und demzufolge Scope-Austritt automatisch freigegeben wird.

[TeeJay]

Ein array das mit
int i[10]
erstellt wird eine lokale Variable ist die auf dem Stack gespeichert wird.
Und beim compilen muß bekannt sein wie groß dieses Array ist, damit der Stack dementsprechend eingerichtet werden kann.

Auch hier kann ich nur empfehlen sich mal etwas eingehender mit Rechnerarchitektur und Assembler auseinanderzusetzen.
In ASM muß niemand wirklich Programme schrieben können, aber eine gute Lektüre sollte auch einem C++ Programmiere einige gute Kenntnisse darüber geben was hinter seinem Code abläuft.

[Irgendwer]

Hat das eigentlich technische Gründe? Das kann doch dem Stack so &§$%egal sein, wieviel Speicher er jetzt für das Array reservieren muss.

Weil der stack nicht dafür gedacht ist. Wenn man eine lokale Variable benutzt baut der compiler ja eine address (keine absolute sondern relative zu ebp oder manchmal auch esp) in den code ein. Fals nun diese address unbekannt at compile time ist, weil die Grösse einer Variablen (des Arrays) unbekannt ist, so wird das ganze will kompilzirter und produzirt einen nicht zu unterschätzenden overheat.

In C++ gibt es auto_ptr dafür.

[Gast]

@Tee, zufälligerweise bin gerade dabei, mich damit auseinander zu setzen. Und ich verstehe immer noch das Problem nicht.

Das Array wird zur Laufzeit angelegt und bei nem int-Array (als Beispiel) ist es doch jetzt wurscht, ob der Stackzeiger jetzt 5*sizeof(int) oder 9834*sizeof(int) nach oben springen muss. Das kann zur Laufzeit wunderbar berechnet werden und in asm lässt sich das ebenfalls hervorragend implementieren. Mir ist schleierhaft, warum das der Compiler zur Compilierzeit genau wissen will, auch wenn es mich nicht stört, ich habe so etwas noch nie gebraucht.

[Bashar]

Wozu schreib ich überhaupt noch was, wenn ich eh ignoriert werde. Nochmal für etwas langsamere: Das ist kein technisches Problem. alloca und Arrays variabler Länge existieren (wenn auch nicht in C++). Mit einem Minimalverständnis von Assembler versteht man auch, wie das funktioniert.

[TeeJay]

Ja ich weiß man könnte das mit ASM bequem lösen.

Jedoch ist es halt von C/C++ so vorgegeben, das lokale Variablen nur mit zur Compilezeit bekannter Größe erstellt werden kann.

Zum einen hat es den evtl. Vorteil das der Compiler schon erkennen kann das ein Stacküberlauf passieren wird.

Schonmal versucht ein lokales Array mit 5MB anzulegen? *G*

[Shade Of Mine]

TeeJay schrieb:

Jedoch ist es halt von C/C++ so vorgegeben, das lokale Variablen nur mit zur Compilezeit bekannter Größe erstellt werden kann.

Hallo? Hast du Bashars Posting gelesen?
In C gibt es solche Arrays!

[Bashar]

TeeJay schrieb:

Jedoch ist es halt von C/C++ so vorgegeben, das lokale Variablen nur mit zur Compilezeit bekannter Größe erstellt werden kann.

Es ist von C++ vorgegeben. C beherrscht seit 1999 variable-length-arrays.

Schonmal versucht ein lokales Array mit 5MB anzulegen? *G*

Ja, was soll dann passieren? Haut meine Maschine nicht aus den Socken, vielleicht ist das unter Windows ein Problem, weiß ich nicht.

[TeeJay]

Wenn C das beherrscht, dann poste doch einfach wie es genau geht und dann ist ja gut.

[Jester]

int array[length];

dabei darf length eine stinknormale integer-Variable sein, die zum Beispiel zur Laufzeit eingelesen oder berechnet werden kann.

MfG Jester