3. typedef und pointer

typedef und pointer

  • G

    du schreibst ja auch nicht

    int myintptr = new int;
    0
  • W

    Korrekt müßtest du schreiben:

    intptr myint = new int;

    Aber das hier ist IMHO klarer (und kürzer 😉 )

    int* myint = new int;
    0
  • B

    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.

    0
  • W

    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.

    😉

    0
  • S

    dazu fällt mir etwas aus dem CUJ ein:

    typedef int* intptr;

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

    ist doch ein int * const

    0
  • B

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

    0
  • W

    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. 🙄 😉

    0
  • W

    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.

    0
  • S

    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)

    0
  • W

    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. ]

    0
  • D

    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.

    0
  • S

    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?

    0
  • D

    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.

    0
Anmelden zum Antworten