typedef und pointer

[Bashar]

IMHO geht die Unsitte, erstmal pauschal alles mögliche zu typedefinieren, auf Pascal zurück, in der man mit (wie soll ichs nennen) zusammengesetzten oder qualifizierten Typen wie int* nicht arbeiten konnte, sondern erst einen neuen benannten Typ dafür definieren mußte. Viele sogenannte alte Hasen sind in Wirklichkeit Pascal-Programmierer, die seitdem nicht viel dazugelernt haben. In C und C++ sollte man das nicht machen.

[Walli]

Original erstellt von Bashar:
In C und C++ sollte man das nicht machen.

Manchmal macht es aber Sinn, z.B. wenn es zu unleserlich wird

typedef std::vector<std::string> string_vector

oder falls der Typ dahinter nicht interessiert...

typedef unsigned int size_type

Ist aber Ansichtssache.

[Shade Of Mine]

dazu fällt mir etwas aus dem CUJ ein:

typedef int* intptr;

void foo(const intptr p)
{
  *p=bar(); //erlaubt oder nicht? und warum?
}

[fisch]

ist doch ein int * const

[Bashar]

MastaH: Ich hab lange überlegt, ob ich das Wort "pauschal" in Fettdruck setzen soll, damit solche Kommentare überflüssig werden. War wohl umsonst

[Walli]

Original erstellt von Bashar:
MastaH: Ich hab lange überlegt, ob ich das Wort "pauschal" in Fettdruck setzen soll, damit solche Kommentare überflüssig werden. War wohl umsonst

Da hab ich wohl beim lesen am Ende des Beitrages nicht mehr gewusst was am Anfang stand... Jetzt wo du es sagst.

[Walli]

Original erstellt von Shade Of Mine:
***p=bar(); //erlaubt oder nicht? und warum?
**

Warum sollte das nicht erlaubt sein? Das p ist doch ein const int* wie fisch schon gesagt hat! Dann ist das doch eigentlich erlaubt.

[Shade Of Mine]

Original erstellt von MaSTaH:
Warum sollte das nicht erlaubt sein? Das p ist doch ein const int wie fisch schon gesagt hat! Dann ist das doch eigentlich erlaubt.*

also wenn p ein const int* wäre, dann wäre es nicht erlaubt.
aber tatsächlich ist p ein int* const wie fisch ja schon sagte.

deshalb ist es auch unmöglich einen typedef auf T* wie einen const T* zu behandeln -> man braucht ein zweites typedef auf const T*

deshalb: nie Zeiger typedefen - nur den typen dahinter (unter rücksichtnahme auf Bashars einwurf)

[Walli]

Original erstellt von Shade Of Mine:
also wenn p ein const int wäre, dann wäre es nicht erlaubt.
aber tatsächlich ist p ein int const wie fisch ja schon sagte.**

Äh, mein ich ja . *verdreh*

[ Dieser Beitrag wurde am 06.04.2003 um 20:00 Uhr von MaSTaH editiert. ]

[Daniel E.]

Original erstellt von Shade Of Mine:
deshalb: nie Zeiger typedefen

Doch, doch. Als Iterator macht man das im Trivialfall ständig. Ich behaupte viel lieber: nie Arrays typedefen.

[Shade Of Mine]

Original erstellt von Daniel E.:
Doch, doch. Als Iterator macht man das im Trivialfall ständig. Ich behaupte viel lieber: nie Arrays typedefen.

iterator ist IMHO etwas anderes weil es eine abstraktion ist.
ob hinter iterator jetzt T* oder class iterator steckt ist egal, es muss sowieso einen const_iterator geben.

aber ich bin sicher, du hast noch n anderes beispiel wo man einen T* typedeft, stimmts?

[Daniel E.]

Es geht doch bei typedef immer um Abstraktion im weitesten Sinne. Ich möchte einen Typen möglichst schnittstellentransparent austauschen können.

Beispiele für getypedefte Zeiger gibt's wie Sand am Meer: »typedef void (*fun)(int);«. Mehr fällt mir gerade mal nicht ein, ist aber auch nicht schlimm; schlimm fände ich es eher, wenn C++ mit einer Datenbank von paxisrelevanten Anwendungsfällen daherkäme und mir dann erzählen würde, getypedefte Zeiger sein blöd.

Mal ein Ansatz zu einer Stringbibliothek, die Nullen ('\0') enthalten darf (Vorsicht, kein wirkliches C++, sondern ein ungetestetes C):

typedef int       *string;
typedef int const *const_string;

/* ... */

size_t lenstr(const_string str)
{
    const_string begin;

    begin = str;
    while (*str >= 0) ++str;
    return str - begin;
}

Irgendwann stellt man dann schon fest, dass ein

typedef struct string {
    size_t len;
    unsigned char* string;
} string;

/* ... */

#define lenstr(s) ((s).len)

vielleicht doch schöner sein könnte... Um mal ein Beispiel zu nehmen, dass in der Realität nicht vorkommen wird und damit von Anwendungsfallerkenner zuverlässig eliminiert werden kann.