void Parameter speichern (Listen)

[DirkB]

typedef struct
{
    void *pData; // Der Debugger sieht nur den void-Pointer
    struct tCnct *next;
    struct tCnct *prev;
}tCnct;/* Datentyp fuer Connector */

woher soll der Debugger dann wissen, welchen Datentyp du da abspeicherts.
Du kannst das ja erstmal durch einen tData *pData; ersetzen.
Dann musst du aber tData vor tCnct deklarieren.

[Wutz]

Die "Design"vorgabe des 2. Parameters als void* ist Naivunsinn deines Lehrers ebenso wie verkettete Listen per se akademische Luftnummern sind.
Solches "Design" nötigt dich zu völlig überflüssigen Zeigercasts. Du schaffst damit unnötige Abhängigkeiten, die leicht zu Fehlern und Unübersichtlichkeit führen.

[M^M]

Wutz schrieb:

... ebenso wie verkettete Listen per se akademische Luftnummern sind.

Das habe ich schon öfter hier im Forum gelesen. Warum eigentlich? Werden verkettete Listen in der Praxis nicht verwendet? Was nimmt man statt dessen?

Gruß
M

[Nathan]

M^M schrieb:

Wutz schrieb:

... ebenso wie verkettete Listen per se akademische Luftnummern sind.

Das habe ich schon öfter hier im Forum gelesen. Warum eigentlich? Werden verkettete Listen in der Praxis nicht verwendet? Was nimmt man statt dessen?

Gruß
M

Verkette Listen sind sehr schlecht, wenn man regelmäßig auf die Elemente zugreifen will. Sie sind zwar schnell, was das Einfügen angeht, aber der langsame Zugriff ist ein riesiger Nachteil.
Eine Alternative wäre einfach via malloc ein Array anzufordern, sagen wir, was 10 Elemente fasst. Sind 10 Elementen drin, wird ein neues Array angefordert, sagen wir, was 20 Elemente fasst, die Elemente hinüberkopiert und das alte Array freigegeben. Ähnlich bei einer erneuten Vergrößerung. So ein Container bietet konstante Zugriffszeit auf jedes Element und das Anfügen von Elementen am Ende ist auch schnell, so lange kein neues Array angefordert werden muss.

[Harbor]

Nathan schrieb:

Eine Alternative wäre einfach via malloc ein Array anzufordern, sagen wir, was 10 Elemente fasst. Sind 10 Elementen drin, wird ein neues Array angefordert, sagen wir, was 20 Elemente fasst, die Elemente hinüberkopiert und das alte Array freigegeben. Ähnlich bei einer erneuten Vergrößerung. So ein Container bietet konstante Zugriffszeit auf jedes Element und das Anfügen von Elementen am Ende ist auch schnell, so lange kein neues Array angefordert werden muss.

Wäre es da nicht noch sinnvoller, den Array mit realloc zu erweitern anstatt einen neuen zu erstellen und die Daten rüber zu kopieren?

[M^M]

Nathan schrieb:

Verkette Listen sind sehr schlecht, wenn man regelmäßig auf die Elemente zugreifen will. Sie sind zwar schnell, was das Einfügen angeht, aber der langsame Zugriff ist ein riesiger Nachteil.
Eine Alternative wäre einfach via malloc ein Array anzufordern, sagen wir, was 10 Elemente fasst. Sind 10 Elementen drin, wird ein neues Array angefordert, sagen wir, was 20 Elemente fasst, die Elemente hinüberkopiert und das alte Array freigegeben. Ähnlich bei einer erneuten Vergrößerung. So ein Container bietet konstante Zugriffszeit auf jedes Element und das Anfügen von Elementen am Ende ist auch schnell, so lange kein neues Array angefordert werden muss.

Ok, das verstehe ich ja. Aber was ist, wenn ich ein Element nicht am Ende, sondern irgendwo mittendrin einfügen möchte? Dann bin ich die ganze Zeit nur am rumkopieren.
Oder wenn ein einzelnes Element sehr groß ist und Speicher eine Rolle spielt?

Mir kommt es hier immer so vor, als währen verkettete Listen das Pohlsche Rad der Programmierung, oder (noch schlimmer) ein Instrument inkompetenter Lehrer, mit dem sie ihre Schüler foltern...

Gruß
M

[Nathan]

Die C++ Standardbibliothek bietet diverse Container:
http://en.cppreference.com/w/cpp/container
An den Beschreibungen sieht man schön die Laufzeitkomplexitäten.
Und wenn man wirklich einen großen Container hat, an dem viel in der Mitte einfügt und die Elemente nur nacheinander durchlaufen muss, dann nimmt man natürlich auch eine Liste.

[M^M]

Nathan schrieb:

Und wenn man wirklich einen großen Container hat, an dem viel in der Mitte einfügt und die Elemente nur nacheinander durchlaufen muss, dann nimmt man natürlich auch eine Liste.

Danke, also doch keine akademische Luftnummer

Gruß
M

[elixirm]

Harbor schrieb:

Wäre es da nicht noch sinnvoller, den Array mit realloc zu erweitern anstatt einen neuen zu erstellen und die Daten rüber zu kopieren?

Ja, natürlich. Wenn realloc den Speicherblock allerdings nicht vergrößern kann, allokiert es auch einfach einen neuen und kopiert die Daten rüber. In der Regel erhöht es dabei die Größe um mehr als angefordert, damit nachfolgende Aufrufe ohne Kopieren durchgeführt werden können. Also in etwa das was Nathan beschrieben hat.

[SeppJ]

M^M schrieb:

Danke, also doch keine akademische Luftnummer

Ich fürchte, in den meisten Fällen doch. Denn der Fall, dass man oft (oder überhaupt) etwas in der Mitte eines Containers einfügen möchte ist praktisch eben extrem selten. Ich programmiere eine ganze Weile und es ist, wenn ich mich recht erinnere, mir noch nie vorgekommen, dass eine verkettete Liste die beste Wahl war. Wenn man nämlich etwas in der Mitte einfügen will, dann weil der Container nach irgendeinem Kriterium sortiert ist. In dem Fall gibt es aber wesentlich bessere Datenstrukturen.