sieht so professioneller code aus???

Termite

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

class DLL_Manager ; ist z.b die managerklasse aus dem programmpacket DLL ( hir auch als DLL implementiert )

oder

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)

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

typdef DLL_Manager* p_DLL_Manager;

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

gruss termite

japro

Original erstellt von Termite:
**
typdef DLL_Manager* p_DLL_Manager;
**

die _ in den namen drinn stören mich überhaupt nicht. so nenne ich z.b. alle meine eigenen typen in der art nummer_t, meintyp_t etc.
aber die vorangestellten find ich grässlich besonders wenn man dann sowas sieht:
--__a;

virtual

@japro
Was noch dazu kommt: Mit doppelten Underscores oder Aehnlichem solltest Du auch gar nix machen. Aus dem Standard:
17:4.3.1.2:

[...]- Each name that contains a double underscore (__) or begins with an underscore followes by an uppercase letter is reserved to the implementation for any use.
- Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace. Such names are also reserved in Namespace ::std.

HumeSikkins

@virtual
Das ist tatsächlich eindeutig besser formuliert als mein umgangssprachliches Geholpere

kartoffelsack

Ich schätz mal, dass da sogar ein bisschen Absicht dahintersteckt, wenn die stl möglichst unleserlich geproggt ist. Es tut den Firmen wahrscheinlich sowieso schon weh, dass sie wegen dem Template-Zeugs den kompletten Quellcode mitliefern müssen ...

SideWinder

@kartoffelsack: Ich wollte mir mal die Stream-Bibliothek der MSVC-Libary näher ansehen - damals wollte ich eine eigene bauen. Nur leider kann man da überhaupt nix erkennen. Da werden nur einbuchstabrige Variablen hin und her geschaukelt, und alles endet irgendwo in einem Header mit einem 'x' am Anfang :(.

MfG SideWinder

Gerard

wahrscheinlich haben die eine art parser der das so unläserlich macht

[ Dieser Beitrag wurde am 05.07.2002 um 11:46 Uhr von Dimah editiert. ]

ich denke mal die stl implementeure wussten nicht genau was sie machen und haben deshalb eben so dummy variablen genommen, weil sie den eigentlichen sinn der variable nicht verstanden haben

virtual

@dimah
du meinst vermutlich sowas wie cfog, zu finden z.B. hier:
http://www.norfolk.navy.mil/oasys/c/files.html
Die machen IHMO aber richtig krassen output.

@iknow
Also IMHO wissen die Jungs und Mädels schon sehr genau, was sie so machen. Meistens jedenfalls.

Gerard

Original erstellt von virtual:
**@dimah
du meinst vermutlich sowas wie cfog, zu finden z.B. hier:
http://www.norfolk.navy.mil/oasys/c/files.html
Die machen IHMO aber richtig krassen output.
**

heist das das der code noch schlimmer aussehen würde wenn sie ihn durch solch ein paser laufen lassen würden? oder hatten die nicht so viel zeit ein guten zu schreiben? oder es gibt menschen die wirklich so progen vieleicht sehen sie es als cool an zum glück denke ich genau anders rum

virtual

@dimah
Aus dem Manual von dem Teil

o uses your system's C preprocessor to incorporate the contents of include files into the source file and execute all preprocessor directives. By default, FOG only processes local include files and does not process system include files.

o replaces all identifier names (including function names) with a generic style of name--by default this is i_dn where n is a number that is different for every unique identifier.

o "octalizes" strings. The characters in all character strings in the file (e.g., those in printf statements) are replaced with their octal equivalents; i.e., "hello world" becomes "\150\145\154\154\157\40\167\157\162\154\144".

o removes comments.

o removes the physical structure of the program.

Eben alles, was das Herz begehrt.

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.