Ada



  • Danke für die Links. Auf Usenet wäre ich wohl nie gekommen, habe immer nach Webforen gesucht..





  • Die Mods könnten hier ja auch ein Unterforum für Ada und Pascal einführen.

    Ada und Pascal kann man sicher in einem Unterforum ganz gut zusammenklatschen.
    Und wenn noch für D Platz wäre, dann wäre das ganz toll.



  • DDDD schrieb:

    Die Mods könnten hier ja auch ein Unterforum für Ada und Pascal einführen.

    Ada und Pascal kann man sicher in einem Unterforum ganz gut zusammenklatschen.
    Und wenn noch für D Platz wäre, dann wäre das ganz toll.

    Unterforen werden nur eröffnet, wenn es ein Bedarf gibt. Die Anzahl der Ada-, Pascal- oder D-Fragen in den letzten 5 Jahren kann man hier sicher an einer Hand abzählen. => Kein Unterforum.



  • Moin!

    Gibt es in Ada eigentlich andere Möglichkeiten für Bitshifts/rotate, als die im Interfaces-Paket?

    Ich finde es ziemlich nervig, daß ich die dort vorgegebenen Typen verwenden muß, um die Funktion überhaupt benutzen zu können. Ich habe folgendes Testprogramm geschrieben, daß ich doch ziemlich umständlich finde:

    with Ada.Text_IO;
    with Ada.Integer_Text_IO;
    with Interfaces;
    
    procedure Bitshift_Test is
        package Unsigned_16_IO is new Ada.Text_IO.Modular_IO(Num => Interfaces.Unsigned_16);
    
        Test_Variable : Interfaces.Unsigned_16;
        Shift_Amount : Natural;
    begin
        Test_Variable := 1;
        Ada.Integer_Text_IO.Get(Item => Shift_Amount);
        Test_Variable := Interfaces.Shift_Left(Value => Test_Variable, Amount => Shift_Amount);
        Unsigned_16_IO.Put(Item => Test_Variable);
    end Bitshift_Test;
    

    Ist wirklich die einzige Alternative dazu Test_Variable := Test_Variable * (2**Shift_Amount), oder habe ich in der Referenz etwas übersehen? Und was hat der Bitshift mit "Interfaces" zu tun?



  • Und was soll an Ada nochmals so toll sein? Ich versteh da nur Bahnhof.



  • Ja, und wenn ich ein guter Ada-Programmierer wäre, von C keine Ahnung hätte und mir C-Code anschauen müßte, würde ich auch nur Bahnhof verstehen.

    Es ist tippaufwändig, aber ich finde es jetzt schon leichter zu lesen. Das Programmieren ist auch leichter, die Fehlermeldungen des Compilers sind ein Genuß und äußerst streng im Gegensatz zu denen von C. Das spart die Zeit, die man länger zum Tippen braucht.



  • Test_Variable := Interfaces.Shift_Left(Value => Test_Variable, Amount => Shift_Amount);
    

    versus

    Test_Variable <<= Shift_Amount;
    

    mhm...



  • Nagila Hawa schrieb:

    Ja, und wenn ich ein guter Ada-Programmierer wäre, von C keine Ahnung hätte und mir C-Code anschauen müßte, würde ich auch nur Bahnhof verstehen.

    Es ist tippaufwändig, aber ich finde es jetzt schon leichter zu lesen. Das Programmieren ist auch leichter, die Fehlermeldungen des Compilers sind ein Genuß und äußerst streng im Gegensatz zu denen von C. Das spart die Zeit, die man länger zum Tippen braucht.

    Nicht ganz, der Unterschied ist der, dass dieses kleine Programm, das nichts mehr tut als die Bits zu shiften, furchtbar aufgebläht ist mit komischem Zeugs und die Übersicht auf das Wesentliche verloren geht.
    Da ich etwas Programmiererfahrung habe kann ich aus dem Programm mit relativ hoher Wahrscheinlichkeit heraus lesen was es tut, wenn ich es lange genug anschaue, das kann ich bei einem C Programm nicht, das ist richtig.
    Aber bei einem C Programm kann ich auf einen Blick sofort das Wesentliche herauslesen, das finde ich ist hier nicht möglich, da es sehr viel Text enthält der gelesen werden muss.

    Aber die Fehlermeldungen würden mich interressieren, kannst du mal eine posten?

    P.S. Ich finde C auch nicht ideal, aber kleinere Codefragmente sind meist schnell zu erfassen.



  • Fühlt ihr euch besser wenn er die "named associations" weglässt und noch ein use interfaces; hinzufügt damit es dann so aussieht?

    [...]
        Test_Variable := Shift_Left(Test_Variable,Shift_Amount); 
    [...]
    


  • Shade Of Mine schrieb:

    Test_Variable := Interfaces.Shift_Left(Value => Test_Variable, Amount => Shift_Amount);
    

    versus

    Test_Variable <<= Shift_Amount;
    

    mhm...

    Na, du kannst das ja zumindest abkürzen zu

    Test_Variable := Shift_Left(Test_Variable, Shift_Amount);
    

    Außerdem ist das ja gerade der Grund, weshalb ich hier gepostet habe. Wenn das wirklich die einfachste Variante ist, ist das schade, aber auch kein Beinbruch. Mich stört eher, daß ich keine eigenen Typen benutzen kann, da ich befürchte, daß das Ganze so an Portabilität verliert (die in Ada an sich sehr hoch scheint).

    Sowieso kann ich Ada nicht wirklich einschätzen oder sogar verteidigen. Ich habe bisher nichtmal ein Tutorial zu Ende gebracht.

    Für kleine Programme ist Ada aber glaube ich auch überhaupt nicht ausgelegt und in großen Programmen freut man sich bestimmt über die zusätzlichen Informationen, die ja nun nicht ganz sinnlos da stehen.

    Das mit den langen Text hängt auch damit zusammen, daß man mir erzählt hat, daß man in Ada für gewöhnlich lieber den langen Weg geht, um wirklich das letzte bischen Info aus den Bezeichnern rausquetschen zu können.
    Auch das Typsystem mit den Subtypes bläht den Vereinbarungsteil des Programms auf, ist aber, finde ich, nicht störend und bringt auch Vorteile mit sich (zB die angesprochene Portabilität).

    Zu Compilernachrichten habe ich hier ein paar gefunden:
    http://studiwiki.informatik.uni-stuttgart.de/index.php?title=Ada/Compiler_Messages&printable=yes
    Allerdings zählen auch nicht nur die Compilernachrichten. Wenn ich in einem C-Programm irgendwelche seltsamen Ergebnisse finde (zB aufgrund eines Überlaufs, oder eines falschen Speicherzugriff), gibt es manchmal sehr viele Stellen an denen der Fehler liegen könnte. Da gibt es in Ada (auch in anderen Sprachen) die schönen Laufzeitprüfungen (übrigens sogar mit Zeilenangabe in dem der Fehler auftritt), die man, wenn alles läuft, auch ausschalten kann.



  • Mach dir nich so den Kopf. Lern die Sprache, weil du Freude daran hast. Die Sprache selbst hat auch ihre Ecken und Kanten, jedoch kannst du dich damit beruhigen das sie (neben Eiffel) besser die Methoden der Softwartechnik unterstützt. Der Blick über den Tellerrand eben.

    Noch zwei nützliche Links,

    Style Guide zu ADA95

    http://www.adaic.com/docs/95style/html/sec_1/

    Ada 2005 Reference Manual

    http://www.adaic.org/standards/05rm/html/RM-TOC.html

    PS: Hier etwas zu den named associations http://www.adaic.com/docs/95style/html/sec_5/5-2-2.html



  • Danke, für den Link, schau ich mir Morgen mal durch.

    Ich verstehe nicht ganz inwiefern die name association zur Portabilität beiträgt, das ist doch bei den meisten Sprachen nur ein Feature um das Problem mit Default-Argumenten zu umgehen wie es beispielweise in C++ auftritt.

    Ich denke Ada ist schon eine interessante Sprache, werde sie mir demnächst selbst mal anschauen, aber im Moment beschäftige ich mich eher mit funktionaler Programmierung.



  • Durch die Benutzung von einigen, festgelegten Typen erhält die Portabilität. Man verliert sie nicht. Bitshifts sind nur auf bestimmte, modulare Typen anwendbar. Dadurch wird z.B. gewährleistet, dass ein Shift um ein Bit nach Links immer einer Multiplikation mit zwei entspricht. Unabhängig von der Endianess des Systems. Solche Operationen werden meist auf Daten angewandt, die über irgendein Interface zu Ada hineinkommen bzw. herausgehen. Für interne Bitknispelleien nimmt man lieber Bitfelder.

    Ada versucht es einem durchaus so schwer wie möglich zu machen, wenn es um potentiell gefährliche Dinge geht. Einer der Designkriterien bei der Entwicklung der Sprache war da, dass es viele "dumme" Programmierer gibt. Diese sollen vom Compiler so gut wie möglich unterstützt werden, richten Code zu produzieren.

    Mal devon abgesehen gehen die Shift-Operatoren in C auch nur für die "modularen" Typen (Integer-Typen). Wenn man mehr will, muss man casten, wobei man dabei oft Schrott produziert. In Ada kann man das z.B. mit Unchecked_Conversion erreichen.

    Ich will Ada ebenfalls nicht verteidigen. Ich muss mit der Sprache arbeiten, obwohl ich lieber mit anderen Sprachen arbeiten würde. Ada ist oft nervig pingelig. man muss viel schreiben, um wenig zu erreichen. Z.B. dass ich zu jedem Typen aus einem anderen Packet auch erstmal die Operatoren sichtbar machen muss, ist einfach nur ätzend.
    Dennoch hat die Sprache durchaus ihre Stärken. Z.B. laufen Programme, die sich übersetzen lassen auch meist erstmal, ohne wirklich grobe Fehler zu verursachen (Speicherzugriffsfehler oder Lecks z.B.). Das starke Typenkonzept hat ebenfalls durchaus seine Vorteile. Ich finde es gut, dass man m/s nicht ohne Cast (also ohne explizit zu sagen, dass man Unsinn machen will) m/s2 zuweisen kann.
    Sehr gut ist auch, dass man Fehler die Exceptions auslösen (was die meisten Fehler tun) sofort anhand ihrer Zeilennummer und einer aussagekräftigen Fehlermeldung finden kann.
    Und die eingebauten Mechanismen zum Erstellen von multithreaded Programmen sind auch nicht zu verachten. Es wäre schön, wenn C++0x so was (auch wenn es auf Library-Ebene ist) auch bekommen würde (was ja angedacht ist, soweit ich da im Bilde bin). Und das Interfacing von und zu anderen Sprachen ist ebenfalls sehr bequem.



  • LOL? schrieb:

    Ich verstehe nicht ganz inwiefern die name association zur Portabilität beiträgt, das ist doch bei den meisten Sprachen nur ein Feature um das Problem mit Default-Argumenten zu umgehen wie es beispielweise in C++ auftritt.

    Die Named Associations meinte ich mit der Portabilität nicht (danke für den Link, vor allem den letzten Punkt hatte ich so noch nicht einberechnet). Die dienen eher der Übersichtlichkeit.

    Ich meinte das Typsystem. In Ada erstellst du dir ja eigene Subtypes, dessen Eigenschaften du selbst festlegt. Der Compiler entscheidet dann anhand der Eigenschaften, welcher eigentliche Datentyp benutzt wird. Er wählt sich einen aus, der auf dem jeweiligen System den Eigenschaften des Subtypes entspricht und möglichst Effizient umsetzt. Dadurch kannst du deine Subtypes auf jedem System nutzen, ohne etwas zu verändern und hast immer die gleichen Ergebnisse und beste Effizienz.

    Funktionale Programmierung lasse ich schön links liegen. Ich denke nicht, daß ich die beruflich als Elektroniker jemals gebrauchen kann. C werde ich jedoch auf jeden Fall anwenden müssen und Ada eventuell auch (Hier gibt es sogar eine Firma gleich um die Ecke, die bei AdaCore verlinkt wird).


Anmelden zum Antworten