Stroustrup Interviews



  • asc schrieb:

    earli schrieb:

    C89 wird vom GCC vollständig unterstützt, C99 mindestens von Sun und IBM.

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    "nicht vollständig unterstützt" impliziert nicht "kann nicht".

    http://gcc.gnu.org/c99status.html



  • Tim schrieb:

    asc schrieb:

    earli schrieb:

    C89 wird vom GCC vollständig unterstützt, C99 mindestens von Sun und IBM.

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    "nicht vollständig unterstützt" impliziert nicht "kann nicht".

    http://gcc.gnu.org/c99status.html

    Von C++ wird nicht einmal die erste Version unterstützt.



  • Tim schrieb:

    asc schrieb:

    earli schrieb:

    C89 wird vom GCC vollständig unterstützt, C99 mindestens von Sun und IBM.

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    "nicht vollständig unterstützt" impliziert nicht "kann nicht".

    http://gcc.gnu.org/c99status.html

    Es war auch ironisch gemeint, da earli scheinbar genau das bei C++ ankreidet (weil ansonsten wäre seine Aussage einfach nur Schwachsinn hoch drei).

    C++ wird von Compilern unterstützt, aber es gibt Features die sich nicht rentabel umsetzen lassen (z.B. das erwähnte export bei Templates laut C++98). Die meisten aktuellen C++ Compiler dürften dennoch weitgehend kompatible zum Standard sein.



  • earli schrieb:

    Von C++ wird nicht einmal die erste Version unterstützt.

    Ach, wenn du ein Compiler entwickelst und feststellst das ein Feature einfach nicht mit sinnvollen Kosten-/Nutzenverhältnis umsetzbar ist, oder sich im nach hinein als Unsinnig herausstellt, würdest du es dennoch umsetzen, Koste es was es wolle? Und dies haben nun einmal fast alle Compilerhersteller festgestellt, Comeau brauchte wenn ich es richtig in Erinnerung habe alleine 3 Jahre für die Implementierung.



  • asc schrieb:

    earli schrieb:

    Von C++ wird nicht einmal die erste Version unterstützt.

    Ach, wenn du ein Compiler entwickelst und feststellst das ein Feature einfach nicht mit sinnvollen Kosten-/Nutzenverhältnis umsetzbar ist, oder sich im nach hinein als Unsinnig herausstellt, würdest du es dennoch umsetzen, Koste es was es wolle? Und dies haben nun einmal fast alle Compilerhersteller festgestellt, Comeau brauchte wenn ich es richtig in Erinnerung habe alleine 3 Jahre für die Implementierung.

    Natürlich. Das spricht nicht gegen den Compiler, sondern gegen die Sprache/den Standard.



  • earli schrieb:

    Natürlich. Das spricht nicht gegen den Compiler, sondern gegen die Sprache/den Standard.

    Dann hoffe ich das du HTML, CSS usw. ablehnst, weil diese niemals komplett umgesetzt werden.

    Eine ursprünglich gute Idee (Die ursprüngliche Idee des extern/Template-Konstruktes war z.B. nicht einmal so schlecht) kann sich im Nachhinein als Schlecht heraus stellen. Dies macht aber nicht den Gesamtentwurf als Ganzes schlecht.

    camper schrieb:

    asc schrieb:

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    Wenn man die Fehler in diesem Standard betrachtet, dürfte es schwierig sein, überhaupt eine konformen Compiler dafür zu schreiben...

    Q.E.D.



  • earli schrieb:

    Tim schrieb:

    asc schrieb:

    earli schrieb:

    C89 wird vom GCC vollständig unterstützt, C99 mindestens von Sun und IBM.

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    "nicht vollständig unterstützt" impliziert nicht "kann nicht".

    http://gcc.gnu.org/c99status.html

    Von C++ wird nicht einmal die erste Version unterstützt.

    Es gibt keinen Zertifizierungs- oder Kontrollprozess. Woher willst du wissen, das ein Compiler wirklich C voll unterstützt? Oder ein Compiler C++ nicht voll unterstützt? Was ist wenn der Compiler einen Bug hat und in einem speziellen Fall einen speziellen aber gültigen C89 Code nicht kompiliert (zB weil er abstürzt)? Im Endeffekt ist das alles sinnlose Pedanterie. Man entwickelt Programme ja nicht im luftleeren Raum sondern für eine spezifische Umgebung und wenn der Compiler etwas nicht kann (oder etwas mehr kann), dann muss man sich dem im Endeffekt eben anpassen. Der C und der C++ Standard sehen das ja genauso. Aus dem Grund gibt es ja explizit Dinge die den Implementierungen überlassen werden (implementation defined behaviour).



  • Warum füttert ihr den Troll?



  • Bashar schrieb:

    Warum füttert ihr den Troll?

    NadrW-Forum, was soll man da sonst machen 🤡



  • rüdiger schrieb:

    Es gibt keinen Zertifizierungs- oder Kontrollprozess. Woher willst du wissen, das ein Compiler wirklich C voll unterstützt? Oder ein Compiler C++ nicht voll unterstützt? Was ist wenn der Compiler einen Bug hat und in einem speziellen Fall einen speziellen aber gültigen C89 Code nicht kompiliert (zB weil er abstürzt)? Im Endeffekt ist das alles sinnlose Pedanterie.

    Könnte doch aber auch sein, dass das daran liegt, weil sich Compiler-Programmierer nicht am C und C++ Standard halten? Oder im umgekehrten Sinn: Die Doc. der Programmiersprache C und C++ immer noch zu ungenau ist? Irgendwo liegt der Fehler.

    Trotzdem ist es beachtlich was man mit C oder C++ erreichen kann ohne das einem die Fehler auffallen müssen bzw. man umständlicher Programmieren muss.

    Ansonsten finde ich das Interview im allgemeinen recht interessant. 😉



  • Jodocus schrieb:

    z.B. ob C obsolet sei (was ich persönlich auch denke, </flamewar>) und was Stroustrup so von der Softwareentwicklung dieser Tage hält.

    Habe mir gerade mal das Video angeschaut. Er "argumentiert" dass C obsolet ist weil man C und C++ zusammenmergen hätte sollen. Naja, was habe ich auch erwartet 😃



  • Bjarne Stroustrup hat eins mit Bill Gates gemeinsam: Mehr Glück als Verstand.

    Jester schrieb:

    - auto (klar, endlich muß ich die iterator-namen nicht mehr schreiben
    - thread support
    - initialisierung von z.B. vector aus einem Array (das ist wirklich nervig)
    - template typedefs
    - eingebautes for each
    - nullptr
    - >> bei templates erlaubt

    Es ist immer wieder erstaunlich wie einfach man C++-ler begeistern kann. Liegt wohl daran, dass alles mit 20 Jahren Verzögerung aufgenommen wird und nach 20 Jahren als Neuheit angepriesen wird.

    Ne, im ernst: Es freut mich, dass ihr C++-ler jetzt in 2011 auch in der Neuzeit angekommen seid.



  • Ah, ich hatte mich schon gewundert.



  • Schneewittchen schrieb:

    Es ist immer wieder erstaunlich wie einfach man C++-ler begeistern kann. Liegt wohl daran, dass alles mit 20 Jahren Verzögerung aufgenommen wird und nach 20 Jahren als Neuheit angepriesen wird.

    Ne, im ernst: Es freut mich, dass ihr C++-ler jetzt in 2011 auch in der Neuzeit angekommen seid.

    Im Gegensatz zu Sprachen wie Java sind die Features aber besser durchdacht. Denk mal an Generics im Zusammenhang mit Wrapperklassen, implizite Operatoren-Überladung bei String + Wrapperklassen. Bei solchen Dingen könnte ich kotzen. C# hat hier einiges besser gemacht, aber immer noch nicht perfekt.



  • rüdiger schrieb:

    earli schrieb:

    Tim schrieb:

    asc schrieb:

    earli schrieb:

    C89 wird vom GCC vollständig unterstützt, C99 mindestens von Sun und IBM.

    Merkwürdig, der GCC kann kein C99? Und dabei ist der C99 Standard doch schon mehr als 10 Jahre alt...

    "nicht vollständig unterstützt" impliziert nicht "kann nicht".

    http://gcc.gnu.org/c99status.html

    Von C++ wird nicht einmal die erste Version unterstützt.

    Es gibt keinen Zertifizierungs- oder Kontrollprozess. Woher willst du wissen, das ein Compiler wirklich C voll unterstützt? Oder ein Compiler C++ nicht voll unterstützt? Was ist wenn der Compiler einen Bug hat und in einem speziellen Fall einen speziellen aber gültigen C89 Code nicht kompiliert (zB weil er abstürzt)? Im Endeffekt ist das alles sinnlose Pedanterie. Man entwickelt Programme ja nicht im luftleeren Raum sondern für eine spezifische Umgebung und wenn der Compiler etwas nicht kann (oder etwas mehr kann), dann muss man sich dem im Endeffekt eben anpassen. Der C und der C++ Standard sehen das ja genauso. Aus dem Grund gibt es ja explizit Dinge die den Implementierungen überlassen werden (implementation defined behaviour).

    Bugs gibts immer, aber von C++ gibt es immer noch Features, die niemand versucht hat, zu implementieren.



  • Tim schrieb:

    Jodocus schrieb:

    z.B. ob C obsolet sei (was ich persönlich auch denke, </flamewar>) und was Stroustrup so von der Softwareentwicklung dieser Tage hält.

    Habe mir gerade mal das Video angeschaut. Er "argumentiert" dass C obsolet ist weil man C und C++ zusammenmergen hätte sollen. Naja, was habe ich auch erwartet 😃

    Stroustrup argumentiert doch so (und ich finde das schlüssig):

    C ist in C++ "eingemergt", sieht man schon am Namen. Idealisiert soll jedes C-Programm ein C++-Programm sein. Wenn man vernünftig C programmiert, entspricht das auch der Realität (Kompatibilitätsprobleme sind doch eher selten).

    C++ ist eine ganze Menge von Sprachenmitteln, wobei man die Mittel nutzen kann, die man benutzen will, aber nicht muss. Man kann auch auf alle Abstraktionsmittel verzichten und "nur" die C-Untermenge von C++ nutzen. Warum aber sollte man das tun?
    Wenn z.B. Exceptions der einzige Grund sind, warum man C und nicht C++ programmiert, warum dann nicht einfach C++ ohne Exceptions programmieren? Wenn selbst die Stdlib stört, kann man sogar diese weglassen. C++ bietet sozusagen nur Vorteile gegenüber von purem C. Weil es C eben erweitert. Und deshalb ist es obsolet.



  • Jodocus schrieb:

    C ist in C++ "eingemergt", sieht man schon am Namen.

    Nein, C++ baut auf C auf. Es ist eben nicht eingemergt weil es ausreichend viele Inkompatibilitäten gibt.

    Jodocus schrieb:

    Idealisiert soll jedes C-Programm ein C++-Programm sein. Wenn man vernünftig C programmiert, entspricht das auch der Realität (Kompatibilitätsprobleme sind doch eher selten).

    Nun die Realität ist z.B. folgendes:

    type *foo = malloc (n * sizeof *foo);
    

    Das ist C. Nicht C++. Inkompatibilität bei Grundlagen. Und komm mir jetzt nicht mit new denn deine Argumentation war, dass jedes C-Programm auch ein C++-Programm ist.

    Jodocus schrieb:

    C++ ist eine ganze Menge von Sprachenmitteln, wobei man die Mittel nutzen kann, die man benutzen will, aber nicht muss. Man kann auch auf alle Abstraktionsmittel verzichten und "nur" die C-Untermenge von C++ nutzen. Warum aber sollte man das tun?

    Ich bin z.B. vor einer Weile auf einen Compiler von einem namhaften µC-Hersteller gestossen, der keine Template-Parameter kann. Also kann ich nicht guten Gewissens Template-Parameter einsetzen. Nur mal als Beispiel.

    Jodocus schrieb:

    C++ bietet sozusagen nur Vorteile gegenüber von purem C. Weil es C eben erweitert. Und deshalb ist es obsolet.

    Selbst wenn C++ keine Nachteile gegenüber C hätte (Compilerverfügbarkeit, Fachkräfteverfügbarkeit, ...), reichen die übrigbleibenden Vorteile für einen Wechsel aus? Ich hoffe dir ist klar, dass ein pauschales "ja" hier nicht angebracht ist. Im Job sehe ich allerhand Probleme bei der Softwareentlicklung, und könnte für viele davon Abhilfmaßnahmen anbieten. Irgendwelche C++-Features sind da nicht dabei, weil sie nicht die eigentlichen Probleme lösen würden. Deswegen ist C nicht obsolet. Wenn man natürlich die "veraltet" Definition von "obsolet" anwedet, dann sieht es sicher anders aus. Aber auch C wird weiterentlickelt. Halt nicht in Richtung C++, weil das gibt es ja schon 😉



  • > Nein, C++ baut auf C auf. Es ist eben nicht eingemergt weil es ausreichend viele Inkompatibilitäten gibt.

    Stroustrups (und Ritchies) Bemühungen waren stets der Einsatz für die Beseitigung dieser Inkompatibilitäten. In früheren Standards gab es sicher mehr als jetzt.

    > Das ist C.

    Ja, aber ich finde diesen Code nicht schön. Das sieht so aus wie "Hähähäh ich programmiere mit Absicht unkompatibel mit C++". Implizite Konvertierungen bringen auch keinen nennenswerten Vorteil, ganz im Gegenteil (weshalb es in C++ dafür ein paar Gelegenheiten weniger gibt). Dabei wäre eine Cast-Ergänzung wie

    type *foo = (type*) malloc (n * sizeof *foo);
    

    keine große Geschichte, nur, dass man jetzt ein C++-Programm hat.

    Auf http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B stehen noch ein paar andere Sachen. Das Schlüsselwort-Problem ist das gleiche. Man kann es sich doch einfach mal verkneifen, Sachen wie "class" oder "new" als Bezeichner zu benutzen. Gerade C(++)-Programmierer haben doch ein gewisses Maß an Selbstbeherrschung gelernt. 🙂 Im allgemeinen sind die C++-Regeln meist etwas strikter. Aber nur, weil C++-Programmierer durch ihre Compiler gezügelt werden müssen, heißt das nicht, dass man mit Absicht inkompatibel programmieren muss.
    Ich denke, wenn man wirklich will, kann man jetzt schon C ausreichend kompatibel mit C++ programmieren.

    Die Linkerschwierigkeiten werden mit extern "C" ja auch bewältigt. Es gehört IMO also nicht mehr viel dazu, C-Programme zu schreiben, die mit C++ erweiterbar sind.

    > Compilerverfügbarkeit, Fachkräfteverfügbarkeit

    Nun ja, das ist an sich nicht das Problem von C++, das wäre theoretisch ja alles machbar. Deshalb ist es ja nur ein angestrebtes Ideal.

    > Im Job sehe ich allerhand Probleme bei der Softwareentlicklung,

    Ich bin zwar nicht in der Branche tätig, aber ich kann mir vorstellen, dass C++ nicht die großen Design- u. andere Probleme in der Softwareentwicklung per se löst. Aber ich denke, dass C++ einem viele kleine Probleme und lange Debug-Sitzungen ersparen kann.

    > Aber auch C wird weiterentlickelt. Halt nicht in Richtung C++, weil das gibt es ja schon 😉

    C99 hat doch z.B. mit der Einführung von "const" einen Schritt richtung C++ gemacht. 🙂 Wohin geht denn die Entwicklung von C? Richtung funktional (was C++ ja auch versucht)?



  • earli schrieb:

    Bugs gibts immer, aber von C++ gibt es immer noch Features, die niemand versucht hat, zu implementieren.

    Welche Features?

    Jodocus schrieb:

    Wohin geht denn die Entwicklung von C? Richtung funktional (was C++ ja auch versucht)?

    http://en.wikipedia.org/wiki/C1X



  • Jodocus schrieb:

    Richtung funktional (was C++ ja auch versucht)?

    Das musst du begruenden! C++ versucht das nicht.


Anmelden zum Antworten