typedef int *IntPointer;

Wenn ich jetzt folgendes schreibe:

int value = 3;
const IntPointer pointer = &value;

dann ist Zeile 2 identisch mit

int * const pointer = &value;

Das heißt: Der int-Wert würde sich zwar verändern lassen, aber der Zeiger nicht auf eine andere Adresse umbiegen.
Ich will mit dem selbstdefinierten Typ aber etwas deklarieren, das folgendem entspricht:

const int *pointer = &value;

Also: Der int-Wert ist unveränderlich, aber der Zeiger kann auf eine andere Adresse geändert werden.
Das hier soll gehen:

int otherValue = 20;
pointer = otherValue;

Aber das hier nicht:

*pointer = 5

Wie mache ich das mit dem selbstdefinierten Typ, ohne dass ich direkt mit [c]int *[/cp] arbeite?

Wie mache ich das mit dem selbstdefinierten Typ, ohne dass ich direkt mit int * arbeite?

Warum denn überhaupt? Wenn's sich noch um rohe Zeiger handelt, kann man es natürlich mit TypeTraits machen:

typedef int* intptr;
typedef remove_pointer<intptr>::type const* constintptr;

Einfacher und praktischer ist da schon ein zweiter typedef. Das ist eben so mit dem Typsystem. Ich behaupte sogar, dass es sich ganz normal ergibt und keine künstliche Schwäche von C++ ist. Alles andere ist mir höchst suspekt (zB die D Entwickler, die mit "transitivem const" Werbung machen. Was für ein Schwachsinn *kopfschüttel*). Wenn Du zwei Typen brauchst, definiere zwei Typen und versuche nicht zwei Typen (zB iterator und const_iterator) in einem zu vereinen. Das funzt einfach konzeptionell gar nicht.

typedef int *IntPointer;
typedef const int *ConstIntPointer;

dann steht ja das int zweimal da. Das heißt, würde int irgendwann mal zu unsigned char far werden, müsste ich das an zwei Stellen ändern. Gibt es also eine Möglichkeit, den ConstIntPointer direkt aus dem IntPointer zu deklarieren, ohne dort nochmal int hinschreiben zu müssen?

typedef int* IntPointer;
typedef const IntPointer ConstIntPointer;

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

Also.... FAIL!

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

Also.... FAIL!

Macht also der Compiler kein inplace?

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.

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.

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

Klick

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

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

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.

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.