hübsche anwendung von #define

ness

Wollen wir jetzt wieder in die Gosse verfallen und uns um die schönsten Präprozessoranweisungen streiten?

Ben04

Ich bin für:

#define self (*this)
#define repeat(n) for(size_t counter__=0,loop__=(n);counter__<loop__;++counter__)

Die benutz ich des öfteren wirklich.

Shade Of Mine

Ben04 schrieb:

Ich bin für:
#define self (*this)
#define repeat(n) for(size_t counter__=0,loop__=(n);counter__<loop__;++counter__)
Die benutz ich des öfteren wirklich.

*OMFG*
warum nicht gleich: http://thedailywtf.com/archive/2004/10/27/2962.aspx

Ben04 schrieb:

Ich bin für:
#define self (*this)
#define repeat(n) for(size_t counter__=0,loop__=(n);counter__<loop__;++counter__)
Die benutz ich des öfteren wirklich.

Nene. Nene. Dafür gibts doch fertige Algorithmen in der STL.
Am weichsten finde ich natürlich sowas:

foreach( Foo obj in myFooCollection )
    obj.fooMethode();

Ben04

Shade Of Mine schrieb:

Ben04 schrieb:
Ich bin für:
#define self (*this)
#define repeat(n) for(size_t counter__=0,loop__=(n);counter__<loop__;++counter__)
Die benutz ich des öfteren wirklich.
*OMFG*
warum nicht gleich: http://thedailywtf.com/archive/2004/10/27/2962.aspx

Da ich kein Pascal mag.

Optimizer schrieb:

Nene. Nene. Dafür gibts doch fertige Algorithmen in der STL.

Also ich wäre schon erstaunt wenn du das schöner mit irgendwelchen Templates hinkriegen würdest:

class Foo
{
public:
  Foo&operator+=(int);
  Foo&operator++(){
    self+=1;
  }
};

repeat(4)
  cout<<"Guten Tag"<<endl;

Also es ist jedenfals wesentlich schöner als ohne Makros. Und von der Sicherheit sind diese auch einbahn frei (jedensfals hab ich noch nie Probleme damit gehabt).

Mr. N

#define self (*this)

gefällt mir sogar recht gut. jedes * im code stört das auge

Schöner ist es vielleicht, aber nicht klarer. Es ist immer klarer, wenn man Standardmittel benutzt. Ja ich weiß, sie sind hässlich. C++ ist halt einfach hässlich, da kann man nichts machen.

Mr. N schrieb:

#define self (*this)
gefällt mir sogar recht gut. jedes * im code stört das auge

Vielleicht ist C# eine schönere Sprache für dich? Für mich auf jeden Fall. Ich halte nur nichts davon, dass dann zwanghaft auf C++ übertragen zu wollen.

Mr. N

Optimizer schrieb:

Vielleicht ist C# eine schönere Sprache für dich? Für mich auf jeden Fall. Ich halte nur nichts davon, dass dann zwanghaft auf C++ übertragen zu wollen.

Sicher, dass das von C# stammt? Ich kenn self eher von Ruby und so.

volkard

Mr. N schrieb:

#define self (*this)
gefällt mir sogar recht gut. jedes * im code stört das auge

volle zusimmung. ich stell gleich mal meine ide um, daß sie self als keyword färbt.

Mr. N schrieb:

Optimizer schrieb:

Vielleicht ist C# eine schönere Sprache für dich? Für mich auf jeden Fall. Ich halte nur nichts davon, dass dann zwanghaft auf C++ übertragen zu wollen.

Sicher, dass das von C# stammt? Ich kenn self eher von Ruby und so.

Jo, stimmt. Ich habe jetzt eigentlich mehr ans explizite Dereferenzieren gedacht. Ich weiß gar nicht, ob man in Ruby dereferenzieren muss. *nix weiß*

groovemaster

Mr. N schrieb:

#define self (*this)
gefällt mir sogar recht gut. jedes * im code stört das auge

Und was machst du, wenn du die Adresse der Instanz brauchst? Stört der Adress Operator dann nicht genauso oder nimmst du dann einfach wieder this?
Schön find ich auch sowas

#define SAFE_DELETE(x) delete x; x = NULL

Sollte es etwa nicht egal sein, ob sich ein Programm beim dereferenzieren eines Nullzeigers oder eines Zeigers auf eine ungültige Adresse erhängt?

otze

Sollte es etwa nicht egal sein, ob sich ein Programm beim dereferenzieren eines Nullzeigers oder eines Zeigers auf eine ungültige Adresse erhängt?

beim dereferenzieren machts keinen unterschied, aber beim delete schon. ein doppelt deletetes(omg) objekt sollte zum absturz führen, das funktioniert aber nur,wenn der pointer nicht null ist.

groovemaster schrieb:

Schön find ich auch sowas
#define SAFE_DELETE(x) delete x; x = NULL

Ich nicht, weil du so sauberen Ärger bekommst, wenn du das nicht in einem Block zusammenfasst.

if( blubb )
    SAFE_DELETE(foo);   // OMG, jetzt wird zwar gelöscht aber nicht auf 0 gesetzt.

Und darum löst man das auch viel schöner in einer Template-Funktion.

Walli

Optimizer schrieb:

if( blubb )
    SAFE_DELETE(foo);   // OMG, jetzt wird zwar gelöscht aber nicht auf 0 gesetzt.

Wieso sollte jetzt nicht auf 0 gesetzt werden?

Weil der Präprozessor einsetzt:

if( blubb )
    delete foo; foo = NULL;

darum.

Walli

Schau es dir nochmal an:

if(blubb)
    delete foo;
foo = NULL;

Es wird in jedem Fall auf 0 gesetzt! Dass das Makro trotzdem scheiße ist, darüber brauchen wir nicht reden .

EDIT: Ach, jetzt weiß ich was du meinst. Du meinst, dass nicht innerhalb des gewünschten Scopes auf 0 gesetzt wird... War etwas verwirrend formuliert.

Einigen wir uns einfach darauf, dass das Makro scheiße ist.

Walli

Jo, klassische Fehler beim Umgang mit Makros... Auch sowas wird immer gerne gesehen:

#define FOO(x) x + x

// ...

int foobar = FOO(x) * bar;

Das man define vermeiden sollte steht schon in Effektiv C++ programmieren. Unter anderem weil es sehr fehleranfällig ist (wie ein paar Posts vorher schon erwähnt).
Ich hab auch schon von Leuten gehört die { und } durch Begin / End ersetzt haben... so etwas ist arm, vor allem für nachfolgende Programmierer, die werden sich über so einen Mist freuen.

Ben04

groovemaster schrieb:

Mr. N schrieb:
#define self (*this)
gefällt mir sogar recht gut. jedes * im code stört das auge
Und was machst du, wenn du die Adresse der Instanz brauchst? Stört der Adress Operator dann nicht genauso oder nimmst du dann einfach wieder this?

Also & stört mich weniger, allerdings ja dann nehme ich wieder this.

groovemaster schrieb:

Schön find ich auch sowas
#define SAFE_DELETE(x) delete x; x = NULL
Sollte es etwa nicht egal sein, ob sich ein Programm beim dereferenzieren eines Nullzeigers oder eines Zeigers auf eine ungültige Adresse erhängt?

Naja über Schöhnheit kann man bekanntlich streiten. Jedenfals hast du dir als du das geschrieben hast keine Gedanken über Sicherheit gemacht und ob es mit Templates nicht besser geht:

template<class T>
inline void SafeDelete(T*&t)
{
  delete t;
  t=NULL;
}

Hörte mal Leute die Argument gegen Makros die ihr hier anführt sind ja wohl sowas von Schwachsinn. Dass man sich das Genick bricht wenn man Anfängerfehler Numero Uno begeht ist doch wohl klar und, dass Makros keine Funktionen erstetzen auch.