new, arrays statt vector, char* statt string - warum?
-
phänomenal schrieb:
Was muss er bei
new
denn unbedingt mehr wissen als beivector<>
, außer dass noch eindelete
dazu gehört?Genau darum geht es doch unter anderem, um das delete[] (und auch um die Sachen das es Unterschiede zwischen delete und delete[] gibt etc).
-
phänomenal schrieb:
...Spaß beiseite - für einen Anfänger ist
v = new int[xyz]
doch genauso eine Blackbox wievector<int> v(xyz)
. Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.Gutes Argument
Ich glaube übrigens, dass Tachyon Dein Argument noch um einen weiteren Vorteil verstärken wollte...
Gruß,
Simon2.
-
asc schrieb:
Genau darum geht es doch unter anderem, um das delete[] (und auch um die Sachen das es Unterschiede zwischen delete und delete[] gibt etc).
Ja, ok, jetzt. Da stand ich kurz auf dem Schlauch.
-
Simon2 schrieb:
phänomenal schrieb:
...Spaß beiseite - für einen Anfänger ist
v = new int[xyz]
doch genauso eine Blackbox wievector<int> v(xyz)
. Bei beiden weiß er nicht, was hinter den Kulissen passiert. Ich bezweifle deshalb, dass das wirklich eine nennenswert verbreitete Motivation dafür ist, den kompliziertesten und fehleranfälligsten Weg zu wählen.Gutes Argument
Ich glaube übrigens, dass Tachyon Dein Argument noch um einen weiteren Vorteil verstärken wollte...
Gruß,
Simon2.
Jup. Bei new muss man eben wissen, dass man a) einen Pointer braucht, um den Speicherbereich zu referenzieren, b) der Pointer auch ins Nirvana zeigen kann, c) der Pointer explizit wieder freigegeben werden muss, d) Unterschiede zwischen delete und delete[] bestehen, usw.
Obwohl ich eigentlich Deine Aussage stärken wollte widerspreche ich Dir, bei genaurer Betrachtung, zum Teil.
Für die reine Benutzung von v-Vektor und v-Heapobjekt ergibt sich für den Benutzer tatsächlich erstmal kein Unterschied. Aber wenn man mit der Benutzung fertig ist, oder wenn v "leer" sein soll, ergibt sich sehr wohl ein Unterschied.
Bei v-Vektor muss man sich um all diese Dinge wenig gedanken machen. Bei v-Heap muss man sehr konkret wissen, wie das ganze Geschäft mit dem dynamischen Speicher abläuft.
Für die meisten Anwendungsfälle (vor allem, die, die für Anfänger relevent sind) muss man aber von dem ganzen Pointergeschäft nichts wissen, weil man sehr gut ohne auskommt.
-
Shade Of Mine schrieb:
BorisDieKlinge schrieb:
Deswgen hasse ich Java... ^^ Wenn ich mal schnell ein kleine tool bauen muss nehm ich VB^^ java ist nichts halber und nichts ganzes... Ich fühl mich nicht als richtiger programmierer, wenn ich nicht weis was so i nen tiefen abgeht.
gerade java ist sehr transparent finde ich. bei vb sieht es da schon komplett anders aus - zumindest im nicht .net VB...
Eigentlich hat er recht, wenn er sagt, dass er Java hasst, weil er keine Ahnung davon hat. Das kann man doch bestätigen.
-
Boris Karloff schrieb:
Eigentlich hat er recht, wenn er sagt, dass er Java hasst, weil er keine Ahnung davon hat. Das kann man doch bestätigen.
Das kann man. Vor allem verwundert es mich wie sein Programmcode und Alternativsprachen aussehen wenn er Java hasst
Ich 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
cu André
-
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?