sieht so professioneller code aus???

Lars

Bei der STL find ich das nicht so schlimm, weil der Code eh unwichtig ist, schließlich will ich sie nur benutzen. Ich will sie ja nicht verändern oder erweitern, denn das wäre ziehmlich dumm. Anders bei Open-Source Projekten wo man sich mal da und dort die einzelnen Klassen Funktion hohlt um sie in seinem Programm einzusetzten. Hier will man evt. das ein oder andere ändern, oder sich den Code schlicht zum verstehen was die Klasse macht angucken. Die STL ist da ausreichen dokumentiert.

SideWinder

Original erstellt von Lars Skiba:
Bei der STL find ich das nicht so schlimm, weil der Code eh unwichtig ist, schließlich will ich sie nur benutzen. Ich will sie ja nicht verändern oder erweitern, denn das wäre ziehmlich dumm. Anders bei Open-Source Projekten wo man sich mal da und dort die einzelnen Klassen Funktion hohlt um sie in seinem Programm einzusetzten. Hier will man evt. das ein oder andere ändern, oder sich den Code schlicht zum verstehen was die Klasse macht angucken. Die STL ist da ausreichen dokumentiert.

Hmm, wieso sollte man die STL nicht erweitern können/dürfen/sollen? Allerdings benötigt man zum Erweitern ziemlich selten die Implementierung ... da reicht die Dekleration und das Wissen über die einzelne Klasse/Methode.

Aber wer solchen Code bei OpenSource-Projekten einsetzt ... hmm, der kann einen leid tun.

MfG SideWinder

other

Hi.

Gestehe Termite!

Original erstellt von Termite:
**ich gestehe.
**

Gut :).
Wo waren sie in der Nacht zu gestern zwischen 4:00 und 5:00?

**
ich verwende auch hin und wieder den hässlichen "_" aber im momentanen project nur bei classen namen und den dazugehörigen dateinahmen.
**

*würg*
Bei mir kommt sowas nicht in den Quelltext :).

**
class IF_Manager ; ist auch eine managerklasse nur aus dem programmpacket IF ( IF steht bei mir für InterFace, damals nichts besseres eingefallen. diese klassen sind alle abstrackt und dienen wie gesagt nur als interface)
**

this sagt: IManager (I steht für Interface ;)).

**
meist leg ich auch noch für jede klasse nen typedef für den Pointer an

typdef DLL_Manager* p_DLL_Manager;
**

Unter C++ sind also Instancen von Objekten nicht gleich Zeiger?
Heißt das etwa, das bei Übergabe dieser Instanz an eine Funktion das gesamte Objekt über den Heap übergeben wird (sprich: neuer Speicher auf dem Heap reserviert und Objekt hineinkopiert)?

**
ich weiss zwar nicht ob das leserlich ist. ich weis zumindestens was was ist und wie ich das zu deuten habe.
**

Ich weiß von nix =).
Aber wenn ich Zeiger auf Typen verwende, schreibe ich meist nur ein P davor.
Diese "_" entfallen, da in Pascal verpöhnt.

MfG other.

[ Dieser Beitrag wurde am 05.07.2002 um 14:18 Uhr von other editiert. ]

volkard

Original erstellt von japro:
sieht so professioneller code aus

jo. leider.
sagte ich nicht irgendwo, daß die stl eigentlich müll ist?
Also nicht wirklich müll, aber ein kind ihrer zeit.

HumeSikkins

Unter C++ sind also Instancen von Objekten nicht gleich Zeiger?

Nö.

Heißt das etwa, das bei Übergabe dieser Instanz an eine Funktion das gesamte Objekt über den Heap übergeben wird (sprich: neuer Speicher auf dem Heap reserviert und Objekt hineinkopiert)?

Nö. Nicht zwangsläufig.
In C++ hast du die freie Wahl wie wo was angelegt wird und wie was übergeben wird.

Bei der Wertübergabe wird der Copy-Ctor des Objekts aufgerufen. Dabei ensteht also eine Kopie (die aber nicht auf dem Heap liegen muss. Der Stack tuts auch). Wenn das zu teuer/nicht erwünscht ist, dann übergibt man Objekte per Referenz (entweder über einen Zeiger oder direkt unter der Verwendung einer Referenz).

sagte ich nicht irgendwo, daß die stl eigentlich müll ist?
Also nicht wirklich müll, aber ein kind ihrer zeit.

Ich halte die STL ja noch wie vor für ein geniales Stück Softwaredesign. Bin aber natürlich wie immer für deine Einwände offen.

Was meinst du mit "kind ihrer zeit"?
Geht es um eine spezielle Implementation oder um das allgemeine Konzept?
Gibt es in deinen Augen eine ähnlich gute Bibliothek (z.B. das Java-Collection-Framework)? Und wenn ja, was zeichnet diese Lib gegenüber der STL aus?
Was sind die Schwächen der STL?

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