Clientsockets aus der vhlib

volkard

Konrad schrieb:

Was mich sonst noch interessieren würde ist, warum "baust" du die vhlib?
Das einzige was Ich mitbekommen habe ist das du die Std-Bibliothek nicht benutzen möchtest. Aber warum?
Erzähl mal ein bisschen, bitte.

ich mag tolle sachen. und wenn etwas das prädikat "nicht toll" verdient hat, dann die standard-lib von c++.
bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting, der packer packt nicht mehr toll. dann der verzicht auf großbuchstaben mit der folge vermehrter namenskollission. das weglassen von get/set, womit kein arsch wissen kann, ob foo.begin() das foo anfangen läßt oder ob's den anfang zurückliefert. und das sind nur die offensichtlichsten sachen.
subtiler ist, daß die streams default-konstruktoren haben und lebende und zugleich ungültige zombie-streams existieren können. daß der default-ctor von vector keinen speicher allokiert, daß delete(0) legal ist, daß assert keine exception wirft, daß die streams hoffnungslos verkompliziert sind, daß vector nur freispeicher mag und damit prinzipiell zu lahm für kleine aufgaben ist, daß die baume aufwärtszeiger haben, daß man irgendwe immer wieder gezwungen wird, zeiger zu nehmen, wo man gar keine zeiger haben mag, sondern objekte, und daß man dann zu smart-pointers gezwungen wird und sich auf einmal fragt, warum das in C schneller ging.

ich mach mal das verzeichnis mit den standard-headers auf und meckere alle ab.
algorithm
jo, die ist gut. supi.

bitset
ist kein zufall, daß ich seit jahren ne eigene klasse BitField habe.

complex
naja, stört nicht.

template<typename _Tp>
    inline complex<_Tp>
    operator-(const _Tp& __x, const complex<_Tp>& __y)
    {
      complex<_Tp> __r(__x, -__y.imag());
      __r.real() -= __y.real();
      return __r;
    }

deque
die ist auch ganz ok.

exception
why gibt nen string aus, der irgendwie mit new speicher holt? oder einen char*, der vielleicht static ist? warum kann sich die exception nicht in einen stream schreiben und wer echt nen string haben muss, läßt sich in nen stringstream schreiben?

fstream
default-ctor. komische sachen wie ios::append. private erblichkeit für coole hacks. unduchsichtig. wer braucht eigentlich locales?

functional
ausgetobt mit exceptions, aber weitgehend ohne praktischen nutzen? ok, nehmen wir mal an, wir hätten wenigstens typeof verfügbar.

iomanip
entweder klickibunti oder konsole unformatiert. iomanip zum formatieren braucht man eigentlich nicht. was macht iomanip noch?

ios

iosfwd
daß <iosfwd> nötig wurde, sagt was über andere headers aus.

iostream
eigentlich ein sehr komischer name für eine datei, die nur cin, cout, cerr und clog berreitstellt.

istream

iterator
mal schauen, ob ich sowas brauchen werde. ich hoffe, es ist nicht nötig.

limits
ok.

list
zu schwach. man braucht wenigstens einfach-verkettete liste als stack und als queue, doppelt verketteten ring und dazu jede sorte nochmal als intrusive version.

locale
wer braucht das?

map
avl-tree mit aufwärtszeigern. wozu sind die aufwärtszeiger gut? und die schnittstelle ist umständlich wenn man speed will und teuer wen man [] schreiben will.

memory
?

(ein paar ausgelassen)

stack
ganz schlimmes ding. man mag stack nicht benutzen. es tut einem weh.

string
copy-on-write ist out. wegen weil wir ganz viel multithreading machen wollen und weil wir nix locken wollen. und weil die allokatoren schneller geworden sind.

typeinfo
schade, daß man zu einem sprachmittel gleichzeitig die klasse exception kaufen muss. das erinnert mich stark an java, wo string-literale von objekt erben.

vector
zu teuer. es fehlt die alternative für statischen speicher, es fehlt reinkonstruieren statt reinkopieren mit push_back.

ist alles nichts schlimmes. aber so alles zusammen nervt's dann doch ein wenig. und ich hab im moment viel zeit. und ich lerne viel dabei. allerdings auf die gefahr hin, daß ich nächstes jahr gar nicht mehr mit normalem c++ arbeiten kann.

Artchi

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

Beispiele? Hier:

http://www.kharchi.de/vcpp2003/dynhelp.png
http://www.kharchi.de/vcpp2003/dynhelp2.png
http://www.kharchi.de/vcpp2003/dynhelp3.png

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

virtuell Realisticer

Artchi schrieb:

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

Beispiele? Hier:

http://www.kharchi.de/vcpp2003/dynhelp.png
http://www.kharchi.de/vcpp2003/dynhelp2.png
http://www.kharchi.de/vcpp2003/dynhelp3.png

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das
Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum
Thema ueber die Sockets in der vhlib zurueckkommen, oder?

mfg
v R

volkard

Artchi schrieb:

volkard schrieb:

bereits den anfänger nervt es, daß headers keine extension haben. der editor verzchtet deswegen aufs systax-highlighting.

Dann würd ich mir einen vernünftigen Editor oder IDE besorgen?

die ide kennt eine liste von dateinamen, die als C++-Source interpretiert werden sollen. na, klasse. was ein trick. helau!
es ändert nix daran, daß das weglassen der dateinamenerweiterung eine größliche fehlentscheidung war. wieviele jahre wird es dauern, bis sich alle ides angepaßt haben? und dann gibts noch den explorer, woher soll der den dateityp kennen? andere explorer? ja, auch ein ftp-uploader, der anhand der erweiterung den binary-modus setzt oder nicht (also *.pl, *.cgi als ascii und *.jpg als binary). soll der raten?

VC++2003 zeigt mir sogar in Realtime dynamisch Hilfetexte aus der MSDN an, wenn ich mich mit dem Cursor im Source bewege. (da ist Syntax Highlightning ein Witz gegen)

wegen solcher sachen benutze ich das VS nicht mehr. mit notapad, einem makefile und ein ganz wenig framework hat man inzwischen mehr spaß, als mit dem VS. als es angefangen hat, daß der focus ins fehlermeldungendfenster geht, statt im source-fenster zu bleiben, isses für mich gestorben. und es wird immer schlechter.

C++ sollte man es nicht in die Schuhe schieben, nur weil einige Editoren oder IDEs micht mächtig genug sind.

kannste mir sagen, weshalb die erwreiterungen abgeschafft wurden? kannste mir einen vernünftigen weg zeigen, wie ein ftp-uploader den dateityp erkennt, wenn auf einmal jeder keine erweiterungen mehr benutzt?
kannst dich ja noch auf den standpunkt stellen, daß würde nur c++ betreffen und für die paar files könne man ne feste liste machen. aber erstens ist das weit gefehlt, weil die compilerbauer mehr files bauen als im standard vorgeschrieben ist und die files machen sie sinnvollerweise ohne erweiterungen. und dann würde die dateityperkennung sogar wissen müssen, welchen compiler in welcher version du drauf hast. nein mehr noch, was ist, wenn jemand mehrere compiler benutzt? und wenn die anderen communitoes mit dem gleichen recht anfangen, ihre erweiterungen fallenzulassen, dann ist aber schluß mit lustig. dem mp3-player ist egal, wie die datei heißt. und mit meinen hard-rock-kumpels spiele ich hier im keller songs mit feinen namen wie iostream oder new. da guckste! und die ide guckt auch, wenn sie ein 12M großes lied aufmachen soll und gerade nachdenkt, welcher schwachmat denn so viel code in eine datei packt. aber die ersten zeichen bis zum eof werden lustig eingefärbt. wenigstens etwas.

wie war nochmal dein argument gegen dateinamenerweiterungen? man soll sie abschaffen, weil es ides gibt, die sie nicht brauchen?

Artchi

Ein Screenshot fehlt noch:

http://www.kharchi.de/vcpp2003/syntax_std.png

volkard

virtuell Realisticer schrieb:

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum Thema ueber die Sockets in der vhlib zurueckkommen, oder?

artchis einwand ist irgendwie on-topic.

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Artchi

wie war nochmal dein argument gegen dateinamenerweiterungen? man soll sie abschaffen, weil es ides gibt, die sie nicht brauchen?

Kannst du das bitte zitieren, wo ich das behauptet habe? Nur bin ich der Meinung, das ich eine IDE benutze, damit mir sowas letztendlich egal ist. Wer natürlich alles handmade machen will, kann das natürlich tun. Nur wird es nichts nützen, wenn man auf das Std-Commitee motzt. Du kannst übrigens eine Stimme beim Commitee kaufen, um mit abzustimmen. Ich finde auch sehr vieles in C++ nicht toll! Aber ich behelfe mir dann, in dem ich mir das passende Werkzeuge besorge um die Nachteile wieder auszubessern. Man muß halt das beste draus machen, wenn man in der C++ nur ein kleines Licht ist und nicht die Macht des Committees hat.

My 2 cent.

Artchi

volkard schrieb:

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Ich persönlich benenne meine Header immer mit hpp und gehe den Weg den Boost geht. Die Groß- und Kleinschreibung richte ich danach, wie sich die Klasse nennt.

virtuell Realisticer

volkard schrieb:

virtuell Realisticer schrieb:

Gut, wo du ja jetzt bezueglich volkards gesagtem uns gezeigt hat, wie das Syntaxhighlighting in einer std-Header ausschaut, koennen wir ja jetzt wieder zum Thema ueber die Sockets in der vhlib zurueckkommen, oder?

artchis einwand ist irgendwie on-topic.

also gehen wir wieder zu vhlib. wie sollten eigentlich die header heißen? "Socket.h" oder "Socket" oder "Socket.hpp" oder "socket" oder "socket.h" oder "socket.hpp" ?

Wenn moeglich socket.h, meinetwegen auch socket.hpp, aber hauptsache klein. Bei Shades
Lib hatte ich unter Unix echt Probleme, da die Dateien GrossUndKlein geschrieben waren,
aber z. B. nur klein includiert. Das macht unter Windows keinen Unterschied, aber
unter Unix wird auch hier zwischen Gross- und Kleinschreibung unterschieden.

Nur socket ist bloed hab keine so tolle IDE wie der vc (kann der auch Dateien ohne
Endung highlighten, die nicht zum Standard gehoeren?).

mfg
v R

rüdiger

Ich bin für socket.hpp

.h wird von vielen Editoren als C Header erkannt und entsprechendes Syntax Highlight eingestellt. Hier kann man dein Argument wieder anbringen

volkard schrieb:

kannste mir sagen, weshalb die erwreiterungen abgeschafft wurden? kannste mir einen vernünftigen weg zeigen, wie ein ftp-uploader den dateityp erkennt, wenn auf einmal jeder keine erweiterungen mehr benutzt?

In dem Sinne "kannste mir einen vernünftigen weg zeigen, wie ein ftp-uploader den dateityp erkennt, wenn auf einmal jeder eine erweiterung benutzt?"

Eine .wav ist ja auch keine .mp3, nur weil beide Audiodaten enthalten

.hpp passt außerdem besser zum .cpp der Code Dateien und vermittelt so einheitlichkeit.

Ich bin für Socket.hpp

virtuell Realisticer

kleines licht schrieb:

Ich bin für Socket.hpp

Selbstverstaendlich klein

mfg
v R

virtuell Realisticer schrieb:

kleines licht schrieb:

Ich bin für Socket.hpp

Selbstverstaendlich klein

mfg
v R

warum? klassen fangen auch mit Grossbuchstaben an.

volkard

virtuell Realisticer schrieb:

Wenn moeglich socket.h, meinetwegen auch socket.hpp, aber hauptsache klein. Bei Shades Lib hatte ich unter Unix echt Probleme, da die Dateien GrossUndKlein geschrieben waren, aber z. B. nur klein includiert. Das macht unter Windows keinen Unterschied, aber unter Unix wird auch hier zwischen Gross- und Kleinschreibung unterschieden.

und wenn wir einfach korrekt inkludieren?

virtuell Realisticer

volkard schrieb:

virtuell Realisticer schrieb:

Wenn moeglich socket.h, meinetwegen auch socket.hpp, aber hauptsache klein. Bei Shades Lib hatte ich unter Unix echt Probleme, da die Dateien GrossUndKlein geschrieben waren, aber z. B. nur klein includiert. Das macht unter Windows keinen Unterschied, aber unter Unix wird auch hier zwischen Gross- und Kleinschreibung unterschieden.

und wenn wir einfach korrekt inkludieren?

Dann gehts.

mfg
v R

DrGreenthumb

spätestens wenn jemand ein schlechtes (altes) ftp-, pack- oder sonstwas-programm benutzt, sind die dateinamen wieder hin. Da wünscht man sich dann, alles wäre klein geschrieben (lässt sich nämlich dann mit einem einzeiller wieder hinbiegen).

ich weiß auch nicht wieso das so stört, unter windows kann man doch ohnehin nicht "EineDatei" und "einedatei" gleichzeitig haben.

volkard

DrGreenthumb schrieb:

spätestens wenn jemand ein schlechtes (altes) ftp-, pack- oder sonstwas-programm benutzt, sind die dateinamen wieder hin. Da wünscht man sich dann, alles wäre klein geschrieben (lässt sich nämlich dann mit einem einzeiller wieder hinbiegen).

hab vor 5 jahren das letzte mal gesehen, wie ein linux-packer die dateinamen fälschlicherweise klein machte. ich denke, das ist was ganz anderes als ne alte ide, die "new" nicht als standardheader erkennt. es ist eher ein programmierfehler.

ich weiß auch nicht wieso das so stört, unter windows kann man doch ohnehin nicht "EineDatei" und "einedatei" gleichzeitig haben.

wenn ich

#include "Socket.hpp"

lese, möchte ich gleich an "die Klasse Socket" denken. da hilft mir der großbuchstabe schon und nimmt ein wenig denken ab.

evilissimo

DrGreenthumb schrieb:

ich weiß auch nicht wieso das so stört, unter windows kann man doch ohnehin nicht "EineDatei" und "einedatei" gleichzeitig haben.

Aber unter linux nicht und das wäre dann ja nicht mehr portabel

BR

volkard

kingruedi schrieb:

Ich bin für socket.hpp

.h wird von vielen Editoren als C Header erkannt und entsprechendes Syntax Highlight eingestellt.

den editor hat man mit wenigen handgriffen umgestellt, daß er nurnoch c++-highlighting macht.

volkard

klar ist, daß auch großbuchstaben in dateinamen genommen werden. also datei genbauso wie klasse.

es ist schon irgendwie elegant, c/h und cpp/hpp zu haben. mal sehen, was dafürspricht.
1. kingruedi
2. nix.

hmm. und was spricht dagegen? 2 zeichen mehr zu tippen immer. nicht wirklich relevant.

das mit dem highlighter, der c-code anders highlightet als c++-code müßte man mal den admins dieses forums verraten. die gleuben nämlich, es gäbe eine sprache c/c++

//der beweis

andererseits gibt es keine reinen c-header. man darf jeden die ganzen c-header in c++ includieren. gegebenenfalls steht dann ein extern "C" in #ifdef/#endif. daher war es von anfang an nicht sinnvoll, beim umsteig von c nach c++ die header auf einmal anders zu benennen. man baut seinen socket in die "Socket.h" und man includiert trotzdem noch die "process.h" für threads.

ich habe jetzt angefangen, alles nach *.hpp umzustellen.
und jetzt kommen mir schreckliche gedanken. was soll denn das für ein wuselwirrwarr werden, wenn ich bei jedem header vorher überlegen muss, ob da eher C oder eher C++ drinsteht, ob ich .h oder .hpp schreiben muss?

soll ich die Size.h jetzt auch Size.hpp nennen? da ist ja kein einziges ding drin, daß c++ aber nicht c wäre.

von den *.hpp-vorschalgern, hat einer von euch *.hpp bereits über eine längere zeit oder in einem projekt mit mehr als 15 dateien verwendet?