Login
Newsletter
Werbung

Thema: Clang erreicht Meilenstein

45 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von jochenplumeyer am Fr, 5. Februar 2010 um 17:39 #

Ich glaube ja, daß der schnell kompiliert, aber seine Kompilate, wie sieht es mit deren Laufzeit-Effizienz aus?

[
| Versenden | Drucken ]
0
Von Name am Fr, 5. Februar 2010 um 17:41 #

isbn dazu: 3540495967

ich hab das much gelesen und glaube, mich zu erinnern, dass darin genau diese methode des compilerbaus beschrieben wird.


PS: Diese Kontrollwörter sind ja teilweise nicht mal für einen Menschen lesbar.

[
| Versenden | Drucken ]
0
Von jesus am Fr, 5. Februar 2010 um 17:43 #

Ab jetzt sollte man nicht mehr weiterentwickeln. Der restliche Teil von C++, der noch nicht unterstützt wird, ist offensichtlich völlig überflüssig und nutzloser Ballast, und man sollte ihn aus dem C++-Standard herauswerfen. Dann hätte man vielleicht etwas, das in die Richtung geht wovon Stroustrup mal sprach:

"Within C++, there is a much smaller and cleaner language struggling to get out." -- Bjarne Stroustrup

[
| Versenden | Drucken ]
  • 0
    Von sauer2 am Fr, 5. Februar 2010 um 18:06 #

    Mit dem äußeren, fiesen Teil meinte er sicher das Headerkonzept. ;)

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 18:07.
    [
    | Versenden | Drucken ]
    • 0
      Von zeh tut weh am Fr, 5. Februar 2010 um 18:18 #

      Gibt es da eigentlich IDEs/Scripte, die die Header automatisch erstellen können?

      [
      | Versenden | Drucken ]
      • 0
        Von sauer2 am Fr, 5. Februar 2010 um 18:35 #

        Interessante Frage. Damit hätte C++ einen Nachteil weniger.
        Ist das technisch möglich und umgesetzt oder können im Header zuviele Sachen wie z.B. Art der Klasse (abstrakt und so) drinstehen, die ein solches Programm nicht wissen kann?

        EDIT: Ich denke aber nicht, dass es möglich ist, andernfalls wäre es längst in alle größeren IDEs implementiert.

        Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 18:48.
        [
        | Versenden | Drucken ]
        • 1
          Von jesus am Fr, 5. Februar 2010 um 19:31 #

          Bei C++ stehen sogar die privaten Variablen in den Headern. Da fragt man sich schon, was das soll. :o :?

          [
          | Versenden | Drucken ]
          • 0
            Von sauer2 am Fr, 5. Februar 2010 um 20:01 #

            Ok, das passiert, wenn man Kernkonzepte wie Kapselung irgendwo dranschustert.

            Aber jetzt mal ne konstruktive Frage: Gibt es ein Tool, mit dem man eine Anbindung von C/c++ bibliotheken zu D bauen kann?
            D benutzt nämlich Module.

            Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 20:06.
            [
            | Versenden | Drucken ]
            • 1
              Von D am Sa, 6. Februar 2010 um 16:59 #

              D kann doch C Bibliotheken direkt verwenden.


              Lediglich für C++ Bibliotheken müßtest du dir etwas überlegen.

              [
              | Versenden | Drucken ]
              • 0
                Von sauer2 am Sa, 6. Februar 2010 um 17:06 #

                Danke.
                Hmja, man kann ja so komische Übergänge für C entwickeln, die man dann in D verwendet. SFML macht das anscheinend so.

                [
                | Versenden | Drucken ]
            0
            Von Vater Rhein am Fr, 5. Februar 2010 um 20:31 #

            Eine private Variable heißt privat weil man nicht auf sie zugreifen können soll, nicht, weil man nichts von ihrer Existenz wissen soll.

            [
            | Versenden | Drucken ]
            • 0
              Von sauer2 am Fr, 5. Februar 2010 um 21:40 #

              Möglicherweise, aber übersichtlicher wird der Header dadurch nicht.
              Welche Vorteile bietet ein Header gegenüber Modulen?

              [
              | Versenden | Drucken ]
              • 0
                Von Lothar am Fr, 5. Februar 2010 um 22:24 #

                Keine das ist lediglich historischer Ballast aus der Zeit einer Rechen- und Speicherbegrenzten PDP-7 Kiste.

                [
                | Versenden | Drucken ]
                • 0
                  Von Erik am Sa, 6. Februar 2010 um 09:24 #

                  > Keine das ist lediglich historischer Ballast aus der Zeit einer Rechen- und Speicherbegrenzten PDP-7 Kiste.
                  Natürlich gibt es Unterschiede. Mithilfe von Headern ist es möglich, so etwas wie die Trennung von Deklaration und Definition vorzunehmen. Angenommen, Du hast zwei Bibliotheken, die die gleichen Klassen grundverschieden implementieren und eine Anwendung, die diese Klassen verwendet.

                  Du compilierst Deinen gesamten Anwendungscode gegen einen Satz Headerfiles. Damit wird es möglich, die Entscheidung, welche der beiden Bibliotheken zur Verwendung kommt, erst ganz am Ende, zur Link-Zeit, zu treffen.


                  lg
                  Erik

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von panzi am Sa, 6. Februar 2010 um 23:49 #

                    Ich kann deine Argumentation absolut nicht nachvollziehen. Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht (welche die selben Features bietet). Das Konzept der Schnittstelle einer Bibliothek hat nix mit Headern zu tun.

                    Aber warum müssen auch die privaten Attribute im Header stehn? Ganz einfach, weil der Kompiler das Speicherlayout der Klassen kennen muss. Überall wo ein new steht oder schlimmer noch ein Objekt am Stack angelegt wird muss der Kompiler wissen wie groß das Objekt ist. Und wenn irgendwo auf ein (auch nicht privates) Attribut zugegriffen wird muss der Kompiler den Offset dieses Attribut kennen. Das kann er nur kennen wenn er weiß wie viele und wie große Attribute im Objekt vor kommen und wie diese sortiert sind.

                    Wenn man Objekte nur über new anlegen können würde dann könnte man zumindest die Größe des Objekts in eine Methode herausheben (allocator). Aber C++ kann Objekte ja auch am Stack anlegen und muss zumindest dort schon zur Compiletime die Größe kennen. Bei Java ist das anders. In Java gibts nur new. Theoretisch könnten jedoch JVMs den Controllflow analysieren und Objekte, die garantiert nur so lange leben wie die Methode in der sie erzeugt werden am Stack anlegen und nicht dem Garbage Collector überlassen (z.B. oft bei StringBuilder/StringBuffer). Das würde gehen weil Java einen JIT hat un erst den endgültigen nativen Code generiert wenn die entsprechende Klasse geladen wurde und die JVM somit das Speicherlayout/Größe der Klasse kennt. (Würde die Klasse entladen und aus anderer Quelle neu geladen werden müsste nochmal der JIT angeworfen werden. Aber ich glaub zu so einen Fall wirds wohl nicht kommen, da die Klasse mit dem neu zu JITeten Code ja noch eine Referenz auf den z.B. StringBuilder hält und somit wird die Klasse auch nicht entladen.) Und auch in Java sind die privaten Attribute "sichtbar". Man kann sie per Reflection auflisten und wenn das Programm nicht in einen speziellen Security Context (z.B. Sandbox) läuft, können private Attribute auch ausgelesen und gesetzt werden (ebenfalls per Reflection).

                    Sprich es hat einen guten Grund warum private Attribute im Header stehn. Wer sich über so etwas wundert sollte mal Konzepte des Kompilerbau wiederholen.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Erik am So, 7. Februar 2010 um 01:51 #

                      > Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht
                      Das ist halt der Punkt: Du brauchst mit Headern zum Programmieren noch nicht einmal eine Implementierung. Ein Textfile mit ein paar Forward-Deklarationen, schon kompiliert Dein Sourcefile zu einem Objektfile.

                      Das man das nutzen kann um gegen mehrere Libs linkbar zu sein, solange sie die API des Headerfiles erfüllen, ist lediglich eine denkbare Anwendung dafür. Mock-up prototyping wäre eine andere, die ich persönlich zum Beispiel recht gern nutze.

                      > Aber warum müssen auch die privaten Attribute im Header stehn?
                      Das wurde doch schon weidlich diskutiert.

                      > oder schlimmer noch ein Objekt am Stack angelegt wird
                      Daran ist gar nichts schlimmes.


                      lg
                      Erik

                      lg
                      Erik

                      [
                      | Versenden | Drucken ]
                    0
                    Von Lothar am So, 7. Februar 2010 um 12:27 #

                    Das geht aber auch wenn der Kompiler selbst die API aus der Sourcecode entnimmt wie bei D, Pascal, Eiffel oder Java.

                    Händisch verwaltete Headers sind einfach nur schlecht, kompliziert, fehleranfällig und auch insbesondere langsam.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Erik am So, 7. Februar 2010 um 17:59 #

                      > Das geht aber auch wenn der Kompiler selbst die API aus der Sourcecode entnimmt
                      Und wenn auch mein Code schon geschrieben ist, muss ich morgens gar nicht erst aufstehen. Auch richtig, geht aber ebenfalls an der Grundaussage vorbei.

                      Header sind deklarative Konstrukte, sie haben doch gerade den Sinn, dass man den Code an sich nicht zur Verfügung haben muss.

                      > Händisch verwaltete Headers sind einfach nur schlecht, kompliziert, fehleranfällig
                      Man kann sich auch dumm anstellen.

                      > und auch insbesondere langsam.
                      Also die anderen Argumente lasse ich ja noch unter "Geschmackssache", "Designphilosophie" oder ähnlichen Stichworten durchgehen, langsamer ist es mit Headern aber definitiv nicht. Ob Du die Symbolinformationen nun aus einem oder einem anderen Format entnimmst, ist diesbezüglich vollkommen irrelevant.


                      lg
                      Erik

                      [
                      | Versenden | Drucken ]
            0
            Von Koder am Fr, 5. Februar 2010 um 20:35 #

            Private Variablen/Member stehen drin, damit der Compiler weiß, wieviel Speicherplatz ein Objekt der Klasse braucht (deswegen können Klassen der privaten Member auch nicht nur forward deklariert sein).
            So könntest Du in Deinem Code z.B. kein sizeof() machen von einer Klasse aus einer anderen Bibliothek oder ein Objekt davon anlegen.

            [
            | Versenden | Drucken ]
            • 0
              Von Lothar am Fr, 5. Februar 2010 um 22:27 #

              Das könnte er aber auch wissen wenn er einfach den source code zusätzlich parst. Genau wie private virtuelle Methoden.
              Und wie diese völlig merkbefreiten Forward Declarations. Nur weil das Drecksding immer noch ein single parse compiler ist der nicht weiss was 3 zeilen später passiert.

              Ach muss meinen Blutdruck wieder runtergehen lassen - C++ ist einfach Drecksmist.

              [
              | Versenden | Drucken ]
              • 0
                Von sauer2 am Fr, 5. Februar 2010 um 22:37 #

                Tja, klingt, als wurdest Du gezwungen, c++ zu benutzen oder einen Compiler zu entwickeln.;)

                Oh, OT: Ich muss eine Fehlinformation richtig stellen, die ich in den Umlauf gebracht habe. Irgendwo in den PyGame Docs stand, dass die Performance von PyGame so grottig sei, dass man damit keine Anwendungen bauen könnte, bei denen der ganze Bildschirm neugezeichnet wird, was ich bei der LÖVE-Nachricht mal erwähnt hatte.

                Nun meinte Kiba aus dem Forum von Freegamer dass das Ganze weder mit PyGame noch mit RubyGame ein Problem sei, selbst mit einem 1Ghz Rechner käme er damit auf eine brauchbare Framerate, obwohl PyGame kein OpenGL benutzt. Wahrscheinlich sind einfach die Dokumente veraltet.

                Dieser Beitrag wurde 1 mal editiert. Zuletzt am 06. Feb 2010 um 00:08.
                [
                | Versenden | Drucken ]
                0
                Von Koder am Sa, 6. Februar 2010 um 00:14 #

                "source code zusätzlich parst"
                Haha, dann bräuchtest Du ja für alle Bibliotheken, die Du in Deinem Code verwendest, auch die Quellen. Scheint wohl nur unter Linux unterwegs, auch nett.

                C++ Drecksmist? Und dann mit Begriffen wie Single-Parse-Compilern um Dich werfen? Lebenslanges Lernen scheint angesagt... ;)

                [
                | Versenden | Drucken ]
                • 0
                  Von sauer2 am Sa, 6. Februar 2010 um 00:32 #

                  Vielleicht meint Lothar ja den Quelltext der vorliegenden Datei. Würde ja auch Sinn machen, im Sinne von welche "Verbindungen" der Compiler zu den Klassen/Variablen der Bibliothek bauen muss. Private Sachen würden halt keine Verbindung bekommen.

                  Nur so ne Theorie. Nicht, dass ich mich mit Compilern groß auskennen würde.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Erik am Sa, 6. Februar 2010 um 07:58 #

                    Um zum Beispiel eine statische Instanz einer Klasse auf dem Stack anzulegen, musst Du deren Layout ja vollständig zur Compile-Zeit kennen. Deshalb müssen auch alle Datenmember Bestandteil der Deklaration sein - und deren Datenmember in deren Deklaration. Oder eben auch allgemein, um die Größe einer Instanz oder den Offset von Membern zu kennen.

                    Wenn Du gern ganz privat mit deinen privaten Datenstrukturen sein willst, mache es doch wie die KDE-Entwickler: In die Deklaration packst Du einen Pointer auf eine private Datenstruktur, die Du in lediglich benennst. Das funktioniert,. weil auf einer Plattform die Breite eines Pointers fest und daher zur Compile-Zeit bekannt ist. In der Implementierung schließlich legst Du im Konstruktor eine dynamische Instanz Deiner dort vollständig bekannten privaten Klasse an und referenzierst einfach deren Member.


                    lg
                    Erik

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Ingo am Sa, 6. Februar 2010 um 11:18 #

                      Na super, dann operiert man also bei KDE das Gehirn nicht durch den Arsch (GObject) sondern durch den Bauchnabel.

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von Erik am Sa, 6. Februar 2010 um 12:06 #

                        Es wurde doch bereits weidlich diskutiert, warum es Vorteile haben kann, Header zu verwenden und warum ich dann auch private Strukturmember im Header deklarieren muss. C++ ist nun einmal eine Programmiersprache, die Headerdeklarationen unterstützt und nutzt.

                        Bestimmte Designentscheidungen haben eben Konsequenzen, mit denen man leben muss. Darüber kann man sich jetzt echauffieren oder ersatzweise Sprachen verwenden, die eine andere Herangehensweise haben. Vielleicht solltest Du letzteres in Betracht ziehen.


                        lg
                        Erik

                        [
                        | Versenden | Drucken ]
                  0
                  Von Lothar am Sa, 6. Februar 2010 um 03:58 #

                  Ja ja sollte "Single-Pass" Compiler heissen, aber diesen Typo sollte iegentlich jeder erkennen der was von Compilern versteht.
                  Und das C++ kein Drecksmist ist sagen nur Leute mit weniger als 10 Jahren C++ Erfahrung.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Erik am Sa, 6. Februar 2010 um 08:55 #

                    Ich habe mehr als 10 Jahre C++-Erfahrung. C++ ist kein Drecksmist.


                    lg
                    Erik

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von hazelnut am Sa, 6. Februar 2010 um 09:56 #

                      Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase, weil man stolz ist, dass man Template-Metaprogramming durchstiegen hat und man vermurkste Dinge, die man hart erlernt hat toll findet, weil ist ja "mächtig" (TM). Wart's ab, du wirst C++ auch noch hassen lernen.

                      "If you like C++, you don't know C++. There's a mutual exclusion going on here, and I've yet to see a counter-example other than possibly a few of the members of the standards committee."

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von kap am Sa, 6. Februar 2010 um 11:24 #

                        C++ ist, man staune, so wie jede andere Sprache nicht perfekt. Sie hat ihre Ecken und Kanten.

                        Und genau hier liegt der Unterschied zu den Leuten, die immer an ihrem Platz stehen bleiben werden, obwohl sie sich bewegen und die Zeit fortschreitet.
                        Trotz oder genau wegen seiner - von vielen gehassten - Nachteile hat man die Möglichkeit das Beste aus der Sprache rauszuholen. Man hat weiterhin die Möglichkeit Tugende wie Geduld oder gar Beharrlichkeit zu entwickeln, die sich auf das übrige Leben positiv auswirken. Hassen bringt einen also nirgends weiter.

                        Wie will man sonst die Nachteile einer Sprache erkennen, wenn man 'die vermurksten Dinge' nicht begreift? Obwohl ich das Wort Nachteile durch Schwächen ersetzen würde.

                        Wenn man mit der Zeit eine Zuneigung zu der Sprache entwickelt, weil man die Sprache besser beherrscht oder Teile davon verstanden hat und diese Zuneigung Liebe nennt, dann ist es doch perfekt! Wird man auch noch mit den Schwächen der Sprache besser vertraut und versteht sie zu hantieren, dann hat man sich weiterbewegt. Unabhängig von Zeit um Raum.

                        [
                        | Versenden | Drucken ]
                        0
                        Von Erik am Sa, 6. Februar 2010 um 11:33 #

                        > Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase
                        Es sind bereits mehr als 10 Jahre. Aktuell sind es genau genommen 14 Jahre. Davor mehrere Jahre andere Programmiersprachen.

                        > Wart's ab, du wirst C++ auch noch hassen lernen.
                        Ich kenne die Tiefen von C++ bereits. Die Vorteile sind jedoch unbestreitbar und - je nach Kontext - verglichen mit den sogenannten "Alternativen" unverzichtbar. Es gibt einfach Umgebungen, in denen Du das Layout des Speichers, die Architektur, das Footprint Deines Codes, das Verhalten des Compilers und andere Spezifika genau kennen musst. Hier gibt es einfach keinen Ersatz zu C/C++.


                        lg
                        Erik

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von D am Sa, 6. Februar 2010 um 17:08 #

                          > Hier gibt es einfach keinen Ersatz zu C/C++.

                          Doch, D!

                          http://en.wikipedia.org/wiki/D_%28programming_language%29


                          D 2.0 braucht zwar noch ein bischen, aber so lange ist der Weg auch nicht mehr.
                          Und die Compiler werden auch immer besser.

                          Rein von der Sprache her ist D aber unglaublich elegant und schön.
                          Es macht einfach Spaß damit zu programmieren.

                          [
                          | Versenden | Drucken ]
                          • 0
                            Von Erik am Sa, 6. Februar 2010 um 19:13 #

                            Ich finde D auch sehr nett, die Aussage, dass es aber (noch) kein Ersatz ist, stimmt aber.


                            lg
                            Erik

                            [
                            | Versenden | Drucken ]
                    0
                    Von bjarne am Sa, 6. Februar 2010 um 19:40 #

                    Ja kommt drauf an, wo man es einsetzt. In der Systemprogrammierung hat es sicher noch einen festen Platz. Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...

                    Ich kann zwar mittlerweile nicht mehr sagen, dass ich C++ besonders mag, aber so schlimm finde ich es auch nicht. Manchmal kommt man halt nicht drum rum...

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Lothar am So, 7. Februar 2010 um 12:36 #

                      Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...

                      Ja ist sie, aber jetzt komm mir bitte nicht mit den anderem Müll der sich C# und Java nennt.
                      Es gibt auch ein Leben ausserhalb der heiligen Dreifaltigkeit.

                      Ich würde alle 3 Sprachen jedenfalls nicht nutzen. Schade nur das es keinen MFC Wrapper für Objective-C gibt, nichtmal einen vernünftigen Objective-C Compiler.

                      Daher nehme ich auch weiterhin Eiffel für alle GUI Anwendungen.

                      [
                      | Versenden | Drucken ]
            0
            Von Anonymous am Sa, 6. Februar 2010 um 02:48 #

            Es ist einfach, private Variablen in Headern zu vermeiden, wenn man das denn für nötig hält (in der Regel ist es das nicht, da man sie zwar sehen, aber nicht in irgendeiner Form darauf zugreifen kann). Dazu deklariert man in der Headerdatei eine abstrakte Basisklasse, die das Interface spezifiziert. Außerdem braucht man noch eine statische Methode, die dazu dient, Instanzen der Klasse zu erzeugen:
            class B {
            public:
            virtual void f() = 0;
            static B *create();
            };
            In der Implementierungsdatei leitet man von dieser Basisklasse die Klasse ab, die das Interface implementiert.
            class D : public B {
            public:
            void f() {
            //Code hier
            }
            };

            B *B::create() {
            return new D();
            }
            Und schon hat man alle private-Variablen aus den Headern entfernt.

            [
            | Versenden | Drucken ]
1
Von am Fr, 5. Februar 2010 um 18:27 #

http://chaosradio.ccc.de/cre114.html

[
| Versenden | Drucken ]
0
Von D am Sa, 6. Februar 2010 um 16:54 #

http://www.dsource.org/projects/ldc

[
| Versenden | Drucken ]
  • 0
    Von Lothar am So, 7. Februar 2010 um 12:39 #

    Leider ist diese D Backend genau wie der Rest von D sowas von Buggy das du schon mit dem Klammerbeutel gepudert sein müsstest um damit ernsthaft eine Mission Critical Anwendung zu schreiben.

    D's Drang besser zu sein als C/C++ um sich damit endlich mal zu etablieren führt leider zum Gegenteil. Hoffentlich wird nach D 2.0 endlich mal 5 Jahre ein Sprachweiterentwicklungsverbot verhängt - ähnlich wie bei Python 3

    [
    | Versenden | Drucken ]
    • 0
      Von D am Mo, 8. Februar 2010 um 05:19 #

      Dieses D Backend ist ja auch noch in Entwicklung.


      D 2.0 gibt es deswegen, weil es bei D 1.0 dazu kam, daß neben der Standardlibrary noch eine zweite von der Community entwickelt wurde, die genau das gleiche macht, nur halt auf eine andere Weise.
      Das eigentliche Problem dabei war nur, daß man nicht beide gleichzeitig verwenden kann, da sie inkompatibel zueinander sind.
      Mit D 2.0 ist nun geplant, diese zu vereinen.

      Und dann gibt's natürlich hier und da noch ein paar kleinere Verbesserungen für D 2.0.
      Was aber für D 2.0 viel wichtiger wäre, wäre meiner Meinung nach, daß man D in etwas anderes umbennt, z.B. D++, damit man danach auch suchen kann ohne Ständig "Programming Lanuage" dem Suchmuster hinzuügen zu müssen.

      [
      | Versenden | Drucken ]
      0
      Von D am Mo, 8. Februar 2010 um 05:20 #

      Und bevor ich es vergesse.

      Wenn du ein paar kleinere Programme mit D schreiben willst, dann nimmst du moment besser den Compiler von Digital Mars, denn der ist ausgereift.
      Zumindest gilt das für D 1.0.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung