Bisher habe ich mir nach folgendem Schema beholfen:

/*
 * C.h
 */

#ifndef IARRAY_H_
#define IARRAY_H_

class C
{
public:
	C();
	virtual ~C();
	const static int *array;
private:
	static const int *initArray();
};

#endif /* C_H_ */

/*
 * C.cpp
 */

#include "C.h"

C::C()
{
	// TODO Auto-generated constructor stub

}

C::~C()
{
	// TODO Auto-generated destructor stub
}

const int* C::initArray(){
	int* tmp = new int[1000];
	for (int i=0;i<1000;i++){
		tmp[i] = tolleFunktion(i);
	}
	return tmp;
}

const int* C::array = initArray();

Gibt es da keine elegantere Lösung? Mir missfällt der Gedanke, dass dieses statische Array auf dem Heap liegt. Da der Datentyp kompliziert und das Array beliebig groß sein kann/will ich es nicht auf die übliche Weise im Quellcode initialisieren.

Viele Grüße

Wandfliese

Mir missfällt der Gedanke, dass dieses statische Array auf dem Heap liegt

Wo soll es dann liegen?!

Wo ist genau dein Problem?

?

edit: Ahh, ich sehe, du willst es so zurückgeben. Merkwürdige Methode.

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.

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

Wirklich?

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

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

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 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.

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 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

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