statisches Array mit >1000 Elementen initialisieren

[volkard]

Für so viele Elemente ist Heap doch supi. Wo ist dein Problem?

[SeppJ]

volkard schrieb:

Für so viele Elemente ist Heap doch supi. Wo ist dein Problem?

Ich hatte halt noch nie Probleme, dass mir der Stack übergelaufen ist. Bin zu verwöhnt...

edit: Und nochwas zum Thema
Wenn ich so schön runde, groß wirkende Zahlen, die fest im Quellcode eingebaut sind, sehe, dann beschleicht mich immer der Verdacht, dass da auf gut Glück Elemente reserviert werden, weil der Programmierer nicht weiß, wie es dynamisch geht und einfach mal "1000 Elemente sind genug für jeden, für alle Zeiten" sagt.

[volkard]

SeppJ schrieb:

Warum versuchst du überhaupt statische Sachen mit new zu allokieren? Das macht doch nur [...] unnötige Pointerdereferenzierungen zur Laufzeit.

Wirklich?

[Wandfliese]

Ich finde es einfach unästhetisch, dass statische Elemente erst allokiert werden müssen. Bei meiner Lösung ist auch nicht das Array sondern nur der Zeiger statisch. Diese Methode funktioniert zwar aber ist irgendwie total unbefriedigend. In C++ muss es doch einen eleganteren Weg geben.

[volkard]

Wandfliese schrieb:

Ich finde es einfach unästhetisch, dass statische Elemente erst allokiert werden müssen. Bei meiner Lösung ist auch nicht das Array sondern nur der Zeiger statisch. Diese Methode funktioniert zwar aber ist irgendwie total unbefriedigend. In C++ muss es doch einen eleganteren Weg geben.

Also ich finde das total klasse. Und ich weiß nicht, was nun daran unästetisch ist. Gibt es irgendwas, wo es zu langsam, zu speicherfressend, zu unübersichtluch, zu unsicher, zu wartungsunfreundlich oder sowas ist?
http://www.linuxhilfen.org/c/c_aufsteiger_rot.html

[Wandfliese]

SeppJ schrieb:

volkard schrieb:

Für so viele Elemente ist Heap doch supi. Wo ist dein Problem?

Ich hatte halt noch nie Probleme, dass mir der Stack übergelaufen ist. Bin zu verwöhnt...

edit: Und nochwas zum Thema
Wenn ich so schön runde, groß wirkende Zahlen, die fest im Quellcode eingebaut sind, sehe, dann beschleicht mich immer der Verdacht, dass da auf gut Glück Elemente reserviert werden, weil der Programmierer nicht weiß, wie es dynamisch geht und einfach mal "1000 Elemente sind genug für jeden, für alle Zeiten" sagt.

Das war wie gesagt nur ein Beispiel. Die Größe des Arrays soll zur Laufzeit nicht verändert werden. Das Array selbst soll vorberechnete Funktionswerte enthalten. Um genau zu sein Binomialkoeffzienten. Aber diese Zusatzinformation soll euch nicht dazu verleiten mit Algorithmen zur schnellen Berechnung von Binomialkoeffzienten anzudrehen. Das habe ich schon ausführlich getestet und das nachschlagen im Speicher war schneller

[volkard]

Wandfliese schrieb:

Das Array selbst soll vorberechnete Funktionswerte enthalten. Um genau zu sein Binomialkoeffzienten. Aber diese Zusatzinformation soll euch nicht dazu verleiten mit Algorithmen zur schnellen Berechnung von Binomialkoeffzienten anzudrehen.

Hätte aber gehelft, zu verstehen, was Du suchst.
Du willst also sagen wir mal ein zweidimensionales Array mit 1625x1625 Einträgen basteln, um fast alle Funktionswerte nachschauen zu können. Und das Erstellen soll nicht zur Laufzeit geschehen, weil die Sekunde Rechenzeit doof ist.
Tja, da kann ich Dich beruhigen: Zur Comilezeit gehts nicht nur mit C++.
Was gerne gemacht wird, ist ein Miniprogramm zu bauen, was die Datei tabelle.h schreibt und die inkludiertst Du in deinem Projekt.

[SeppJ]

volkard schrieb:

SeppJ schrieb:

Warum versuchst du überhaupt statische Sachen mit new zu allokieren? Das macht doch nur [...] unnötige Pointerdereferenzierungen zur Laufzeit.

Wirklich?

Ok, schlechtes Beispiel, da der Threadersteller ein Array angelegt hat - da macht es natürlich keinen Unterschied. Habe aber auch schon einmal sowas in der Art gesehen:

int *i const = new int;  // Da stand zwar kein const, aber i wurde so verwendet, als ob.

Der Programmierer, dachte, das wäre so "professioneller".

Entschuldigung, ist etwas weit weg vom Thema, dieser Beitrag.

[Gate]

Hmm, wenn du schon zur Compilezeit die Größe kennst wie wäre es denn dann mit:

static std::tr1::array<T,1000>
//oder c++0x
static std::array<T,1000>

Das Array könntest du dann doch im Kontruktor deiner Klasse befüllen.
Dazu biete std::array ja entsprechende Kontruktoren oder die fill()-Methode an.
Oder übersehe ich da was?

Gruß Gate

[Wandfliese]

volkard schrieb:

Wandfliese schrieb:

Ich finde es einfach unästhetisch, dass statische Elemente erst allokiert werden müssen. Bei meiner Lösung ist auch nicht das Array sondern nur der Zeiger statisch. Diese Methode funktioniert zwar aber ist irgendwie total unbefriedigend. In C++ muss es doch einen eleganteren Weg geben.

Also ich finde das total klasse. Und ich weiß nicht, was nun daran unästetisch ist. Gibt es irgendwas, wo es zu langsam, zu speicherfressend, zu unübersichtluch, zu unsicher, zu wartungsunfreundlich oder sowas ist?
http://www.linuxhilfen.org/c/c_aufsteiger_rot.html

Das hat alle meine Skrupel über Bord geworfen. Danke!
Anfangs wollte ich auch ein Perl-Skript zu schreiben, dass mir die Header-Datei erstellt aber diese wäre schnell mehrere MB groß geworden.

Auf die eine Sekunde Rechenzeit beim Programmstart kam es mir auch gar nicht an. Ich wollte nur wissen wie ich ein statisches Array initialisieren kann ohne alle Werte in der Header-Datei anzugeben.

Es ist zwar überaus anmaßend als Unregistrierter und Normalsterblicher vorzuschlagen basierend auf diesen Thread einen Eintrag im FAQ zu erstellen aber ich denke das ist eine oft wiederkehrende Frage in diesem Forum

Beste Grüße

Wandfliese

[lagalopex]

class C
{
public:
	C()
	{
		static int *a = 0;

		if (!a) {
			a = new int[1000];
			for (int i = 0; i < 1000; i++)
				a[i] = tolleFunktion(i);
		}
		array = a;
	}
// Destruktor und Reference-Counter fehlen halt.
	int operator[](int i) const
	{
		return array[i];
	}
private:
	int *array;
};

[Sebastian Pizer]

SeppJ schrieb:

Ich hatte halt noch nie Probleme, dass mir der Stack übergelaufen ist. Bin zu verwöhnt...

Der Stack kommt hier sowieso nicht in Frage. :p

Man sollte außerdem darauf achten, dass man die verschiedenen Bedeutungen von "static" nicht durcheinander bringt. Am besten "static" nicht auf Namensraum-Ebene verwenden, weil's dort die Bindung und nicht die Lebenszeit beeinflusst. Dafür gibt's dann ja anonyme Namensräume.

Gruß,
SP