edit: Ich könnte dem letztten ELemnt einen Schlusswert zuweisen, doch gibt es auch etwas anständiges?

Vielen Dank für eure Hilfe
lg, freakC++

Vielen Dank für deine schnelle Antwort!
lg, freakC++

template <unsigned int Size>
void function(int (&array)[Size]);

P.S. Wenn du produktive Dinge programmieren willst, zahlt sich die STL schnell aus, da sie sicher (Compilezeit- und Laufzeitprüfungen), hochoptimiert und bugfrei ist. Aber zur Übung kann es sinnvoll sein, zuerst ein grundlegendes Verständnis von Arrays und Zeigern zu haben.

Vielen Dank
lg, freakC++

Hallo zusammen,
gibt es eine Möglichkeit bei einer Arrayübergabe die Größe des Arrays herauszufinden? Ich will keine STL. Ich erinnere mich an einen ähnlichen Thread, doch ich finde ihn nicht mehr. Ich möchte nämich nicht immer "n" mitübergeben.

edit: Ich könnte dem letztten ELemnt einen Schlusswert zuweisen, doch gibt es auch etwas anständiges?

Vielen Dank für eure Hilfe
lg, freakC++

Deine Idee funktioniert nicht. Wie willst du das letzte Element rausfinden, wenn du nicht weißt, wie groß es überhaupt ist?

So würds gehen, aber na ja...

#include <iostream>

#define ARRAY_CREATE(t, n, s) t n[s + 1]; n[0] = (s);
#define ARRAY_SIZE(n) (*n)
#define ARRAY_FOREACH(n, i) for (int i = 1; i < ARRAY_SIZE(n) + 1; ++i)

void func(int *x);

int main()
{
	ARRAY_CREATE(int, x, 10);

	ARRAY_FOREACH(x, i)
	{
		x[i] = i;
	}

	func(x);
}

void func(int *x)
{
	int size = ARRAY_SIZE(x);

	ARRAY_FOREACH(x, i)
	{
		std::cout << i << std::endl;
	}
}

Im Übrigen gibts für statische Arrays den Wrapper std::tr1::array . Ich verwende bei eigenen Projekten nur noch den, Arrays sind mir zu unkomfortabel und riskant.

baut der compiler nicht irgendwie vor oder hinter das letzte element die größe, damit delete[] funktionieren kann? könnte man nicht das für sich nutzen?

Es ist auf jeden Fall undefiniert und somit bist du gleichweit, wie wenn dus nicht benutzt..

Ist nicht böse gemeint, aber die drei bisherigen Vorschläge, nur um sich nicht mit vorhandenen Standardmitteln wie der STL zu beschäftigen, halte ich für etwas fragwürdig. Zumal die hier gebrachten Codestücke in meinen Augen weder elegant noch besonders benutzerfreundlich oder sicher sind.

Sinnvoll ist es natürlich nicht, aber habe ich auch nie behauptet

Dann ist dein cleanup überflüssig, wenn du anständig mit Initialisierungslisten arbeitest.

Dazu kommt noch etwas prinzipielles. Anscheinend ist dein Array irgendwie mit einer festen Grösse, aber du machst es trotzdem dynamisch und implementierst einen Zuweiungsoperator. Wenn ich also z.B ein Element noch zusätzlich einfügen will zur Laufzeit, dann muss ich dafür ein Array erstellen, dass 1 Grösser ist und das meinem ursprünglichen zuweisen.. Nicht sehr konsequent.

Dann ist dein cleanup überflüssig, wenn du anständig mit Initialisierungslisten arbeitest.

Kannst du das mal beispielhaft demonstrieren? Mich hat allgemein geärgert, dass ich gewissermaßen Redundanzen drinne habe. So macht der Kopierkonstruktor zunächst exakt das selbe, wie der Konstruktor. Aber der wird ja dann nicht aufgerufen, also muss ich im Kopierkonstruktor erneut den Code schreiben...

Wäre cool, wenn du mir da an der Stelle etwas weiterhelfen könntest

Und wenn du dann den Zuweigungsoperator auch nocht mit z.B dem Copy/Swap Idiom beglückst, dann hast du da auch genügend Exceptionsicherheit, dass im Destruktor immernoch alles definiert ist. (Mit dem Idiom hast du dann auch die Redundanz weg).

template<typename T>
class Array
{
	public:
		Array(unsigned int Size)
		: MySize(size)
		, MyArr(new T[Size])
		{
		}

		Array(const Array& Origin)
		: MySize(Origin.MySize)
		, MyArr(new T[Origin.MySize])
		{
			std::copy(Origin.MyArr, Origin.MyArr + Origin.MySize, MyArr);
		}

		~Array()
		{
			delete[] MyArr;
		}

		Array& operator= (const Array& Origin)
		{
			Array Temp(Origin);
			swap(Temp);
			return *this;
		}

		void swap(Array& Other)
		{
			std::swap(MyArr, Other.MyArr);
			std::swap(MySize, Other.MySize);
		}

    private:
        unsigned int MySize;
        T*           MyArr;
};

Ausserdem würde ich eine operator[] -Überladung schreiben, die eine Const-Referenz (und keine Kopie) zurückgibt. Und den Speicher würde ich womöglich nicht gleich mit default-konstruierten Objekten initialisieren (kommt jedoch auf den Anwendungsfall an).

...

Nexus schrieb:

...

Das ist zwar auch interessant ... belegt aber im Prinzip nur, dass die Weigerung, std::vector (oder andere Elemente der StdLib) zu verwenden, fast immer dazu führt, dass man diese Dinge selbst nachprogrammiert - und das üblicherweise schlechter (aufwendiger, fehleranfälliger, unflexibler, langsamer, schlechter zu bedienen, .... ).

Merke: Die Jungs, die die StdLib schreiben, können schon was.

Gruß,

Simon2.

Das ist zwar auch interessant ... belegt aber im Prinzip nur, dass die Weigerung, std::vector (oder andere Elemente der StdLib) zu verwenden, fast immer dazu führt, dass man diese Dinge selbst nachprogrammiert - und das üblicherweise schlechter (aufwendiger, fehleranfälliger, unflexibler, langsamer, schlechter zu bedienen, .... ).

Ich habe meinen Code auch weniger mit dem Ziel geschrieben, diesen als Array-Klasse einzusetzen, sondern eher um zuzuzuzu eine exceptionsichere Implementierung aufzuzeigen, da er danach gefragt hat.

Ich kann mich deiner Meinung völlig anschliessen, das habe ich ja oben schon geschrieben:

Nexus schrieb:

[...] die drei bisherigen Vorschläge, nur um sich nicht mit vorhandenen Standardmitteln wie der STL zu beschäftigen, halte ich für etwas fragwürdig. Zumal die hier gebrachten Codestücke in meinen Augen weder elegant noch besonders benutzerfreundlich oder sicher sind.