Wahl der Programmiersprache für ein Projekt / Erfahrungen?

k_e_x

Well-Known Member
Hallo zusammen,

mir ist durchaus bewusst, dass wenn es um Programmiersprachen geht, teilweise pseudo-religiöse Ausbrüche bei Diskussionen vorkommen können. Mir geht es hier aber nüchtern betrachtet nur um eine Empfehlung, welche der Sprachen für meine Anwendungszwecke nützlich(er) sein könnte und eure Erfahrungen, nicht darum, welche Sprache "besser" oder "schlechter" ist.

Situation:
  • Projektleiter an einem Forschungsinstitut mit einem Team aus 4-5 Mitarbeitern
  • Windows ist seitens der IT die offiziell unterstützte Platform / Linux wird aber dennoch von einigen Mitarbeitern als einziges OS auf dem Rechner genutzt (durch die IT geduldet, durch einige Abteilungsleiter gefördert)
  • Persönliche Programmiererfahrung:
    • C, geringfügig C++
    • Java (von JavaCard, über normales Java hin zu WebServices)
  • Anwendung:
    • Steuerung von eingebetteten Systemen (Mikrocontroller/FPGA) für Datenerfassung
    • Erfassung der Daten teilweise über Stunden oder Tage hinweg (Klimakammertests, etc)
    • Teilweise auch Auslagerung der Datenerfassung an Studenten für zu vermessende Testobjekte (d.h., einzelnes Gerät, viele Testobjekte, Steuerung dann über GUI zwingend erforderlich)
    • Auswertung der erfassten Daten (vmtl. in Matlab bzw. Scilab)
    • Vor-Verarbeitung der Daten und/oder Plots parallel zur Datenerfassung oft hilfreich (d.h. man läuft zur Klimakammer und sieht auf dem angezeigten Plot den zeitlichen Verlauf der Rohdaten)
  • Anforderungen entsprechend:
    • Cross-Platform (Windows / Linux)
    • GUI
    • Stabil (!!!)
    • Kommunikation über USB (virtual ComPort)
    • Auslieferung der Anwendung muss als binär-Datei möglich sein (quasi, als copy-paste auf anderen PC)
    • Neue Mitarbeiter/Studenten sollten sich in den Code halbwegs leicht einarbeiten können
    • Programmieraufwand bis zum Ergebnis möglichst gering (es geht also nicht darum, die beste Software zu schreiben, sondern die Aufgabe zu lösen, was sich ebenfalls durch den zu erwartenden geringen Nutzerkreis begründen lässt)
Was ich bisher beobachtet habe ist: Viele Mitarbeiter setzen auf Python, was *jedes* mal dazu führt, dass wenn ich eines dieser Projekte nutzen will, massive Probleme habe durch Abhängigkeiten und die Problematik Python2 vs Python3. Durch den wissenschaftlichen Charakter am Institut werden diese Projekte natürlich auch nicht ordentlich maintained (d.h., Software wird oft für ein spezifisches Projekt geschrieben und dann gammelt sie 1-2 Jahre herum, bis mal wieder jemand daraus einen Nutzen ziehen möchte). Python ist daher für mich irgendwie keine reelle Lösung??! (mag auch an meiner Python-Unkenntnis liegen)

Was wären also mögliche Empfehlungen (und warum)?
  • C/C++ ggf. mit Qt oder GTK als GUI?
  • Java?
  • Go?
  • Swift?
  • Rust?
Grundsätzlich wäre es kein Problem sich in eine neue Sprache einzuarbeiten (bei egal welcher Wahl, müsste das einer der Projektmitarbeiter ohnehin tun), weshalb ich das Thema "Vorkenntnisse" gerne nicht zu stark gewichten würde. Bisher tendiere ich dennoch zu einer C/C++ Lösung (bissle Erfahrung vorhanden) mit entsprechendem GUI (da jedoch 0 Erfahrung meinerseits vorhanden), da mir Java ggf. als zu intransparent erscheint was bei Stabilitätsproblemen dann die Fehlersuche unmöglich macht.

Gibt es von eurer Seite Anregungen oder Nachfragen dazu? Was würdet ihr für diesen Anwendungsfall nehmen?
 
Ich beschränke mich erst einmal auf einen recht kleinen Teilaspekt der ganzen Frage:

Was wären also mögliche Empfehlungen (und warum)?
  • C/C++ ggf. mit Qt oder GTK als GUI?
  • Java?
  • Go?
  • Swift?
  • Rust?

Ich habe das Pech, mich beruflich unter anderem mit den guten Ideen und Moden der Vergangenheit herumärgern zu müssen und meine Konsequenz aus den daraus resultierenden Erfahrungen ist: Nehme für ein ernsthaftes Projekt um Gottes Willen eine möglichst weit verbreitete, etablierte und standardisierte Sprache. In deiner Liste sind es im Moment C/C++ und Java, mit ein wenig Wohlwollen vielleicht noch Go. Rust und Swift mögen sich durchsetzen, vielleicht programmieren wir in 10 Jahren alle darin. Aber es besteht eben auch die Gefahr, dass Mozilla und Apple beschließen, dass die Sprache eine dumme Idee waren und sie wieder fallen lassen. Und dann sitzt du da, hast zehntausende oder hunderttausende Zeilen Code in einer Sprache ohne aktuellen Compiler und mit Bibliotheken aus der dunklen Vergangenheit. Aber auch aktuell haben junge und nur von Randgruppen genutzte Sprachen ihre Probleme. Wie sieht es mit Bindings zu den großen Toolkits aus? Welche Qualität haben die Interfaces zum darunter liegenden Betriebssystem. Und so weiter.
 
Ich arbeite mit C++ und Python und deine Erfahrung mit der Abhängigkeitshölle bei Python kann ich bei uns im Institut leider auch bestätigen.
Ich habe auch den Verdacht, dass aus PyPI Packetversionen mit der Zeit verschwinden und damit irgendwelche gut gemeinten Install-Scripte nach einem Jahr einfach nicht mehr funktionieren.
Anderseits werden bei uns, wenn's denn erst mal läuft, Messgeräte von Pythonprogrammen stabil über Monate hinweg gesteuert. Also der Interpreter selber ist schon gut. Außerdem ist mein Eindruck, dass sich wissenschaftliche Steuerungs- und Auswertungssoftware in Python schneller implementieren lässt, als in C++, einfach weil man einfacher an entsprechend nützliche Python Pakete kommt, als an äquivalente C/C++ Bibliotheken.

Mit C++/Qt kann man deine Anforderungsliste erfüllen, außer, dass die letzten beiden Punkte im Konflikt stehen.
Ich habe keine Erfahrungen in Java, aber gehört, dass Hardware anzusteuern in Java eher keinen Spaß macht.
 
Studenten kommen und gehen, die müssen ohnehin schnell sich anderswo einarbeiten. Wenn diese aber rasch zu lesbaren Code kommen wollen, sehe ich keine Alternative zu Python. Zur Not vielleicht noch Java, wenn die Schützlinge das bereits mehrheitlich beherrschen und ihr auch damit arbeiten könnt.
Und noch ein Punkt zu den veränderten Abhängigkeiten und Brüchen bei Python, man updatet niemals ohne Grund seine Bibliotheken oder Sprache.
 
Beim Microcontroller selbst kommst du in meinen Augen um C kaum herum, vielleicht auch C++ wenn es eine STL-Implementierung dafür gibt. Was GUIs angeht bin ich ein Qt-Fanboy, Java-Oberflächen finde ich persönlich unerträglich. Generell würde ich Empfehlen, die einzelnen Teilaufgaben in den passenden Sprachen zu erledigen.

Python mag ich zwar auch gerne, aber auch das ist keine magische Lösung für alle unsere Probleme, auch in Python kann häßlicher Code geschrieben werden. Durch die dynamische Natur wird das meiner Erfahrung nach irgendwann schwer wartbar, wenn viele unterschiedliche Personen nacheinander an dem Projekt arbeiten, vor allem wenn diese auch noch unterschiedlich viel Erfahrung haben. Tests wären dann unerlässlich, aber gerade im akademischen Umfeld ist das schreiben von Tests nicht sehr weit verbreitet. Wenn es schnell gehen muss und eher temporären Charakter hat, dann ist Python super, aber langfristige Pflege größerer Projekte finde ich persönlich eher schwierig.

Entsprechend blieben Java, C und C++ übrig, ich persönlich würde C für die Logik und C++/Qt für die GUI nutzen, aber beides wäre (vermutlich deutlich) schwieriger zum Einarbeiten als Java. C und C++ hätten hingegen den Vorteil, dass sie schonmal näher an der Hardware sind, JNI (Java Native Interface) halte ich insgesamt für Komplizierter als gleich C++ zu nehmen. Und wenn man boost und Template Meta Programming weglässt, dann ist modernes C++ auch garnicht mehr so häßlich.
 
Python ist, mit Verlaub, ziemlich geil für Prototypen, weil man damit unabhängig von seinen Vorkenntnissen meist schnell was fertig bekommt. Dass einem das ganze Ding beim nächsten Paketupdate um die Ohren fliegen kann, macht es aber für das finale Produkt in der Regel unbrauchbar.

Bei Java bin ich religiös und würde gern jedem, der dir Java empfiehlt, die Finger einzeln abhacken, damit er mal sieht, was Schmerzen sind. Aber wie wär's mit Delphi/Lazarus? Hab' ich mich in letzter Zeit mal wieder mit befasst, kann "Cross-Platform" und GUI, ist schnell und stabil, linkt grundsätzlich statisch (Ergebnis = eine Binärdatei, Copy & Paste überhaupt kein Problem), das Sprachdesign ist nie aus dem Konzept einer Lehrsprache herausgewachsen (Einarbeitung ist also Pipifax) - eigentlich doch optimal für euch.
 
da mir Java ggf. als zu intransparent erscheint was bei Stabilitätsproblemen dann die Fehlersuche unmöglich macht.

Bei allen hässlichen Warzen der Java-Welt - bei jedem Ausflug nach Python oder C/C++ wünsche ich mir die Instrumentierung der JVM herbei, sobald etwas nicht erwartungsgemäß funktioniert.

Studenten kommen und gehen, die müssen ohnehin schnell sich anderswo einarbeiten. Wenn diese aber rasch zu lesbaren Code kommen wollen, sehe ich keine Alternative zu Python. Zur Not vielleicht noch Java, wenn die Schützlinge das bereits mehrheitlich beherrschen und ihr auch damit arbeiten könnt.

Das ist auch meine Einschätzung.

Einzige Schwachstelle wäre noch der USB-Zugriff, den kriegt man aber mit PyUSB oder usb4java hin.

Aber wie wär's mit Delphi/Lazarus?

Delphi bewegt sich arg Richtung Legacy. An k_e_x' Stelle würde ich damit im Jahre 2016 kein Projekt mehr anfangen, zumal mit wechselndem Personal.
 
Ich würde für so etwas C/C++ mit eingebettetem Lua verwenden. Dein Hauptprogramm sowie das was notwendig ist (Microcontroller etc) schreibst du in C/C++, und verwendest ansonsten Lua, auch für Prototyping. Lua ist portabel, leicht einzubetten und sieht praktisch aus wie Pseudo-Code was Studenten entgegenkommen sollte. Als GUI biete sich dann IUP an, das sowohl von C/C++ als auch von Lua aus verwendet werden kann. Außerdem kannst du Lua auch sehr gut direkt zur Konfiguration oder als als Datenformat verwenden, z.B. an Stelle von JSON o.Ä.

Außerdem habe ich seit kurzem gute Erfahrungen mit Premake5 als portablen make generator gemacht das intern und zur Konfiguration Lua verwendet. Weit unproblematischer und leichter zu verstehen als z.B. CMake.
 

... unterstützt leider Python 3 nicht.

Verwechselst du gerade "das Ökosystem ändert sich nicht mehr alle zwei Wochen radikal" mit "ist veraltet"? Stabile APIs!

Stabile APIs sind nur die halbe Miete:
  • Kleine und schrumpfende Nutzerbasis, d.h. etwaige neue Mitarbeiter haben weder Erfahrung mit noch Interesse an Delphi
  • Kaum Aktivität im Open-Source-Bereich (z.B. auf GitHub nicht einmal unter den Top 50 der aktiven Programmiersprachen)
  • Wissenschaftliche Bibliotheken erscheinen in anderen Programmiersprachen, d.h. was es anderenorts (z.B. unter Python) als Open Source frei Haus gibt, müsste k_e_x und Kollegen erst alles selber implementieren
 
Kleine und schrumpfende Nutzerbasis, d.h. etwaige neue Mitarbeiter haben weder Erfahrung mit noch Interesse an Delphi

Kann man ziemlich schnell lernen, also die Erfahrung. Was das Interesse angeht: Ich für meinen Teil habe noch nie an einer Sprache so schnell das Interesse verloren wie an Java. Könnte am Studium liegen.

Kaum Aktivität im Open-Source-Bereich (z.B. auf GitHub nicht einmal unter den Top 50 der aktiven Programmiersprachen)

Verwechsle nicht Hype und Aktivität. Seit Lazarus hat sich da auch manches verbessert; mal abgesehen davon, dass es von Haus aus schon viele Dinge mitliefert, die man in anderen Sprachen erst nachprogrammieren muss, weshalb es dafür natürlich auch viele konkurrierende Lösungen gibt.

Wissenschaftliche Bibliotheken erscheinen in anderen Programmiersprachen

Nämlich in R. Trotzdem würde niemand hier @k_e_x zu R raten, weil es halt ansonsten eine nicht besonders geeignete Sprache für seine Zwecke ist.
 
[*]Steuerung von eingebetteten Systemen (Mikrocontroller/FPGA) für Datenerfassung

Bei FPGAs würde ich wenn möglich auf OpenCL setzen das erfordert deutlich weniger Erfahrung und Know-How um ordentliche Ergebnisse zu erzielen als VHDL oder Verilog.

[*]Erfassung der Daten teilweise über Stunden oder Tage hinweg (Klimakammertests, etc)

Da würde ich auf C++ setzen und Konsequent RAII und Smart-Pointer einsetzen. Memory-Leaks sind dein großer Feind, der Einsatz von valgrind ist Pflicht. Wenn Du mit µCs arbeitest bleibst Du wahrscheinlich auf C hängen.

[*]Teilweise auch Auslagerung der Datenerfassung an Studenten für zu vermessende Testobjekte (d.h., einzelnes Gerät, viele Testobjekte, Steuerung dann über GUI zwingend erforderlich)

Ich würde das GUI möglichst von dem Tool trennen. Das heißt natürlich das Tool braucht ordentliche Schnittstellen gegen die man gut programmieren kann. Entweder über Pipes oder eine Programmierschnittstelle. Der Hintergrund ist, dass Toolkits große Abhängigkeiten sind die man nicht in seiner Kernanwendung drin haben will. Ich bin bei Abhängigkeiten immer sehr vorsichtig. Boost geht für mich in Ordnung alles Andere will wohl überlegt sein. Ich weiß Code-Reuse ist Modern und bringt Vorteile mit sich. Aber wenn man Abhängigkeiten deren Entwicklung nicht in der eigenen Hand liegen einsetzt, dann fängt man sich eine externe Fehlerquelle ein.

[*]Auswertung der erfassten Daten (vmtl. in Matlab bzw. Scilab)

Da haben sich CSVs als langfristig und universell unterstütztes Datenformat bewährt. Womit man die Auswertung dann macht hängt von den eigenen Erfahrungen ab. Ich schmeiße Daten gerne in PostgreSQL und mache das dann mit SQL Queries.

[*]Vor-Verarbeitung der Daten und/oder Plots parallel zur Datenerfassung oft hilfreich (d.h. man läuft zur Klimakammer und sieht auf dem angezeigten Plot den zeitlichen Verlauf der Rohdaten)

Dann muss deine Aufzeichnungseinrichtung in der Lage sein die Daten zu Streamen. Achte darauf dass das in einem separaten Prozess passiert. Das Aufzeichnungsprogramm sollte nicht mitbekommen wenn der hängt, stirbt oder neu gestartet wird.

[*]Anforderungen entsprechend:
  • Cross-Platform (Windows / Linux)
  • GUI
  • Stabil (!!!)
  • Kommunikation über USB (virtual ComPort)
  • Auslieferung der Anwendung muss als binär-Datei möglich sein (quasi, als copy-paste auf anderen PC)
  • Neue Mitarbeiter/Studenten sollten sich in den Code halbwegs leicht einarbeiten können
  • Programmieraufwand bis zum Ergebnis möglichst gering (es geht also nicht darum, die beste Software zu schreiben, sondern die Aufgabe zu lösen, was sich ebenfalls durch den zu erwartenden geringen Nutzerkreis begründen lässt)

Beschränke Dich in der Kernkomponente auf Boost und die STL. Bei der GUI würde ich auf QT setzen, nicht weil ich das mag oder damit Erfahrung hätte, sondern weil das die einzige ernst zu nehmende Cross-Platform GUI ist, wenn man kein Webinterface bauen will.

Wie stabil eine Anwendung ist hängt nicht so sehr von der Sprache ab sondern vom Verständnis der Sprache und des Problems das man löst. Hier hilft eine Versionskontrolle, Unit-Tests und Peer-Reviews sind auch toll, wenn man denn Zugang zu kompetenten Kollegen hat. Wenn man das nicht hat reichen 2 Wochen Abstand um den Code selbst zu Reviewen. In der Zeit ist man so weit raus, dass man das selbst mit neuen Augen sieht. Natürlich ist ein Anderer Reviewer trotzdem besser, weil er einen eigenen Erfahrungsschatz hat.

Was die Anfängerkonformität angeht hängt das von der Qualität der Kommentare ab. Ich bin ein Freund ausführlicher Kommentare, die die Idee hinter dem folgenden Code erklären. Niemand anderes scheint das so zu sehen, aber mir hilft das sehr, wenn ich Code bearbeite den ich 2 Wochen oder 2 Jahre nicht mehr angefasst habe.

Was ich bisher beobachtet habe ist: Viele Mitarbeiter setzen auf Python, was *jedes* mal dazu führt, dass wenn ich eines dieser Projekte nutzen will, massive Probleme habe durch Abhängigkeiten und die Problematik Python2 vs Python3. Durch den wissenschaftlichen Charakter am Institut werden diese Projekte natürlich auch nicht ordentlich maintained (d.h., Software wird oft für ein spezifisches Projekt geschrieben und dann gammelt sie 1-2 Jahre herum, bis mal wieder jemand daraus einen Nutzen ziehen möchte). Python ist daher für mich irgendwie keine reelle Lösung??! (mag auch an meiner Python-Unkenntnis liegen)

Python ist toll um Sachen schnell auszuprobieren. Mit der Einführung von python3 wurde die Zukunft der Sprache aber vernichtet. Das wofür man C++ so gerne kritisiert macht es für Code der lange halten muss zur 1. Wahl. Legacy Code wird vom Konsortium nicht gebrauchen. Features werden nur entfernt, wenn sie in 1000en von Code-Basen nicht verwendet werden. Dazu werden vom Konsortium nicht nur Open-Source Projekte sondern auch die Repositories großer Software-Firmen wie Microsoft angezogen.

Python hat sich mit dem Bruch von 2 zu 3 ins aus befördert. Die Sprache war schon zu weit verbreitet für solche Sachen. Nebenbei skaliert es auch schlecht.

Was wären also mögliche Empfehlungen (und warum)?
  • C/C++ ggf. mit Qt oder GTK als GUI?
  • Java?
  • Go?
  • Swift?
  • Rust?

Hier kommen eigentlich nur C/C++ in Frage. Egal was man Dir erzählt, Java ist nicht für Echtzeit geeignet. Damit kannst Du die GUI machen aber den Rest nicht. Alles andere ist nicht abgehangen genug.
 
Kann man ziemlich schnell lernen, also die Erfahrung. Was das Interesse angeht: Ich für meinen Teil habe noch nie an einer Sprache so schnell das Interesse verloren wie an Java. Könnte am Studium liegen.



Verwechsle nicht Hype und Aktivität. Seit Lazarus hat sich da auch manches verbessert; mal abgesehen davon, dass es von Haus aus schon viele Dinge mitliefert, die man in anderen Sprachen erst nachprogrammieren muss, weshalb es dafür natürlich auch viele konkurrierende Lösungen gibt.



Nämlich in R. Trotzdem würde niemand hier @k_e_x zu R raten, weil es halt ansonsten eine nicht besonders geeignete Sprache für seine Zwecke ist.
Lazarus hinkt Delphi gut 10 Jahre hinterher und Delphi modernen Entwicklungsumgebungen nochmal das gleiche. Und ja ich muss mich mit dem Kram auseinander setzen. Delphi eignet sich hervorragend um schlecht wartbaren Code zu fabrizieren. Nur Leute ohne Verstand investieren tausende Euros in so kaputter Software mit trübenden Zukunftsperspektiven.
 
Man braucht nicht immer das neueste shiny bling, um Aufgaben zu lösen. C++ ist jetzt auch nicht gerade hypermodern. Für die gestellte Aufgabe wäre Lazarus ganz gut geeignet, das ist meines Wissens zumindest weitgehend mit Delphi 2007 kompatibel (und seitdem hat Delphi ja nichts Habenswertes mehr hinzugefügt, Firemonkey mal außen vor gelassen).
 
Caching bei der Übersetzung, ich glaub das gibts seit Delphi 1.0, kann FreePascal "noch" nicht. Man kann praktisch jede Delphi Versionen nehmen und Features finden die Lazarus/Freepascal nicht besitzt und da gibts einige. Aber ein großer Nachteil warum keiner FreePascal nutzt, trotz besseren Editor, es kommt nicht mit alten und nicht im Source verfügbaren Kram zurecht.
 
Nimm das, was möglichst viele schon beherrschen und verbreitet ist: Ich würde deswegen Java wählen. Und wenn wirklich copy und paste der Anwendung möglich sein soll; eine war-Datei lässt sich auf dem Tomcat Server auch im laufenden Betrieb austauschen ;)

Ich würde die GUI mittlerweile auch im Browser machen, selbst wenn die Anwendung nur lokal läuft. Da kann man dann auch mal die reine Steuerung der Geräte über ein Smartphone oder Tablet machen.
 
Vielen Dank für eure zahlreichen Beiträge und Erfahrung. Es scheint dann tatsächlich so zu sein, dass man an der Stelle um C/C++ mit GUI (vmtl. QT) dann nicht herum kommt -- bzw. noch immer nicht herum kommt! Gut, ich betrachte das sportlich und auch für mich als Chance mich in ein neues Thema (GUI mit C/C++) einzuarbeiten. Gibt es hierzu vielleicht noch eine passende Buchempfehlung von euch?

Der Mikrocontroller selbst wird sowieso mit C sein, der FPGA sowieso mit VHDL / da gibt es im Prinzip auch keine Alternativen. Es ging mir also ausschließlich nur um die Desktop-Anwendung zur Ansteuerung.

Vielleicht noch als ergänzende Frage dann: Würdet ihr dann bspw. direkt auf C++11 setzen?

Edit: Hintergrund der C++11-Frage ist, da ich in einem kleinen Hobby-Projekt mit C++11 gearbeitet habe und genau die Dinge out-of-the-box liefen, wofür man sonst dann eben boost hätte verwenden müssen ...
 
FPGA ist ein Bereich wo OSS ein Fremdwort ist. Da wird sich einiges in den nächsten Jahren noch tun. In meinen Abschlussarbeit hatte ich mich intensiv mit Matlab auseinandergesetzt, wo es ja auch FPGA Module gibt. Die Hölle für jeden der programmieren kann, Ing. mögen den Quatsch wohl.
Wenn C++ dann bitte die Version einfrieren und nicht ständig den neusten Versionen hinterher implementieren. Ist aber so gar nicht meine Welt, gibts einen Grund warum nicht C#?
 
Natürlich gibt es auch Literatur für die Klassenbibliothek QT. Allerdings werde ich mich hüten, eine Empfehlung abzugeben, da ich die Qualität nicht wirklich berauschend finde. Die allerbesten Erfahrungen habe ich mit der QT eigenen Dokumentation gemacht, die allererste Sahne schon in früheren Versionen und auch noch heute ist. Die mitinstallierten Beispiele sind die Demos und Examples, die meineserachtens sehr viel für die GUI Programmierung abdecken. Ich wünsche Dir viel Erfolg mit Qt und denke, Du hast eine gute Wahl getroffen.
 
Wie ich schon sagte, bei FPGAs geht inzwischen auch OpenCL. Das ist nicht nur einfacher zu programmieren als VHDL, das Fitting wird dadurch auch einfacher.
 
C++11 sollte inzwischen auf allen relevanten Plattformen verfügbar sein und bietet in meinen Augen deutliche Vorteile. Je nach dem welche Visual Studio-Version unter Windows unterstützt werden soll wäre C++14 natürlich auch empfehlenswert.

Generell würde ich heute von C++98 eher abraten.
 
Anders gesagt: Da zweimal pro Dekade ein neuer C++-Standard rauskommt und der bisherige Standard damit umgehend veraltet ist, gewöhn' dir am besten gar keinen an.
 
Das wird dann zu solchen Blüten führen das keiner mehr weiß warum hier C++ und da Boost verwendet wurde. Warum da ein Workaround und dort wieder aktuelleres C++.
 
Zurück
Oben