[linux-l] Designfrage bzgl. Deckverwaltung

[Steffen Dettmer]

* Frank Reker wrote on Tue, Nov 15, 2005 at 19:12 +0100:
> Am Mon 14. Nov 2005 23:32 +0000 schrieb Steffen Dettmer:
> 
> >* Frank Reker wrote on Thu, Nov 10, 2005 at 12:01 +0100:
> >[zweite Mail]
> >> for (int i=Name1; i<count_E; ++i) ...
> >> funktioniert auch ohne cast!
> >
> >Scheisse, tatsächlich, welch ein Bug!
> 
> feature - nicht bug!

IMHO ein Bug: untergräbt das Typkonzept, was ja ohnehin nicht perfekt
ist ;) Aber natürlich auch Geschmackssache.

> >Eben, und daher kann man mit enums nicht rechnen. Macht ja auch keinen
> >Sinn: "for (farbe = rot; farbe <= gelb; farbe++)" oder was?
> 
> warum soll das keinen sinn machen. ab und an muss man eben ueber enums
> iterieren. 

Weil "apfel++" halt Blödsinn ist. Wenn es ein int ist, kann man ja einen
int nehmen. Na egal.

> extra funktionen zum iterieren zu schreiben ist unnoetiger
> overhead. und selbst wenn, wird man intern doch wieder zu integer
> arithmetik greifen. aussnahme waere, wenn die enums eben nicht in
> numerischer folge auftreten, dann muss man eben ein mega switch machen,
> aber aeusserst unschoen.

Wer unterstellt denn, dass Äpfel und Birnen überhaupt eine "numerische
Reihenfolge" haben? Vielleicht sind meine enums nichtmal in einer
Halbordnung!

> >Schade, dann man in C++ so Äpfel und Biernen vergleichen kann, wenn man
> >sie über for iteriert.
> 
> im endeffekt sind enums immer noch ints mit namen anstatt nummern.
> warum sollte man das nicht ausnutzen koennen, wuerde mich arg nerven.

jajaja, im Endeffekt sind alles CPU DWORDs, schon klar :-)

> das fuehrt aber nicht zum ziel ;-))
> 
> 
> >Aber wir waren ja bei C++ :-)
> 
> casts sind auch C++. 

Wenn (const unsigned char*)"hallo" C++ ist, ist es Inline-Assembler auch
;)

> oder willst du mit gewalt alles in objekte pressen
> alla java? - imho ein aeusserst schlechter programmierstil. wo oop sinn
> macht ok, wo nicht, da nicht.

Ja, seh ich auch so, aber ein paar Typen machen schon Sinn, finde ich,
muss ja nicht gleich wie in Ada sein ;)

> ich war auch mal begeisterter oop programmierer. die erfahrung hat mich
> gelehrt moeglichst "flat" zu programmieren. wo verebung, abstrakte
> klassen, polymorphie, funktionsueberladung, ... sinn machen - ok.
> aber nicht alles unnoetig aufblaehen. ist mehr programmieraufwand,
> aufwendiger zu debuggen, schwieriger zu lesen, und inperformanter.

Ja, vor allem lieber leistungsfähige Datenstrukturen und einfachen Code.
Ein prozedurales Problem ist halt ein prozedurales solches, seh ich auch
so :)

> no, in der vergangenheit hab ich auch wo's ging referenzen benutzt.
> nur dann passiert's, dass man einen wert uebergibt, und gar nicht
> beachtet, dass der wert ja evtl. veraendert werden kann, da es eine
> referenz ist. 

Erstens ist das mit Zeigern genauso, und zweitens schreibt man an const
halt const ran :-) 

> ganz schlimm ist es dann solche fehler in fremden
> programmen zu finden.
> wer einmal fremde programme debugt hat, der wird referenzen verfluchen.

Ersteres hab ich oft, zweiteres nicht :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.