new, arrays statt vector, char* statt string - warum?



  • Simon2 schrieb:

    fricky schrieb:

    ...C hat nun mal nicht so eine riesige standard-library ...

    Ich glaube, dir ist der Diskussionskontext ein wenig aus dem Fokus geraten .... 😉
    Es ging um die Frage, wie wichtig es für C++-Programmierer ist, die STL selbst nachprogrammieren zu können ... oder ob nicht ihre Benutzung schon Vorteile hat.
    F
    Gruß,

    Simon2.

    Naja, eigentlich ging es darum, weshalb so viele "C++"-Programmierer sich mit fehleranfälligen C-Konstrukten abquälen, anstatt auf die Konstrukte zurückzugreifen, die C++ liefert.



  • Simon2 schrieb:

    Ich glaube, dir ist der Diskussionskontext ein wenig aus dem Fokus geraten .... 😉
    Es ging um die Frage, wie wichtig es für C++-Programmierer ist, die STL selbst nachprogrammieren zu können ... oder ob nicht ihre Benutzung schon Vorteile hat.

    threads entwickeln sich nun mal weiter. aber um beim thema zu bleiben: klar ist es schon mal gut, wenn ein C++-user die STL 'nur' benutzen kann. zweifelt jemand daran? warum sollte man sie nachprogrammieren wollen? naja, wer sich den code der STL anschaut, der wird es vielleicht versuchen wollen. etwas hässlicheres gibt es kaum, aber es geht ja dabei nicht um die optik.
    🙂



  • fricky schrieb:

    ...warum sollte man sie nachprogrammieren wollen?...

    DAS ist die Ausgangsfrage, um die sich dieser Thread dreht ... denn die Erfahrung zeigt, dass es viele versuchen.
    😃

    Gruß,

    Simon2.



  • Tachyon schrieb:

    ...Naja, eigentlich ging es darum, weshalb so viele "C++"-Programmierer sich mit fehleranfälligen C-Konstrukten abquälen, anstatt auf die Konstrukte zurückzugreifen, die C++ liefert.

    Darum geht "es" (= Thema dieses Threads) und darum geht "es" (= Meine Antwort auf Boris' Post) gleichzeitig NICHT. 😃

    Gruß,

    Simon2.



  • Simon2 schrieb:

    DAS ist die Ausgangsfrage, um die sich dieser Thread dreht ... denn die Erfahrung zeigt, dass es viele versuchen.

    Und neben denen, die einfach die STL nicht kennen gibt es dann die andere Gruppe, die dann aus Performancegründen nicht die STL verwenden wollen. In der Regel ohne zu prüfen ob die STL nicht doch schneller ist, oder ohne sich über deren Anwendung kundig zu machen (Wenn man die STL falsch verwendet...).

    cu André



  • es ist halt gewohntheit.. blick ihr das nicht?^^ die meinsten die C Syntax in C++ einbauen, haben davor viel routine in C code gewonnen...

    Es geht nicht darum STL container etc. nachzubauen... oft verwendet ältere bibliotheken oder selbstgeschrieben, weil man zu faul ist sich bei moderen umuzuschaun oder anzueignen (zeitgründen).. man musss sich an alle gewöhnen..

    die syntax und programmiergewohnheiten von C zu C++ ist nicht schlagartig^^

    wenn es bspw. darum geht was auf der konsole auszugeben, hab ihr anfangs (diejenigen die zuvor C programmiert haben) auch printf verwendet, bis ihr euch an std:cout gewöhnt hat... könnt mir erzählen was ihr wollt..

    Ich mach euch ja auch nich dumm an, oder mach mich über euere programmiergewohnheiten etc. lustig... 😉



  • BorisDieKlinge schrieb:

    es ist halt gewohntheit.. blick ihr das nicht?^^ die meinsten die C Syntax in C++ einbauen, haben davor viel routine in C code gewonnen...

    Das ist nicht das Problem. Sondern das Problem ist das die, die C-Routine haben es auch so an andere weitervermitteln. C++ ist nunmal nicht C, unabhängig von den Wurzeln. Man kann in C++ zwar (weitgehend) C programmieren, aber ob das der Sinn und Zweck ist, wage ich doch zu bezweifeln.

    BorisDieKlinge schrieb:

    Ich mach euch ja auch nich dumm an, oder mach mich über euere programmiergewohnheiten etc. lustig... 😉

    Sorry, einmal muss ich noch meckern ;P
    Ich verstehe deinen Programmierstil wirklich nicht, wenn du tatsächlich schon 2 Jahre Java Programmiert hast - und 1 Jahr C++ bedeutet auch dennoch nicht den Anfängern C vor die Füße zu knallen.

    cu André



  • BorisDieKlinge schrieb:

    es ist halt gewohntheit.. blick ihr das nicht?^^ die meinsten die C Syntax in C++ einbauen, haben davor viel routine in C code gewonnen...

    ..oder lesen eben veraltete Bücher. Um Gewohnheit geht es hier doch garnicht, sondern um Neulinge. Blickst Du's nicht? 😃



  • Ich verstehe deinen Programmierstil wirklich nicht, wenn du tatsächlich schon 2 Jahre Java Programmiert hast - und 1 Jahr C++ bedeutet auch dennoch nicht den Anfängern C vor die Füße zu knallen.

    wenn ich eine rohe bytesequenz vor die füsse geschmissen bekomme ,welche aufbereit werden muss byteorder etc. und in einer structur gemappt werden muss... da is C einfach was schönes.. hardware nah.. die hardware schnittstellen und treiber zwischen moderen C++ Apllikationen müssen bzw. sind in Ansi c geschrieben.. ich muss das ja auch verstehen... naja seit ich C++ bzw. C programmiere hab ich so eine systemtransparenz, was in java nicht gegebenwar.. gut ist vll. alles bischen komplexer aber es gefällt MIR so halt.. ihr könnt gern in java rumhacken..



  • BorisDieKlinge schrieb:

    Ich verstehe deinen Programmierstil wirklich nicht, wenn du tatsächlich schon 2 Jahre Java Programmiert hast - und 1 Jahr C++ bedeutet auch dennoch nicht den Anfängern C vor die Füße zu knallen.

    wenn ich eine rohe bytesequenz vor die füsse geschmissen bekomme ,welche aufbereit werden muss byteorder etc. und in einer structur gemappt werden muss... da is C einfach was schönes.. hardware nah.. die hardware schnittstellen und treiber zwischen moderen C++ Apllikationen müssen bzw. sind in Ansi c geschrieben.. ich muss das ja auch verstehen... naja seit ich C++ bzw. C programmiere hab ich so eine systemtransparenz, was in java nicht gegebenwar.. gut ist vll. alles bischen komplexer aber es gefällt MIR so halt.. ihr könnt gern in java rumhacken..

    Jo, und so systemnahe Geschichten sind natürlich der tägliche Standardanwendungsfall einer Hochsprache... 🙄



  • ne, aber wenn es darum geht eine hardware nahe schnittstellen zu programmieren, hörts halt auf;) deswegen ist es von vorteil sicht tiefer auszukennen..



  • BorisDieKlinge schrieb:

    ihr könnt gern in java rumhacken..

    Es geht ja gar nicht um Java, sondern die Vermischung C und C++ beziehungsweise Gründe dafür, trotz den modernnen Errungenschaften von C++ wie die STL noch alte C-Funktionen und C-Style zu verwenden.
    Das war eigentlich schon seit Anfang des Threades die Kernfrage. Ich verstehen deine Argumentation nicht, Boris. Wieso sollte man auf C beruhen? Weil man früher einmal C programmiert hat und es schade wäre, etwas Neues zu lernen (also wegen deiner "Routine")?

    BorisDieKlinge schrieb:

    ne, aber wenn es darum geht eine hardware nahe schnittstellen zu programmieren, hörts halt auf;) deswegen ist es von vorteil sicht tiefer auszukennen..

    Das ist aber immer noch kein Grund, C++-Anfängern C beibringen zu wollen. Zumal die wenigsten sich gleich mit hardwarenaher Programmierung befassen.



  • BorisDieKlinge schrieb:

    ne, aber wenn es darum geht eine hardware nahe schnittstellen zu programmieren, hörts halt auf;) deswegen ist es von vorteil sicht tiefer auszukennen..

    Es ging aber nicht ums tiefer auskennen, sondern darum, das "tiefer auskennen" dafür zu benutzen, nur Murks zusammenzuschreiben.



  • BorisDieKlinge schrieb:

    wenn ich eine rohe bytesequenz vor die füsse geschmissen bekomme ,welche aufbereit werden muss byteorder etc. und in einer structur gemappt werden muss... da is C einfach was schönes.. hardware nah.. die hardware schnittstellen und treiber zwischen moderen C++ Apllikationen müssen bzw. sind in Ansi c geschrieben.. ich muss das ja auch verstehen... naja seit ich C++ bzw. C programmiere hab ich so eine systemtransparenz, was in java nicht gegebenwar.. gut ist vll. alles bischen komplexer aber es gefällt MIR so halt.. ihr könnt gern in java rumhacken..

    da hast du teilweise recht, aber sprachen wie Java z.b. sind einfach nicht für hardwarenahes zeug gedacht. ein Java-coder bekommt fast nie rohe byte-ströme vorgesetzt, die er in echtzeit verarbeiten muss. und wenn doch, wird z.B. über JNI native code (z.b. in C-code geschrieben) eingebunden, der das erledigt.
    jede sprache hat ihr bevorzugtes anwendungsgebiet. C ist für maschinennahes zeug gut geeigent und 'richtige' hochsprachen sind besser, wenn ein hoher abstraktionslevel gefragt ist.
    🙂


  • Administrator

    Ich kenne womöglich noch einen Grund, der sich allerdings mit einem anderen etwas überschneidet. Das war der Grund, wieso ich am Anfang miserablen C++ Code geschrieben habe und heute erst langsam vernünftiges zusammen kriege ...

    Ich hatte nämlich nicht C++ lernen wollen, sondern GUI-Programmierung, bzw. später vielleicht mal 3D (bis heute noch keine Anwendung in 3D gemacht 🙂 ).

    So habe ich ein Buch über die MFC gekauft, welche im ersten Teil eine Einführung in C++ hatte. Wie ich erst viel später feststellen musste, war die Einführung einfach nur miserabel und wie einige vielleicht wissen, ist die MFC nicht gerade eine Vorzeigebibliothek für C++ 😉

    Und da ist wohl auch ein Problem. Viele fangen nicht an einfach C++ zu programmieren, sondern kommen mit einem Themenbereich rein. Kaufen sich dazu dann ein Buch über das entsprechende Thema, welches noch zusätzlich eine Einführung in C++ hat. Natürlich dann aber viel zu wenig Zeit auf C++ setzt, hauptsächlich mehr auf das Thema. Man beschäftigt sich dann auch mit dem Thema und nicht mit C++. Es kommt gar nicht so weit, dass man sich C++ genauer anschaut, ausser wenn einem die Neugier dazu treibt.

    Den Professoren darf man durchaus auch die Schuld geben. An unserer Uni sieht es folgendermassen aus:
    1 Semester Java
    1 Semester Java-Projekt
    So gut wie alle Übungen sind in Java
    10 Stunden C++, als wenn man da jemanden C++ beibringen könnte und die Übungen ... Mal ein paar "Stichwörter":

    FILE*
    #include "iostream.h"
    strcmp(...) // allerdings mit std::string
    using namespace std; // Konsequent durchgezogen, auch in Header Files usw.
    // Und was man sich sonst noch alles schlimme denken kann
    

    Naja, aber das wurde ja schon erwähnt.

    Grüssli



  • Dravere schrieb:

    Den Professoren darf man durchaus auch die Schuld geben. An unserer Uni sieht es folgendermassen aus:
    1 Semester Java
    1 Semester Java-Projekt
    So gut wie alle Übungen sind in Java
    10 Stunden C++, als wenn man da jemanden C++ beibringen könnte und die Übungen ...

    das hängt wohl auch etwas mit der relevanz beider sprachen zusammen.
    🙂


  • Mod

    fricky schrieb:

    Dravere schrieb:

    Den Professoren darf man durchaus auch die Schuld geben. An unserer Uni sieht es folgendermassen aus:
    1 Semester Java
    1 Semester Java-Projekt
    So gut wie alle Übungen sind in Java
    10 Stunden C++, als wenn man da jemanden C++ beibringen könnte und die Übungen ...

    das hängt wohl auch etwas mit der relevanz beider sprachen zusammen.
    🙂

    indem die Relevanz durch die Zeitzuteilung geschaffen wird?



  • camper schrieb:

    indem die Relevanz durch die Zeitzuteilung geschaffen wird?

    könnte schon sein, daß bildungsstätten sich am dahinsiechen von C++ mit schuldig machen.
    🙂



  • fricky schrieb:

    das hängt wohl auch etwas mit der relevanz beider sprachen zusammen.
    🙂

    Mit der Relevanz hat das mit Sicherheit nicht zu tun...

    Was aber viele Studenten vergessen ist, das es nicht die Aufgabe der Uni ist einen Programmiersprachen beizubringen (wird aber eigentlich immer an einer - von Uni zu Uni unterschiedlichen gemacht).

    Aber nichts desto trotz kann ich zumindestens sagen das ich in meinem Bereich, als ich kürzlich nach einer neuen Stelle suchte, mit C# und Java mehr Auswahl gehabt hätte (wobei ich in beiden Kenntnisse habe, nicht aber große Projekterfahrungen).

    Wobei es in anderen Anwendungsbereichen (und Regionen, wobei ich relativ regionsübergreifend gesucht hatte) wieder gänzlich anders aussehen kann.

    cu André



  • fricky schrieb:

    könnte schon sein, daß bildungsstätten sich am dahinsiechen von C++ mit schuldig machen.
    🙂

    Die Bildungsstätten sind wie gesagt nicht für das Lehren von Programmiersprachen zuständig.


Anmelden zum Antworten