3. Thema: "Naming Conventions" (mein Tip!)

Thema: "Naming Conventions" (mein Tip!)

  • V

    1310-Logik schrieb:

    warum nicht gleich so?

    //ctor
Foo(unsigned int size_):
size(size_)
{
}

    Den Paramter braucht man ja weniger oft als die Membervariable.

    das mach ich seit jahren so. den bedarf dafür gibts übrigend *nur* nur bei konstruktoren, also ausreichend selten.

    0
  • O

    rapso schrieb:

    klar ist ne möglichkeit, die lösung an sich find ich auch ok. ich bin aber gegen dieses this->, weil es n00bs, die sich mal mit so nem code auseinander setzen auf die idee bringt, man sollte immer this-> für member verwenden und daraus entsteht dann ein recht grausiger code.

    dann muss man diesen n00bs erklären, dass man this-> nur in ganz wenigen spezialfällen benutzt, und auch nur wnen man weis, was man tut!

    ich frage mich aber wie du dann accessorfunktionen schreibst, sowas wie:

    class CFoo
{
void* data;
...

public:

    void* data(){return this->data;}
}

    dürfte doch nicht compilieren? mir würden da spontan nur set/get funktionen aus c zeiten einfallen 😮
    klär mich auf 🙂

    ich benutze eigentlich auch noch die guten alten set/get funktionen 😉
    sie sagen genug aus, und man kann wenig mit falsch machen. Im moment überleg ich mir aber, davon weg zu gehen und properties zu nutzen.

    0
  • R

    @rapso
    Eure Namenskonventionen sehen mir eher danach aus, als wollte man eher die Fehler eines uneinheitlichen Programmierstil reduzieren wollen.

    Ich benutze eigentlich sehr wenige POD-structs. Die die ich benutze sind in der Regel ziemlich lokal angesiedelt oder es ist eindeutig zu verstehen das es sich um simple Datensammlungen handelt. Daher würde ich bei einem ImageDescriptor kein zweites mal nachdenken und sofort von einer Klasse ausgehen. Aber selbst wenn das alles nicht der Fall ist, so verrät mir ein CImageDescriptor oder ein SImageDescriptor immer noch nicht wie ich die Klasse oder POD-struct benutze.

    Oder kannst du mir nun sagen, wie erzeuge ich ein CImageDescriptor oder ein SImageDescriptor? Da ist man eh auf die Dokumentation, ein Blick in den Code oder die IDE angewiesen. Warum benötige ich dann also ein extra C oder S?

    Bei den Konstanten seh ich das ähnlich, im Zweifelsfall müsste ich ja erst nachgucken, weil ich nicht weiß ob EVENTS_N nun ein enum oder ein int const ist und so also eEVENTS_N oder cEVENTS_N heißt. Da sehe ich keinen großen Mehrwert. Ich würde eher sagen nur const benutzen (#define sollte man ja eh nicht benutzen) oä.

    0
  • R

    otze schrieb:

    dann muss man diesen n00bs erklären, dass man this-> nur in ganz wenigen spezialfällen benutzt, und auch nur wnen man weis, was man tut!

    klingt als hättest du das noch nie machen müssen, ich hab das am WE stunden dazu verbracht... 😞

    otze schrieb:

    ich benutze eigentlich auch noch die guten alten set/get funktionen 😉
    sie sagen genug aus, und man kann wenig mit falsch machen. Im moment überleg ich mir aber, davon weg zu gehen und properties zu nutzen.

    meinst damit c#?

    im prinzip tauscht du m_ gegen get/set, ich würde das nicht als besser ansehen;)

    0
  • R

    kingruedi schrieb:

    @rapso
    Eure Namenskonventionen sehen mir eher danach aus, als wollte man eher die Fehler eines uneinheitlichen Programmierstil reduzieren wollen.

    eher als was?
    ich denke genau dazu ist unsere styleguide da, sicherlich nicht dazu um programmierer zu unnötigen dingen zu nötigen. deswegen haben wir auch einige dinge rausgenommen gehabt. die styleguide wurde auch gefreezt und auch wenn sie nicht perfekt ist, werden keine ewiglangen diskussionen mehr geführt, sondern man hällt sich daran damit code konstant lesbar bleibt.

    Ich benutze eigentlich sehr wenige POD-structs. Die die ich benutze sind in der Regel ziemlich lokal angesiedelt oder es ist eindeutig zu verstehen das es sich um simple Datensammlungen handelt. Daher würde ich bei einem ImageDescriptor kein zweites mal nachdenken und sofort von einer Klasse ausgehen.

    ich nutze structs auch sehr selten, eigentlich fast nur für gemappte resourcen und als initialisierungskonstrukte für factories... aber wie du schon sagst, würdest du darüber nachdenken was ImageDescriptor ist, bei 50leuten die nachdenken, kann es passieren, dass einer was anderes denkt, das ist menschlich.

    Aber selbst wenn das alles nicht der Fall ist, so verrät mir ein CImageDescriptor oder ein SImageDescriptor immer noch nicht wie ich die Klasse oder POD-struct benutze.

    nein, die benutzung wird dadurch nicht geklärt, da kommt man über gedocte interfaces/header nicht hinweg. aber wenn du einen source liest, weißt du eher was das zu bedeuten hat. aber auf der anderen seite, wenn du im source

    apData

    siehst, weißt du dass die resource freigegeben wird, bei pData könntest du ein memoryleak oder sogar ne accessviolation bedenken müssen, wenn du das nutzt. einen änlichen unterschied hast du ja bei param-by-reference und param-by-pointer auch. eine funktion die einen pointer annimt MUSS es handlen können dass es ein NullPointer sein kann den sie bekommt. eine die eine reference will, da mußt du dich drum kümmern, dass du sie sauber fütterst. fütterst du eine die einen pointer erwartet, darfst du sie nicht mit "new CFoo" füttern, eine mit nem autopointer/smartpointer/refcountpointer (je nach festlegung) kümmert sich selber um die daten auf die der pointer zeigt.

    Oder kannst du mir nun sagen, wie erzeuge ich ein CImageDescriptor oder ein SImageDescriptor? Da ist man eh auf die Dokumentation, ein Blick in den Code oder die IDE angewiesen. Warum benötige ich dann also ein extra C oder S?

    ich kann dir sagen, dass du einen SImageDescriptor so erzeugst:
    SImageDescriptor Desc;
    ich kann dir sagen, dass du ein CImageDescriptor vermutlich über einen konstruktor erzeugst der eventuell parameter braucht (SImageD... hat keine funktionen und ctors)
    ich kann dir sagen, dass du ein IImageDescriptor nicht erzeugen könntest, sondern von einer factory erzeugen müßtest, auch deleten könntest du es nicht selbst und müßtest das über die factory machen (oder es gibt ein refcounting, dann würdest du aber einen CAPImadeDescriptor nutzen, der sich um alles kümmert.

    das weiß ich alles nur aufgrund des namens ohne dass es die objekt-deklaration überhaupt gibt 😉

    Bei den Konstanten seh ich das ähnlich, im Zweifelsfall müsste ich ja erst nachgucken, weil ich nicht weiß ob EVENTS_N nun ein enum oder ein int const ist und so also eEVENTS_N oder cEVENTS_N heißt. Da sehe ich keinen großen Mehrwert. Ich würde eher sagen nur const benutzen (#define sollte man ja eh nicht benutzen) oä.

    du würdest EVENTS_N kennen ohne das prefix zu sehen? naja, aber wie ich schon sagte ist es für die lesbarkeit des codes und dann auch die richtige nutzung davon. es hilft dir natürlich nichts, wenn du etwas suchst. dann mußt du nachsehen ob es ESIGNAL oder EEVENT oder EVENT oder ... gibt.

    0
  • ?

    rapso schrieb:

    und mit einer guten styleguid nie vorhanden ist/war.
    ...
    und ebenfals mit einer guten styleguid nie in frage stünde.

    Deiner Meinung nach ist also jede weitere Innovation, Weiterentwicklung völlig unnötig, weil Namenskonventionen bereits die perfekte Lösung sind? 🙄

    Ihr (sämtliche Befürworter von Konventionen mit Präfixen) zählt doch immer nur Argumente auf warum Namenskonventionen besser als gar nichts sind, mich würden aber Vorteile gegenüber heutzutage üblichen IDEs interessieren ..

    0
  • R

    unkreativ`` schrieb:

    rapso schrieb:

    und mit einer guten styleguid nie vorhanden ist/war.
    ...
    und ebenfals mit einer guten styleguid nie in frage stünde.

    Deiner Meinung nach ist also jede weitere Innovation, Weiterentwicklung völlig unnötig, weil Namenskonventionen bereits die perfekte Lösung sind? 🙄

    da intepretierst du viel zu viel rein, als ich gesagt habe. natürlich ist eine gute IDE wichtig, ich könnte ohne mein VisualAssist garnicht mehr leben ;).

    ich könnte nun aber fragen, glaubst du man sollte gute dinge sein lassen, weil es auf mit ein wenig mehr aufwand auch auf andere weisen ginge?

    0
  • T

    rapso schrieb:

    1310-Logik schrieb:

    warum nicht gleich so?

    //ctor
Foo(unsigned int size_):
size(size_)
{
}

    Den Paramter braucht man ja weniger oft als die Membervariable.

    weil jemand später mal auf die idee kommen könnte, dass man noch parameter dazubaut

    das geht doch dann auch ohne aufwand:

    //ctor
Foo(unsigned int size_, unsigned int count_):
size(size_), count(count_)
{
}

    oder meinst du grundsätzlich _ als postfix für alle parameter?

    Nein nur für Members, denn die Übergabeparameter für Members brauch ich nur in den Konstruktoren und Accessoren, die Membervariable auch in x anderen Methoden der Klasse. Da spar ich mir die Prä/Postfixe dann.

    0
  • ?

    da intepretierst du viel zu viel rein, als ich gesagt habe. natürlich ist eine gute IDE wichtig, ich könnte ohne mein VisualAssist garnicht mehr leben

    Ich interpretier da gar nichts hinein und hab auch nichts von IDEs erwähnt in diesem Kontext. Damit wollte ich nur festhalten, dass du andere Ansätze für - ich sag mal - Typbeschreibung mit dem Argument, gibt es bereits "abschmetterst", was auf mich nicht gerade offen gegenüber Innovationen wirkt.

    ich könnte nun aber fragen, glaubst du man sollte gute dinge sein lassen, weil es auf mit ein wenig mehr aufwand auch auf andere weisen ginge?

    Die Möglichkeiten der IDE zu benutzen ist meiner Ansicht nach ganz klar weniger aufwendig, schon allein deswegen, weil man sich den Kopf freihalten kann, von irgendwelchen Konventionen.

    Klarerweise ist das allein kein Argument für IDEs oder nur ein sehr schwaches, andererseits bleibt eben noch die offene Frage im Raum, welchen Vorteil Präfixe im Vergleich zu den Möglichkeiten einer IDE existieren?

    0
  • R

    rapso schrieb:

    kingruedi schrieb:

    @rapso
    Eure Namenskonventionen sehen mir eher danach aus, als wollte man eher die Fehler eines uneinheitlichen Programmierstil reduzieren wollen.

    eher als was?
    ich denke genau dazu ist unsere styleguide da, sicherlich nicht dazu um programmierer zu unnötigen dingen zu nötigen. deswegen haben wir auch einige dinge rausgenommen gehabt. die styleguide wurde auch gefreezt und auch wenn sie nicht perfekt ist, werden keine ewiglangen diskussionen mehr geführt, sondern man hällt sich daran damit code konstant lesbar bleibt.

    Ich meine nur, das eine Namensrichtlinie nicht viel bringt. Natürlich ist es wichtig dass der Code lesbar und weitesgehend einheitlich ist. Aber ich halte nichts davon, dass man Namen mit Typinformationen versieht, die dann auch noch durch 1 buchstabige Abkürzungen ausgedrückt werden.

    Ich sehe so ein Vorgehen eher als mangel von Codingrichtlinien. Die müssen ja nicht sehr streng sein und können zum größten Teil aus Effektiv C++ und Exceptional C++ bestehen.

    Ich benutze eigentlich sehr wenige POD-structs. Die die ich benutze sind in der Regel ziemlich lokal angesiedelt oder es ist eindeutig zu verstehen das es sich um simple Datensammlungen handelt. Daher würde ich bei einem ImageDescriptor kein zweites mal nachdenken und sofort von einer Klasse ausgehen.

    ich nutze structs auch sehr selten, eigentlich fast nur für gemappte resourcen und als initialisierungskonstrukte für factories... aber wie du schon sagst, würdest du darüber nachdenken was ImageDescriptor ist, bei 50leuten die nachdenken, kann es passieren, dass einer was anderes denkt, das ist menschlich.

    eigentlich meinte ich, ich würde kein erstes mal nachdenken 🙂 Aber wie gesagt, es bringt mir keinen Mehrwert zu wissen ob es ein Struct oder eine Klasse ist. (siehe unten)

    rapso schrieb:

    Aber selbst wenn das alles nicht der Fall ist, so verrät mir ein CImageDescriptor oder ein SImageDescriptor immer noch nicht wie ich die Klasse oder POD-struct benutze.

    nein, die benutzung wird dadurch nicht geklärt, da kommt man über gedocte interfaces/header nicht hinweg. aber wenn du einen source liest, weißt du eher was das zu bedeuten hat. aber auf der anderen seite, wenn du im source

    apData

    siehst, weißt du dass die resource freigegeben wird, bei pData könntest du ein memoryleak oder sogar ne accessviolation bedenken müssen, wenn du das nutzt. einen änlichen unterschied hast du ja bei param-by-reference und param-by-pointer auch. eine funktion die einen pointer annimt MUSS es handlen können dass es ein NullPointer sein kann den sie bekommt. eine die eine reference will, da mußt du dich drum kümmern, dass du sie sauber fütterst. fütterst du eine die einen pointer erwartet, darfst du sie nicht mit "new CFoo" füttern, eine mit nem autopointer/smartpointer/refcountpointer (je nach festlegung) kümmert sich selber um die daten auf die der pointer zeigt.

    Hier hilft ein vernünftiger Codingstandard. Die freigabe wird ja nicht dadurch erledigt, in dem man ein p an einen Variablennamen hängt. Hier hilft es zB in dem man Resourcenfreigabe automatisiert. Man sollte also lieber durch die Codelogik Fehler vermeiden und nicht durch Namensgebung.

    rapso schrieb:

    Oder kannst du mir nun sagen, wie erzeuge ich ein CImageDescriptor oder ein SImageDescriptor? Da ist man eh auf die Dokumentation, ein Blick in den Code oder die IDE angewiesen. Warum benötige ich dann also ein extra C oder S?

    ich kann dir sagen, dass du einen SImageDescriptor so erzeugst:
    SImageDescriptor Desc;
    ich kann dir sagen, dass du ein CImageDescriptor vermutlich über einen konstruktor erzeugst der eventuell parameter braucht (SImageD... hat keine funktionen und ctors)
    ich kann dir sagen, dass du ein IImageDescriptor nicht erzeugen könntest, sondern von einer factory erzeugen müßtest, auch deleten könntest du es nicht selbst und müßtest das über die factory machen (oder es gibt ein refcounting, dann würdest du aber einen CAPImadeDescriptor nutzen, der sich um alles kümmert.

    das weiß ich alles nur aufgrund des namens ohne dass es die objekt-deklaration überhaupt gibt 😉

    Das ist aber ziemlich wenig und ziemlich nutzlos. Gut CImageDescriptor braucht einen Ctor, aber welche Parameter hat er? Welche Daten enthält SImageDescriptor, wie muss ich es also initialisieren? etc. Also muss ich immer noch nachschlagen, wenn ich ImageDescriptor benutzen will. Die gegebenen Informationen bringen mir nichts.

    0
  • T

    wow, scheint doch ein interessantes thema zu sein? (über 50 comments an einem tag, wenn auch nicht alle so geistreich...)

    also, vieleicht ligt es ja daran, dass ich generell beim arbeiten recht ordentlich und struckturiert vorgehe...
    ich für meinen teil muss sagen, dass es besonders für eine spätere überarbeitung, fehlersuche oder dokumentation meiner projekte sehr hilfreich ist, wenn man "von weitem" erkennt worum es sich handelt: z.b membervariable(wert) oder membervariable(control), variable die als switch verwndet wird (also bool), welcher typ das Steuerelement hat (txt, lbl, opt, ...) da ich oft meherer Elemente hab die funktionell zusammen gehören und somit den gleichen Namen tragen können zb: m_optConnect, m_cmdConnect, c_optConnect, c_cmdConnect

    das würde dann im code so aussehen:

    void ... ::OnCmdConnect
 ... blabla.Connect(m_optConnect, blabla);
 m_cmdConnect = "Disconnect";
 c_optConnect.EnableWindow(false);
 ... //oderso...

    aber wie gesagt muss jeder selber wissen, ich denke es geht hier weniger um notwendigkeit als und "ordnung und sauberkeit" im code. also klar verstädlich auf den 1. blick...

    ein guter stiel beim programmieren ist wie schönschrift bei gedicht und gehört somit einfach dazu

    mfg thinux

    0
  • B

    thinux schrieb:

    wow, scheint doch ein interessantes thema zu sein? (über 50 comments an einem tag, wenn auch nicht alle so geistreich...)

    also, vieleicht ligt es ja daran, dass ich generell beim arbeiten recht ordentlich und struckturiert vorgehe...
    ich für meinen teil muss sagen, dass es besonders für eine spätere überarbeitung, fehlersuche oder dokumentation meiner projekte sehr hilfreich ist, wenn man "von weitem" erkennt worum es sich handelt:

    Wo wir beim Verarbeiten sind: was machst du wenn erkennst, dass die Ergebnisse deines Programmes nicht genau genug sind, und du deine Variablen alle von float auf double umstellen musst? Durch den ganzen Quelltext gehen und alle "f"-Prefixe durch "d"-Prefixe ersetzen? Oder wenn du statt Comboboxen doch lieber ein List-Element einsetzen willst? alle cmb durch lst ersetzen?

    0
  • J

    thinux schrieb:

    w
    ein guter stiel beim programmieren ist wie schönschrift bei gedicht und gehört somit einfach dazu

    Du bist offtopic, hier geht's um Stil, nicht um Stiel. 🤡

    0
  • R

    1310-Logik schrieb:

    Nein nur für Members, denn die Übergabeparameter für Members brauch ich nur in den Konstruktoren und Accessoren, die Membervariable auch in x anderen Methoden der Klasse. Da spar ich mir die Prä/Postfixe dann.

    und wenn du eine neue member einbaust die du nutzen möchtest, prüfst du dann in der implementierungsdatei ob der variablenname schon in funktionen benutzt wurde und änderst den dort oder wie ist der workflow?

    0
  • R

    unkreativ`` schrieb:

    Ich interpretier da gar nichts hinein und hab auch nichts von IDEs erwähnt in diesem Kontext. Damit wollte ich nur festhalten, dass du andere Ansätze für - ich sag mal - Typbeschreibung mit dem Argument, gibt es bereits "abschmetterst", was auf mich nicht gerade offen gegenüber Innovationen wirkt.

    nein ich schmetter sie nicht ab, ich verteidige lediglich meine ansicht.

    Die Möglichkeiten der IDE zu benutzen ist meiner Ansicht nach ganz klar weniger aufwendig, schon allein deswegen, weil man sich den Kopf freihalten kann, von irgendwelchen Konventionen.

    da kann ich dich beruhigen, nach ner zeit hat man es drauf, es ist wie tippen auf der tastatur, darüber muss man nicht mehr nachdenken, man macht es aus gewohntheit dann so.

    Klarerweise ist das allein kein Argument für IDEs oder nur ein sehr schwaches, andererseits bleibt eben noch die offene Frage im Raum, welchen Vorteil Präfixe im Vergleich zu den Möglichkeiten einer IDE existieren?

    wieso sollten sich IDE und prefixe unbedingt ausschliessen? nur weil man eine IDE hat, muss man doch nicht auf die vorteile einer styleguide verzichten. ich kann jetzt natürlich das argument bringen, dass nicht jede IDE gleich arbeitet und gerade diff-tools oft auf das highlighting von unterschieden spezialisiert sind, nicht auf syntax;) und sourcebrowsen in sourcedatenbanken ganz andere highlights setzt.

    0
  • R

    kingruedi schrieb:

    Ich meine nur, das eine Namensrichtlinie nicht viel bringt. Natürlich ist es wichtig dass der Code lesbar und weitesgehend einheitlich ist. Aber ich halte nichts davon, dass man Namen mit Typinformationen versieht, die dann auch noch durch 1 buchstabige Abkürzungen ausgedrückt werden.

    Ich sehe so ein Vorgehen eher als mangel von Codingrichtlinien. Die müssen ja nicht sehr streng sein und können zum größten Teil aus Effektiv C++ und Exceptional C++ bestehen.

    wie ich schon sagte, je besser man dem menschen die daten representiert, desto besser kann er damit arbeiten. Namen die eindeutige (wichtige) eigenschaften mitteilen vermeiden falsche annahmen.

    eigentlich meinte ich, ich würde kein erstes mal nachdenken 🙂 Aber wie gesagt, es bringt mir keinen Mehrwert zu wissen ob es ein Struct oder eine Klasse ist. (siehe unten)

    klar, bewust nicht, aber eine annahme würdest du zwangsweise machen damit du damit arbeiten kannst denk ich mir.

    Hier hilft ein vernünftiger Codingstandard. Die freigabe wird ja nicht dadurch erledigt, in dem man ein p an einen Variablennamen hängt. Hier hilft es zB in dem man Resourcenfreigabe automatisiert. Man sollte also lieber durch die Codelogik Fehler vermeiden und nicht durch Namensgebung.

    aus gründen der effiziens und manchmal durch zwänge externer libs (z.b. d3d), kann man kein automatisches resourcehandlich von anfang an machen, sondern muss eine kapselung davon schreiben oder muss damit leben.

    rapso schrieb:

    Das ist aber ziemlich wenig und ziemlich nutzlos. Gut CImageDescriptor braucht einen Ctor, aber welche Parameter hat er? Welche Daten enthält SImageDescriptor, wie muss ich es also initialisieren? etc. Also muss ich immer noch nachschlagen, wenn ich ImageDescriptor benutzen will. Die gegebenen Informationen bringen mir nichts.

    wenn du die arbeitsweise weißt, mußt du nicht mehr nachsehen, trotzdem mußt du beim arbeiten eventuell differenzieren zwischen CImageDescriptor und IImagedescriptor.

    0
  • R

    Blue-Tiger schrieb:

    Wo wir beim Verarbeiten sind: was machst du wenn erkennst, dass die Ergebnisse deines Programmes nicht genau genug sind, und du deine Variablen alle von float auf double umstellen musst? Durch den ganzen Quelltext gehen und alle "f"-Prefixe durch "d"-Prefixe ersetzen? Oder wenn du statt Comboboxen doch lieber ein List-Element einsetzen willst? alle cmb durch lst ersetzen?

    das macht man zum teil mit http://en.wikipedia.org/wiki/Refactoring und um die umschreibung der parameter und aufrufe beim umstellen auf andere typen kommt er nicht herum. du mußt ja auch durch den source (oder zumindestens die consts gehen) und die multiplikationen mit anderen floats dann umcasten oder gleich auf double umstellen.

    0
  • T

    rapso schrieb:

    und wenn du eine neue member einbaust die du nutzen möchtest, prüfst du dann in der implementierungsdatei ob der variablenname schon in funktionen benutzt wurde und änderst den dort oder wie ist der workflow?

    Nein, aber da ich selten globale Variablen hab, krieg ich da kaum Konflikte.
    Lokale Variablen in Funktionen heissen bei mir oft gleich, die verlieren ja ihre gültigkeit beim Verassen des Blocks.

    void move( int x_, int y_, object& elem )
    elem.x = x_
    elem.y = y_
}

void check( int x_, int y_ object& elem )
    if( x_ == elem.x ) && ( y_ == elem.y ) {
        foo();
}

    Gut ehrlich gesagt sind meine Projekte noch nicht so gross, so dass ich einigermassen im Kopf hab, wie was heisst, und sonst weiss ich wo ich nachschauen muss.
    Ausserdem hilft mir die alte Laboranten Regel: Alles eindeutig beschriften!

    0
  • C

    Also davon, die Datentypen als Kürzel hinzuzufügen, halte ich gar nichts. Wer den Code liest, sieht auch die Typdefinitionen - und dort steht wirklich drin, ob das nun eine int- oder long-Variable ist. Da ändere ich lieber einmal die Definition "int val;" nach "long val;", wenn mir die Genauigkeit nicht reicht, als jedes Vorkommen von "ival" in "lval" umzuwandeln (und am Ende erwische ich dann noch ein Vorkommen, das zu einer ganz anderen Variablen gehört).

    Was Sinn macht, sind logische Kennzeichnungen für die Variablen (z.B. ob dieser char* auf einen 0-terminierten String zeigt oder auf einen Bereich, der die Länge explizit mitführt) - sowas kann man nicht aus den reinen Deklarationen entnehmen, sondern benötigt Zusatzinformationen.

    0
  • ?

    CStoll schrieb:

    Was Sinn macht, sind logische Kennzeichnungen für die Variablen (z.B. ob dieser char* auf einen 0-terminierten String zeigt oder auf einen Bereich, der die Länge explizit mitführt) - sowas kann man nicht aus den reinen Deklarationen entnehmen, sondern benötigt Zusatzinformationen.

    Hier lässt sich natürlich auch darüber streiten, ob man dafür dann nicht einfach nen eigenen Typ einführt, oder ein aussagekräftigeres typedef nimmt.

    0
Anmelden zum Antworten