3. Will eine Methode names register

Will eine Methode names register

  • ?

    und jetzt ist die funktion immer schön gehighlighted 😉

    Also jetzt mal ehrlich: Man sollte eigentlich keine Probleme mit Schlüsselwörtern haben, wenn man wirklich gute Namen gewählt hat...
    Weil das jetzt sooooo wichtig ist, dass die Funktion register heißt 🙄

    0
  • S

    Optimizer schrieb:

    Weil das jetzt sooooo wichtig ist, dass die Funktion register heißt 🙄

    eigentlich schon.
    Mich nervt es auch dauernd.

    man hat nen functor bei dem man eine Function/Functor/was auch immer registrieren kann und dieser ruft die funktion dann eben zum passenden zeitpunkt auf.

    nun ist der name 'register' dafuer ideal, nur leider muss ich Register schreiben, was meiner Namenskonvention zuwiderlaeuft.

    also: aergerlich ist es, aber volkards 'loesung' ist eher mehr ein: 'natuerlich geht es' als eine sinnvolle Loesung.

    0
  • H

    also: aergerlich ist es, aber volkards 'loesung' ist eher mehr ein: 'natuerlich geht es' als eine sinnvolle Loesung.

    Und spätestens nach der Einbindung eines Standardheaders imo auch eine ungültige dazu.

    0
  • H
     

    #include <standard_header>
#include "erlaubeRegister.h"

...

    Wo ist jetzt der Fehler?

    0
  • S

    Helium schrieb:

    Wo ist jetzt der Fehler?

    Ich bilde mir ein, dass es verboten ist, keywords mit define 'umzudefinieren'.
    Aber ich habe jetzt auf die schnelle nichts im Standard gefunden, also ist es uU legal.

    0
  • D

    Shade Of Mine schrieb:

    Helium schrieb:

    Wo ist jetzt der Fehler?

    Ich bilde mir ein, dass es verboten ist, keywords mit define 'umzudefinieren'.
    Aber ich habe jetzt auf die schnelle nichts im Standard gefunden, also ist es uU legal.

    Nein. Hume hat doch schon sehr deutlich 17.4.3.1.1#2 hingeschrieben.

    An Heliums Beispiel sieht man auch schön, das die Reihenfolge der Header keine Rolle spielt:

    /* a.h */
#define a(x) int x = 0;

/* b.h */
#define int void

/* include a.h und b.h */
a(quak)
    0
  • H

    Du meinst, wenn im Standard header ein Makro definiert wurde, das ich verwende, in dem register vorkommt kommt es zu problemen. OK. Hast du auch ein beispile, wo das so ist oder ist das rein hypotetisch?

    0
  • D

    Helium schrieb:

    Du meinst, wenn im Standard header ein Makro definiert wurde, das ich verwende, in dem register vorkommt kommt es zu problemen. OK. Hast du auch ein beispile, wo das so ist oder ist das rein hypotetisch?

    #define assert(expr) if (register bool __meiner = !(expr)) { \
    blabla(); abort(); }

    Naja.

    0
  • C

    Hi,

    unter C++ sollte man die Praecompilerdirektive tunlichst vermeiden (außer bei Headern, um Doppeldeklarationen zu vermeiden) Zumindest bei Quelltextersetzungen ist es extrem unschön. In C wurde sie z.B. bei kleinen Funktionen genutzt, um den Header zu minimieren. dafür gibt es jetzt das Schlüsselwort inline. Weiterhin hat man es bei konstanten genutzt, was man in C++ besser mit const macht. Und außerdem wurde es noch für funktionen mit belibigem Parametertyp genutzt, was dank der Templates viel besser gelöst ist... Und Schlüsselwörter durch #define auszuschalten ist nicht der beste Stil.

    0
  • V

    c++eus schrieb:

    Hi,
    unter C++ sollte man die Praecompilerdirektive tunlichst vermeiden (außer bei Headern, um Doppeldeklarationen zu vermeiden) Zumindest bei Quelltextersetzungen ist es extrem unschön.

    aber drei goodies hab ich, wo man nicht ohne auskömmt:

    a)

    #define retrun return
...
retrun 0;
//ich tippe doch andauernd retrun statt retrun, da brauchts präprozessionelle hilfe

    b)

    #define cout cout<<
...
cout "hello, world!";
//damit ich nicht immer << mit >> verwechsele

    c)

    #define sin(x) sin((x)/180*3.14) 
//und schon wieder in die falle 
//mit der integer-division getappt
...
cout<<sin(90);
//endlich ergibt sin(90)==1, wie es sich gehört.
    0
  • C

    Hi,

    wenn du ständig alles verwechselst, kann ich dir auch nicht helfen... Ach ja: noch ein Fall:

    #define END }
#define BEGIN {

    😃

    Also ich hab nie Pascal programmiert. (Diesen Fall hab ich aus meinem C++-Übungsbuch... wird einam aber davon abgeraten)

    0
  • ?

    volkard schrieb:

    c++eus schrieb:

    Hi,
    unter C++ sollte man die Praecompilerdirektive tunlichst vermeiden (außer bei Headern, um Doppeldeklarationen zu vermeiden) Zumindest bei Quelltextersetzungen ist es extrem unschön.

    aber drei goodies hab ich, wo man nicht ohne auskömmt:

    a)

    #define retrun return
...
retrun 0;
//ich tippe doch andauernd retrun statt retrun, da brauchts präprozessionelle hilfe

    b)

    #define cout cout<<
...
cout "hello, world!";
//damit ich nicht immer << mit >> verwechsele

    c)

    #define sin(x) sin((x)/180*3.14) 
//und schon wieder in die falle 
//mit der integer-division getappt
...
cout<<sin(90);
//endlich ergibt sin(90)==1, wie es sich gehört.

    *LOL*

    0
  • H

    @c++eus: Bei Daniel E. und volkrad kannst du davon ausgehen, dass sie wissen, wann sie #define verwenden sollten und wann nicht.

    0
  • C

    Helium schrieb:

    @c++eus: Bei Daniel E. und volkrad kannst du davon ausgehen, dass sie wissen, wann sie #define verwenden sollten und wann nicht.

    Hi,

    die Präprozessordirektiven gegen Tippfehler zu verwenden, ist wohl nicht unbedingt Sinn der Sache. (mal abgesehen davon waren das ja nur Scherze...) Man könnte doch mal einen Contest machen, wer die blödsinnigste Anwendung von #define findet 🙂 .

    0
Anmelden zum Antworten