sieht so professioneller code aus???

volkard

Ich weigere mich ganz einfach, einzusehen, daß Code wie

struct DeletePtr
{
    template <class T>
    void operator()(T* p) const
    {
        delete p;
        p = 0;
    }

};
...
    for_each(Vec.begin(), Vec.end(), DeletePtr());

In irgend einer Weise besser lesbar oder wartbar ist als

for(vector<Base*>::iterator i=Vec.begin();i!=Vec.end();++i)
       delete *i;

Sie ist irgendwie unhandlich. Es macht mir keine Freude, sie zu verwenden.

HumeSikkins

Ich weigere mich ganz einfach, einzusehen, daß Code wie

struct DeletePtr
{
template <class T>
void operator()(T* p) const
{
delete p;
p = 0;
}

};
...
for_each(Vec.begin(), Vec.end(), DeletePtr());

In irgend einer Weise besser lesbar oder wartbar ist als

for(vector<Base*>::iterator i=Vec.begin();i!=Vec.end();++i)
delete *i;

Tja, dann solltest du wohl mal Scott Meyers Effective STL lesen.

Sie ist irgendwie unhandlich

Die Aussage finde ich irgendwie schwammig.

Es macht mir keine Freude, sie zu verwenden

Man wird ja zum Glück nicht gezwungen sie zu verwenden. Ich kann das aber beim besten Willen der STL nicht als Schwachpunkt anlasten. So nach dem Motto: Mich stört an der STL, dass Volkard keine Freude an ihr hat

Als Gegenpol kann ich nur sagen, dass ich von allen Bibs die ich bisher verwendet habe die STL mir am meisten Freude bereitet. Keine großen Klassenhierarchien. Leicht zu erweitern usw.

Das soll natürlich jetzt keiner als Pluspunkt der STL sehen: So nach dem Motto: Ich mag die STL, weil Hume die dufte findet

volkard

Original erstellt von HumeSikkins:
**Tja, dann solltest du wohl mal Scott Meyers Effective STL lesen.
**

Und danach mag ich 10-Zeiler lieber als Zweizeiler?

volkard

Bin aber natürlich wie immer für deine Einwände offen.

Ich versuch mal ein paar Sachen rauszufinden.
Also klar, da es keinen Benutzungszwang gibt, kann man stets sagen, naja, mußt es ja nicht nehmen, also ist nix schlechtes dran.
for_each verwende ich ungern, weil's nur viel mehr Code erzeugt, aber nicht wirklich was bringt.
for(bla::iterator i=...
kenn ich nämlich inzwischen auswendig, und sehe es als fertiges
for each i in bla
Von den vielen Containern hab ich immer nur vector verwendet. Ne Hashtable gabs ja nicht. Und Sortierungen, das hat mein Heap lieber gemacht. Wenn ich überhaupt ne Sortierung brauchte, dann reichte auch immer, nur das kleinste Element zu kennen.
Also blieb's im Wesentlichen dabei, daß ich vector und string verwendet hab. Manchmal auch queue und stack, aber die sind gewöhnlich wieder aus dem Code verschwunden zugunsten eigener Implementierungen.
Außer, wenn ich die STL um der STL Willen verwende, läuft der Anteil der STL-Nutzung bei mir immer wieder ganz von allein auf ein Mindestmaß zurück.
Das mag kein Grund gegen die STL sein, aber es ist für mich einer. Vielleicht liegt das Problem ganz weit unten. Container sind nunmal keine Sequenzen. So wie Dateien nunmal keine Streams sind.
Was ich auch noch nicht nachvollziehen konnte, ist der Verzicht auf Großbuchstaben in der stl. Angenehmer wurde sie dadurch auch nicht.

Natürlich hat mich der Trick mit Funktionsobjekten als Template-Argument auch mal begeistert. Ich hab nen Haufen von Sachen gebaut, die mir die Schleifen aus dem Anwendungscode gezogen haben. Letztendlich war's dann so, daß ich Datenquellen, Datensenken und Filter baute und die nur zu verbinden hatte.

DirectoryReader dr(SL("c:"));
        co.write(SL("searching every hpm.ini in this directory and below\n"));
        IniPathFilter fi;
        Creator<Ini> ic;
        Adder<HomePageMirror> ad(*this);
        ::run(dr>fi|ic|ad);

und hier ein Filter:

class IniPathFilter
{
public:
    template<class RECEIVER>
    void receive(RECEIVER &receiver,char const *path,WIN32_FIND_DATA &data)
    {
        if(data.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY) return;
        if(stricmp(data.cFileName,"hpm.ini")!=0) return;
        receiver.receive(path);
    }
};

Und damit hab ich noch ein paar Tage gespielt, und dann festgestellt, daß es einfach unpraktisch ist, jedes if und jedes for in ne eigene Klasse zu klatschen. Solche Ausflüge ins Extremprogrammieren mach ich hin und wieder mal. Machmal bring ich davon ein nettes Mittelchen zurück, meistens aber die Einsicht, daß ein bestimmter Weg nur ins Verderben führt. Den Weg in die schleifenfreie Programmierung kenn ich jetzt.

ps: Das, was in ::run(dr>fi|ic|ad); steckt, war vermutlich das Komplizierteste, was ich bisher gebaut hab.

Mis2com

Hallo!
Also ich finde, dass man den Code slber gut verstehen und erkennen sollte.
Was bringt es einem einen super aufgebauten Code zu haben, wenn er dann superlahm ist?
Ich meien:
Es kommt auf den Code selber und nicht auf dessen Styling an.

Wenn das Programm fertig ist guckt eh keiner mehr rein.

Gut gestylter Code ist nämlich keinen Tick schneller.

volkard

Original erstellt von Mis2com:
...

Kindchen, wir gehen eh nur von schnellem Code aus.

HumeSikkins

Hallo,
über die Verwendung von foreach kann man sicher streiten.
Der Algo läßt sich ja nun wirklich sehr leicht implementieren. Auf der anderen Seite gibt es ne Menge Leute die selbst hier noch Fehler machen:

for (Container<Foo>::iterator Beg = cont.begin() ; Beg != cont.end() ; Beg++)
//...

Ist einfach nicht perfekt (min. 2 kleine Mängel).

Wenn der Container dann noch Pointer enthält kommen häufig sogar noch ungewollte Typfehler hinzu.

Kurz gesagt: Es mag Situationen geben, in denen es angebrachter ist einen Algo selbst zu schreiben. Grundsätzlich ist die Anwendung der std::algorithmen aber
1. Effezienter - wer außer Volkard kennt denn alle Tricks. Außerdem können die std-Implementierer Sachen berücksichtigen, die wir als Anwender nicht berücksichten können -> z.B. bestimmtes Containerlayout

2. Leichter zu verstehen und zu lesen - Algorithmen haben einen eindeutigen Namen an denen man ihre Aufgabe erkennt. Schleifen sind ein low-level-Konzept. Die Semantik muss ich erstmal suchen.

3. Weniger Fehleranfllig - viele Typfehler werden bei der Templateparameterauflösung automatisch erkannt. In handgeschriebenen Code muss ich sie erst selbst suchen.

Alles in Allem verstehe ich nicht, warum man sich gegen die Algos wehrt. Es verwenden ja auch alle strlen, strcpy, memcpy usw. anstatt jedesmal ne eigene Schleife zu basteln.

Zugegeben, C++ mit STL ist ein anderes C++ als das von vor ein paar Jahren.

Lars

Original erstellt von Mis2com:
**Hallo!
Also ich finde, dass man den Code slber gut verstehen und erkennen sollte.
Was bringt es einem einen super aufgebauten Code zu haben, wenn er dann superlahm ist?
Ich meien:
Es kommt auf den Code selber und nicht auf dessen Styling an.

Wenn das Programm fertig ist guckt eh keiner mehr rein.

Gut gestylter Code ist nämlich keinen Tick schneller.
:D**

Gut gestylter Code und schneller Code sind NIE ein Wiederspruch. Nie nie nie. Im Gegenteil gut gestylter Code ist sogar schneller! In der Verwendung und in der Erweiterbarkeit.

Marc++us

Original erstellt von Mis2com:
Wenn das Programm fertig ist guckt eh keiner mehr rein.

Hast Du eine Ahnung. Zum einen sind Programme oftmals nie fertig, zum anderen ist es immer ein Dritter, der rein schauen muß.

Helium

Ich könnte mir ein Leben (nur aufs Programmieren bezogen) ohne STL garnicht mehr vorstellen.
Da ich die sgi-Implementation der STL verwende habe ich einen Hash. Und ich habe schon oft maps, multimaps und lists verwendet.

Manitu

Hi,

also wenn wir schon von "Professionalität" reden.
Professionalität heisst, dass ein Programm
1. zufriedenstellend läuft.
2. schnell und dadurch kostengünstig fertiggestellt wird.

So, und nur somit lässt sich damit Geld verdienen !!!
Und keinem Unternehmer, und keinem Kunden schon gleich gar nicht,
interessieren irgendwelche Internas.
Sollten später im Zuge der Wartung noch diverse Änderungen vorgenommen werden müssen, können diese Programmteile im Nachhinein übersichtlicher gestaltet werden, was meisst auch nicht gemacht wird.

Das ist wie im Fussball. Die Mannschaft muss viele Tore schiessen, und nicht wenige schöne.

Cu
Manitu

virtual

also wenn wir schon von "Professionalität" reden.
Professionalität heisst, dass ein Programm
1. zufriedenstellend läuft.
2. schnell und dadurch kostengünstig fertiggestellt wird.

So, und nur somit lässt sich damit Geld verdienen !!!
Und keinem Unternehmer, und keinem Kunden schon gleich gar nicht,
interessieren irgendwelche Internas.
Sollten später im Zuge der Wartung noch diverse Änderungen vorgenommen werden müssen, können diese Programmteile im Nachhinein übersichtlicher gestaltet werden, was meisst auch nicht gemacht wird.
Das ist wie im Fussball. Die Mannschaft muss viele Tore schiessen, und nicht wenige schöne.

Auch als Kunde wuerde zumindestens ich mich ganz massiv fuer die internas interessieren: Wenn die Software halbwegs relevant ist und einen blocking Error hat, dann entscheidet die Wartbarkeit vom Code ganz erheblich darueber, wie schnell das Problem gefixt ist. Dass das Kunden nicht immer tun, mag erhoiehte Risikobereitschaft oder einfach nur Dummheit sein.

Ich selbst arbeite in der Produktentwickung, d.h. der Code den ich schreibe muss einerseits von einigen anderen verstanden werden, zum anderen vom mir auch nach 5 Jahren noch (vorausgesetzt, dass ich dann noch hier bin ). Ich kann nur sagem, dass zumindestens in diesem Bereich es praktisch unmoeglich ist im Nachhinein irgendetwas Wartbar zu machen. Und ich wuerde auch jeden in den Hintern treten, der Code schreibt, des es nicht von vorne herein ist: das ist in meinem Augen hoechst unprofessionell.

Manitu

Hi,

@virtuell:
Wie glaubst du denn, ist das bei "relativ" erfolgreichen Firmen wie
Microsoft ?

Cu
Manitu

Shade Of Mine

Original erstellt von Manitu:
Wie glaubst du denn, ist das bei "relativ" erfolgreichen Firmen wie Microsoft ?

Wieso sollte Microsoft und Co nicht genauso auf wartbarkeit wert legen wie andere Firmen?

Gerade wenn man immer neue Versionen des gleichen Programmes rausbringt, dann MUSS man ja wartbaren code haben.

Bashar

Hihi Aber nichtsdestotrotz gibt es keine andere Firma die sich unwartbaren Code erlauben kann

virtual

Wie glaubst du denn, ist das bei "relativ" erfolgreichen Firmen wie Microsoft ?

Naja, leider ist Windows ja keine Eintagsfliege geblieben, so dass das wohl nur den Schluss nahelegt, dass die ihren Code im Griff haben.
Ich find zwar Windows ziemlichen Muell, aber ich denke, dass es guter Muell ist.

kartoffelsack

Professionalität heisst, dass ein Programm
1. zufriedenstellend läuft.
2. schnell und dadurch kostengünstig fertiggestellt wird.

Und ich wage zu bezweifeln, dass einer dieser beiden Punkte erreichbar ist, wenn der Code nicht gut und übersichtlich ist. Schließlich sind professionelle Projekte, Projekte bei denen mehr als einer schon die ein oder andere Woche programmiert. Wenn das nicht gut entworfen und schön geschrieben ist, hast Du spätestens nach dem nächsten verlängerten Wochenende keinen Plan mehr.

Manitu

Hi,

klar darf der Code nicht wie Kraut und Rüben aussehen, sonst wird's nie ein vernünftiges Programm. Es muss aber so programmiert werden, dass die beiden von mir genannten Punkte auf jeden Fall erfüllt werden. Falls nicht, kann der Code schön sein wie er will, dann kann man niemals damit Geld verdienen, und das allein ist
Professionalität.
Guter Code heisst: Möglichkeit einer kostengünstigen Wartungs- und Erweiterungsmöglichkeit. Dies kann man als 3. Punkt durchaus aufführen. Aber wie gesagt, nur als DRITTEN Punkt. Und auch nur, wenn eine Wartung und Erweitung geplant ist.

CU
Manitu

Shade Of Mine

OK, bei Punkt 1 sind wir uns einig...

aber Punkt 2 und 3 sind austauschbar.

Denn es bringt mir nichts wenn ich zwar schnell fertig bin, aber jegliche Wartungsarbeit unermaesslich viel Zeit verlangt!

gmAwesome

void model_try_cache_render(int model_num, matrix *orient, vector * pos, uint flags, int objnum, int num_lights )
{
    model_really_render(model_num, orient, pos, flags, objnum);
}

Das ist aus dem FreeSpace2-Source