new, arrays statt vector, char* statt string - warum?
-
asc schrieb:
ch sollte ihn für meine (noch) bisherige Firma empfehlen, da kann er sich dann mit meinen Programmierchef zusammen tun. Der Code in unserem C++ Projekt gleicht den von Boris
hatte 2 jahre lang java in der schule... und programmiere jetzt seit einem Jahr effektiv C++!
-
Java ist die schwulste sprache der Welt...
-
Simon2 schrieb:
weder der pädagogisch sinnvolle erste Schritt (so wie man nicht erst einen Rechner zusammenlötet bevor man sein erstes Programm schreibt)
manche machen es umgekehrt, also lernen zuerst programmieren, bevor sie sich für elektronik interessieren. ich gebe boris teilweise recht, daß es sehr unbefriedigend sein kann, nur mit black boxes zu hantieren.
Simon2 schrieb:
(*): Denn auch C-Programmierer werden ihr einmal mühsam entworfenen "Containermodul" und Algorithmensammlung nicht jedesmal neu schreiben, sondern wiederzuverwenden streben ... leider mit proprietären Schnittstellen/Eigenschaften.
normalerweise nimmt ein C-programmierer für sowas was fertiges. meistens hat er es noch nicht mal selber geschrieben.
-
fricky schrieb:
...
Simon2 schrieb:
(*): Denn auch C-Programmierer werden ihr einmal mühsam entworfenen "Containermodul" und Algorithmensammlung nicht jedesmal neu schreiben, sondern wiederzuverwenden streben ... leider mit proprietären Schnittstellen/Eigenschaften.
normalerweise nimmt ein C-programmierer für sowas was fertiges. meistens hat er es noch nicht mal selber geschrieben.
... aber DAS ist dann nichtmal standardisiert - ergo: Anders Projekt=Neue Einarbeitung (inkl. aller Fehler).
Ich kenne übrigens tatsächlich nur sehr wenig "C-Hasen", die derartige Funktionalitäten von "fremd" einsetzen ... und viele, die immer ihre eigene "Radsammlung" mitbringen. Lustig wird's dann, wenn sie diese in ihre Schnittstellen verwursten.
Allerdings muss ich sagen, dass C in unserer Firma eine Außenseitersprache ist.Gruß,
Simon2.
-
Simon2 schrieb:
Ich kenne übrigens tatsächlich nur sehr wenig "C-Hasen", die derartige Funktionalitäten von "fremd" einsetzen ... und viele, die immer ihre eigene "Radsammlung" mitbringen.
C hat nun mal nicht so eine riesige standard-library wie Java und .NET. deshalb gibt es eine unmenge an proprietären libs mit ähnlicher funktionalität. aber C wird sowieso meistens für sehr spezielle dinge eingesetzt, wo libs für speicherintensiven, allgemeinen kram wie hashmaps, container, etc. nicht so gefragt sind. auf geschwindigeit getrimmte und speichersparende fifos, queues, stacks und trees schon eher.
-
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.Gruß,
Simon2.
-
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.