const bei typedefs auf Zeigern

EOutOfResources

typedef int* IntPointer;
typedef const IntPointer ConstIntPointer;

krümelkacker

EOutOfResources schrieb:

typedef int* IntPointer;
typedef const IntPointer ConstIntPointer;

Das wäre ein konstanter int-Zeiger
und kein const-int Zeiger.

Also.... FAIL!

EOutOfResources

krümelkacker schrieb:

Das wäre ein konstanter int-Zeiger
und kein const-int Zeiger.

Also.... FAIL!

Macht also der Compiler kein inplace?

wxSkip

Lies das:
http://www.c-plusplus.net/forum/p2003525#2003525

Nexus

krümelkacker schrieb:

Alles andere ist mir höchst suspekt (zB die D Entwickler, die mit "transitivem const" Werbung machen. Was für ein Schwachsinn *kopfschüttel*).

Hab ich soeben kurz angeschaut, ich kann mich dir nur anschliessen. D ist mir ohnehin recht suspekt. Ist halt auch eine Sprache, die alles "besser" als C++ macht

EOutOfResources schrieb:

Macht also der Compiler kein inplace?

Wäre ziemlich bescheuert, wenn er das tun würde. Wenn ich const T schreibe, will ich ein konstantes T und nicht etwa ein veränderbares T , das auf ein konstantes Objekt zeigt. Ist übrigens auch ein Grund, wieso man für Typdefinitionen keine Makros nimmt.

Denkbar:

typedef int              ValueType;
typedef ValueType       *ValuePointer;
typedef ValueType const *ValueConstPointer;

Da die typedefs allerdings aller Wahrscheinlichkeit nach direkt untereinander im selben Header stehen werden, hielte ich es auch nicht für unglaublich kritisch, wenn da zweimal int stünde.

Ach ja, D. Das uneheliche Kind von Python und C++ und genau das, was die Welt nicht gebraucht hat. Wusstet ihr, dass derzeitige D-Implementationen ihre Speicherverwaltung einer Heuristik anvertrauen? Ich finde diese Sprache echt komisch.

EOutOfResources

seldon schrieb:

Wusstet ihr, dass derzeitige D-Implementationen ihre Speicherverwaltung einer Heuristik anvertrauen?

Klick

dooooomi

seldon schrieb:

Wusstet ihr, dass derzeitige D-Implementationen ihre Speicherverwaltung einer Heuristik anvertrauen?

Faszinierend... Hast du zufällig einen guten Link zu dem Thema?

otze

seldon schrieb:

Wusstet ihr, dass derzeitige D-Implementationen ihre Speicherverwaltung einer Heuristik anvertrauen?

Gerüchteweise gibt es eine andere enorm erfolgreiche Sprache, die das genau so macht.

Die Sprache heißt Java.

Java hat deutlich komplexere Zeiger als wir es von C und C++ gewohnt sind, und jedes Objekt schleppt Informationen für den Garbage-Collector mit. Das erlaubt die Implementation eines präzisen Garbage-Collectors im Gegensatz zu einem heuristischen.

In D ist das nicht der Fall, und das ist ein echtes Problem für eine Sprache, die sich auf ihren GC verlässt. Hier wird der Stack nach Werten durchsucht, die ein Zeiger sein könnten und Deallokation unter Umständen ewig verzögert. Das Szenario ist auch auf Plattformen mit breiten Zeigern weit weniger unwahrscheinlich, als man zunächst vermuten könnte - nehmt beispielsweise

void foo() {
  char *s = new char[1000000]; // Ich verlasse mich auf Garbage-Collection
  int data[100];
}

void bar() {
  int data[100]; // Hiervon werden in der Praxis höchstens die ersten 80 benutzt
  while(true) {
    do_server_stuff();
  }
}

int main() {
  foo();
  bar();
}

...und da bei einem nach unten wachsenden Stack der ehemalige Speicherort von s in foo am üblicherweise unbenutzten Ende von data in bar liegt, kriege ich das Megabyte Speicher niemals wieder.

Ganz zu schweigen von komplexeren Adressierungsmethoden wie XOR-verlinkten Listen.

Jetzt ist Javas Garbage-Collection nicht frei von Problemen - an die genannte XOR-verlinkte Liste beispielsweise ist in Java gar nicht zu denken - aber um eine Heuristik handelt es sich dabei nicht. Sonst wäre Java wohl auch nicht so erfolgreich.