Möglichkeit 1:

const int *p

Hierbei kann zwar die Adresse, auf die der Zeiger zeigt, geändert werden, aber nicht der Wert dieser Adresse.

Möglichkeit 2:

int * const p

Diesmal kann man zwar den Wert, auf den referenziert wird, ändern, aber den Zeiger nicht auf eine andere Adresse "umbiegen".

Nun meine Frage: Wenn ich einen vordefinierten Typ:

typedef int * PINT

und in einer Funktion den Parameter

const PINT p

habe, dann wird das automatisch als Möglichkeit 2 erkannt. Da das aber in den meisten Fällen nicht wünschenswert ist, würde ich gern wissen, wie ich das in so einem Fall schreiben muß, damit es sich um Möglichkeit 1 handelt.

sonst geht nix.

denn PINT ist n typ und const PINT ist ein konstanter typ und ein konstanter zeiger ist halt ein zeiger den du nicht veraendern kannst (den pointee (als das worauf gezeigt wird) hat mit dem zeiger ansich ja nix zu tun).

typedef const PINT PCTINT;

noch

typedef PINT const PCTINT;

Wenn der Parameter dann

PCTINT p

ist, tritt das gleiche Verhalten auf.
Mein konkretes Problem ist übrigens, wer es wissen will, daß ich in Windows eine Klasse habe, die mit Handles (HBITMAP, HDC, HWND, HINSTANCE) arbeitet. Und da Handles ja Zeiger sind (void *), würde ich das eben gern so machen, daß, wann immer sie als Parameter übernommen werden und nicht geändert werden sollen, der Wert, auf den sie zeigen, konstant ist.
Irgendeine Möglichkeit muß es da doch geben, sonst wäre das echt ein fehlendes Feature.

Mein konkretes Problem ist übrigens, wer es wissen will, daß ich in Windows eine Klasse habe, die mit Handles (HBITMAP, HDC, HWND, HINSTANCE) arbeitet. Und da Handles ja Zeiger sind (void *), würde ich das eben gern so machen, daß, wann immer sie als Parameter übernommen werden und nicht geändert werden sollen, der Wert, auf den sie zeigen, konstant ist.
Irgendeine Möglichkeit muß es da doch geben, sonst wäre das echt ein fehlendes Feature.

dass es ein void* ist, braucht eigentlich irgendwie nicht zu interessieren: denn der typ ist HBITMAP...

man kann den inhalt des void* ja auch nicht so einfach aendern dazu muss man sowieso casten und dann geht das const sowieso weg (sind ja in der winapi alles c casts... die machen n const aus "versehen" weg).

also passt schon. nenn es const HBITMAP und gut ist

typedef const boost::remove_pointer<pointer2T>::type* pointer2constT;

Aber es geht ja hier darum, daß der Zeigertyp von außerhalb bereits vorgegeben ist.

Genau darum geht es ja. Der Typ ist nunmal vorgegeben, also kannst du nur noch den Zeigertyp beeinflussen

const HBITMAP wäre ja wieder: Ich kann den Wert ändern, aber die Adresse nicht. In diesem Fall kann ich das const ja gleich weglassen, denn ob die Funktion intern den Zeiger verbiegen darf, ist nach außen hin sowieso unerheblich. Aber gerade das wollte ich nicht, sondern ich möchte es so machen, daß ein Außenstehender sieht, ob die Funktion intern den Wert ändern kann. (So wie in strcpy (char *, const char *): Da sieht man sofort: Der zweite Parameter wird nicht verändert. Und so wird das, soweit ich weiß, eigentlich fast überall geschrieben, wo Werte als Zeiger übergeben werden.)

Und nochmal zu der Sache mit dem selbst Erstellen von Typen: Wir haben jetzt natürlich den Vorteil, daß ein void * alles sein kann, und man das ganze somit direkt codieren könnte. Aber meiner Meinung ist das nur eine Verdrängung, aber keine Lösung des Problems. Wie gesagt, man stelle sich vor, jemand stellt den Typ PZAHL zur Verfügung. Die Zahl wird nie direkt verändert oder ausgegeben, das machen alles Funktionen, die sie als Parameter entgegennehmen. (Ja, ich weiß, heutzutage würde man dann eine Klasse schreiben, deren Methoden diese Funktionen wären, aber nehmen wir es nur mal an.) Und nun schreibe ich:

typedef const int *PCTZAHL

. Spätestens, wenn der Programmierer für PZAHL eine Struktur nimmt, dürfte ich Probleme bekommen.

Genau darum geht es ja. Der Typ ist nunmal vorgegeben, also kannst du nur noch den Zeigertyp beeinflussen

Aber ich kann bei einem P_NICHT_NAEHER_ERKLAERTER_TYP keinen PCT_NICHT_NAEHER_ERKLAERTER_TYP deklarieren, der vom Ursprungstyp ausgeht, sondern muß den direkt auf P_NICHT_NAEHER_ERKLAERTER_TYP basieren lassen.

was HBITMAP jetzt intern ist, hat dich nicht zu interessieren, das ist abstraktion.

es koennte zB morgen ein unsigned int sein und am tag darauf ein char* und am naechsten tag ne klasse...

An camper:
Soweit ich weiß, ist Boost (noch) kein Standard und ich benutze nicht so gerne Funktions- oder Klassensammlungen von außerhalb. Gibt es da ein Pendant in Standard-C++ (oder zumindest in der WinAPI), denn von so etwas habe ich noch nie gehört.

das ist witzig, schließlich hat die WinAPI weitaus weniger mit standard C++ zu tun als boost
aber wie gesagt, das ganze kannst du dir auch selbst basteln:

template<typename T>struct remove_pointer { typedef T type; };
template<typename T>struct remove_pointer<T*> { typedef T type; };

was HBITMAP jetzt intern ist, hat dich nicht zu interessieren, das ist abstraktion.
es koennte zB morgen ein unsigned int sein und am tag darauf ein char* und am naechsten tag ne klasse...

Deswegen sag ich ja, daß die Variante von Neku

typedef int* PINT; 
typedef const int* CPINT;

nicht geht, da sich das zweite typedef auf den neu erzeugten Typ und nicht auf den Originaltyp beziehen muß.

das ist witzig, schließlich hat die WinAPI weitaus weniger mit standard C++ zu tun als boost

Wie gesagt, meine Begründung war ja:

ich benutze nicht so gerne Funktions- oder Klassensammlungen von außerhalb

Die WinAPI ist zwar noch weitaus weniger Standard, aber sie ist zumindest in Visual C++ enthalten und ich muß nicht extra irgendwelche zusätzlichen Header und Libraries installieren. Aber das ist sowieso egal, denn von der WinAPI wird es für dieses Problem wohl keine Lösung geben. Deine Variante will ich mir mal ansehen, aber ich finde es noch immer ein Versäumnis, daß die Leute vom Standard-Kommitee offensichtlich keine Möglichkeit eingebaut haben, einen const typ * zu erzeugen, wenn typ * bereits als PTYP definiert ist.

Genau darum geht es ja. Der Typ ist nunmal vorgegeben, also kannst du nur noch den Zeigertyp beeinflussen

Aber ich kann bei einem P_NICHT_NAEHER_ERKLAERTER_TYP keinen PCT_NICHT_NAEHER_ERKLAERTER_TYP deklarieren, der vom Ursprungstyp ausgeht, sondern muß den direkt auf P_NICHT_NAEHER_ERKLAERTER_TYP basieren lassen.

Bei dir ist es aber so:

EIN_TYP << int
P_EIN_TYP << int*
PC_EIN_TYP << hier möchtest du EIN_TYP (int) durch ein const erweitern
und wenn ich mich nicht irre ist dies nicht möglich

Bei makros (MS Praxis) wuerde es dem Standard-Orientierten C++ Anwender die Schuhe ausziehen

Den Typen in nen Wrapper kapseln und das ganze als Template waer unter c++ ne saubere Loesung, die scheint der Fragesteller aus diversen gruenden aber hartnaekisch zu ignorieren ^^

Keine Ahnung was dann ueber bleibt.

Ciao ...