C++: Framework oder nicht? (keine GUI)

Ε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++).

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.

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.

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.

old man:
> [STL zu langsam]
> [flusht sinnlos nach jeder Zeile den Buffer mit std::endl]

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 ...

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.

> 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.

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?

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.