Unterforum C++ auch offiziell für Boost?

volkard

Hutzli schrieb:

Das suggeriert, es dies sei die übliche vorherrschende Einteilung der n->unendlich Unterteilungen von verschiedenen Arbeitsweisen und Problemlösungsansätzen.

echt? das glaube ich nicht.

Tatsächlich kann ich das nur für einseitig halten, und verbreitet ist es wohl eher unter den Pre-Standard-Entwicklern. Ich hab sie jedenfalls schon lange nicht mehr gehört und bin auch schon aus der Pre-Standard-Zeit .

es soll auch anfänger geben. soll es geben, ja. leute, die erstmal eine schleife hinkriegen müssen. die von copy und stream-iteratoren im moment gar nix haben. die dauernd mit stl vollzunerven ist nicht produktiv. und das wird schlimmer, wenn die stl üblicher wird.

Zunächst mal gibt es in Standard-C++ keine STL,

ach? ich nenne teile der standarlib so und du weißt, welche teile ich meine. wie klasse. du klungst wie ein physiklehere der sagt "es gibt keine kälte, es gibt nur mangel an wärme" und von den kids in der klausur verlangt, daß sie sagen "ein kühlschrank macht innen wärme weg" statt "ein kühlschrank macht innen kalt". kein witz, so lehrer gips.

und jenes was fälschlicherweise oft so genannt wird, die Standard C++ Library, ist integraler Bestandteil der Sprache vom ersten Tag ihrer konkreten Standardisierung.

dennoch gibt es eine sinnvolle trennung zwischen sachen wie clock(), sqrt(), abs(), swap(), iostream einerseits und copy(), vector, next_permutation(), lexicographical_compare() andererseits. letzteres nenne ich stl.

Dies herauszulösen macht aus C++ eine andere Sprache. Wenn man also so argumentiert muß auch der ISO-Standard-Hinweis aus der Beschreibung gelöscht werden, der ist dann nämlich Makulatur.

du argumentierst damit, man müsse dann ein wort löschen? oh schrecklich. ja, ein gelöschtes wort würde ich in kauf nehmen.

Ob boost in die Beschreibung hinein soll, ist sicher eine andere Frage, dazu kann man stehen wie man will, aber ein Splitten der Sprache C++ in zwei Teile halte ich für Unsinn.

ok, du willst nicht splitten. da hab ich auch nix dagegen.

aber wenn splitten, dann halt nicht zwischen c++-stl und boost, sondern zwischen c++ und stl-boost.

hier will einer die ganze zeit ein boost-unterforum, und ich meine, dann müßte man stl da auch reinpacken. was ist so schwierig an dem gedanken? nur, daß die stl formal zu c++ gehört? wir können durchaus unser eigenes c++ ohne stl oder unser eigenes c++ mit boost definieren und werden nicht daran sterben.

Artchi

Kann ja sein, das ich auf dem falschen Dampfer bin, aber seit wann ist die STL nicht im C++ Standard drin? Bjarne Stroustrup hatte doch damals extra bei den STL-Erfindern nachgefragt, ob er die STL in die ISO aufnehmen darf. Was auch prompt erlaubt wurde. Und jetzt soll die STL nicht im Standard drin sein?

Ich lasse mich aber gerne eines besseren belehren. Bin ja lernfähig.

Was die Benutzung der STL angeht: ja, für Anfänger kann sie verwirrend sein. Muß aber sagen, das auch die Literatur die es gibt daran schuld ist und nicht die STL selbst.

Und ich bin der Meinung, das man die STL in seinen C++ Projekten benutzen sollte, ohne Wenn und Aber.

Volkard hat aber auch Recht, wenn er sagt, das wenn man die Boost benutzt, das auch autom. die STL benutzt wird. Viele Konzepte sind der STL nachempfunden, ja, einige vererben sogar von der Standard-Library (z.B. boost::filesystem::fstream), es gibt Abhängigkeiten zur STL oder benutzen mind. den std::string (endlich mal eine Lib die std::string und nicht C-Strings benutzt!!!). Deshalb liebe ich Boost, auch wenn ich bisher nur einen kleinen Teil von Boost nutze (soll aber mehr werden).

Übrigens Volkard! Ich wollte erst kein Boost-Unterforum, sondern lädiglich Boost offiziell im C++-Unterforum dabei haben. Ist ja schon was anderes. Wenn aber die Mehrheit ein Boost-Unterforum will, dann würde ich dem nicht abgeneigt sein... weil ich mir denke: besser als garnichts.

Hutzli

Also, um das jetzt nicht ausarten zu lassen, ja, natürlich gibt es Anfänger, und genau darum halte ich die Trennung nicht für Sinnvoll, die haben es dann nämlich noch schwerer das richtige Brett zu finden. Okay, sie werden ja verschoben, wenn sie falsch liegen, aber helfen tut es wohl trotzdem nicht, weil sich der Unterschied nicht implizit aufdrängt, wenn man nicht eh schon den Durchblick hat, die Verschiebungen erzeugen Rauschen, und der Traffic scheint mir beileibe nicht so hoch, das daraus ein Gewinn resultiert (auch wenn das C++-Forum zugegeben den grössten Traffic hat).

Das Du das mit dem "Wort" so überspitzt ist schade, aber letztlich wohl einfach darauf zurückzuführen das mein Beitrag zu sehr nach persöhnlichem Vorwurf aussah, ich empfinde die Existenz dieses "ISO-Standards" als eine Wohltat und bin in meinem Berufsleben sehr froh das es ihn gibt, hilft einem das doch immer mal wieder, wenn man einem Compilerhersteller ein wenig Stress machen muß (und manchmal bekommt man dann auch was man braucht). Es geht mir also nicht um das Wort, sondern um die Bedeutung, ich denke es ist gut, das alles was zur Sprache an sich gehört in das Forum passt und dort auch bleiben sollte. Wenn ich die Bedeutung des Standards im Forum überinterpretiere, dann bitte ich zum einen mir das zu sagen und es meiner kurzen Zeit hier zuzuschreiben, zum anderen kann ich mir dann höchstens vornehmen, zu versuchen das zu ändern.

Natürlich kann und sollte nicht auf jede Frage ein fettes Konstrukt aus Algorithmen, Iteratoren und Funktionsobjekten folgen, das verschrekt und hilft niemandem. Aber nur weil man die Lib im Forum lässt bedeutet das ja nicht, das man die Fragenden damit erschlagen muß. Ich hatte auch nicht den Eindruck das es bisher dazu gekommen wäre.

Zu der Sache mit dem Namen der Lib: Das sollte kein Angriff auf Dich sein, wir kennen uns ja garnicht, sondern nur eine kleine Feststellung, weil diese Verwechslung schon manchen zu Problemen geführt hat, gibt es doch zwischen der STL von HP/SGI und dem was dann im Standard gelandet ist einige subtile Unterschiede so das es hilft zu wissen das es eigentlich zwei (zugegeben sehr ähnliche) Dinge sind. Für alte Hasen ist das natürlich kein Thema, aber die stellen hier eh keine Frage. Also sorry, wenn es klang wie eine Attacke, als die war es nicht gedacht.

Zur Definition von C++: Die habt Ihr halt selber getroffen, da hab ich die Beschreibung als Verbindlich angesehen (weil viele Foren und Newsgroups sehr OT-empfindlich sind und diese daher sehr ernst nehmen), aber natürlich kann man sich davon lösen und einen eigenen Mix festlegen und sogar argumentieren das man sich damit von sowas wie d.c.l.iso-c++ differenziert. Ich weiss eben nicht wie formal das ganze sein soll. Leider geht das auch aus keinem weiterführendem Text hervor, den ich hier gefunden habe. Also macht wie's beliebt, auch ich sterbe sicher nicht.

Zum eigentlichen Thema und um auch mal Farbe zu bekennen: Ich bin nicht nur gegen das Splitten, ich bin auch gegen die Erwähnung von boost in der Beschreibung, denn es adelt die (in meinen Augen in vielen Teilen hervorragende Sammlung) vielleicht über Gebühr und täuscht über die Probleme hinweg die ein Einstieg in boost (sicher auch Einsteigern, manchmal bei ihren Compilern) erstmal macht. Die Standard-Lib passt ja meist noch zum Compiler (wenn sie auch nicht immer ganz konform ist) aber wer mal mit boost an die Wand läuft hat schon ein echtes Problem, wenn er selber wenig Erfahrungen hat.

Und nun bitte wieder mehr auf die Themen bezogen, es lohnt nie im Internet, egal welche Plattform, aufeinander herumzuhacken. Solange man einander nicht aus dem RL kennt, kann man einander viel zu wenig einschätzen. Ich bemühe mich um vorsichtigere Formulierungen. Peace!

HumeSikkins

@Volkard
Gibt es einen bestimmten (didaktischen?) Grund, warum du Sachen wie copy und vector als ungeeignet für Anfänger betrachtest?
Sprich: Hälst du es für Vorteilhaft, wenn ein Anfänger erst mit Arrays und dynamischen Arrays arbeitet und dann erst auf vector umsteigt? Oder, wenn er erst eine for-Schleife und danach erst eine Abstraktion über einen Algo verwendet?

Wenn ja: Würdest du bei dynamischeren Sprachen wie z.B. Ruby genauso argumentieren? Würdest du dort z.B. auf die Erklärung von Closures erstmal verzichten und stattdessen for-Schleifen verwenden?
Also statt:

def managers(emps)
	return emps.select {|e| e.isManager}
end

def managers(emps)
   i = 0;
   a = Array.new;
   while i != emps.length
      if  emps[i].isManager then
          a.push(emps[i]);
      end
      i = i + 1;
   end
   return a
end

In meinen Augen gibt es einen Unterschied zwischen Programmieren lernen und C++ lernen. Ersteres ist unabhängig von irgendwelchen Standardbibliotheken, man konzentriert sich auf Grundlagen und Konzepte (Schleifen, Bedingungen, Funktionen, Datenstrukturen, Algorithmen, abstrakte Maschinen usw.).
Letzteres sollte imo immer auch ein wenig auf Qualität und Effektivität des Ergebnisses setzen.
C++ hat sich weiterentwickelt und davon sollten meiner Meinung nach auf Anfänger profitieren dürfen. Bücher wie "Accelerated C++" machen vor, wie sowas gehen kann.

Mir scheint dir geht es grundsätzlich mehr darum das Programmieren zu lehren. C++ ist dabei nur Mittel zum Zweck. Es könnte auch Pascal oder Abstrakt-User-1 sein. Sehe ich das richtig?

HumeSikkins

Kann ja sein, das ich auf dem falschen Dampfer bin, aber seit wann ist die STL nicht im C++ Standard drin?

Sie war nie drin. Die STL ist eine Bibliothek von Stepanov und Lee, die bei HP entwickelt wurde. Diese Bibltiohek war ein Vorbild bei der Standardisierung der C++ Standardbibliothek. Es wurden viele der Konzepte übernommen. Trotzdem ist der Container/Iterator/Algorithmen-Teil der C++ Standardbibliothek nicht identisch mit der Original-STL-Bibliothek.

Nichtsdestotrotz ist es heute üblich den Container/Iterator/Algorithmen-Teil der C++ Standardbibliothek mit STL zu bezeichnen.

Hutzli

Artchi schrieb:

Kann ja sein, das ich auf dem falschen Dampfer bin, aber seit wann ist die STL nicht im C++ Standard drin? Bjarne Stroustrup hatte doch damals extra bei den STL-Erfindern nachgefragt, ob er die STL in die ISO aufnehmen darf. Was auch prompt erlaubt wurde. Und jetzt soll die STL nicht im Standard drin sein?

Ohje, was hab ich getan? - Also keine Panik! Alles wird gut!

Die STL wurde unter dem Namen "Standard C++ Library" in den Standard integriert (mit minimalen Anpassungen), heisst da also offiziell anders, mehr nicht.

Nur um den subtilen Unterschied zwischen der (Pre-Standard-)STL und ihrer Manifestation im Standard ging es mir, weil ich genug Leuten helfen musste die da mit der STL-Doku nicht ihr Standard-Library-Programm zum laufen brachten.

Sorry, wenn ich jetzt mehr verwirrt habe als geplant. Also benutzt es ruhig wie bisher.

Was die Benutzung der STL angeht: ja, für Anfänger kann sie verwirrend sein. Muß aber sagen, das auch die Literatur die es gibt daran schuld ist und nicht die STL selbst.

Ich kann nur empfehlen sich den Josuttis (The C++ Standard Library: A Tutorial and Reference) zu besorgen, wenn man mit englischen Büchern klarkommt. Aber ein Einsteigerbuch ist das auch nicht, in sofern muß ich Dir recht geben.

Artchi

Ihr schlingel, macht mir nicht nochmal solche Schärze! OK, also mit STL ist _eigentlich_ die orig. Implementierung von den orig. Erfindern bei HP (die später zu SGI gewechselt sind) gemeint. OK, soweit war ich auch schon. Gut, und im ISO gibt es also nur die nachempfundene STL, und Bjarne hat sich nur die Erlaubnis eingeholt sie nachzuempfinden. Ich hatte halt gedacht die orig. STL wurde 1:1 übernommen, samt Namen.

OK, alles paletti.

Artchi

HumeSikkins schrieb:

In meinen Augen gibt es einen Unterschied zwischen Programmieren lernen und C++ lernen. Ersteres ist unabhängig von irgendwelchen Standardbibliotheken, man konzentriert sich auf Grundlagen und Konzepte (Schleifen, Bedingungen, Funktionen, Datenstrukturen, Algorithmen, abstrakte Maschinen usw.).
Letzteres sollte imo immer auch ein wenig auf Qualität und Effektivität des Ergebnisses setzen.
C++ hat sich weiterentwickelt und davon sollten meiner Meinung nach auf Anfänger profitieren dürfen. Bücher wie "Accelerated C++" machen vor, wie sowas gehen kann.

Mir scheint dir geht es grundsätzlich mehr darum das Programmieren zu lehren. C++ ist dabei nur Mittel zum Zweck. Es könnte auch Pascal oder Abstrakt-User-1 sein. Sehe ich das richtig?

Hier muß ich wirklich mal HumeSikkin zustimmen. Ich finde Anfänger werden durch selbst implementierte dynamische Arrays eher verwirrt, als wenn sie einfach (erstmal) vector benutzen. DAS ist doch gerade der Erfolg von Java, C# usw. bei den Anfängern. Natürlich sollte jemand, der sich C++ Profi nennt, selbst einen vector implementieren können. Aber ein Anfänger will schnell Ergebnisse sehe, sonst endet das im Frust.

Deshalb plädiere ich doch dafür, das man Boost hier aufnimmt, um die Arbeit mit C++ zu erleichtern.

Die Einwänden von wegen Compiler-Probleme mit Boost usw. kann ich auch nicht verstehen. Wenn es danach gehen würde, müssten wir alle mit uralt-Libraries arbeiten, weil immer noch nicht alle Compiler 100% ISO-konform sind.

C++ hat keine Marketingmaschinerie a la Java oder C#. Also müssen wir als Community C++ fördern (die Boost-Community macht es jedenfalls!). Und dann müssen halt die Compiler-Entwickler aus dem Arsch kommen und ihre Compiler den User-Bedürfnissen anpassen. Warum sollen sich die User (also wir) nach den Compilern richten? Dann darf man halt die schlechten Compiler nicht kaufen.

Ich habe mir VC++2003 gekauft, weil er Boost, Loki und Blitz offiziell ohne Probleme compiliert! Steht sogar auf der Verpackung. Wenn ein anderer Compiler das nicht kann, hat der halt pech.

phlox81

Wenn macht es vernünftig, und macht ein Unterforum für C++ Libs, wie es ja
schon für GUIs es gibt. Boost ist nur eine von vielen Interessanten Libraries,
welche auch erwähnens wert sind (DTL,MTL z.b.).

Devil

Hutzli

Artchi schrieb:

Die Einwänden von wegen Compiler-Probleme mit Boost usw. kann ich auch nicht verstehen. Wenn es danach gehen würde, müssten wir alle mit uralt-Libraries arbeiten, weil immer noch nicht alle Compiler 100% ISO-konform sind.

Das stimmt zwar, und ist auch mehr oder weniger meine Einstellung, aber natürlich im Bereich von Projekten nicht immer allegmeingültig. Ich bin ein grosser Fan von Boost, aber ich kenne halt auch die Probleme.

Leider sieht es auf verschiedenen Unix-Varianten nicht immer so gut aus, mit dem Support und gerade diese Systeme geben einem wenig Auswahl beim Compilerkauf. Da es den KAI C++ nicht mehr gibt (von Intel verschluckt), existieren kaum ernstzunehmende Alternativen zum Compiler des Herstellers, ausser g++. Letzterer ist aber in Firmen nicht immer eine Option, weil es entweder eine politische Entscheidung ist, oder aber der Support für eine Third-Party-Lib nicht mit g++ zu bekommen ist (oder diese nicht mit g++ funktioniert).

Das sind sicher Randprobleme, aber wenn man ein Projekt jetzt auf einer gut von Boost unterstützten Plattform entwickelt um dann zwei Wochen vor Termin erst zu bemerken das es auf den anderen Plattformen, auf denen auch ausgeliefert werden soll, nicht funktioniert, so wünscht man sich sicher, das einem vorher zumindest ein Fingerzeig auf mögliche Probleme gegeben worden wäre. (Es klingt krank, erst so spät auf allen Platformen zu testen, aber in der Praxis kommt es immer wieder dazu, z.B. weil ein exotischeres Zielsystem nur beim Kunden zur Verfügung steht.)

Boost ist in Teilen nicht nur leading sondern auch bleading Edge Software, wenn man sich abseits der ausgetretenen Pfade bewegt. Das soll einen nicht daran hindern es zu benutzen, aber zur Vorsicht und frühen Tests ermahnen.

Und mit der Boost-Unterstützung von VC++7.1 (den ich für einen Segen halte, nach dem mit der Lupe zu suchenden Fortschritt zwischen 6.0 und 7.0) ist es zwar gut bestellt, aber auch nicht Problemlos. So kommt der Compiler bei komplexen Spirit++-Konstruktionen deutlich schneller an seine Grenzen und wirft mit ICEs um sich, als z.B. der g++. Aber Spirit++ ist natürlich auch nicht ohne, was Anforderungen angeht.

Artchi schrieb:

Ich habe mir VC++2003 gekauft, weil er Boost, Loki und Blitz offiziell ohne Probleme compiliert! Steht sogar auf der Verpackung. Wenn ein anderer Compiler das nicht kann, hat der halt pech.

Ja, geht mir privat ähnlich, aber nicht jeder der hier fragt hat wirklich eine Wahl bei der Wahl des Compilers. Also Boost-Unterstützung durch passende Antworten gerne, aber wenn es um kritischere Komponenten von Boost (wie z.B. Spirit++) geht, vielleicht nicht ohne einen warnenden Nebensatz.

Abgesehen davon für die Jungs von boost.org mein