Wofür C++ und C?
-
Simon2 schrieb:
Sorry, in C nicht anders zu lösen, aber in C++ schlecht.
Edit: Oder war das Ironie ?Der ganze Thread ist ein Witz, genauso wie seine Trolle.
-
Konrad Rudolph schrieb:
F98 schrieb:
*snip*
Alles falsch.
C++ eben. :p
Artchi schrieb:
Simon2 schrieb:
Sorry, in C nicht anders zu lösen, aber in C++ schlecht.
Edit: Oder war das Ironie ?Der ganze Thread ist ein Witz, genauso wie seine Trolle.
Ja, ich find ihn wieder lustig.
-
Artchi schrieb:
Der ganze Thread ist ein Witz, genauso wie seine Trolle.
wen, ausser mir, siehst du hier noch als troll?
-
Konrad Rudolph schrieb:
Tim schrieb:
Artchi schrieb:
Yo, std::basic_string und std::vector usw. sind nur aus Jux und Dollerei vorhanden.
[…]Beziehst du die Aussage jetzt auf mich?
Weiß ich natürlich nicht, aber mich würde mal interessieren, worauf Du *Deine* Aussage beziehst bzw. was Du damit sagen willst. Was stört Dich an Simons Aussage?
Auf das "lässt sich in C nicht anders lösen". Das ist offensichtlich grober Unfug. Vielleicht meinte er "lässt sich nicht besser lösen"? Dann wäre es nur noch Unfug.
-
Tim schrieb:
Konrad Rudolph schrieb:
Tim schrieb:
Artchi schrieb:
Yo, std::basic_string und std::vector usw. sind nur aus Jux und Dollerei vorhanden.
[…]Beziehst du die Aussage jetzt auf mich?
Weiß ich natürlich nicht, aber mich würde mal interessieren, worauf Du *Deine* Aussage beziehst bzw. was Du damit sagen willst. Was stört Dich an Simons Aussage?
Auf das "lässt sich in C nicht anders lösen"....
Warum schreibst Du das nicht gleich ?
Welche Formulierung wäre Dir denn lieber ?
"Da es std::string in C nicht gibt, löst man es da manchmal so" ?Gruß,
Simon2.
-
Simon2 schrieb:
F98 schrieb:
...
struct stPoint { float fX; float fY; char cName[32]; }Völlig ausreichend, platzsparend und übersichtlich.
... und unsicher und wartungsunfreundlich und unflexibel und ...
unsicher: ... eben so unsicher, wie der der es programmiert. Es kommt immer auf die Verhältnismäßigkeit an. Wegen des kleinen Structes einen fetten programmtechnischen Aufriß zu machen, lohnt sich doch nicht.
wartungsunfreundlich: Hää? Erklären bitte!
unflexibel: dito.
-
F98 schrieb:
...
unsicher ,wartungsunfreundlich: Hää? Erklären bitte!unflexibel: dito.
Spontan:
1.) Mit diesem Ansatz überlässt Du ungekapselten und begrenzten Speicher dem Anwender. Wenn der eine 0-Terminierung vergisst oder zu lang schreibt, bist Du "in the fritz" (natürlich kann man sagen: Tja, dann ist er halt selbst schuld - aber warum dem Anwender überhaupt dieses Verantwortung aufbürden ?).
(BTW "Bufferoverflow-Attacken" sind immer noch mit die beliebtesten)
2.) In Version 7 reichen plötzlich 32 Zeichen nicht mehr ... und dann ? Alle Programme dürfen neu kompilieren, alle geschriebenen Daten müssen migriert werden, ....
3.) "fetter Programmaufriss"
Was soll denn daran "fett" sein ?
Sooo groß ist string nicht (habe schon festgestellt, dass nicht wenige std::string-Implementierungen für kurze Strings anscheinend statische Buffer verwenden - da bleibt nicht viel Overhead) und Du darfst nicht unterschlagen, dass dem Anwender eine seeeehr komfortable (und sichere, s.o.) Schnittstelle zur Verfügung steht .... statt str...()-Funktionen.Gruß,
Simon2.
-
@F98:
Ich könnte jetzt fragen, was Deine Kunden machen, wenn Du Dich irgendwann entschließt, cName auf wchar_t oder fX, fY auf double umzustellen. Aber ist lasse es, denn in diesem Thread geht es nicht um ungarische Notation (netter Versuch, BTW :D)
-
F98 schrieb:
Simon2 schrieb:
F98 schrieb:
...
struct stPoint { float fX; float fY; char cName[32]; }Völlig ausreichend, platzsparend und übersichtlich.
... und unsicher und wartungsunfreundlich und unflexibel und ...
unsicher: ... eben so unsicher, wie der der es programmiert. Es kommt immer auf die Verhältnismäßigkeit an. Wegen des kleinen Structes einen fetten programmtechnischen Aufriß zu machen, lohnt sich doch nicht.
Sagt dir Buffer Overflow und One Off Error etwas?
-
Simon2 schrieb:
Tim schrieb:
Konrad Rudolph schrieb:
Tim schrieb:
Artchi schrieb:
Yo, std::basic_string und std::vector usw. sind nur aus Jux und Dollerei vorhanden.
[…]Beziehst du die Aussage jetzt auf mich?
Weiß ich natürlich nicht, aber mich würde mal interessieren, worauf Du *Deine* Aussage beziehst bzw. was Du damit sagen willst. Was stört Dich an Simons Aussage?
Auf das "lässt sich in C nicht anders lösen"....
Warum schreibst Du das nicht gleich ?
Weil ich es so offensichtlich fand. Sorry.
Simon2 schrieb:
Welche Formulierung wäre Dir denn lieber ?
"Da es std::string in C nicht gibt, löst man es da manchmal so" ?"Da es std::string in C nicht gibt, muss man sich in C halt überlegen wie man es, den Anforderungen entsprechend, effizient löst." z.B.
-
Tim schrieb:
...
"Da es std::string in C nicht gibt, muss man sich in C halt überlegen wie man es, den Anforderungen entsprechend, effizient löst." z.B.Kann ich gut mit leben.
Für mich ist das halt "der kanonische Weg in C" und alles Andere eher exotisch - weswegen ich schrieb "geht nicht anders" (meinte: "Geht nicht mit std::string" oder gar "geht nicht besser" ... wobei ich natürlich weiß, dass "besser "relativ ist). Außerdem war das von mir nur eine Randbemerkung und es ging mir nie wirklich um C (hatte gedacht, dass das aus dem Kontext heraus ersichtlich gewesen sei).Aber gut, dass Du mit einer eindeutigeren und exakteren Formulierung hier Klarheit geschaffen hast.
Gruß,
Simon2.
-
Mr. N schrieb:
Sagt dir Buffer Overflow und One Off Error etwas?
Sind doch so typische C/C++ Fehler.
-
scnr schrieb:
Mr. N schrieb:
Sagt dir Buffer Overflow und One Off Error etwas?
Sind doch so typische C/C++/Java/Smalltalk/Cobol/Fortran/ASM/... (choose one) Fehler.
Der ist einfach so schön, der muss wieder her:
-------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________Gruß,
Simon2.
-
Um mit Java nen Buffer Overflow hin zu bekommen, musst du dich schon richtig gut auskennen, und wer sich so gut auskennt macht solche Fehler nicht. Aber in C++ bekommt die jeder Anfänger hin und macht sie auch.
Simon2 schrieb:
Ich bin dumm
ich kann dich auch falsch zitieren
-
scnr schrieb:
Simon2 schrieb:
Ich bin dumm
ich kann dich auch falsch zitieren
Auch wenn er Dich richtig zitiert hätte, wär's nicht besser gewesen. Man könnte der Liste noch VB6 hinzufügen, selbst da kann man mit etwas Know-How einen Buffer Overflow hinbekommen.
-
scnr schrieb:
Um mit Java nen Buffer Overflow hin zu bekommen, ...
"Lesen, mein lieber Watson !! Lesen ist das A und O beim Verstehen !"
-
na dann is ja gut
-
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
-
Mr. N schrieb:
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
-------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________
-
Undertaker schrieb:
Mr. N schrieb:
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
<<Snip>>Sorry, das war ernst gemeint. Ich lese ständig Sicherheitswarnungen über Buffer-Overflows in C-Programmen...
Und wenn ich bedenke, dass strcat, sprintf etc. Buffer-Overflows geradezu erzwingen und so Funktionen wie strncat auch nicht viel besser sind, dann lob ich mir doch mein std::string. :p