muß ich auf printf verzichten?

Ich lese immer wieder, dass man doch Bitte in C++ nicht printf verwenden sollte.
Ok, hab ein wenig nachgelesen und zumindest verstanden, dass durch Benutzereingaben BufferOverflows erzeugt werden können.

Was mich wundert, ist die Tatsache, daß ich in 2 Büchern zum Thema C++ Anleitungen zur printf Familie finde, obwohl ich hier immer wieder großes Entsetzen erlebe, sobald jemand Code mit sprintf oder fprintf postet, da es angeblich C standard ist.

Ich persönlich mag printf irgendwie, benutze es aber nicht für Benutzereingaben/ -verarbeitung.

Ich lese desöfteren, daß man diesbezüglich die Boost Bibliothek nutzen sollte. Die scheint aber keine Standardbibliothek zu sein...

Bashar

milkana schrieb:

Ich lese immer wieder, dass man doch Bitte in C++ nicht printf verwenden sollte.
Ok, hab ein wenig nachgelesen und zumindest verstanden, dass durch Benutzereingaben BufferOverflows erzeugt werden können.

Das mit den Buffer-Overflows recherchierst du besser nochmal ...

recherchiert, keine veränderung
www.secologic.org/downloads/c/051123_eurosec_schulungsfolien_sichere_programmierung_von_C.pdf

Andromeda

milkana schrieb:

Ich lese desöfteren, daß man diesbezüglich die Boost Bibliothek nutzen sollte. Die scheint aber keine Standardbibliothek zu sein...

Boost ist ein Quasi-Standard. Jeder ernsthafte C++ Programmierer benutzt Boost. Übrigens kannst Du unter C++ natürlich auch printf verwenden, wenn du möchtest. Das ist nicht verboten.

milkana schrieb:

Ich lese immer wieder, dass man doch Bitte in C++ nicht printf verwenden sollte.

In C++ verwendet man für sowas streams (s. cout in deinem C++ buch auf S. 1)

milkana schrieb:

Ich persönlich mag printf irgendwie, benutze es aber nicht für Benutzereingaben/ -verarbeitung.

ich mag printf auch, habe es aber auch noch nie für benutzereingaben/verarbeitung verwendet... sicher dass wir von dem gleichen printf reden?

milkana schrieb:

Ich lese desöfteren, daß man diesbezüglich die Boost Bibliothek nutzen sollte. Die scheint aber keine Standardbibliothek zu sein...

Nein! du musst dazu ein gutes C++ tutorial durcharbeiten, dort stehen die printf/gets/etc. äquivalente, die man in C++ verwendet.

mit benutzeringaben meinte ich zB die Verarbeitung von Argumenten die dem Prog. beim starten mitgegeben werden.

diddler schrieb:

In C++ verwendet man für sowas streams (s. cout in deinem C++ buch auf S. 1)

du bist ja ein Witzbold.

Nexus

milkana schrieb:

diddler schrieb:

In C++ verwendet man für sowas streams (s. cout in deinem C++ buch auf S. 1)

du bist ja ein Witzbold.

Bis auf die Klammerbemerkung hat er damit aber Recht.

printf() ist einfach zu unsicher und unhandlich. Da ändert auch die Tatsache, dass es viele schlechte C++-Bücher gibt, die "C mit Klassen" vermitteln, nichts. Man muss bei printf() z.B. auch immer angeben, wie ein Argument interpretiert werden muss. Da lob ich mir std::ostream::operator<< .

milkana schrieb:

diddler schrieb:

In C++ verwendet man für sowas streams (s. cout in deinem C++ buch auf S. 1)

du bist ja ein Witzbold.

ne is so. C++ tickt nunmal anders als C. programmiererfahrungen sind immer sinnvoll aber du musst bei C++ nochmal von vorn anfangen (hauptsächlich wegen OOP und was das so mit sich bringt). um ein vernünftiges tutorial kommste daher nicht herum: eine absolute empfehlung sind die beiden hier

schornboeck's C++ tutorial
volkard's C++ tutorial

die autoren sind soweit ich weiß auch beide hier im forum unterwegs.

Bashar

milkana schrieb:

recherchiert, keine veränderung
www.secologic.org/downloads/c/051123_eurosec_schulungsfolien_sichere_programmierung_von_C.pdf

Da steht zwar was von Buffer-Overflows, und auch was zu printf, aber nicht das, was du behauptest. Bitte genauer lesen.

Nexus

diddler schrieb:

um ein vernünftiges tutorial kommste daher nicht herum: eine absolute empfehlung sind die beiden hier

schornboeck's C++ tutorial
volkard's C++ tutorial

Da solltest du aber auch ein wenig kritisch sein, in Volkards Kurs wird z.B. void main() vermittelt.

Tutorials sind Büchern meistens unterlegen; man lernt meines Erachtens besser mit Büchern. Empfehlungen dafür gibt es viele, der C++-Primer wird dabei oft erwähnt.

Andromeda

Nexus schrieb:

printf() ist einfach zu unsicher und unhandlich.

Unsicher ja, aber unhandlich würde ich printf nicht nennen. Praktisch an printf und sprintf finde ich, daß man mehrere Formatangaben zu einem string zusammenfassen kann, während man bei der Verwendung von C++ streams eine ganze Latte an Modifizierern und Formatoptionen mit << "hineinschieben" muß.

pyromania

Wenn dir der printf-Style so gefällt, dann nimm doch boost::format (http://www.boost.org/doc/libs/1_36_0/libs/format/index.html)

Nexus schrieb:

diddler schrieb:

um ein vernünftiges tutorial kommste daher nicht herum: eine absolute empfehlung sind die beiden hier

schornboeck's C++ tutorial
volkard's C++ tutorial

Da solltest du aber auch ein wenig kritisch sein, in Volkards Kurs wird z.B. void main() vermittelt.

haste recht, void main suckt. das ding is aber jetzt auch schon 8 jahre alt und ich hab früher sehr gute erfahrungen damit gemacht. ich halte es trotzdem für eines der besten einsteigertutorials: es vermittelt C++ von den grundlagen an bis hin zu den wichtigsten bausteinen wie templates/STL, und zwar gut unterteilt und mit einer denkaufgabe am ende jeder lektion. du kannst es mit folgenden änderungen weiterhin verwenden: ersetze "#include <iostream.h>" aus der ersten zeile durch "#include <iostream>" und "void main()" durch "int main()"
und natürlich: wer sich ernsthaft mit C++ auseinandersetzen will kauft sich das passende buch dazu!

Lol, printf ist sicher nicht unsicher. Es ist nur unsicher, wenn man es falsch benutzt. Z.B. ist printf(var) unsicher, während printf("%d", var) sicher ist. Bitte genauer lesen und nicht irgend ein Mist behaupten. Sonst geht ne Ebene tiefer und schaut selber nach. bye

Andromeda

DuddelSack schrieb:

Es ist nur unsicher, wenn man es falsch benutzt.

Aber genau so definiert man Unsicherheit in diesem Kontext.

Bashar

Andromeda schrieb:

Aber genau so definiert man Unsicherheit in diesem Kontext.

Das halte ich nicht für sinnvoll, das ist zu sehr Schwarz-Weiß-Denken. Man kann nicht durch ein Programmierwerkzeug Sicherheit erzwingen, es ist in jeder Sprache möglich, unsichere Programme zu schreiben. Ich würde sowas nicht auf Unwissenheit basieren, vielmehr würde ich eine Aussage wie "xyz ist unsicher" so verstehen, dass es auch bei Kenntnis der Sicherheitsproblematik sehr leicht ist, unabsichtlich unsichere Programme zu schreiben.

Nexus

DuddelSack schrieb:

Bitte genauer lesen und nicht irgend ein Mist behaupten.

...

Wenn man alles in C richtig verwendet, ist nichts unsicher. Wie Andromeda sagte, kann das aber kein Kriterium sein. Man muss nämlich immer genau aufpassen und trotzdem können einem sehr leicht Fehler unterlaufen. In C++ kann man genauso Fehler machen, jedoch ist die Wahrscheinlichkeit geringer, da man den Mitteln der Sprache mehr Verantwortung übergibt.

drakon

Imo gehört beim programmieren das Hirn und nachdenken dazu. Aber dazu zähle ich auch, dass ich mich nicht unbedingt immer auf mich verlasse und nehme darum üblicherweise die C++ Streams und nicht printf o.ä. Wenn ich allerdings irgendwann mal das Gefühl habe, dass ich etwas aus dem C-Teil brauche, dann verwende ich das auch. Wie z.B cmath.

Ich würde sowas nicht auf Unwissenheit basieren, vielmehr würde ich eine Aussage wie "xyz ist unsicher" so verstehen, dass es auch bei Kenntnis der Sicherheitsproblematik sehr leicht ist, unabsichtlich unsichere Programme zu schreiben.

Genau. Wenn man z.B eine Funktion hat, wo man immer die Grösse mitübergeben muss, dann kann das bei einer schnellen änderung des Programmes schnell zu Problemen kommen, auch wenn man "normalerweise" weiss, dass die Grösse stimmen muss. Oder auch die %d's usw. in C. sagen wir einmal, dass ich den Typen ändern muss, dann muss ich überall, wo ich eine Ausgabe, oder Formatierung mache dran denken das ändern zu gehen. In C++ passiert dir das nicht. Da bekommst du höchstens eine Fehlermeldun vom Compiler, dass Operator << nicht überladen is, wenn du den falschen (respekive einen eigenen) Datentypen benutzt.