Array Grösse Mit Integer Variable definieren

[helix]

Hi Leute
Wie Kann man ein Array mit einer Grösse aus einer Integer Variable definieren?
Ich habe das so Versucht:

int size;
std::cin>>size;
int array[size];

Das geht aber nicht, der computer sagt: "constant expression required" (oder so ähnlich )
Weiss jemand Hilfe?
EDIT: Programmiersprache ist c++

MfG
helix

 

[quarx]

Ein C-Array muss eine feste, zum Compilierzeitpunkt bekannte Größe haben. Da müsstest Du auf Pointer umsteigen und den Speicherbereich zur Laufzeit anfordern. Oder (da Du eh schon mit C++ arbeitest) Du verwendest die Containerklassen aus der STL:

#include <vector>
...
std::vector<int>::size_type size;
std::cin >> size;
std::vector<int> v(size);

Zugriff auf Elemente syntaktisch wie bei C-Arrays.

 

[Gubbie]

ich habe keine Ahnung von C, aber wie wärs, wenn du das Array einfach gross genug dimensionierst und nur die benötigten Felder nutzt?

 

[helix]

ich habe keine Ahnung von C, aber wie wärs, wenn du das Array einfach gross genug dimensionierst und nur die benötigten Felder nutzt?

Jo, das hat auch der Informatiklehrer gesagt, als ich ihm die Frage gestellt habe. Ist aber nicht besonders elegant oder? . Ich muss ihm die Sache mit vector mal unter die Nase reiben... .

MfG
helix

 

[Gubbie]

Jo, das hat auch der Informatiklehrer gesagt, als ich ihm die Frage gestellt habe. Ist aber nicht besonders elegant oder? . Ich muss ihm die Sache mit vector mal unter die Nase reiben... .

MfG
helix

ja, habe ich mir schon gedacht, dass dir das nicht gefällt. Das ist auch wirklich unsauber. Aber ich habe wie gesagt nix mit C zu tun ( zum glück ),

 

[helix]

ja, habe ich mir schon gedacht, dass dir das nicht gefällt. Das ist auch wirklich unsauber. Aber ich habe wie gesagt nix mit C zu tun ( zum glück ),

wieso denn zum glück?

 

[MatzeLoCal]

Wie wäres es mit einer Liste? Ok, du kannst nicht unbedingt wahlfrei zugreifen, aber vll brauchst du das garnicht.

Das mit einem "sehr grossen, fix definierten Array" würde ich sein lassen.
1. verschwendest Du Resourcen
2. ist das ein potentieller Fehlerherd zur Laufzeit. Wer garantiert Dir, dass die Arraygrösse NIE erreicht wird?

 

[helix]

Wie wäres es mit einer Liste? Ok, du kannst nicht unbedingt wahlfrei zugreifen, aber vll brauchst du das garnicht.

Das mit einem "sehr grossen, fix definierten Array" würde ich sein lassen.
1. verschwendest Du Resourcen
2. ist das ein potentieller Fehlerherd zur Laufzeit. Wer garantiert Dir, dass die Arraygrösse NIE erreicht wird?

Also eigentlich ist das Problem mit den vectoren super gelöst! :-D. Und die Sache mit dem "sehr grossen, fix definierten Array" stammt von meinem Lehrer...
MfG
helix

 

[MatzeLoCal]

Also eigentlich ist das Problem mit den vectoren super gelöst! :-D.

Oh sorry, hab ich überlesen

Und die Sache mit dem "sehr grossen, fix definierten Array" stammt von meinem Lehrer...

Dann richte ihm doch mal aus, dass er bitte NIE von ihm geschriebene Software verteilen soll...... boha.. Lehrer ey...

 

[helix]

Dann richte ihm doch mal aus, dass er bitte NIE von ihm geschriebene Software verteilen soll...... boha.. Lehrer ey...

Soweit kommst (hoffentlich) nicht . Und: der Informatikunterricht ist sowieso nicht für viel; alles auf Windows ausgelegt .

MfG
helix

 

[Trapper]

Wie Kann man ein Array mit einer Grösse aus einer Integer Variable definieren?

Für Felder, deren Größe erst zur Laufzeit bekannt ist existiert in C++ der new-Operator. Der relevante Codeausschnitt für dein Beispiel sieht so aus:

int size;
int* myArray;

std::cin >> size;
myArray = new int[size];

 

[quarx]

... nicht zu vergessen ein

delete [] myArray;

zum Schluß...

 

[Trapper]

@quarx: Da hast du vollkommen recht, das sollte unbedingt noch erwähnt werden! Danke für den Hinweis. Ich hab wohl schon zu lange Java programmiert

 

[tjp]

Für Felder, deren Größe erst zur Laufzeit bekannt ist existiert in C++ der new-Operator. Der relevante Codeausschnitt für dein Beispiel sieht so aus:

Das Beispiel ist leider auch falsch. malloc & Co. und der new Operator erwarten ein Argument von Typ size_t. size_t ist auf einem UNIX niemals von Typ int, es ist entweder unsigned int (ILP32, 32Bit UNIX Umgebung) oder unsigned long (LP64, 64Bit UNIX Umgebung).

include <stddef.h>
size_t size = 0;

std::cin >> size;

int* const myArray = new int[size];

delete[] myArray;

Das Herumreiten auf diesen Feinheiten ist wichtig, da man durch die falsche Verwendung von int anstelle des richtigen size_t die Kompatiblität mit dem 64Bit Modus versaut. size_t ist immer vom passenden Typ, daher besteht keinerlei Notwendigkeit in so einem Kontext nach den Typ int zu verwenden wie dies zu K&R Zeiten mal der Fall war.

Allerdings sollte man gerade als Anfänger auf die Lösung via Zeiger Speicher anzufordern dankend verzichten und statt dessen lieber std::vector<T> verwenden.

Korrektur: Richtiges delete[] eingesetzt

 

[quarx]

Da Du size_t ansprichst: die STL-Container std::vector<T> (und das in diesem Thread vielleicht ebenfalls interessante std::valarray<T>) benutzen meistens auch size_t als Indextyp (genauer: std::vector<T>::size_type). Sollte ich vielleicht in meinem Beispiel oben updaten...

 

[Trapper]

Das Beispiel ist leider auch falsch.

Nun ja, das sieht Bjarne Stroustrup (der Erfinder von C++) in seinem Buch wohl etwas anders

 

[quarx]

Nun ja, das sieht Bjarne Stroustrup (der Erfinder von C++) in seinem Buch wohl etwas anders

Seitenangabe (mit Auflagennummer)?

 

[Trapper]

4. aktualisierte Auflage, deutsche Übersetzung, Seite 138.
Auszug:

void f(int n) {
  vector<int>* p = new vector<int>(n);
  int* q = new int[n];
...

Sieht mir beide Male sehr nach einem Datentyp int als Größenangabe aus.

 

[quarx]

4. aktualisierte Auflage, deutsche Übersetzung, Seite 138.
Auszug:

void f(int n) {
  vector<int>* p = new vector<int>(n);
  int* q = new int[n];
...

Sieht mir beide Male sehr nach einem Datentyp int als Größenangabe aus.

In der Tat, hast Recht. In meinem Stroustrup auch. Böser Schnitzer, Bjarne! :-D

 

[tjp]

Nun ja, das sieht Bjarne Stroustrup (der Erfinder von C++) in seinem Buch wohl etwas anders

Einige Teile des Buches sind nicht wirklich auf dem neusten Stand. Das Buch wurde zwar überarbeitet, aber vieles erinnert noch an die älteren Auflagen. Eine vollständige Neubearbeitung des Buches wäre nicht schlecht. Vielleicht wird das der Fall sein, wenn die nächste Version der ISO-Norm verabschiedet ist.