void Array::Copy(const void* sourceArray, void* destinationArray, int length)
{
	char* dest = static_cast<char*>(destinationArray);
	const char* src = static_cast<const char*>(sourceArray);
	while (length--)
	{
		*dest++ = *src++;
	}
}

Nun verwende ich diese in meiner List-Klasse folgendermaßen:

template <class T>
List<T>::List(const List& list) :
	capacity(list.capacity),
	items(new T[list.capacity]),
	size(list.size)
{
	Array::Copy(list.items, items, capacity * (sizeof(items) / sizeof(items[0])));
}

Ist der Aufruf von Array::Copy so nun richtig? Bei der sizeof Geschichte bin ich mir unsicher.

Und wäre ein Aufruf von

Array::Copy(list.items, items, size * (sizeof(items) / sizeof(items[0])));

auch legitim? Die reservierten Stellen mitzukopieren ist ja nicht gerade sinnvoll.

Was soll das? Wieso experimentierst du nicht gleich mit echtem C++ und verwendest die bereits vorhandenen Mittel?

Aus Lernzwecken.

Die reservierten Stellen mitzukopieren ist ja nicht gerade sinnvoll.

Nein, absolut nicht.

Array::Copy(list.items, items, size * (sizeof(items) / sizeof(items[0])));

Ich nehme mal an, items ist ein Zeiger.
Dann einfach

Array::Copy(list.items, items, size * sizeof(*items));

Das Äquivalent zu deiner Copy-Funktion wäre übrigens std::memcpy .

Wird nur für echte Arrays verwendet.
Der Trick ist einfach:

When applied to an array, the result is the total number of bytes in the array.
This implies that the size of an array of n elements is n times the size of an element.

Dividiert man also das Ergebnis mit der Größe eines Array-Elements, hat man die Länge.
Das Funktioniert aber nur, falls, in diesem Beispiel items , auch wirklich als ein Array deklariert wurde.

Was soll das? Wieso experimentierst du nicht gleich mit echtem C++ und verwendest die bereits vorhandenen Mittel? Was du machst, ist C#/Java in C++, das will niemand.

Was erinnert dich hier bitte an C#/Java?

Was erinnert dich hier bitte an C#/Java?

Die Array -Klasse, um array-basierte Funktionen zu gruppieren.
Der Name List , um dynamische Arrays kennzuzeichnen.

Ich nehme mal an, items ist ein Zeiger.
Dann einfach

Array::Copy(list.items, items, size * sizeof(*items));

Jupp, ist ein Zeiger. Das hatte ich ursprünglich so verwendet aber sporadisch Programmabstürze mit dieser Funktion. Nehme ich stattdessen

for (int i = 0; i < size; ++i)
{
	items[i] = list.items[i];
}

im Copy-Constructor funktioniert alles prima. Sehr merkwürdig.

Ethon schrieb:

Was erinnert dich hier bitte an C#/Java?

Die Array -Klasse, um array-basierte Funktionen zu gruppieren.
Der Name List , um dynamische Arrays kennzuzeichnen.

Und deswegen ist es kein C++ oder was ;). Sorry aber der Styling-Code der Standard-Library ist ein absolutes Grauen, weshalb ich mich gerne an C# halte.

So oder so solltest du dir aber mal std::vector anschauen. Den scheinst du da gerade nachbauen zu versuchen.

Der äußere Schein trügt Mich erinnert das ganze viel eher an schlechtes C.

Ach bitte dann schau dir mal die Implementiering von std::vector an. Das funktioniert unter der Haupe genau so. Weis gar nicht was ihr Standard-Library Fanatiker euch immer einbildet. Die Standard-Library kann - jetzt bitte nicht traurig sein - leider auch nicht zaubern.

Sorry aber der Styling-Code der Standard-Library ist ein absolutes Grauen, weshalb ich mich gerne an C# halte.

Wenn du versuchst, C#s Standardbibliothek in C++ nachzubauen, wirst du dich auf große Schmerzen einstellen müssen. Eine ganze Reihe Dinge funktionieren in C++ ganz anders -- wenn du von einer gemanagten Sprache kommst, wird dir insbesondere die Umstellung auf Wertesemantik Probleme bereiten, was sich schon an der Zeile

items(new T[list.capacity]),

in der ctor-init-list deines Kopierkonstruktors deutlich zeigt.

Ach bitte dann schau dir mal die Implementiering von std::vector an. Das funktioniert unter der Haupe genau so.

Nope, hast du dir sie einmal angesehen? Bei denen ist copy ein Template und nicht einfach ein memcopy.

Nicht alle Typen sind einfach mit memcpy (oder Äquivalenten) kopierbar. Wenn jetzt jemand Liststd::string benutzt, fliegt dir das im hohen Bogen auseinander. Die Zuweisungsschleife benutzt ggf. den Zuweisungsoperator, der das richtige machen sollte. (Wenn er es nicht tut, ist das ein Fehler im Werttyp, nicht in der Liste)

So oder so solltest du dir aber mal std::vector anschauen. Den scheinst du da gerade nachbauen zu versuchen.

Warum fliegt das auseinander? Kannst du das ein wenig genauer erklären?

template <typename T>
class autp_ptr {
  T *p;
public:
  auto_ptr(T *p) : p(p) {}
  auto_ptr(auto_ptr& o) : p(o.p) { o.p = 0; }
 ~auto_ptr() { delete p; }
};

Längere Antwort: Wenn Objekte deiner Klasse Verweise enthalten (Zeiger oder Referenzen), dann wird bei einer flachen Kopie mit memcpy der Verweis einfach mitkopiert, nicht aber das, worauf er verweist. Dadurch geht das, worauf das überschriebene Objekt verweist, verloren, und zwei Objekte verweisen nachher auf das selbe. Das hat dann (üblicherweise; garantiert ist so was dann nicht mehr) zur Folge, dass (jetzt im Fall zweier std::strings) Änderungen am Inhalt des einen Strings auch den anderen betreffen (können), dass Änderungen am einen String, die diesen dazu veranlassen, seinen Inhalt im Speicher zu verlegen, den anderen ins Nirvana zeigen lassen, und dass bei der Zerstörung mindestens eines der beiden Objekte der Heap zerschossen wird.

std::copy( list.items, list.items + size, items );

Kurze, korrekte, aber wenig hilfreiche Antwort: Das Kopieren von Nicht-POD-Typen erzeugt undefiniertes Verhalten.

TriviallyCopyable ist das Wort, das du suchst. Man darf auch manche Nicht-PODs mit memcpy kopieren.

Sone schrieb:

Hui, ich hab' auf weiteres nicht geachtet! Wusst' nicht, dass er ein Template hat, hab ich glatt übersehen. Natürlich ist das Doofsinn, was da passiert.

std::copy( list.items, list.items + size, items );

Inwiefern ist das weniger Doofsinn? Damit hast du knallhart ein Memory-Leak in die Liste von Enumerator eingebaut.
Werkzeug der Wahl wäre Speicher allozieren ohne initialisieren und dann mit uninitialized_copy drüberrauschen.
Die Standardbibliothek kann zwar nicht zaubern, aber ein korrektes uninitialized_copy nicht TriviallyImplementable.

Kurze, korrekte, aber wenig hilfreiche Antwort: Das Kopieren von Nicht-POD-Typen erzeugt undefiniertes Verhalten. Der Compiler darf dann Code erzeugen, der deinen Computer explodieren lässt.

Etwas korrekter: das Kopieren (per memcpy & co.) an sich ist unproblematisch, erzeugt aber keine Objekte des Ursprungstyps. Ein Zugriff auf diese Kopien mit dem Ursprungstyp wird also für gewöhnlich die Aliasingregeln (3.10/10) oder die Regeln für den Umgang mit nicht initialisiertem Speicher (3.8) verletzen.

seldon schrieb:

Kurze, korrekte, aber wenig hilfreiche Antwort: Das Kopieren von Nicht-POD-Typen erzeugt undefiniertes Verhalten.

TriviallyCopyable ist das Wort, das du suchst. Man darf auch manche Nicht-PODs mit memcpy kopieren.

Sone schrieb:

Hui, ich hab' auf weiteres nicht geachtet! Wusst' nicht, dass er ein Template hat, hab ich glatt übersehen. Natürlich ist das Doofsinn, was da passiert.

std::copy( list.items, list.items + size, items );

Inwiefern ist das weniger Doofsinn? Damit hast du knallhart ein Memory-Leak in die Liste von Enumerator eingebaut.

Ähm, nein? Wie zum Teufel kommst du darauf?

template <class T> 
List<T>::List(const List& list) : 
    capacity(list.capacity), 
    items(new T[list.capacity]), 
    size(list.size) 
{
     std::copy( list.items, list.items + size, items ); 
}

experimentator schrieb:

seldon schrieb:

Kurze, korrekte, aber wenig hilfreiche Antwort: Das Kopieren von Nicht-POD-Typen erzeugt undefiniertes Verhalten.

TriviallyCopyable ist das Wort, das du suchst. Man darf auch manche Nicht-PODs mit memcpy kopieren.

Sone schrieb:

Hui, ich hab' auf weiteres nicht geachtet! Wusst' nicht, dass er ein Template hat, hab ich glatt übersehen. Natürlich ist das Doofsinn, was da passiert.

std::copy( list.items, list.items + size, items );

Inwiefern ist das weniger Doofsinn? Damit hast du knallhart ein Memory-Leak in die Liste von Enumerator eingebaut.

Ähm, nein? Wie zum Teufel kommst du darauf?

template <class T> 
List<T>::List(const List& list) : 
    capacity(list.capacity), 
    items(new T[list.capacity]), 
    size(list.size) 
{
     std::copy( list.items, list.items + size, items ); 
}

Dann erkläre mir doch bitte was mit

int instances;
struct doofsinn {
  doofsinn() { ++instances; }
 ~doofsinn() { --instances; }
  doofsinn& operator=(doofsinn const&) {
    static int doofsinn_counter = 0;
    if (++doofsinn_counter % 5 == 0)
      throw "Sone";
  }
};

passiert (http://ideone.com/Y5C1KA).

template <class T> 
List<T>::List(const List& list) : 
    capacity(list.capacity), 
    items(new T[list.capacity]), 
    size(list.size)
{ 
    try
    {
        std::copy( list.items, list.items + size, items ); 
    }
    catch(...)
    {
        delete [] items;
        throw;
    }
}

Sorry aber der Styling-Code der Standard-Library ist ein absolutes Grauen, weshalb ich mich gerne an C# halte.

So eine Aussage kommt meist von Leuten, die sich noch nicht genauer damit befasst haben

Schau dir die STL mal im Detail an. Durch die Trennung von Containern, Algorithmen und Iteratoren ist enorme Flexibilität möglich. Zum Beispiel basiert alles auf Templates und hat dadurch nicht die Nachteile tiefer Vererbungshierarchien. Wenn dich das interessiert, könntest du auch mal einen Blick auf "Notes on Programming" von Alexander Stepanov werfen -- das ist die Person, welche die STL entworfen hat -- wohl bis heute einer der bedeutendsten Beiträge zu C++.

Davon abgesehen ist es unsinnig, für produktive Programmierung das Rad neu zu erfinden. Du wirst niemals an die Qualität heutiger STL-Implementierung herankommen. Das betrifft Kriterien wie Performance, Fehlerfreiheit, Debug-Unterstützung, API-Design, Integration in den Rest der Standardbibliothek. Als Übung kann man sich sowas antun, aber sobald du dies später wirklich brauchst, benutze bitte existierende Mittel. Und löse dich von C#, C++ ist eine komplett andere Sprache mit anderen Paradigmen, in der Probleme anders angegangen werden.

Es gibt nichts Schlimmeres als wenn Leute dauernd Standardmechanismen selbst schreiben, "weil ihre Implementierung ja so viel schneller und besser ist". Diese Unsitte sieht man in vielen in die Jahre gekommenen C++-Biblitoheken. Die Konsequenz ist, dass man bei deren Benutzung ständig Inkompatibilitäten hat und gezwungen ist, selbst ihre Datenstrukturen zu verwenden, die meist schlechter entwickelt sind als Standardmechanismen.

Diese Unsitte sieht man in vielen in die Jahre gekommenen C++-Biblitoheken.

Gehört Qt dazu? Ich meine, ok, die haben schon das ein oder andere angepasst, aber QList, QString, QMap, QSet...