Ich erstelle gerade ein Konzept für eine Software, die ich demnächst in Angriff nehmen werde. Das Ganze ist aber Hobby und rein zum Lernen, bzw. zum Spaß. Ich arbeite unter verschiedenen Linux-Dsitris. Sprache soll C++ werden. Die Software wird erstmal eine reine Konsolenanwendung, aber wie mans im *nix-Umfeld kennt ist vorgesehen das später mal ein graphisches Frontend dazukommt. Die Software muss: - (Text)Dateien einlesen und parsen - Threads für Hintergrundarbeiten - Netzwerkverbindung (TCP/UDP) oder serielle Schnittstelle (Datenaustausch mit einem Controller) - Pipes (oder andere Interprozesskommunikation) zum Datenaustausch mit anderen Prozessen oder der späteren GUI - und, im CMD-Modus natürlich Konsolenein/ausgabe Kein HExenwerk, ich weiß. Das geht mit plain C++. Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze oder bläht das die Software unnötig auf? Bieten mir diese Frameworks Features, die mir die Arbeit an obigen Punkten erleichtern oder komm ich ohne genauso schnell ans Ziel? (Beispiele wieso ich evtl ein Framework benutzen will: die STL hat keinen String-Tokenizer; serielle Kommunikation läuft über Devicefiles mittels C-API) PS: das ist kein "Welche Programmiersprache Thread".
Sobald Threads und Netzwerk ins Spiel Kommen: tu dir einen Gefallen, und nimm ein Framework dafür. Klar, die C-APIs (pthread_create_xxx, socket(), connect(), usw) gehen alle auch unter C++. Aber Spaß geht anders, und bis das alles durchdebuggt ist, fehlerfrei läuft und frei von Memory/Socket-Leaks, Race conditions etc ist...
Εrnst B✶ schrieb: > Aber Spaß geht anders, und bis das alles durchdebuggt ist, fehlerfrei > läuft und frei von Memory/Socket-Leaks, Race conditions etc ist... und bei welchen Framework gibt es diese Probleme nicht? Selbst bei Java gibt es Race conditions.
QT wirklich nur wenn du ein GUI brauchst. Das ist so vermüllt mit redundanten Typdefinitionen und zwingt zu einer Applikationsstruktur, in der einfache Dinge plötzlich kompliziert werden, dass es keinen richtigen Spaß macht. QT ist der Versuch eine eigene Welt, unabhängig von der darunterliegenden Plattform, zu schaffen, weil man sich vor der Plattform fürchtet. Boost nur, wenn man das harte Zeug in Boost wirklich braucht, also nicht nur weil man gerne damit angibt möglichst komplizierten Code schreiben zu können. Boost sicher nicht, um nur ein bisschen Stringverarbeitung zu bekommen (Pro-Tipp: Die guten alten C-Funktionen gibt es allesamt in C++).
Hans schrieb: > Die Software wird erstmal eine reine Konsolenanwendung, aber wie mans im > *nix-Umfeld kennt ist vorgesehen das später mal ein graphisches Frontend > dazukommt. dann würde ich vorschlagen die wirkliche Anwendung als Bibliothek (.so) bereitzustellen und die Konsolenanwendung ist nur eines der Frontends, die diese Bibliothek nutzen können. So ist die GUI viel einfacher zu implementieren. > Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze > oder bläht das die Software unnötig auf? Boost ist mittlerweile soetwas geworden, wie ein Inkubator für die nächsten C++-Standardlib. Viel von dem, was jetzt in die Standardlib von C++11 eingeflossen ist, stammt aus Boost. Boost hat nicht die Idee Teile der C++ Standardlib zu ersetzen, sondern zu ergänzen und damit zusammenzuarbeiten. Bei QT sieht es dagegen ganz anders aus: die wollten eine GUI-Lib entwickeln. Damals als die angefangen haben, war die C++ Standardlib aber noch in vielen Compilern nicht nutzbar, nicht enthalten, zu buggy etc. Daher mussten die was eigenes für die Standardfunktionen machen. Diese Teile von QT, wie z.B. QString, stehen ein wenig in Konkurrenz zur Standardlib. Ich würde die C++ Standardlib und Boost als gute Basis ansehen die man ohne Bedenken verwenden kann. Die Dinge die dort enthalten sind selber rezuimplementieren wird fast immer schlechter als das Original und kostet unnötig Zeit. Für solche Dinge wie Deine Netzwerkkommunikation etc. kann es evtl. andere Libs geben die mehr bieten, die dann gezielt anschauen und evaluieren. QT macht für eine GUI auf jeden Fall sind, für ne Lib oder Konsolenanwendung würde ich mir das gut überlegen.
M, nicht Q schrieb: > Boost sicher nicht, um nur ein bisschen Stringverarbeitung zu > bekommen (Pro-Tipp: Die guten alten C-Funktionen gibt es allesamt in > C++). Die guten Stringfunktionen sind bereits in der Standardbibliothek. Dafür braucht man kein Boost. Die schlechten alten C-Funktionen für string-ähnliche Bytewürste läßt man natürlich links liegen.
Peter II schrieb: > und bei welchen Framework gibt es diese Probleme nicht? Keine Ahnung. Javascript vielleicht, mangels Threads. Wollte nur ausdrücken, dass z.B. Qt es sehr viel einfacher macht, diese Probleme zu umschiffen. Die Klassen sint z.B. teilweise selber Thread-Safe, oder es gibt nette Helfer wie den QMutexLocker, die gerade im Zusammenspiel mit Exceptions viel Kopfschmerzen ersparen können...
Fred schrieb: > M, nicht Q schrieb: >> Boost sicher nicht, um nur ein bisschen Stringverarbeitung zu >> bekommen (Pro-Tipp: Die guten alten C-Funktionen gibt es allesamt in >> C++). > > Die guten Stringfunktionen sind bereits in der Standardbibliothek. Dafür > braucht man kein Boost. Aber schon so kleine Dinge wie BOOST_FOREACH machen das Leben leichter und den Code schöner. Schon dafür lohnt sich das. Bei ner Kommandozeilen-Applikation kommt dann noch Program Options dazu, wenn man sauber programmieren möchte noch unit testing. Alles bei Boost dabei und nicht unnötig kompliziert. > Die schlechten alten C-Funktionen für string-ähnliche Bytewürste läßt > man natürlich links liegen. Auf jeden Fall, bei nem Netzwerkprogramm riecht das ganze sonst schon nach Exploits durch falsche Pufferallokierung.
Gerd E. schrieb: > Aber schon so kleine Dinge wie BOOST_FOREACH machen das Leben leichter > und den Code schöner. Schon dafür lohnt sich das. Braucht man nicht mehr seit C++11. Hans schrieb: > - (Text)Dateien einlesen und parsen Geht wunderbar mit den Standard-Streams. Für komplizierteres Parsen: Boost Spirit. > - Threads für Hintergrundarbeiten Geht in C++11 "nativ" und elegant. > - Netzwerkverbindung (TCP/UDP) oder serielle Schnittstelle Geht mit Boost.Asio sehr gut. > (Datenaustausch mit einem Controller) > - Pipes (oder andere Interprozesskommunikation) zum Datenaustausch mit > anderen Prozessen oder der späteren GUI ebenfalls Boost.Asio > - und, im CMD-Modus natürlich Konsolenein/ausgabe C++ Standardlib. Mit anderen Worten: C++ Standard Libray und Boost können alles was du brauchst.
M, nicht Q schrieb: > QT wirklich nur wenn du ein GUI brauchst. Das ist so vermüllt mit > redundanten Typdefinitionen Bitte was?
Wenn eine GUI später angedacht ist, solltest du dir jetzt schon Gedanken machen was du dafür für eine Lib nehmen willst. Sollten es Qt oder wxWidgets sein, bist du besser bedient gleich darauf zu setzen. Solange nur der no-Gui-Teil verwendet wird, wird es nicht ganz so groß. Aber mal ehrlich, Theads, Mutexe, Sockets u.s.w kriegt man auch ohne Lib portabel für Linux, Windows und Mac in unter 1000 Zeilen Code unter. Es muss nicht immer eine fette Lib sein. Zumal häufig noch genügend Libs dazukommen für die verschiedesten Sachen. Die meisten sicherlich in reinem C. Ich denke da nur an openssl, libharu, v8, libjansson... Nur ein paar von denen die bei mir immer im Spiel sind. Das letzte was ich mir antun würde wäre Boost. Ausser du stehst auf solche Konstruktionen:
1 | typedef boost::tokenizer<boost::char_separator<char> > tokenizer; |
2 | std::string s = "Boost C++ libraries"; |
3 | tokenizer tok(s); |
4 | for (tokenizer::iterator it = tok.begin(); it != tok.end(); ++it) |
5 | std::cout << *it << std::endl; |
Da kriege ich schon beim Draufgucken Augenkrebs. Ich verwende auch die C++ Standardlib nicht. Das hat sich aber historisch so ergeben. Vor 20 Jahren konnte man sich noch nicht darauf verlassen dass jeder Compiler das selbe darunter verstand. Also hat man sich das Grundgerüst (Listen, Strings u.s.w.) selbst gebaut. Und wenn man es einmal gemacht hat kommt man auch nicht wieder weg davon.
old man schrieb: > Wenn eine GUI später angedacht ist, solltest du dir jetzt schon > Aber mal ehrlich, Theads, Mutexe, Sockets u.s.w kriegt man auch ohne Lib > portabel für Linux, Windows und Mac in unter 1000 Zeilen Code unter. Richtig, denn die C++ Standard Library enthält all das. > Ausser du stehst auf solche Konstruktionen: > typedef boost::tokenizer<boost::char_separator<char> > tokenizer; > std::string s = "Boost C++ libraries"; > tokenizer tok(s); > for (tokenizer::iterator it = tok.begin(); it != tok.end(); ++it) > std::cout << *it << std::endl; > > Da kriege ich schon beim Draufgucken Augenkrebs. Du stehst mehr darauf den entsprechenden Algorithmus auf 1000 Zeilen selber zu schreiben? Klar, ist natürlich viel besser lesbar! Außerdem kann man seit C++11 obigen Code vereinfachen:
1 | using tokenizer = boost::tokenizer<boost::char_separator<char> >; |
2 | for (auto token : tokenizer {"Boost C++ libraries"}) |
3 | std::cout << token << std::endl; |
Und ja, C++ verstehen sollte man natürlich wenn man C++ verwenden will. > Ich verwende auch die > C++ Standardlib nicht. Das ist natürlich besonders bekloppt. Die Standardlib ist äußerst mächtig und effizient; was besseres von Hand hinzubekommen ist utopisch, und natürlich wahnsinnig unnötige Arbeit. > Also hat man sich das Grundgerüst (Listen, > Strings u.s.w.) selbst gebaut. Und wenn man es einmal gemacht hat kommt > man auch nicht wieder weg davon. Das fällt dann aber unter Beratungsresistenz bzw. Ablehnung von allen Neuerungen...
Dr. Sommer schrieb: > Das fällt dann aber unter Beratungsresistenz bzw. Ablehnung von allen > Neuerungen... Klar doch, zeig mir mal jemanden der regelmäßig bestehenden Code an den jeweils aktuellen Hype anpasst. Wenn ich 20 unabhängige Projekte von 0 an jedes Jahr habe, kann man an so was denken. Nachträglich alten Code durch neuen zu Ersetzen nur weil's schöner aussieht können sich nur die leisten die nicht von ihrer Arbeit leben müssen. > Und ja, C++ verstehen sollte man natürlich wenn man C++ verwenden will. Es geht nicht darum diese Konstruktionen zu verstehen. Es geht ganz einfach darum, daß mit diesen Sprachkonstrukten der ehemalige große Vorteil von C++, nämlich lesbareren Code zu produzieren, wieder hinfällig wird. > Die Standardlib ist äußerst > mächtig und effizient; ja, ja. Aber nur für Wald und Wiesen Anwendungen. Sobald es um Geschwindigkeit geht und in engen Schleifen ein einfaches new zum Killerkriterium wird sieht die Sache gewaltig anders aus. Da kann man sich nicht auf eine Lib verlassen, sondern muss es selbst in der Hand haben. > Das ist natürlich besonders bekloppt. Wenn man die Projekte auf sourceforge und co. so betrachtet, gewinnt man schnell den Eindruck hier sind nur Bekloppte unterwegs wenn es nach deiner Sicht der Dinge geht. Ich kann damit leben.
old man schrieb: > Klar doch, zeig mir mal jemanden der regelmäßig bestehenden Code an den > jeweils aktuellen Hype anpasst. Ja, bei alten Projekten muss man wohl damit leben. Aber hier geht es um eine neues Projekt. Es sei denn man wäre von Anfang an so schlau gewesen, das Interface der eigenen Library kompatibel zur Standard Library zu machen... > Es geht nicht darum diese Konstruktionen zu verstehen. Es geht ganz > einfach darum, daß mit diesen Sprachkonstrukten der ehemalige große > Vorteil von C++, nämlich lesbareren Code zu produzieren, wieder > hinfällig wird. An C++ ist leider gar nichts lesbar. Hier geht es aber um Wiederverwendbarkeit; den einemillionsten Token-Parser zu bauen macht das Programm auch nicht lesbarer. > ja, ja. Aber nur für Wald und Wiesen Anwendungen. Sobald es um > Geschwindigkeit geht und in engen Schleifen ein einfaches new zum > Killerkriterium wird sieht die Sache gewaltig anders aus. Da kann man > sich nicht auf eine Lib verlassen, sondern muss es selbst in der Hand > haben. Klar, dann implementierst du deinen eigenen vector der natürlich viel schneller als std::vector ist, denn die Experten die den implementiert haben sind natürlich längst nicht so erleuchtet wie du! Oder vielleicht verwendest du die Standard Library einfach nur falsch wenn sie bei dir zu ineffizient ist, denn die bietet ja durchaus Dinge wie std::vector<T>::reserve zur Performance-Optimierung. > >> Das ist natürlich besonders bekloppt. > Wenn man die Projekte auf sourceforge und co. so betrachtet, gewinnt man > schnell den Eindruck hier sind nur Bekloppte unterwegs wenn es nach > deiner Sicht der Dinge geht. Ich kann damit leben. Ja, leider ist das so. Eine Unmenge an OpenSource-Projekten ist alles andere als gut/sinnvoll implementiert.
Hans schrieb: > Die Software muss: > - (Text)Dateien einlesen und parsen Geht portabel mit Native-C++, solange die Syntax der Eingabedateien mit Reglar-Expressions erschlagen werden kann. Kommen mehr oder weniger statndardisierte Dateiformate (wie bspw. CSV) ins Spiel, ist evtl. eine entsprechende Zusatzbibliothek von Vorteil. > - Threads für Hintergrundarbeiten Geht portabel mit Native-C++. > - Netzwerkverbindung (TCP/UDP) oder serielle Schnittstelle > (Datenaustausch mit einem Controller) Wenn's nur unter Linux laufen soll und keine höheren Protokolle wie HTTP, FTP u.ä. realisiert werden sollen, geht das auch mit den Linux-Systemfunktionen recht einfach. > - Pipes (oder andere Interprozesskommunikation) zum Datenaustausch mit > anderen Prozessen oder der späteren GUI Dto. Für den Datenaustausch mit einem späteren GUI-Prozess stellt der dafür verwendete GUI-Toolkit evtl. bessere Kommunikationsmöglichkeiten zur Verfügung. > - und, im CMD-Modus natürlich Konsolenein/ausgabe Geht portabel mit Native-C++.
old man schrieb: > Klar doch, zeig mir mal jemanden der regelmäßig bestehenden Code an den > jeweils aktuellen Hype anpasst. Das macht man ja auch nicht. Aber wenn Du heute mit etwas neu anfängst und dabei auf die Fortschritte der letzten 10 Jahre verzichtest, ist das nicht unbedingt klug. > Es geht nicht darum diese Konstruktionen zu verstehen. Es geht ganz > einfach darum, daß mit diesen Sprachkonstrukten der ehemalige große > Vorteil von C++, nämlich lesbareren Code zu produzieren, wieder > hinfällig wird. hängt davon ab wie du lesbar definierst. C++ ist ziemlich mächtig und mit so Dingen wie z.B. Operatorüberladungen kannst Du sehr unleserlichen, aber auch sehr leserlichen Code schreiben. Hängt ganz davon ab wie Du das Stilmittel einsetzt. Ich finde das Beispiel mit dem Tokenizer oben eigentlich doch recht leserlich. > ja, ja. Aber nur für Wald und Wiesen Anwendungen. Sobald es um > Geschwindigkeit geht und in engen Schleifen ein einfaches new zum > Killerkriterium wird sieht die Sache gewaltig anders aus. Da kann man > sich nicht auf eine Lib verlassen, sondern muss es selbst in der Hand > haben. Mit dem Argument "Geschwindigkeit" wird so viel Mist begründet. Ich hab früher auch oft versucht irgenwas auf Geschwindigkeit zu optimieren, dann hab ich nachgemessen und es hat nix gebracht. Und zwar nicht weil der Code an der Stelle nicht schneller geworden wäre, sondern weil ich an der vollkommen falschen Codestelle optimiert hatte. Mittlerweile schreibe ich den Code so, daß er gut lesbar & wiederverwendbar ist und die Klassen sinnvoll aufgeteilt sind. Wenn es hinterher Performanceprobleme gibt, messe ich nach wo die Zeit draufgeht und optimiere nur gezielt an ganz wenigen Stellen nach, wenn es sein muß in Assembler. Darunter darf aber auf keinen Fall die Leserlichkeit und Wartbarkeit des restlichen Codes leiden.
Gerd E. schrieb: > Mittlerweile schreibe ich den Code so, daß er gut lesbar & > wiederverwendbar ist und die Klassen sinnvoll aufgeteilt sind. Wenn es > hinterher Performanceprobleme gibt, messe ich nach wo die Zeit draufgeht > und optimiere nur gezielt an ganz wenigen Stellen nach, wenn es sein muß > in Assembler. Hand aufs Herz und Butter bei die Fische: Wie oft war Nachoptimierung notwendig? Interessiert mich wirklich. Ich behaupte nämlich, dass man in der überwiegenden Mehrzahl der Fälle ein akzeptables Programm bekommt, indem man einfach nur sauberen, vernünftigen Code schreibt. Also: dem Compiler nicht Prügel zwischen die Füsse werfen und 'absichtlich' bescheuerten Code verwenden. Normalerweise reicht das heutzutage völlig aus. Und wenn nicht, dann stellt sich oftmals heraus, das es nicht an der Implementierung liegt, sondern an den Algorithmen. Tausch das Verfahren gegen ein besseres aus, dann bringt das mehr. Profilen sowieso. Ist mir auch schon so gegangen, dass ich auf Biegen und Brechen Dinge optimiert habe und hinterher wars dann sogar langsamer. Seitdem lasse ich das, wenn sich nicht klar herausstellt, dass tatsächlich ein Zeitproblem vorliegt. Auf der anderen Seite, habe ich hoch-'optimierten' Code geerbt, der nach 15 Jahren völlig unverständlich ist, nur so vor Bugs strotzt und wenn man das ganze komplizierte Machwerk durch etwas solides, nach den Regeln der Kunst gebaute ersetzt stellt isch plötzlich raus: das funktioniert nicht nur besser, das ist sogar noch schneller als das Original.
Karl Heinz schrieb: > Hand aufs Herz und Butter bei die Fische: Wie oft war Nachoptimierung > notwendig? recht überschaubar. In den allermeisten Fällen hab ich dann den Algorithmus oder die verwendeten Datenstrukturen angepasst um das Problem zu beheben. Evtl. im Gegensatz zu Dir zähle ich das auch mit zum Nachoptimieren des Codes, da ich vorher nicht unbedingt immer weiß wie häufig z.B. ein bestimmter rechenintensiver Zugriff dann bei realen Daten gemacht werden muss. Bei Code für µCs kam es aber doch hin und wieder mal vor daß ich eine bestimmte Schleife oder so in Assembler machen musste damit das Timing funktionierte.
M, nicht Q schrieb: > QT ist der Versuch eine eigene Welt, unabhängig von der > darunterliegenden Plattform, zu schaffen, weil man sich vor der > Plattform fürchtet. Nein, weil man auch die Plattform ausreichend abstrahieren muss, wenn man auf deren mehreren unterwegs ist. Da das für den TE allerdings kein Thema ist, braucht man das hier auch nicht als Entscheidungskriterium zu nehmen.
old man: > [STL zu langsam] > [flusht sinnlos nach jeder Zeile den Buffer mit std::endl]
Hans schrieb: > Die Software wird erstmal eine reine Konsolenanwendung, aber wie mans im > *nix-Umfeld kennt ist vorgesehen das später mal ein graphisches Frontend > dazukommt. Es macht Sinn, die Kernlogik von der Oberfläche und der Datenhaltung zu trennen (3-Schichten-Architektur). ιst vielleicht schon etwas Overkill für eine kleine Anwendung, aber Skalierbarkeit ist auch eine gute Qualität. > Kein HExenwerk, ich weiß. Das geht mit plain C++. > Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze > oder bläht das die Software unnötig auf? Du solltest dich fragen, welche Software-Qualitäten dir wichtig sind: Performance, Wartbarkeit, Portierbarkeit, usw. und davon ausgehend dich fragen, ob dir die Frameworks helfen, diese Qualitäten einzuhalten. Kannst du die Frage mit 'ja' beantworten - los geht's. > Bieten mir diese Frameworks Features, die mir die Arbeit an obigen > Punkten erleichtern oder komm ich ohne genauso schnell ans Ziel? > (Beispiele wieso ich evtl ein Framework benutzen will: die STL hat > keinen String-Tokenizer; serielle Kommunikation läuft über Devicefiles > mittels C-API) Verschaffe dir doch mal einen Überblick, auf welche Weise die von dir zitierten Frameworks diese Probleme lösen - noch nicht mal im Detail. Kommt dir irgendwas dran spanisch vor - lass es und mach es so, wie du es am besten lösen kannst. Machst du vielleicht noch bisschen Programmierung gegen selbstdefinierte Schnittstellen, die du einhalten musst (interface-driven programming), kannst du einen großen Teil der von dir skizzierten Sachen kohärent lösen und entkoppeln.
Dr. Sommer (Gast) schrieb: (old man schrieb:) >> Es geht nicht darum diese Konstruktionen zu verstehen. Es geht ganz >> einfach darum, daß mit diesen Sprachkonstrukten der ehemalige große >> Vorteil von C++, nämlich lesbareren Code zu produzieren, wieder >> hinfällig wird. > An C++ ist leider gar nichts lesbar. Hier geht es aber um > Wiederverwendbarkeit; den einemillionsten Token-Parser zu bauen macht > das Programm auch nicht lesbarer. "An C++ ist leider gar nichts lesbar" Endlich mal einer der (nach dem was so zu lesen ist) sich auskennt und DAS zugibt. Ein Satz den man sich einrahmen sollte. Vielen lieben Dank! ;-) Ich vermute mal das ist auch der Hauptgrund, warum viele sich lieber anderen Programmiersprachen zuwenden. Denn Wiederverwendbarkeit und Portierbarkeit wird kaum einer der vor C++ flüchtet was einzuwenden haben. Naja, vielleicht brauchen es viele auch nicht so dringend, vor allem wenn sie eher für sich selber programmieren.
Leute, Leute schrieb: > Endlich mal einer der (nach dem was so zu lesen ist) sich auskennt und > DAS zugibt. Ein Satz den man sich einrahmen sollte. > > Vielen lieben Dank! ;-) Danke auch :-D es gibt sogar Vorschläge die C++ Syntax umzubauen und die Semantik zu behalten, aber viel ist daraus scheinbar nicht geworden. > Ich vermute mal das ist auch der Hauptgrund, warum viele sich lieber > anderen Programmiersprachen zuwenden. Denn Wiederverwendbarkeit und > Portierbarkeit wird kaum einer der vor C++ flüchtet was einzuwenden > haben. Naja, richtig angewendet ist C++ dank Metaprogrammierung portierbarer und wiederverwendbarer als alles andere, aber das beherrschen leider nicht viele... Mit etwas Gewöhnung kann man auch lustige Template-Konstruktionen lesen.
Was mir auch auffällt sind die vielen Buzzwords, die von C++ Leuten gerne verwendet werden. "3-Schichten-Architektur", "Skalierbarkeit", "interface-driven programming", "Sachen kohärent lösen und entkoppeln", "Metaprogrammierung", "String-Tokenizer". Die anderen hab ich jetzt mal weggelassen, da die mir vom C her selber recht geläufig sind. Und der "String-Tokenizer" ist nichts anderes als eine Funktion die einen String in Teilstrings zerrupft so wie hier http://www.addison-wesley.de/service/krueger/kap12005.htm Ist wohl wie bei der Visite am Krankenbett, wenn das Fachpersonal in Weiß mit der Patientenakte in der Hand vorbeischaut und beginnt den Terminus Duktus in der Fachsprache runterzurasseln.
Leute, Leute schrieb: > Was mir auch auffällt sind die vielen Buzzwords, die von C++ > Leuten > gerne verwendet werden. > > "3-Schichten-Architektur", "Skalierbarkeit", "interface-driven > programming", "Sachen kohärent lösen und entkoppeln", > "Metaprogrammierung", "String-Tokenizer". Ehehe. Nur ist es eben so dass Programmieren eine komplexe Angelegenheit ist (wenn man mehr als zwei LED's blinken lassen will), weswegen man eine Menge Methodik braucht um guten Code/Programme zu produzieren. Und diese Methodiken haben eben Namen. > Die anderen hab ich jetzt mal weggelassen, da die mir vom C her selber > recht geläufig sind. Und der "String-Tokenizer" ist nichts anderes als > eine Funktion die einen String in Teilstrings zerrupft so wie hier Ja... und? > Ist wohl wie bei der Visite am Krankenbett, wenn das Fachpersonal in > Weiß mit der Patientenakte in der Hand vorbeischaut und beginnt den > Terminus Duktus in der Fachsprache runterzurasseln. Nur dass man als Programmierer keine Patienten hat die man damit eventuell verwirren könnte. Alle Fachgebiete haben ihre eigenen Fachsprachen damit man sich effizient unterhalten kann und nicht alles umschreiben muss. Wenn du damit ein Problem hast, ist das dein Pech... Bei ETechnik ist das doch auch nicht anders, "Astabiler Multivibrator" ist doch fast ein Zungenbrecher, und unter einem Ringoszillator kann sich auch kein Nicht-ETechniker etwas vorstellen.
Dr. Sommer (Gast) schrieb: > Ja... und? Ja und so einfach kann das aufgelöst sein, wofür andere so komplizierte Begriffe verwenden (müssen). Wie war das noch gleich im anderen Thread "Haskell für Embedded Systeme" und Industrie 4.0, mit IoT, IIoT usw.? Man muss die Begriffe auch nicht überstrapazieren und den Dingen mehr Bedeutung verleihen, als es eigentlich wert ist. > Nur dass man als Programmierer keine Patienten hat die man damit > eventuell verwirren könnte. Dafür aber Kunden, die man wohl beeindrucken möchte. > Alle Fachgebiete haben ihre eigenen > Fachsprachen damit man sich effizient unterhalten kann und nicht alles > umschreiben muss. Wenn du damit ein Problem hast, ist das dein Pech... Man muss es ja nicht übertreiben. Meistens nutzen gerade gerne die Blender übermäßig viele Fachbegriffe, weil sie darauf spekulieren, dass keiner ihrer Zuhörer mal nachfragt, was sie mit dem Kauderwelch eigentlich ausdrücken möchten. > Bei ETechnik ist das doch auch nicht anders, "Astabiler Multivibrator" > ist doch fast ein Zungenbrecher Denn nenn es doch einfach Kippschaltung.
Ein Framework ist ok. Aber wenn du mehrere Frameworks in einem Programm mischen willst, kann das Ärger geben. Die vertragen ich oft nicht besonders gut. Vor allem wenn jedes Framework eine eigene mainloop braucht, weil es keine standardisierte Möglichkeit gibt, blockierend auf Ereignisse aus verschiedenen Quellen zu warten. Aber vielleicht kannst du dieses Problem mit Threads umgehen. Gibt dann halt einen Thread für jede mainloop. Konkret: Oben wurde boost asio vorgeschlagen. Ich könnte mir vorstellen, dass sich das nicht mit QT verträgt (Außer du kommunizierst mit der GUI über einen socket...)
> Ja und so einfach kann das aufgelöst sein, wofür andere so komplizierte > Begriffe verwenden (müssen). Welchen anderen Begriff als Tokenizer würdest du also vorschlagen? Funktion-die-String-in-Teilstrings-zerrupft? Klingt super. > Man muss die Begriffe auch nicht überstrapazieren und den Dingen mehr > Bedeutung verleihen, als es eigentlich wert ist. Das tut auch keiner, und deswegen verwendet man das weithin bekannte und verstandene Wort "Tokenizer". > Dafür aber Kunden, die man wohl beeindrucken möchte. Wenns funktioniert ist doch toll. Aber ich bin gespannt auf deine nicht-beeindruckenden Begriffsalternativen. > Man muss es ja nicht übertreiben. Meistens nutzen gerade gerne die > Blender übermäßig viele Fachbegriffe, weil sie darauf spekulieren, dass > keiner ihrer Zuhörer mal nachfragt, was sie mit dem Kauderwelch > eigentlich ausdrücken möchten. Du hast doch die ganzen Fachwörter zusammengesucht... Aber ob du es glaubst oder nicht, manchmal will man einfach nur über Dinge reden und sie bei ihrem anerkannten Namen nennen, ohne alles komisch um schreibeiben zu müssen. > Denn nenn es doch einfach Kippschaltung. Ah, den kannte ich noch nicht. Aber da weiß ich leider auch nicht was gemeint ist. sebastian schrieb: > weil es > keine standardisierte Möglichkeit gibt, blockierend auf Ereignisse aus > verschiedenen Quellen zu warten Die Betriebssysteme haben aber eine, und man kann typischerweise in die Mainloops HANDLE's (Win32)/File Descriptor's (UNIX) einfügen um bei Änderungen benachrichtigt zu werden.
> Aber ich bin gespannt auf deine > nicht-beeindruckenden Begriffsalternativen. Ich habe ja nicht gesagt, dass man solche Begriffe nicht verwenden darf oder soll. Ich habe nur mal freundlich auf das Beispiel aus dem Nachbarthread hinweisen wollen. Die Parallele hat sich mir hier aufgedrängt bei der Anhäufung von Buzzwords hier. >> Denn nenn es doch einfach Kippschaltung. > Ah, den kannte ich noch nicht. Aber da weiß ich leider auch nicht was > gemeint ist. Du kanntest den Begriff Kippschaltung nicht? Kaum zu glauben ...
Leute, Leute schrieb: >> Bei ETechnik ist das doch auch nicht anders, "Astabiler Multivibrator" >> ist doch fast ein Zungenbrecher > > Denn nenn es doch einfach Kippschaltung. und schon hast Du Informationsverlust. Denn Kippschaltungen gibts in Astabil, Bistabil oder Monostabil. Und das macht durchaus einen Unterschied. Da nehm ich lieber den Fachausdruck. Vor allem weil hier die Frage von einem Programmierer kam und sich an Programmierer richtete. Da kann man erwarten daß alle Teilnehmer die Fachtermini kennen.
Gerd E. (robberknight) schrieb: >> Denn nenn es doch einfach Kippschaltung. > und schon hast Du Informationsverlust. Denn Kippschaltungen gibts in > Astabil, Bistabil oder Monostabil. Und das macht durchaus einen > Unterschied. Das ist jetzt Korinthenkackerei. Diesen Unterschied kennen auch die Allermeisten und vieles ergibt sich aus dem Zusammenhang. > Vor allem weil hier die Frage von > einem Programmierer kam und sich an Programmierer richtete. Da kann man > erwarten daß alle Teilnehmer die Fachtermini kennen. Na wenn alle hier alles kennen würden bräuchten sie gar nicht erst zu fragen.
Gerd E. schrieb: > hängt davon ab wie du lesbar definierst. C++ ist ziemlich mächtig und > mit so Dingen wie z.B. Operatorüberladungen kannst Du sehr > unleserlichen, aber auch sehr leserlichen Code schreiben. Hängt ganz > davon ab wie Du das Stilmittel einsetzt. Das sehe ich auch so. Ich kann nicht nachvollziehen, warum in dieser Hinsicht immer so viel auf C++ geschimpft wird. Qt ist für mich das beste Beispiel, dass man damit wirklich schönen und gut lesbaren Code schreiben kann.
Leute, Leute schrieb: > Gerd E. (robberknight) schrieb: > >>> Denn nenn es doch einfach Kippschaltung. > >> und schon hast Du Informationsverlust. Denn Kippschaltungen gibts in >> Astabil, Bistabil oder Monostabil. Und das macht durchaus einen >> Unterschied. > > Das ist jetzt Korinthenkackerei. Diesen Unterschied kennen auch die > Allermeisten und vieles ergibt sich aus dem Zusammenhang. So, so. Du willst es also für Einsteiger und Fachfremde einfacher verständlich machen, in dem Du von ihnen verlangst die durch Deine ungenaue Sprache verloren gegangene Information aus dem Kontext zu rekonstruieren? >> Vor allem weil hier die Frage von >> einem Programmierer kam und sich an Programmierer richtete. Da kann man >> erwarten daß alle Teilnehmer die Fachtermini kennen. > > Na wenn alle hier alles kennen würden bräuchten sie gar nicht erst zu > fragen. Wenn ich mich nicht täusche hatte der TO nicht nach Fachtermini gefragt.
> Ich habe ja nicht gesagt, dass man solche Begriffe nicht verwenden darf > oder soll. Ich habe nur mal freundlich auf das Beispiel aus dem > Nachbarthread hinweisen wollen. Die Parallele hat sich mir hier > aufgedrängt bei der Anhäufung von Buzzwords hier. Was ist denn für dich der Unterschied zw. Buzzword und Fachbegriff, und warum hälst du deine o.g. Begriffe für Buzzwords? > Du kanntest den Begriff Kippschaltung nicht? > Kaum zu glauben ... Du kennst Tokenizer nicht? Kaum zu glauben!
> So, so. Du willst es also für Einsteiger und Fachfremde einfacher > verständlich machen, Klar, was soll daran falsch sein? Es lesen hier ja auch andere mit. > Was ist denn für dich der Unterschied zw. Buzzword und Fachbegriff, Die Art und Weise des Gebrauchs bzw. des Umgangs damit. > Du kennst Tokenizer nicht? Kaum zu glauben! Da siehst du mal wo wir alle noch so unsere Lücken haben. :) Nein, ganz so ist es nicht. Ich hatte nur ähnliche Gefühle wie old man (Gast) der schrieb " "Da kriege ich schon beim Draufgucken Augenkrebs." beim Betrachten von typedef boost::tokenizer<boost::char_separator<char> > tokenizer; std::string s = "Boost C++ libraries"; tokenizer tok(s); for (tokenizer::iterator it = tok.begin(); it != tok.end(); ++it) std::cout << *it << std::endl; wobei mir das Codestück inzwischen klar geworden ist. Die Frage hier > Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze > oder bläht das die Software unnötig auf? wird dem TE sowieso keiner beantwoten können. Das wird er schon selber rausfinden müssen.
Philip K. (philip_k) schrieb: > Ich kann nicht nachvollziehen, warum in dieser > Hinsicht immer so viel auf C++ geschimpft wird. Qt ist für mich das > beste Beispiel, dass man damit wirklich schönen und gut lesbaren Code > schreiben kann. Ob der Code gut lesbar ist sieht am immer erst in einem direkten Vergleich Ultimate++ vs Qt (R) http://www.ultimatepp.org/www$uppweb$vsqt$en-us.html Ultimate++ vs Java/Swing http://www.ultimatepp.org/www$uppweb$vsswing$en-us.html Ultimate++ vs wxWidgets http://www.ultimatepp.org/www$uppweb$vswx$en-us.html
> Die Art und Weise des Gebrauchs bzw. des Umgangs damit. Also ist die kasuale Verwendung der Fachbegriffe wie hier im Thread kein Buzzword. > Da siehst du mal wo wir alle noch so unsere Lücken haben. :) Mecker halt nicht mit anderen rum wenn du die üblichen Begriffe nicht kennst... > Nein, ganz so ist es nicht. Ich hatte nur ähnliche Gefühle wie old man > (Gast) der schrieb " > > "Da kriege ich schon beim Draufgucken Augenkrebs." beim Betrachten von Das Codestück hat nichts mit Buzzwords zu tun und ist auch nicht so schlimm wenn man sich ein bisschen mit C++ auskennt. >> Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze >> oder bläht das die Software unnötig auf? > > wird dem TE sowieso keiner beantwoten können. Das wird er schon selber > rausfinden müssen. Die Wiederverwendung von passendem Code (Libraries) schrumpft den eigenen Code und die Entwicklungszeit jedenfalls drastisch.
> Mecker halt nicht mit anderen rum wenn du die üblichen Begriffe nicht > kennst... Ich Mecker doch gar nicht. Habe dich doch sogar gelobt weiter oben. Auch habe ich mich weniger am Wort Tokenizer gestört, als an dem Codefragment. Aber in dem Zusammenhang mit dem Posting zuvor erinnerte mich der Gebrauch halt (in der Häufung) an die Buzzwords des Posters mit seinem Haskell. Wer in Haskell geübt ist kann natürlich auch leicht über andere herziehen für die das Kauderwelch darstellt. Also bleib einfach locker und sie die Diskussion als unaufgeregten Plausch.
Hallo, M, nicht Q schrieb: > QT wirklich nur wenn du ein GUI brauchst. Das ist so vermüllt mit > redundanten Typdefinitionen und zwingt zu einer Applikationsstruktur, in > der einfache Dinge plötzlich kompliziert werden, dass es keinen > richtigen Spaß macht. QT ist der Versuch eine eigene Welt, unabhängig > von der darunterliegenden Plattform, zu schaffen, weil man sich vor der > Plattform fürchtet. > > Boost nur, wenn man das harte Zeug in Boost wirklich braucht, also nicht > nur weil man gerne damit angibt möglichst komplizierten Code schreiben > zu können. Boost sicher nicht, um nur ein bisschen Stringverarbeitung zu > bekommen (Pro-Tipp: Die guten alten C-Funktionen gibt es allesamt in > C++). Ich mußte wirklich lange nachdenken, um mich daran zu erinnern, ob ich schon einmal solchen Unsinn gelesen habe. Aber: nein, so einen gewaltigen Unsinn habe ich in meinem ganzen Leben noch nie gelesen. Ja Respekt! Auf so einen Quatsch muß man erst mal kommen! Karnevalistische Grüße, Sheeva
Hallo Mark, Mark Brandis schrieb: > M, nicht Q schrieb: >> QT wirklich nur wenn du ein GUI brauchst. Das ist so vermüllt mit >> redundanten Typdefinitionen > > Bitte was? Bitte bedenke, es ist Karneval! Offensichtlich übt er für seine Büttenrede. Liebe Grüße, Sheeva
Hallo Hans, Hans schrieb: > Die Frage ist: gewinne ich was wenn ich Libs wie Boost oder QT einsetze Ja, zweifellos. Du gewinnst sauberen, wiederverwendbaren Code, den andere bereits für Dich entwickelt und umfangreich debuggt haben. > oder bläht das die Software unnötig auf? Nein. Wenn Du es richtig machst, bindet ein guter Compiler wie der GCC am Ende nur das ein, was Du auch benutzt. > Bieten mir diese Frameworks Features, die mir die Arbeit an obigen > Punkten erleichtern Ja, unbedingt. Das ist der Grund dafür, warum es überhaupt Bibliotheken gibt und warum manche sogar für teures Geld gehandelt werden: weil es immer viel billiger, schneller, stabiler und einfacher ist, bereits ausgereiften Code wiederzuverwenden, als etwas neu zu entwickeln. > oder komm ich ohne genauso schnell ans Ziel? Das kommt primär darauf an, wie viel Aufwand Du in das Erlernen der Libs investieren und wie viel Funktionalität Du von ihnen verwenden kannst. Aber in der Regel kommst Du mit ordentlichen Libraries und Frameworks bedeutend schneller zum Ziel, nicht nur hinsichtlich des Entwicklungs-, sondern vor allem hinsichtlich des Debuggingaufwands. Viel Erfolg, Sheeva
Jörg Wunsch schrieb: > M, nicht Q schrieb: >> QT ist der Versuch eine eigene Welt, unabhängig von der >> darunterliegenden Plattform, zu schaffen, weil man sich vor der >> Plattform fürchtet. > > Nein, weil man auch die Plattform ausreichend abstrahieren muss, wenn > man auf deren mehreren unterwegs ist. Hi Jörg, da stimme ich Dir voll zu. > Da das für den TE allerdings kein Thema ist, braucht man das hier auch > nicht als Entscheidungskriterium zu nehmen. Sollte man. Es macht keinen Sinn ein Programm zu entwickeln was nur auf Windoof läuft :-) old man schrieb: > typedef boost::tokenizer<boost::char_separator<char> > tokenizer; > std::string s = "Boost C++ libraries"; > tokenizer tok(s); > for (tokenizer::iterator it = tok.begin(); it != tok.end(); ++it) > std::cout << *it << std::endl; Wobei ich mich frage, wo ist der Seperator hier angegeben??? Da finde ich persönlich schöner
1 | QString s = "Qt C++ Libraries"; |
2 | QStringList list = s.split(' '); |
3 | for(QStringList::iterator it = list.begin(); it != list.end(); it++) |
4 | {
|
5 | qDebug() << *it; |
6 | //std::cout << it.toStdString() << std::endl; //von mir aus auch so :-)
|
7 | }
|
Naja just my 2 Cents, ich finde es nicht schlimm paar Mb einzubinden, dafür aber Platform unabhängig zu sein :-) Mfg Fabi
Dr. Sommer schrieb: >> Ich verwende auch die >> C++ Standardlib nicht. > Das ist natürlich besonders bekloppt. Die Standardlib ist äußerst > mächtig und effizient; was besseres von Hand hinzubekommen ist utopisch, > und natürlich wahnsinnig unnötige Arbeit. Bei der Gelegenheit kannst du mal einen Blick auf Googles V8 werfen. Reines C++ und portabel zu allen Betriebssystemen und Architekturen. Schade nur dass die bekloppten Entwickler völlig vergessen haben dass es die C++ Standard Lib gibt. Hätten sie doch lieber Dr. Sommer gefragt... Obwohl, liegt die Kernkompetenz von Dr. Sommer nicht ehr im horizontalen Bereich?
Leute, Leute schrieb: > Philip K. (philip_k) schrieb: > >> Ich kann nicht nachvollziehen, warum in dieser >> Hinsicht immer so viel auf C++ geschimpft wird. Qt ist für mich das >> beste Beispiel, dass man damit wirklich schönen und gut lesbaren Code >> schreiben kann. > > Ob der Code gut lesbar ist sieht am immer erst in einem direkten > Vergleich > > Ultimate++ vs Qt (R) > http://www.ultimatepp.org/www$uppweb$vsqt$en-us.html Ich sehe da Unterschiede in der Codelänge aber nicht in der Lesbarkeit.
Philip K. schrieb: > Ich sehe da Unterschiede in der Codelänge aber nicht in der Lesbarkeit. Wenn der Code bei gleich guter Lesbarkeit kürzer ist, so ist das doch eindeutig ein Vorteil von Ultimate++, da einer, der sich in den Code einarbeiten, schneller damit fertig wird, oder?
Yalu X. schrieb: > Philip K. schrieb: >> Ich sehe da Unterschiede in der Codelänge aber nicht in der Lesbarkeit. > > Wenn der Code bei gleich guter Lesbarkeit kürzer ist, so ist das doch > eindeutig ein Vorteil von Ultimate++, da einer, der sich in den Code > einarbeiten, schneller damit fertig wird, oder? Das könnte man schon so sehen. Auch wenn das wohl nicht das einzige Kriterium ist um ein Framework zu beurteilen. Da ich aber Ultimate++ nicht kenne und für mich überhaupt keinen Grund sehe Qt den Rücken zu kehren kann ich dazu auch nicht mehr sagen. Allerdings war das ja auch gar nicht die Frage. Es ging ja darum, ob C++ Code generell schlecht lesbar ist.
old man schrieb: > Bei der Gelegenheit kannst du mal einen Blick auf Googles V8 werfen. > Reines C++ und portabel zu allen Betriebssystemen und Architekturen. So wie die C++ Standard Library. > Schade nur dass die bekloppten Entwickler völlig vergessen haben dass es > die C++ Standard Lib gibt. Hätten sie doch lieber Dr. Sommer gefragt... Auch ohne mich zu fragen wussten sie dass Code wiederverwendung, insbesondere der standard library, sinnvoll ist, weswegen sie das auch getan haben. Im Code findet man schön Verwendung von std::list, std::vector, std::pair, std::max, std::bitset etc. etc. > Obwohl, liegt die Kernkompetenz von Dr. Sommer nicht ehr im horizontalen > Bereich? Deine scheint im Ignorieren von sinnvoller Technologie und im Beharren auf antiken Ansichtsweisen zu bestehen. Aber ich bin gespannt, welche Dinge, die in der C++ Standard Library implementiert sind, kannst du wie und warum effizienter implementieren?
Hey, ohne alles gelesen zu haben; Schonmal an C++11 gedacht? Oder Boost? LG
Dr. Sommer schrieb: > Auch ohne mich zu fragen wussten sie dass Code wiederverwendung, > insbesondere der standard library, sinnvoll ist, weswegen sie das auch > getan haben. Im Code findet man schön Verwendung von std::list, > std::vector, std::pair, std::max, std::bitset etc. etc. Es macht es nicht besser wenn Unwahrheiten behauptet werden. Die V8 implementiert die Listen, Strings und Vectoren komplett selber (utils.h, string-stream.h, list.h). Ich will nicht ausschließen, dass in den Samples die stdlib verwendet wird. Aber eben auch nur dort. Weil sie eben so schlau waren deine Meinung nicht einzuholen. Die haben dir in den Samples nur ein paar Brocken hingeschmissen damit du nicht vom Glauben abfällst. > Aber ich bin gespannt, welche Dinge, die in der C++ Standard Library > implementiert sind, kannst du wie und warum effizienter implementieren? Spätestens wenn du mit großen Datenmengen zu tun hast. Und ich sprechen hier von mehreren Millarden Datensätzen. Wenn du dann die wunderschönen dyn. Strings und Listen aus der Lib verwendest und du dir pro Datensatz eine unbekannte Anzahl automatischer Speicherallocierungen einfängst, weisst du warum man manche Sachen besser selbst macht. Um ein paar Strings fürs Userinterface zusammenzubasteln ist das natürlich nicht nötig. Aber es gibt halt auch noch Anwendungen jenseit von "Hello World".
> Es macht es nicht besser wenn Unwahrheiten behauptet werden. Ebenso. > Die V8 > implementiert die Listen, Strings und Vectoren komplett selber (utils.h, > string-stream.h, list.h). Ich will nicht ausschließen, dass in den > Samples die stdlib verwendet wird. Aber eben auch nur dort. Falsch. Auch im "Core"-Code. z.B. instrument-a64.cc, Zeile 155 und weitere. Das interessante ist dass die "Liste" in list.h das gleiche wie ein std::vector ist, aber ohne nette Features wie move/copy-construct etc. > Weil sie > eben so schlau waren deine Meinung nicht einzuholen. Auch Google macht Fehler; siehe g+ . > Die haben dir in > den Samples nur ein paar Brocken hingeschmissen damit du nicht vom > Glauben abfällst. s.o. > >> Aber ich bin gespannt, welche Dinge, die in der C++ Standard Library >> implementiert sind, kannst du wie und warum effizienter implementieren? > > Spätestens wenn du mit großen Datenmengen zu tun hast. Und ich sprechen > hier von mehreren Millarden Datensätzen. Wenn du dann die wunderschönen > dyn. Strings und Listen aus der Lib verwendest und du dir pro Datensatz > eine unbekannte Anzahl automatischer Speicherallocierungen einfängst, > weisst du warum man manche Sachen besser selbst macht. Wer eine verkettete Liste für eine Mrd Datensätze verwendet hat vermutlich onehin etwas falsch gemacht (-> std::deque). Und wenn du es genau wissen willst, schaust du halt in die Implementation der jeweiligen stdlib; die Sources sind ja offen. Zu faul zu sein dort nachzusehen ist keine Ausrede es nicht zu verwenden. Die Listen-Implementation der GNU stdlib macht jedenfalls genau 1 Allokation pro Element (stl_list.h:334). Wenn du die Allokation besser kontrollieren willst gibt es ja das Allokator Argument. > Um ein paar > Strings fürs Userinterface zusammenzubasteln ist das natürlich nicht > nötig. Aber es gibt halt auch noch Anwendungen jenseit von "Hello > World". Ja, es gibt auch Anwendungen wo man nich akademisch die 1.Millionste verkettete Liste implementiert, und man sich auf eine effiziente korrekte Implementation verlassen möchte, und nimmt daher die STL. Und falls wider Erwarten dann doch einer der Standard Container nicht geeignet ist, ist das immer noch kein Grund die stdlib nicht zu verwenden; die Dinge aus <type_traits>, <algorithm>, <tuple>, <functional> etc. etc. sind immer noch sehr hilfreich. xvzf schrieb: > Hey, > ohne alles gelesen zu haben; Schonmal an C++11 gedacht? Oder Boost? Ja, wurde beides ca. 100x in diesem Thread erwähnt. Strg+F hilft.
Dr. Sommer schrieb: > Falsch. Auch im "Core"-Code. z.B. instrument-a64.cc, Zeile 155 und > weitere. Das interessante ist dass die "Liste" in list.h das gleiche wie > ein std::vector ist, aber ohne nette Features wie move/copy-construct > etc. Das interessamte daran ist, dass es im V8-Code diese Datei nicht gibt. Sie wird auch definitiv nicht für die reine V8lib benötigt. > Ja, es gibt auch Anwendungen wo man nich akademisch die 1.Millionste > verkettete Liste implementiert, und man sich auf eine effiziente > korrekte Implementation verlassen möchte, und nimmt daher die STL. Die STL ist dafür gemacht um einen breiten Bereich abzudecken und erhebt nicht den Anspruch für alles die beste Implementierung zu sein. Es gibt aber immer wieder Deppen die das nicht für möglich halten. Google mag ja viele Fehler gemacht habe, keine Frage. Bei der V8 aber mit Sicherheit nicht. An dieser Stelle werde ich die zu nichts führende Diskussion beenden. Du hast damit angefangen mit dem Wort "bekloppt" Beleidigungen in den Raum zu werfen, und ich werden jetzt dem Klugscheißer keine weitere Munition liefern.
old man schrieb: > Das interessamte daran ist, dass es im V8-Code diese Datei nicht gibt. > Sie wird auch definitiv nicht für die reine V8lib benötigt. Wir reden vom selben Programm, ja? http://code.google.com/p/v8/wiki/Source?tm=4 old man schrieb: > Es gibt > aber immer wieder Deppen die das nicht für möglich halten. Viel schlimmer sind die Deppen, die eine etablierte Implementation aka std::list, ohne es begründen zu können, für schlecht halten, und lieber ihren eigenen Mist produzieren, über den sich dann spätere Maintainer freuen. old man schrieb: > Google mag ja viele Fehler gemacht habe, keine Frage. Bei der V8 aber > mit Sicherheit nicht. Wenn du das sagst. old man schrieb: > An dieser Stelle werde ich die zu nichts führende Diskussion beenden. Dann Tschüss. Für den geneigten Leser bleibt also anzumerken, dass hier bislang kein echtes Argument gegen die Standard Library im Allgemeinen und std::list im Besonderen geliefert wurde, und diese somit die richtige Wahl sind.
old man schrieb: > Die STL ist dafür gemacht um einen breiten Bereich abzudecken und erhebt > nicht den Anspruch für alles die beste Implementierung zu sein. Es gibt > aber immer wieder Deppen die das nicht für möglich halten. Es gibt aber leider auch viele "Deppen", die meinen, ihr Standard-Anwendungsfall ist hochspeziell und funktioniert nicht, ohne alles selbst zu implementieren. Das Resultat sind dann nicht selten fehlerhafte Programme, die weniger effizient sind als mit den Standardkomponenten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.