Allgemeine Frage untersschied zwischen C und C++
-
pointercrash() schrieb:
+fricky schrieb:
ich schwöre auf IBMs notebooks. selbst IBM-notebooks, die aus der qualitätskontrolle geflogen sind und als noname-produkte billiger verkauft werden, ...
... und gibt's nimmer. Das Zeug heißt jetzt Lenovo und ist bis auf die immer noch gute Tastatur der gleiche Chinesenscheißmüll wie von Acer, Asus & Co. Der Laptop eines Bekannten war in 1 1/2 Jahren häufiger in Reparatur als bei ihm zuhause. Lang haben sie ja nicht gebraucht, den guten Ruf anzukratzen ...
Für die N- und R-Serien mag das zutreffen - eben die klassische Erweiterung der Palette nach unten -, aber die T-Serie ist eigentlich kaum anders als die alten IBM-Notebooks.
-
audacia schrieb:
Für die N- und R-Serien mag das zutreffen - eben die klassische Erweiterung der Palette nach unten -, aber die T-Serie ist eigentlich kaum anders als die alten IBM-Notebooks.
Ne, ist leider wirklich ein klassisches Stinkpad (frag' mich jetzt bitte nicht nach dem Typ), mit Business- Service und so. Aber der klappt imerhin noch gut, was auch bitter nötig ist nach dem zweiten Mainboardtausch, mit dem Display war was, der Akku wurde zu Anfang getauscht und irgendwas mit dem DVD- Röster wird als Dauermacke nie behoben.
Ich glaube fast, solche Sachen erledigen sich dann von selbst, wenn der entnervte Kunde wirklich Frisbee damit spielt.
-
pointercrash() schrieb:
... nach dem zweiten Mainboardtausch, mit dem Display war was, der Akku wurde zu Anfang getauscht und irgendwas mit dem DVD- Röster wird als Dauermacke nie behoben.
Das klingt sehr nach einer Einzelerfahrung. Mein T500 hat keine Hardware-Macken, wenn man von dem gelegentlich leicht dysfunktionalen Fingerprint-Reader absieht - aber das ist legitim, denn über den habe ich mal ein Glas Wasser geschüttet
Vielleicht habe ich auch nur Glück, und dein Fall ist die Regel. Dann ist Lenovo aber in absehbarer Zeit gleichfalls dysfunktional.
-
audacia schrieb:
Vielleicht habe ich auch nur Glück, und dein Fall ist die Regel. Dann ist Lenovo aber in absehbarer Zeit gleichfalls dysfunktional.
Ist ja nicht mal mein Fall, nur insofern, als daß ich einem Kumpel gesagt hab' ist ja quasi IBM, guck Dich dort in der Profireihe um. Sein vorheriges Sony- Schleppi war aber noch schlimmer, da gabs massive Probs mit dem Service.
Einfach den nächsten, jährlichen Kundenzufriedenheitsreport der c't genau lesen. Tendenziell weiß man da dann halbwegs Bescheid.EDIT: Achso, ja, Scheiße, mein Sony- Laptop, das einzige Laptop, das ich je hatte, starb nach 6 Monaten den Akkutod. Nix Kulanz, knapp fünfhundert Deutschmarks wollten die für'n Ersatz haben. Die Geschichte hab' ich aber von anderen Marken ähnlich um 00/01 rum gehört und nie wieder Laptops angeschaut.
-
+fricky schrieb:
ich bin eher der ergebnisorientierte typ, und keiner,
Man kann sich in C++ viel Arbeit sparen, die man mit C++ von Hand immer wieder machen muß. Und vermeidet so viele mögliche Fehlerquellen. Die Makros in C sind ein schlechter Versuch das Problem anzugehen, aber als wirklich geglückt kann man das nicht bezeichnen. Templates in C++ lassen einem viel Arbeitszeit sparen, wenn man damit umzugehen weiß. Allerdings sind gerade die Fehlermeldungen bei falscher Nutzung von Templates in ihrer Undurchsichtigkeit wohl kaum mehr zu überbieten. (Mit der neuen ISO Norm wird es daher Abhilfe geben.) Ein weiser Rat ist bei C++ Programmieren, daß man möglichst auf C Sprachmittel verzichten sollte, da man so nicht viel gewinnt, dafür die Fehlerquellen auf C Niveau hält, ergo man gleich C programmieren kann. Für versierte C-Programmierer ein verführerisches Gift, statt C++ gibt es bei denen meist nur C with Classes.
Andere Sprachen sind hier eindeutig im Vorteil z.B. Ada, aber mit Algol artigen Sprachen willst Du ja auch nichts zu tun haben.
-
~john schrieb:
+fricky schrieb:
ich bin eher der ergebnisorientierte typ, und keiner,
Man kann sich in C++ viel Arbeit sparen, die man mit C von Hand immer wieder machen muß.
zum beispiel?
~john schrieb:
Andere Sprachen sind hier eindeutig im Vorteil z.B. Ada, aber mit Algol artigen Sprachen willst Du ja auch nichts zu tun haben.
ich mach manchmal VHDL, ist ja ADA-ähnlich.
-
+fricky schrieb:
zum beispiel?
Template Meta Programming, aber das ist für dich ja so etwas wie "the dark arts" der C++ Programmierung. OOP, Exceptions werden direkt unterstützt, das spart viel Handarbeit gegenüber C ein. Leider habe ich schon viel zu viel C Code gesehen bei denen das Fehlerhandling sehr kreativ mit exit oder abort gelöst war. Fehlerhandling ist scheinbar etwas für Weicheier.
-
~john schrieb:
+fricky schrieb:
zum beispiel?
Template Meta Programming, aber das ist für dich ja so etwas wie "the dark arts" der C++ Programmierung.
ja, so wie's in C++ gemacht wird, ich es total furchtbar. meta programming an sich, halte ich für eine gutes und brauchbares konzept. ich finde nur, dass dafür eigene tools verwendet werden sollten und kein mega-compiler, der einem erlaubt im code die verschiedensten ansätze wild zu vermischen. es gibt aber auch ausnahmen, wo sich metaprogramming-features gut in die sprache integrieren (ich glaube lisp ist so ein kandidat).
~john schrieb:
...Exceptions werden direkt unterstützt, das spart viel Handarbeit gegenüber C ein. Leider habe ich schon viel zu viel C Code gesehen bei denen das Fehlerhandling sehr kreativ mit exit oder abort gelöst war.
sowas beklopptes wie C++ exceptions z.b. könnte ich in meinem tätigkeitsfeld überhaupt nicht gebrauchen. exit, abort, oder nicht abgefangene exceptions, die ein programm killen, overhead eines runtime-systems usw. sind nicht akzeptabel. zum einen muss ich oft sehr diffenziert auf fehler reagieren, direkt an dem punkt, an dem der fehler auftritt. das geht am effektivsten, ohne dass in einen alternativen auführungspfad gehüpft wird, oder durch stack-unwinding der kontext zerstört wird. ausserdem müsste ich c++ exceptions irgendwie mit prozessor-exceptions, interrupts und eventuell einem RTOS in einklang bringen. dazu kämen noch c++'s hausgemachte probleme wie z.b. das vermeiden von exceptions in destruktoren und konstruktoren bzw. in sämtlichen code-teilen, die von einem destruktor oder konstruktor aufgerufen werden könnten. langer rede kurzer sinn: den c++ exception-schwachsinn werde ich mir nicht geben.
-
+fricky schrieb:
sowas beklopptes wie C++ exceptions z.b. könnte ich in meinem tätigkeitsfeld überhaupt nicht gebrauchen
Wenn du Microcontroller programmierst, habe ich dafür Verständnis, aber was ist an den C++-Exceptions sonst so anders als z.B. in Java?
+fricky schrieb:
exit, abort, oder nicht abgefangene exceptions, die ein programm killen
... kann man mit entsprechenden Handlern ausstatten.
+fricky schrieb:
zum einen muss ich oft sehr diffenziert auf fehler reagieren, direkt an dem punkt, an dem der fehler auftritt. das geht am effektivsten, ohne dass in einen alternativen auführungspfad gehüpft wird
Ja, in so einem Fall ist die C-Variante der Fehlerbehandlung sicher zu bevorzugen. Aber das ist ja nun nicht eine übliche Situation für den durchschnittlichen Anwendungsentwickler.
+fricky schrieb:
oder durch stack-unwinding der kontext zerstört wird
Fordert der Standard eigentlich, daß der Kontext bereits beim Exception-Unwinding zerstört wird? Oder ist das nur eines der Implementationsdetails?
+fricky schrieb:
dazu kämen noch c++'s hausgemachte probleme wie z.b. das vermeiden von exceptions in destruktoren und konstruktoren bzw. in sämtlichen code-teilen, die von einem destruktor oder konstruktor aufgerufen werden könnten.
Gegen Exceptions in einem Konstruktor spricht nichts, was mir geläufig wäre.
-
audacia schrieb:
+fricky schrieb:
sowas beklopptes wie C++ exceptions z.b. könnte ich in meinem tätigkeitsfeld überhaupt nicht gebrauchen
Wenn du Microcontroller programmierst, habe ich dafür Verständnis, aber was ist an den C++-Exceptions sonst so anders als z.B. in Java?
ja, microcontroller und low-level programmierung, das meinte ich. dafür könnte man theoretisch auch C++ nehmen, nur sind c++ exceptions in dem bereich unbrauchbar. das ist übrigens nicht der einzige grund, c++ besser überhaupt nicht dafür zu verwenden.
audacia schrieb:
+fricky schrieb:
oder durch stack-unwinding der kontext zerstört wird
Fordert der Standard eigentlich, daß der Kontext bereits beim Exception-Unwinding zerstört wird? Oder ist das nur eines der Implementationsdetails?
wahrscheinlich implementationsabhängig. auf 'ner maschine ohne stacks, würde ein compiler funktionsaufrufe und returns z.b. zu 'jump'-instructions machen. aber ich denke c++ exceptions müssen sich auch dort, wie spezifiziert, verhalten.
audacia schrieb:
+fricky schrieb:
zum einen muss ich oft sehr diffenziert auf fehler reagieren, direkt an dem punkt, an dem der fehler auftritt. das geht am effektivsten, ohne dass in einen alternativen auführungspfad gehüpft wird
Ja, in so einem Fall ist die C-Variante der Fehlerbehandlung sicher zu bevorzugen. Aber das ist ja nun nicht eine übliche Situation für den durchschnittlichen Anwendungsentwickler.
mag sein dass es manchmal passt, wenn das programm einfach mit 'ner fehlermeldung aussteigt, oder in einem globalen exception-handler landet. aber trotzdem zweifle ich dran, dass stroustrup und co. die geringste vorstellung davon hatten, was in der praxis irgendeines entwicklers sinnvoll ist und was nicht.