Publication de la nouvelle norme Ada 2012

Posté par  (site web personnel, Mastodon) . Édité par Nÿco, baud123, Benoît Sibaud, Florent Zara et Lucas Bonnet. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
42
17
déc.
2012
Ada

Après plusieurs années passées à parlementer, la nouvelle norme Ada 2012 vient enfin d'être publiée par l'ISO sous le numéro ISO/IEC 8652:2012. Il s'agit donc de la quatrième révision du langage ajoutant ainsi différentes fonctionnalités par rapport à la version 2005.

N. D. M. : GNAT est le compilateur Ada du projet GNU, faisant partie de GNU Compiler Collection (GCC). Toujours en logiciel libre, on peut citer MaRTE OS un système d'exploitation libre temps-réel en Ada.

Sommaire

Syntaxe

Les points suivants ont été modifiés ou ajoutés.

Le if en tant qu'expression

Les expressions contenant des if sont maintenant permises. On peut donc écrire :

Febdays: constant := (if Leap then 29 else 28);

Cela peut sembler idiot mais cela n'existait pas.

Le case en tant qu'expression

Les expressions contenant des case sont aussi autorisées.

Hours := (case D is
   when Mon .. Thurs => 8,
   when Fri => 6,
   when Sat | Sun => 0);

Les expressions quantifiées

Derrière ce nom barbare se cachent en fait deux nouveaux mot-clés all et some. L'exemple fourni dans le Rationale est le suivant :

B := (for all K in A'Range => A(K) = 0);

qui mettra true dans la variable B si tous les éléments du tableau A sont à zéro. En substituant some à all, B vaudra true si seuls quelques éléments valent zéro.

Les fonctions unilignes

Une sorte de inlining a été ajouté au travers des fonctions expressions qui permet d'écrire le code sans passer par le classique duo begin…end si le code ne fait qu'une seule ligne.

Tests d'appartenance

Les tests d'appartenance ont été étendus pour ajouter le | dans le test. Il est donc possible d'écrire :

if M in Spring | June | October .. December then

Enfin, mais cela ne fait pas l'objet d'un paragraphe car très spécifiques, les règles de conversion dans certains cas d’ambiguïtés ont été assouplies.

Ajouts liés à la lisibilité

Un ensemble de changements a été fait pour améliorer le comportement du compilateur et les règles de vérification.

Sur les paramètres de fonctions et procédures

Un premier changement est l'ajout du mode in out pour les paramètres des fonctions. Cela introduit du coup une restriction qui est somme toute assez logique. Une fonction définissant un tel paramètre ne peut plus être incluse dans un autre appel directement si l'un de paramètres est aussi paramètre de l'appel du niveau supérieur.

Le second changement est la possibilité d'utiliser le mot clé aliased explicitement pour forcer un passage des paramètres par référence quelque soit leur type, cela n'était pas le cas pour les types simples. De plus, la possibilité pour une fonction de retourner des objets sous la forme aliased a été retirée pour éviter de potentiels problèmes de pointeurs pendants.

En vrac

Les autres changements sont donnés en vrac car requièrent réellement une bonne connaissance du langage :

  • Possibilité d'initialiser un discriminant y compris sur les types taggés limités ;
  • Ajout d'un use all type permettant d'ajouter l'intégralité des opérations liées à un type importé au lieu du cas par cas utilisé auparavant ;
  • Extension des possibilités du return.

Vérification statique

Pré-conditions et post-conditions

La gestion des pré-conditions et post-conditions dans la définition des fonctions a été ajoutée au langage. On peut maintenant préciser :

procedure Push(S: in out Stack; X: in Item)
  with
    Pre => not Is_Full(S),
    Post => not is Empty(S);

Les invariants

La prise en charge des définitions d'invariants a été ajoutée pour permettre l'écriture suivante :

type Disc_Pt is private
  with Type_Invariant => Check_In(Disc_Pt);

Les paramètres passés lors de la création d'un objet du type seront vérifiés.

Multitâche

Le principal ajout dans ce domaine est lié aux capacités multi-processeurs et à leur contrôle. Grâce à l'ajout d'un sous-paquetage spécifique, il est maintenant possible d'avoir accès aux informations relatives aux processeurs présents sur la machine. Cela permet au travers d'une spécification d'aspect (comme pour les pré et post-conditions) de préciser sur quel CPU une tâche doit tourner.

task My_Task
  with CPU => 10;

En plus de cet ajout, on trouve maintenant la possibilité d'avoir un compte-rendu du temps passé dans les interruptions, le pragma Volatile devient un aspect et enfin une correction sur le mécanisme requeue pour les objets impémentant une interface synchronisée.

Associé au multitâche, un dernier ajout a été fait. Il s'agit du passage du profil de programmation Profil_Ravenscar au architecture multi-processeurs.

Bibliothèque standard

Si tout ce qui précède touchait majoritairement le langage en lui-même, certains ajouts ont été faits sur la bibliothèque standard.

Codage de chaînes

Une nouvelle partie vient compléter la gestion des chaînes de caractères en fournissant les mécanismes de codage vers UTF8, UTF16 Big Endian et UTF16 Little Endian avec prise en charge du Byte_Order_Mark alias BOM. Elle fournit donc les transcodages entre types UTF et les conversions de String, Wide_String et Wide_Wide_String vers UTF.

Les conteneurs

Différents types de conteneur ont été ajoutés pour fournir de nouvelles fonctionnalités. On trouve donc les arbres multiples ainsi que des versions à stockage limité des tables de hachage, listes chaînées et doublement chaînées et des maps. A aussi été ajoutée une série de conteneurs utilisables en programmes multitâches. Bref, de quoi coller à quasiment toutes les utilisations.

Internationalisation

Pour finir, on trouve un petit paquetage pour un embryon de gestion de l'internationalisation. Son but est juste de fournir la langue et le pays définis au sein du système d'exploitation.

Conclusion

À quelques jours près, la sortie de la dernière mouture a bien failli coïncider avec l'anniversaire d'Ada Lovelace ce qui aurait été un symbole fort, mais bon, l'ISO ne prenant pas de soumission pour ce jour-là, cela n'a pas été possible. Finalement, Ada se modernise encore un peu plus, tout en conservant ses aspects liés à la programmation sécurisée ce qui, pour un langage déclaré mort maintes fois, n'est quand même pas si mal.

Aller plus loin

  • # Vive le fonctionnel

    Posté par  (site web personnel) . Évalué à 1.

    Tiens, je note que dans Ada, on rajoute quelques constructions inspirées par la programmation fonctionnelle. On a vu arriver la même chose dans python ces dernières années, et il me semble aussi dans les langages à la mode (Ruby, …) .

    Serait-ce l'avènement si longtemps attendu que bientôt toute programmation sera fonctionnelle ?

    En tout cas, j'imagine que ça fait bien rire les puristes de la programmation fonctionnelle par ailleurs, pour qui un Febdays: constant := (if Leap then 29 else 28); doit être le niveau 0 du fonctionnel.

    • [^] # Re: Vive le fonctionnel

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Tiens, je note que dans Ada, on rajoute quelques constructions inspirées par la programmation fonctionnelle.

      Sauf que je ne pense pas que le but soit de faire de la programmation fonctionnelle, il s'agit juste d'un sucre syntaxique.
      Les gens qui normalisent Ada n'ont pas pour habitude de suivre les effets de mode et laissent faire la programmation fonctionnelle à ceux dont c'est le métier. C'est pas demain la veille qu'Ada sera un langage fonctionnel.

      Serait-ce l'avènement si longtemps attendu que bientôt toute programmation sera fonctionnelle ?

      Attendu par qui ? Parce que l'avènement de Lisp, ça fait plus de 50 ans qu'on l'attend :D

      Sinon, pour mémoire, On n'est pas vendredi hein !

      • [^] # Re: Vive le fonctionnel

        Posté par  (site web personnel) . Évalué à 5.

        Je ne connais pas suffisamment Ada pour avoir un avis informé, mais visiblement, les ajouts permettent de traiter plein de "patterns" de programmation en une ligne, à coup de fonctions et d'expressions.

        Pour moi, c'est clairement une diffusion lente vers les autres langages (python, ruby, Ada, …) de certaines pratiques de la programmation fonctionnelle. On est plus dans le strict procédural, 1) je teste, 2) je compare mon résultat, 3) j'agis, mais bien dans l'évaluation d'une expression par application d'une fonction, avec des possibilités plus étendues sur les fonctions qu'on peut mettre dans ces expressions.

        D'ailleurs, est-ce que les fonctions sont des objets primaires en Ada ?

        • [^] # Re: Vive le fonctionnel

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          mais bien dans l'évaluation d'une expression par application d'une fonction, avec des possibilités plus étendues sur les fonctions qu'on peut mettre dans ces expressions.

          Enfin, c'est relativement limité quand même et c'est la raison pour laquelle je penche plus pour du sucre syntaxique qu'autre chose.

          D'ailleurs, est-ce que les fonctions sont des objets primaires en Ada ?

          Là, c'est moi qui ne connais pas assez la programmation fonctionnelle :D
          Mais a priori et d'après ce que j'ai compris du fonctionnel, non. On ne manipule pas les fonctions comme on pourrait le faire avec un objet, hormis le célèbre pointeur de fonction mais c'est la même chose qu'en C… Mais bon, j'ai peut-être pas bien compris ce que tu voulais dire :D

          • [^] # Re: Vive le fonctionnel

            Posté par  . Évalué à 1.

            Je n'ai jamais pu trouvé les pointeurs de fonctions en Ada. Aurais-tu un exemple ?

          • [^] # Re: Vive le fonctionnel

            Posté par  (site web personnel) . Évalué à 4.

            Là où on commence à s'amuser, c'est lorsqu'une fonction peut prendre en argument une fonction, et retourner une autre fonction.

            Je ne connais pas la syntaxe Ada mais en Python, ça donnerait:

            def compose(f, g):
    def h(v):
        return g(f(v))
    return h

            Là, on est vraiment dans la programmation fonctionnelle déjà un peu plus avancée. Si tu rajoutes à ça la mémorisation de l'environnement de la fonction, tu obtiens les fameuses closures :

            def call_and_add(f,delta):
    def h(v):
        return f(v)+delta
    return h

            Il parait que c'est super pratique et les développeurs ruby en sont des grands fans.

            J'imagine mal faire ça avec des pointeurs de fonction mais c'est sûrement possible avec beaucoup plus de lourdeur.

            • [^] # Re: Vive le fonctionnel

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Il parait que c'est super pratique et les développeurs ruby en sont des grands fans.

              Ouais avec le magnifique yield

              module Test
  class MaClasse
    # Ici un attribut
    attr_accessor :nawak

    def initialize
      @nawak = 12
    end

    def use_nawak
      yield @nawak
    end

  end
end

require 'ma_classe'

mon_instance = Test::MaClasse.new
mon_instance.nawak += 2
mon_instance.use_nawak do |le_nawak_param|
  puts "Donnes-moi ton nawak qui vaut #{le_nawak_param}"
end

              Trop de la balle, de l'injection de code !! :D

        • [^] # Re: Vive le fonctionnel

          Posté par  (site web personnel) . Évalué à 2.

          Non en fait le but c'est plutôt de pouvoir exprimer les pre- et post-condition ainsi que les invariants plus simplement. Pour le moment Ada n'est pas un langage fonctionnel du tout!

          • [^] # Re: Vive le fonctionnel

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            D'ailleurs, j'ai oublié de le préciser dans la dépêche mais les pre- et post-conditions génèrent un code d' assert levant une exception de type AssertionError si je me rappelle bien.

            le but c'est plutôt de pouvoir exprimer les pre- et post-condition ainsi que les invariants plus simplement

            Comme je le disais plus haut, du sucre syntaxique beaucoup plus qu'une remise en cause du paradigme.

    • [^] # Re: Vive le fonctionnel

      Posté par  . Évalué à 9.

      Serait-ce l'avènement si longtemps attendu que bientôt toute programmation sera fonctionnelle ?

      Non les langages actuellement brisent les limites entre les types de programmation. Le tout objet ou le tout fonctionnel on sait que ça ne marche pas sinon haskell et smalltalk seraint plébiscité. Non actuellement les langages objets intègres des fonctionnalités de programmation fonctionnelle. D'autres langages sont directement multiparadigmes Ocaml et Scala par exemple. Je trouve que c'est une très bonne chose pourquoi chercher à ce que « toute programmation soit fonctionnelle » ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Vive le fonctionnel

        Posté par  . Évalué à 3.

        Bravola faute, j'ai passé deux seconde à me demander si un langage à objets intègres existait vraiment :)

      • [^] # Re: Vive le fonctionnel

        Posté par  (site web personnel) . Évalué à 3.

        Ne pas confondre popularité et qualité. Loft Story est/était populaire et pourtant ça reste de la daube.

        Premier point : on peut faire de la programmation impérative avec Haskell. La différence avec Scala et Ocaml c'est que le compilateur sait quelles zones du code effectuent des effets de bord car ça apparaît dans les types. Exemple :

        import System.IO

main = do
  putStr "Enter your name: "
  hFlush stdout
  s <- getLine
  putStrLn $ "Hello " ++ s

        Le type de la fonction main est "IO ()", le IO indiquant que la fonction fait des effets de bord. Le "do" indique que les lignes de code de la fonction doivent être exécutées séquentiellement. (Je simplifie un maximum. Ceux qui sont intéressés pourront lire que "do" est du sucre syntaxique pour tous les monads, ici l'IO monad).

        C'est une différence fondamentale : par défaut les effets de bord sont interdits. En Scala la question revient souvent d'intégrer un "effect system" pour détecter les fonctions pures des autres. Il est question d'ajouter des annotations de type @pure. Mais ça pose des problèmes, par exemple :
        - la bibliothèque standard repose sur celle de Java qui n'a pas ces annotations.
        - que faire pour les fonctions du genre List[A].map(f : A -> B) pour lesquelles le comportement et les optimisations ne sont pas les mêmes si f est pure ou non ?
        Bref c'est pas pour tout de suite…

        Pour finir une petite citation de Guy Steele qui cherchait à créer un successeur à Fortran dans le domaine du calcul haute performance à travers le projet Fortress :

        Although Fortress is originally designed as an object-oriented framework in which to build an array-style scientific programming language, […] as we've experimented with it and tried to get the parallelism going we found ourselves pushed more and more in the direction of using immutable data structures and a functional style of programming. […] If I'd known seven years ago what I know now, I would have started with Haskell and pushed it a tenth of the way toward Fortran instead of starting with Fortran and pushing it nine tenths of the way toward Haskell.

        Traduction rapide :

        Bien que Fortress soit conçu à l'origine comme un cadriciel (framework) orienté-objet au sein duquel on pourrait utiliser un langage de programmation orienté tableaux, […] plus nous expérimentions et essayions de mettre au point le support du parallélisme, plus nous nous sommes trouvés entraînés du côté des structures de données immuables et de la programmation fonctionnelle. […] Si j'avais su ce que je sais maintenant il y a 7 ans, j'aurais commencé avec Haskell et l'aurait modifié de 10% en direction de Fortran plutôt que de commencer avec Fortran et de le modifier de 90% en direction d'Haskell.

        http://www.haskell.org/pipermail/haskell-cafe/2011-January/088245.html

        • [^] # Re: Vive le fonctionnel

          Posté par  . Évalué à 6.

          Ne pas confondre popularité et qualité. Loft Story est/était populaire et pourtant ça reste de la daube.

          Je n'ai pas parlé de popularité. Si les gains (de la programmation impérative, fonctionnelle, objet, par aspect ou je ne sais quoi) étaient aussi monstrueux que ce qu'expriment certains puristes, il y a bien un moment où ça commencerais à se voir. Pour ce qui est du fonctionnel, comme tu le dis, il y a forcément un système comme les monades parce qu'un programme qui n'interagie pas avec le système n'a pas d'intérêt (ou alors dans un contexte qui m'échappe). La programmation objet a apporté un grand nombre de choses tout à fait bénéfiques, même si des fois quand on lis les commentaires sur linuxfr on a l'impression que c'est le mal absolue.

          Je ne dis pas qu'ils sont tous identiques, je dis qu'ils ont tous leur intérêt et ils deviennent nécessaires dans certains cas. C'est pour ça que j'ai l'impression qu'avoir plusieurs paradigmes au sein d'un même langage est une bonne chose. Ça rend le langage bien plus compliqué, mais il s'adapte bien mieux à différents contextes ou différentes applications.

          Bien sûr c'est aussi une question de « philosophie ». On peut déjà se rapprocher de certains concepts fonctionnels avec des langages objet par exemple (utilisation de fonction pure, implémenter un maximum de contrainte dans le typage, etc). Beaucoup de code impératifs se rapprochent des concepts objets.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Vive le fonctionnel

            Posté par  . Évalué à 5.

            Une chose me fera d'ailleurs toujours rire, chez les détracteurs du paradigme objet, et tout particulièrement chez les dev C haineux du C++:

            Un programme (ou une librairie d'ailleurs), c'est:
            _ des variables internes globales (pas obligatoires, certes)
            _ un point d'entrée vers une fonction précise
            _ un jeu de fonctions ayant accès aux variables globales
            _ une interaction avec l'environnement, que ce soit en utilisant des "fonctions globales" ayant accès au système, ou en utilisant stdin, stdout et stderr

            Lors de l'exécution d'un programme, le système commence par:
            _ charger le code en mémoire
            _ initialiser les variables globales (cette étape est la même que le chargement du code en mémoire dans certains langages, bien que j'imagine qu'il faille de toute façon initialiser les accès vers les 3 flux standards: stdout, stdin, stderr)
            _ exécuter le point d'entrée, en lui passant les paramètres de la ligne de commande, qui permettent de manipuler le programme d'une façon précise
            _ nettoyage des ressources du programme (parce que sinon, fermer/tuer un programme avec des memory leaks ne viderait pas la mémoire… payes ta galère!)

            La remarque intéressante, qui me fait rire, maintenant:
            les étapes de l'exécution d'un programme sont exactement les mêmes que pour l'exécution d'un objet: on crée un espace mémoire, on initialise (appel du constructeur) les données, on utilise différents moyens de manipuler l'objet, puis quand on a finit de l'utiliser, on nettoie les ressources qu'il à utilisées (destructeur, ou garbage collector, selon le langage)

            Au final, un programme, c'est une classe… sauf que:
            _ le système doit initialiser la mémoire à chaque manipulation, puisque la mémoire est vidée entre chaque appel
            _ comme la mémoire est vidée entre chaque appel, le concepteur du programme doit permettre une mécanique pour sérialiser/désérializer les données: sauvegarde sur fichier, souvent, qui, comme tout le monde le sait, implique un accès disque, particulièrement lent. Ce point est nécessaire si on veut effectuer plusieurs manipulations différentes permises par un programme sur un même jeu de données.

            Du coups, moins de performances.
            Autre point négatif, la spécialisation d'un programme en plusieurs déclinaisons est plus complexe a écrire.

            D'ailleurs, ce même point me fait également rire chez les fanatiques du tout objet comme JAVA, ou C#, mais en sens inverse:
            il est très drôle de constater qu'il faille créer une "classe programme", ayant une méthode statique main, qui ne peut donc pas accéder aux données de l'instance du programme: cette méthode main doit instancier la "classe programme" :D
            Si les concepteurs de ce langage avaient été jusqu'au bout de leur délire, le résultat aurait pu être intéressant: considérer qu'un programme c'est l'instanciation d'une classe, puis l'appel à une méthode précise aurait été plus logique, et sûrement plus orienté objet, que d'imposer l'utilisation de méthodes statiques…

            Donc, je te rejoins entièrement quand tu dis que le mono paradigme n'est pas parfait.
            C'est d'ailleurs la raison qui fait que j'apprécie C++, puisqu'il permet l'utilisation de plusieurs paradigmes à la fois: impératif, objet, générique… pas le fonctionnel, ni la programmation par contrat, ni la programmation logique, malheureusement.
            Cela dis, si j'ai bien compris ce que sont les programmations par contrat et fonctionnelle, il intègre quelques outils permettant de s'en rapprocher (via l'utilisation du mot-clé const qui garantit l'immutabilité d'une donnée).
            Si un jour un langage implémentait tout ces paradigmes, je pense qu'il serait celui qu'on pourrait le plus considérer comme langage absolu.

            Dommage qu'il serait probablement encore plus complexe à maîtriser que C++…

            • [^] # Re: Vive le fonctionnel

              Posté par  (site web personnel) . Évalué à 3.

              Si un jour un langage implémentait tout ces paradigmes, je pense qu'il serait celui qu'on pourrait le plus considérer comme langage absolu.

              Ça existe déjà et ça s'appelle Oz (cf Peter Van Roy). Je vous recommande de lire son livre d'ailleurs (Concepts, Techniques and Models) ou au moins l'article résumé : http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

              • [^] # Re: Vive le fonctionnel

                Posté par  . Évalué à 2.

                Je marche, je cours, je vole lire des docs au sujet de ce langage!

                Merci beaucoup, je pense que ça va être très intéressant.

            • [^] # Re: Vive le fonctionnel

              Posté par  (site web personnel) . Évalué à 1.

              [Je ne vois pas trop d'où sort ton post (relativement au précédent, mais bon)]

              Concernant la PpC et le fonctionnel. Le C++ intègre quelques outils du fonctionnel avec l'arrivée des lambdas dans le C++11. On peut trouver à redire, mais cela reste mieux rien. La PpC, même si elle n'est pas enrobée de sucrage syntaxique, marche très bien en natif. Le pattern NVI est un bon début (je te laisse chercher dans la FAQ C++ de dvpz, ou sur le More C++ Idioms en wikibook). Il suffit ensuite de choisir entre assertions pour traquer l'erreur de programmation, ou exceptions pour l'erreur de contexte ou la programmation défensive.

              Sinon, hormis pour le fonctionnel (et la generative meta-programmation), Eiffel présente(/ait?) beaucoup de ces choses.

              • [^] # Re: Vive le fonctionnel

                Posté par  . Évalué à 3. Dernière modification le 19 décembre 2012 à 22:08.

                D'ici:

                Je ne dis pas qu'ils sont tous identiques, je dis qu'ils ont tous leur intérêt et ils deviennent nécessaires dans certains cas. C'est pour ça que j'ai l'impression qu'avoir plusieurs paradigmes au sein d'un même langage est une bonne chose.

                Ou le post précédent indique que le mono paradigme est ridicule. Certes, je me suis "un peu" étendu… mea culpa.

                Par ailleurs, j'ai bien précisé, il me semble, que C++ intègre des outils permettant d'utiliser quelques concepts du fonctionnel et la PpC, je squatte également DVP et ai lus divers documents à gauche et à droite ;)

                Je voulais simplement indiquer que ces paradigmes ne sont pas officiellement implantés dans le C++, rien de plus. Après, quand on sort boost, c'est un C++ bien boosté que l'on récupère, en effet, et qui permet l'utilisation de trucs assez impressionnants… même trop pour mon niveau actuel.

        • [^] # Re: Vive le fonctionnel

          Posté par  . Évalué à 4.

          Point supplémentaire la "lazyness" par défaut d'Haskell est considéré comme un inconvénient pour les perfs et le parallélisme.

          • [^] # Re: Vive le fonctionnel

            Posté par  (site web personnel) . Évalué à 1.

            Tu n'es pas obligé d'utiliser Haskell. Tu as des langages fonctionnels stricts et tu peux utiliser de la réduction de graphe en parallèle. Si tu ajoutes d'autres contraintes pour avoir un modèle "total functional" ou des "dependent types" tu as encore d'autres propriétés qui peuvent être utiles pour le parallélisme.

            • [^] # Re: Vive le fonctionnel

              Posté par  . Évalué à 1.

              Que font les types dépendants dans la cadre du parallélisme ?

              • [^] # Re: Vive le fonctionnel

                Posté par  (site web personnel) . Évalué à 1.

                On cherche à déterminer statiquement le plus d'informations possible sur les dimensions des données pour pouvoir anticiper les partitions et les distributions des données automatiquement.

                • [^] # Re: Vive le fonctionnel

                  Posté par  . Évalué à 1.

                  Effectivement, merci pour cette information. Il y a des langages « orientés performances » où l'on peut expérimenter ce genre de fonctionnalités ?

                  Sinon, les contraintes de linéarités et autres logiques sous structurelles offrent également des garanties intéressantes pour la génération de codes performants et parallélisables.

                  • [^] # Re: Vive le fonctionnel

                    Posté par  (site web personnel) . Évalué à 1.

                    Il y a des langages « orientés performances » où l'on peut expérimenter ce genre de fonctionnalités ?

                    Pas que je sache. Dans le cadre du calcul haute performance, l'offre en matière de langages de programmation de haut niveau est très limitée.

                    Sinon, les contraintes de linéarités et autres logiques sous structurelles offrent également des garanties intéressantes pour la génération de codes performants et parallélisables.

                    J'ai regardé rapidement car je ne connais pas tout ça. Tu as des références à recommander ?

                    • [^] # Re: Vive le fonctionnel

                      Posté par  . Évalué à 2.

                      Les logiques sous-structurelles permettent de suivre au niveau du système de types l'utilisation et le partage de ressources (pour traquer des leaks ou de l'aliasing, borner l'utilisation de la mémoire, …).

                      Cela permet par exemple de réconcilier pureté et mutations (si une ressource n'est pas partagée et qu'elle est mutée, personne ne pourra observer cette mutation), et conduit à des implantations sûres et efficaces.

                      Au niveau des langages permettant de jouer avec ces concepts :

                      Pour davantage d'informations :

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

                      • [^] # Re: Vive le fonctionnel

                        Posté par  (site web personnel) . Évalué à 1.

                        Merci ! J'ai copié ton message et je regarderai tout ça dès que j'aurai un peu de temps. Je connaissais Clean de loin notamment pour l'alternative aux monades utilisée pour gérer les IO, mais il faudra que je regarde ça de plus près.

          • [^] # Re: Vive le fonctionnel

            Posté par  . Évalué à 2.

            Par qui ? Je connais tout un tas de gens qui n'ont absolument pas de problème avec Haskell et le parallélisme.

            • [^] # Re: Vive le fonctionnel

              Posté par  . Évalué à 2.

              Même coté performance?

              • [^] # Re: Vive le fonctionnel

                Posté par  . Évalué à 2.

                Je crois que ça viens du fait qu'avec le "laziness" tu as du mal à savoir ou et quand sont fait les calcules.

      • [^] # Re: Vive le fonctionnel

        Posté par  . Évalué à 3.

        D'après le papa de Scala, programmation OO et langage impératif/fonctionnel sont deux concepts orthogonaux.

        Sinon je suis d'accord avec toi : il y a une lente fusion des styles de programmation dans les langages en ce moment.

  • # Popularité

    Posté par  (site web personnel) . Évalué à 4.

    Le langage Ada a l'air puissant et complet, pourquoi est-il si peu populaire par rapport à C++ ou Java en entreprise?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Popularité

      Posté par  . Évalué à 5.

      Au départ (il y a un peu plus de 25 ans), Ada n'était pas "objet" du tout, la seule API graphique disponible était directement X-Windows et ce n'était pas le langage le plus simple à appréhender. En outre, le marché proposait très peu de développeurs Ada. J'imagine que ces raisons, parmi d'autres sans doute, n'ont pas incité les entreprises à faire l'effort d'adopter le langage, sauf pour certains clients où ce choix était stratégique (systèmes à haute sûreté comme la conduite de centrales nucléaires, par exemple).

    • [^] # Re: Popularité

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Pour plusieurs raisons :
      - lors de sa sortie au début des années 80, étant un langage demandé par le département de la défense américain, il a été boudé par les universitaires et donc n'a que très peu été enseigné à cette époque
      - les premiers compilateurs coûtaient extrêmement cher avec une fâcheuse tendance à être buggué
      - il est souvent vu comme trop verbeux, trop complexe et trop contraignant

      Disons qu'il a toutefois un marché de niche dans les équipements où la sûreté de fonctionnement est plus importante que tout. Du coup, on trouve de l'Ada dans l'aéronautique, l'aérospatiale ou la défense.
      Mais bon, C++ a pris en partie sa place dans certains programmes de ces secteurs mais c'est aussi en grande partie dû au fait qu'il est moins enseigné que C++ ou Java.
      Personnellement, je trouve ça assez dommage surtout quand on voit la complexité de la dernière norme C++, complexité qui a longtemps été reprochée à Ada.

    • [^] # Re: Popularité

      Posté par  . Évalué à 3.

      C'est aussi une question que je me pose. Pour avoir eu un prof féru d'Ada, il nous disait que la courbe d'apprentissage était plus dure que le C au début (et ça c'est vrai, le démarrage est dur en Ada). Forcément, pour le C il n'y a pas grand-chose à savoir.
      Je me demande si ce n'est pas la principale raison.
      Ou alors parce qu'il y avait moins de compilateurs Ada que C dans les années 90, et ils étaient plus chers?
      Ou bien parce qu'une fois que les gens avaient l'habitude du C, ils ne voulaient plus changer (mais ce n'est pas valable pour Java dont la diffusion est plus récente)
      Ou tout simplement parce qu'il n'y a pas eu de grosse boîte pour pousser le langage (contrairement au Java)?

      • [^] # Re: Popularité

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Pour ce qui est de Java, il faut aussi bien voir qu'il y avait la promesse du Write once, run everywhere et surtout la possibilité d'embarquer du vrai code dans une page web avec les applets.
        Quand j'ai commencé en Java en 97, c'est d'ailleurs ce dernier point qui était mis en avant et qui aujourd'hui peut sembler délirant tant les applets ont quasi disparu de la circulation.

      • [^] # Re: Popularité

        Posté par  . Évalué à 6.

        Pas besoin d'aller chercher loin: beaucoup d'outils pour Java étaient gratuits et il y avait une forte publicité faite par Sun, donc Java a décollé même si au départ les outils étaient de faible qualité (j'ai beaucoup souffert des bugs de la plateforme Java dans les années 2000)..

        Les outils pour Ada étaient cher (voire très cher) et il y avait très peu de marketing derrière --> un langage resté confidentiel malgré ses qualités..

        C'est un peu écoeurant d'ailleurs, je trouve qu'Ada a bien plus de qualité que Java (bon ce n'est pas exactement la même cible), le DoD a vraiment manqué de vision sur le coup: ils auraient du sponsoriser GNAT beaucoup plus tôt, organiser des conférences, faire de la pub (une goutte d'eau dans leur budget) et une fois la pompe amorcée ils auraient récolté plein de programmeurs Ada..

        • [^] # Re: Popularité

          Posté par  (site web personnel) . Évalué à 2.

          Et aujourd'hui, est-ce qu'il est au niveau?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Popularité

            Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 18 décembre 2012 à 10:32.

            Au niveau de quoi ? Des outils ? Gnat, c'est du GCC donc on peut faire du profiling, du debugging, il y a un environnement nommé Gnat-GPS, des bibliothèques…

            • [^] # Re: Popularité

              Posté par  (site web personnel) . Évalué à 3.

              Aujourd'hui si je dois échanger:

              • mon baril de C++, ce serait pour de meilleures performances.
              • mon baril de Java, ce serait pour des outils (IDE, debugger, refactoring, gestion de dépendances, GUI designer…) plus productifs.
              • mon baril de python/django, ce serait pour du rad web encore plus rad!

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Popularité

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                mon baril de C++, ce serait pour de meilleures performances.

                Pour les performances, c'est jouable, il suffit de regarder là. Bon, en relativisant les résultats parce que le site, c'est un peu le jeu du "c'est moi qui ai la plus grosse". Mais, les performances d'Ada se rapproche plus du C que de C++.

                mon baril de Java, ce serait pour des outils (IDE, debugger, refactoring, gestion de dépendances, GUI designer…) plus productifs.

                Là, autant être objectif, non.
                - IDE : GPS qui n'est pas mal mais pas au niveau d'un Eclipse ou GnatBench que je n'ai pas encore essayé
                - Debugger : comme je te le disais, on utilise les mêmes outils que pour du C/C++ à savoir pour le debugger gdb ou mieux ddd
                - Gestion des dépendances : C'est un langage compilé avec les problèmes inhérents de différences entre architectures donc il est difficile de partager des bouts de binaires et puis, il n'y a aucun outil pour (si tu pensais à un maven-like)
                - GUI designer : avec les dernières versions de GtkADA, on peut utiliser le GtkBuiler et donc créer des IHMS avec Glade mais comme je suis un vieux con, moi, je le fais à la main :D

                mon baril de python/django, ce serait pour du rad web encore plus rad!

                Là encore, non. On ne fait pas de RAD en Ada, on réfléchit ;)
                On peut quand même trouver quelques trucs un poil avancés chez Stéphane Carrez en termes de programmation Web notamment Ada Server Pages mais ce n'est pas du RAD.

    • [^] # Re: Popularité

      Posté par  (site web personnel) . Évalué à 8.

      Mon expérience perso : on a appris l'algorithmique en Ada (on avait aussi des cours de C, Java, etc.).

      En C : on codait, on compilait, on lançait, ça plantait, on re-codait, on re-compilait, on re-lançait, ça re-plantait, etc.

      En Ada : on codait, ça ne compilait pas, on codait, ça ne compilait pas, …, ça compilait, on lançait, en général ça marchait.

      Le fait de ne pas réussir à compiler et les contraintes multiples sont plutôt désagréables pour un débutant. Et par ailleurs on avait un compilateur Ada pénible, lent et qui saturait nos faibles espaces disques.

      Les années ayant passé, j'apprécierais plus d'avoir un compilo sympa qui m'aide et me signale les soucis à la compilation.

      L'apprentissage de l'Ada paraît plus difficile initialement. Et les compilos se sont améliorés depuis je pense.

      • [^] # Re: Popularité

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Moi, j'aime bien les messages du compilo

        with Ada.Text_Io; use Ada.Text_Io;

procedure Test is

   type My_Int is range 12..42;

   Ma_Var : My_Itn := 14;
begin
   Put_Line("Ma var =" & My_Int'Image(Ma_Var));
end Test;

        qui après tentative de compilation donne

        fred@freddy:~/perso/Ada $ gnatmake test.adb
gcc-4.6 -c test.adb
test.adb:7:13: "My_Itn" is undefined
test.adb:7:13: possible misspelling of "My_Int"
gnatmake: "test.adb" compilation error

        Les messages de gnatgcc sont généralement assez clairs y compris dans les generics (contrairement à ceux fournis pour les templates C++).

        En fait, il faut prendre le compilo comme une aide au développement, pas comme un truc qui est là pour faire chier.

        • [^] # Re: Popularité

          Posté par  (site web personnel) . Évalué à 7.

          Les message d'erreur C++ ont beaucoup évolués ces dernière années. Il faut que tu essayes clang. (et même GCC 4.7 a largement améliorer ces message d'erreurs, motivé par la concurrence)

          typedef int My_Int;
void Test() {
    My_Itn Ma_Var = 14;
    std::cout << "Ma var = " << Ma_Var << std::endl;
}


          $ clang++ test.cc
test.cc:6:5: error: unknown type name 'My_Itn'; did you mean 'My_Int'?

          Et en image:
          clang

    • [^] # Re: Popularité

      Posté par  (site web personnel) . Évalué à 5.

      Il est puissant et complet, à n'en pas douter. C'est d'ailleurs ce que je réponds lorsque des étudiants me demandent pourquoi ils commencent par apprendre l'Ada et non le C ou le Java. Ce que je leur dis c'est que c'est un bon langage pour débuter et qu'il contient tous les concepts de la programmation impérative. Une fois ces concepts compris, le reste n'est qu'une histoire de syntaxe.

      Personnellement, je rêverais de faire du Python à la place de l'Ada pour commencer, mais jamais ils vont vouloir se mettre au C après. Comment tu veux essayer de leur faire faire à la main des listes chaînées ou des tas avec un langage qui te fournit très simplement toutes sortes de structures de données avancées ?

      Bref, l'Ada c'est bien pour enseigner, mais c'est quand même ultra verbeux et les outils sont rares. Tu n'as pas de logiciel à la auteur de ce que fait Eclipse pour le Java dans le monde Ada. Tu n'as pas non plus toutes les bibliothèques disponibles pour Java en Ada. L'outillage est quand même la clef du succès d'un langage en entreprise.

      • [^] # Re: Popularité

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Tu n'as pas non plus toutes les bibliothèques disponibles pour Java en Ada.

        Oui, enfin c'est pas non plus les bindings vers des bibliothèques C qui manquent et quand elles n'existent pas, c'est quand même assez simple à faire.
        C'est juste une question de volonté, de nombre d'utilisateurs et donc de mode car il ne faut pas oublier qu'à ses débuts, Java n'était pas non plus autant fourni, que ce soit dans sa bibliothèque standard que dans les externes.

        L'outillage est quand même la clef du succès d'un langage en entreprise.

        C'est une des clés, pas LA clé car sinon, on ne ferait plus de C ni de C++, ni plein d'autres langages car il n'y en a franchement pas beaucoup qui disposent d'un IDE comme Eclipse.

        • [^] # Re: Popularité

          Posté par  (site web personnel) . Évalué à 8.

          il n'y en a franchement pas beaucoup qui disposent d'un IDE comme Eclipse.

          Eclipse est un argument qui, suivant l'interlocuteur, peur être vu très positivement ou très négativement ;-)

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Popularité

        Posté par  . Évalué à 2.

        Je travail dans la maintenance de logiciels embarqués dans le secteur de la défense en langage C et ADA.

        A choisir en C ou ADA, je préfère largement ADA : moins de chance de tomber sur un pointeur fou, cast douteux, ou autre débordement de tableau qui nécessite des jours voir des semaines à déboguer. Surtout quand on travail sur un calculateur avec comme unique moyen de debug une liaison série et un printf.

        Certes, coder en ADA est long et fastidieux, l'outillage est quasi obsolète. Mais ça finit par payer dans le long terme.

        Malheureusement, je constate que ce beau langage disparait petit à petit, laissant la place au C ou C++. Les faiblesses sécuritaires des ces langages sont (théoriquement) compensées par l'utilisation massive d'outils de vérification de règles de codage et autres tests unitaires.

        • [^] # Re: Popularité

          Posté par  . Évalué à 4.

          Je ne te contredirais pas sur le point des faiblesses de sécurité du C++, parce qu'il est simple de créer un pointeur fou ou une référence folle mais je tiens cependant à mettre les points sur les I:

          C++ à un typage nettement plus strict que C. Le cast de type utilise 4 mots-clés différents, plus la syntaxe hérité de C:
          _ static_cast(donnée) => à utiliser tout le temps! Tout est vérifié à la compilation, ce qui permet de n'avoir aucun impact sur les performances, et un refus de compilation si l'on fait de la merde.
          _ dynamic_cast(donnée) => à utiliser dans le cas d'un cast d'un type vers un type enfant. Quelques vérifications à la compilation, le reste à l'exécution, au moins si on a merdé, le plantage est immédiat avec la levée d'une exception si "donnée" est une référence, ou le renvoi d'un pointeur nul si donnée est un pointeur. Dans ce dernier cas, il est évident qu'il faut systématiquement vérifier et traiter la validité du pointeur.
          _ const_cast(donnée) => à n'utiliser que dans le cas d'un interfaçage avec du code pourri. Et encore… Au moins a-t-il le mérite de vérifier que le type d'arrivée est le même que le type de destination, à la constance de la donnée près (il permet de virer la contrainte de constance…beurk)
          _ reinterpret_cast(donnée) => à proscrire! C'est l'équivalent du cast C: aucune vérification! Malheureusement, il est nécessaire dans le cas ou l'on s'interface avec du code C, typiquement, si on utilise dlopen()
          _ (type)(donnée) => héritage du C, à bannir, car aucune vérification. Certes, plus lisible que la version C++ (reinterpret_cast) mais moins évident à retrouver et éradiquer dans un code source. Faire un CTRL+F (ou / ou… peu importe) est plus simple sur "reinterpret_cast" après tout :P

          Et pour en revenir aux pointeurs, principale cause de problèmes, C++11 s'est pas mal amélioré, l'usage et l'abus de pointeurs intelligents permet de s'affranchir de nombre de soucis. La solution n'est pas parfaite, c'est sûr…

          Si le C++ n'avais pas à conserver son héritage C, je pense qu'il serait plus simple et plus robuste. Mais la conservation de cet héritage à une utilité…

          Enfin, ce qui est sûr, c'est que j'ai toujours voulu jeter un oeil à ADA, justement grâce à sa réputation d'être infernal à compiler. Après tout, si j'active un maximum de warning dans les compilos, ce n'est pas pour rien, j'aime quand le compilateur me signale un gros PEBCAK ou WTF :)
          C'est le genre de raisons qui font que j'ai d'ailleurs un mal de fou à aimer les langages au typage trop faible.

          • [^] # Re: Popularité

            Posté par  (site web personnel) . Évalué à 3.

            Parenthèse
            Le sens exact du cast C dépend du contexte en C++. La simple présence d'un type non défini, mais juste déclaré (dans l'expression) peut aussi changer son sens.
            Quant à reinterpret_cast<>, comme son nom l'indique, c'est pour interpréter autrement une séquence d'octets. Je suis d'ailleurs surpris que tu dises que ce soit lui à utiliser sur un dlopen car la norme préconise static_cast<> vers et depuis du void*.

            PS: Passer au C++ moderne (RAII, lib standard) limite grandement les risques autour de la mémoire. Il faut juste se débarrasser de sa façon de programmer C, et plutôt se rapprocher de ce que l'Ada nous apprend (vu comme il est compliqué (comme dans, il faut vraiment le faire exprès et le vouloir) d'aller bidouiller la mémoire avec lui—dans mes souvenirs)

            • [^] # Re: Popularité

              Posté par  . Évalué à 3.

              Parenthèse
              Le sens exact du cast C dépend du contexte en C++. La simple présence d'un type non défini, mais juste déclaré (dans l'expression) peut aussi changer son sens.

              C'est pour ça qu'il vaut mieux l'éviter, parce que si le static_cast ou le dynamic_cast ne passent pas, ben au pire il fera le reinterpret_cast, là ou il eut fallu avertir le programmeur qu'il à fait une connerie, parce que celui-ci voulait utiliser un static_cast en fait (pour imager).

              Quant à reinterpret_cast<>, comme son nom l'indique, c'est pour interpréter autrement une séquence d'octets. Je suis d'ailleurs surpris que tu dises que ce soit lui à utiliser sur un dlopen car la norme préconise static_cast<> vers et depuis du void*.

              Pour le static_cast du dlopen… bah, en fait, je me suis planté, je pensais à dlsym, puisque dlopen renvoie un pointeur vers on-ne-sait-quoi, qui doit donc rester void*.
              Le retour de dlsym (qui lui renvoie le pointeur vers fonction) à lui bien besoin d'être casté pour être exploitable, en revanche, merci pour m'avoir rapporté mon erreur et permis de corriger mes propres propos.
              C'est donc pour dlsym et son retour qu'il faut utiliser le reinterpret_cast

              PS: Passer au C++ moderne (RAII, lib standard) limite grandement les risques autour de la mémoire. Il faut juste se débarrasser de sa façon de programmer C, et plutôt se rapprocher de ce que l'Ada nous apprend (vu comme il est compliqué (comme dans, il faut vraiment le faire exprès et le vouloir) d'aller bidouiller la mémoire avec lui—dans mes souvenirs)

              C'est ce que je voulais mettre en exergue par mon post, C++ est relativement sûr. Toutefois, j'ai beau adorer RAII, certaines erreurs (qui sont de ma part, je ne le nie pas) sont parfois complexes à détecter. Allez, rien que le fait qu'on ne puisse utiliser de références dans les templates, ça force à l'utilisation de smart pointers pour les collections, et aux galères qui viennent avec. unique_ptr n'est pas franchement si agréable que ça à utiliser.

              D'ailleurs, j'espère que le prochain C++ intégrera une lib comme celle fournie par boost::pointer_container (pas sûr du nom exact) qui permet de gérer des collections polymorphes sans se casser la tête, bien qu'il reste quelques failles mineures qui font qu'on utilise malgré tout encore des pointeurs (puisqu'on veut parfois une référence sur un objet, mais sans le copier, et que cette lib ne permet "que" de rentrer des objets entiers, les clonant si nécessaire, et nettoyant la mémoire à la destruction.) ou permettra directement l'usage des références par les templates. M'est avis que ça m'enlèverai une sacrée épine des pieds.

  • # Temps réel

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    En me baladant sur le site de MaRTE OS, j'ai pu retrouver ce lien qui montre une utilisation sympa d'Ada dans son domaine de prédilection, le multitâche temps réel.
    De fil en aiguille, je suis arrivé sur cette petite vidéo via une page de l'ENST.
    Que des petits trucs sympas quoi ! :)

  • # Erreur possible ?

    Posté par  . Évalué à 2. Dernière modification le 02 janvier 2013 à 01:33.

    Ça fait un moment que je n'ai pas fait d'Ada (au moins un an depuis que j'ai changé de boulot, surement un peu plus), et c'était de l'Ada nonante-cinq à l'époque, donc ce n'est pas sûr, mais en lisant le paragraphe suivant dans la dépêche je pense qu'il y a une erreur :

    Un premier changement est l'ajout du mode in out pour les paramètres des fonctions. Cela introduit du coup une restriction qui est somme toute assez logique. Une fonction définissant un tel paramètre ne peut plus être incluse dans un autre appel directement si l'un de paramètres est aussi paramètre de l'appel du niveau supérieur.

    J'ai plutôt l'impression que ça devrait être n'importe quelle fonction qui ne peut plus être incluse dans l'appel à une fonction avec un paramètre in out. (c'est peut-être ce que la phrase veut dire mais ce n'est pas ce que j'ai compris)

    Ce que je pense :

        -- fonction normale
    function A(x : Integer) return Integer is begin ... end;

    -- nouvelle fonction si j'ai bien compris
    function B(y: in out Integer) return Integer is begin ... end;

    -- ce qui est interdit, je pense
    z := B(A(42));

    -- ce que je comprends de la phrase
    -- en fait je ne sais même pas comment écrire un appel tel que décrit par la phrase ;-)

    Bon sinon je n'arriverai jamais à savoir comment dire à Markdown quel langage je veux utiliser…

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Erreur possible ?

      Posté par  . Évalué à 2.

      Bon comme j'avais du temps, j'ai été rechercher dans l'introduction à Ada 2012 (ce que j'aurais du faire avant) et ce qui est interdit c'est :

      -- en reprenant ma fonction B, F étant une fonction de deux entiers quelconques, et x un entier)
F(x, B(x))

      Ça s'explique. Mais je me demande quand même si mon exemple est interdit ou pas. (on modifierait la sortie d'une fonction, mais elle n'existera plus dès que l'appel sera fini.)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Erreur possible ?

      Posté par  (site web personnel) . Évalué à 2.

      Bon sinon je n'arriverai jamais à savoir comment dire à Markdown quel langage je veux utiliser…

      en passant une ligne devant ```ada cela fonctionne bien :-) (la preuve, ton commentaire que j'ai modifié).

  • # 2 paramètres 'in out' doivent être différents

    Posté par  . Évalué à 3.

    Interessant: dans le Rationale il est marqué que 2 paramètres 'in out' d'une même fonction doivent être différent (ne doivent pas être des alias d'un même emplacement) à la Fortran.
    Bien pour les performances, mais je me demande comment ça marche en pratique: c'est assez simple de faire du code ou le compilateur ne peut pas savoir s'il y a des alias ou pas:
    f(A[i], A[j])..

    • [^] # Re: 2 paramètres 'in out' doivent être différents

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Bien pour les performances, mais je me demande comment ça marche en pratique: c'est assez simple de faire du code ou le compilateur ne peut pas savoir s'il y a des alias ou pas:
      f(A[i], A[j])..

      Surtout qu'en fait, sur le gnat installé sur mon Ubuntu 12.04, ça compile sans problème… Et ça fonctionne mais avec un résultat surprenant.

      with Ada.Text_Io; use Ada.Text_Io;

procedure Test is

   type My_Int is range 12..42;
   type My_Int_Array is array(1..2) of My_Int;

   Le_Douze : constant My_Int := 12;

   function Param(Var1, Var2 : in out My_Int) return My_Int is
   begin
      Var1 := Var1 + 1;
      Var2 := Var2 + 1;
      return Le_Douze;
   end Param;

   Tab : My_Int_Array := (12,21);

begin
   Put_Line(My_Int'Image(Param(Tab(1), Tab(1))));
   Put_Line(My_Int'Image(Tab(1)));
   Put_Line(My_Int'Image(Tab(2)));
end Test;

      puisque ça retourne

       12
 13
 21

      On voit bien que Var1 n'a été incrémenté qu'une seule fois alors qu'on aurait pu imaginer qu'il le soit deux fois mais c'est certainement lié au mode de passage de paramètre.
      A voir si la version Adacore fait la même chose :)

      • [^] # Re: 2 paramètres 'in out' doivent être différents

        Posté par  . Évalué à 4.

        Merci pour le test.

        Je suis vraiment surpris de voir que les concepteurs d'Ada ont sélectionné un comportement privilégiant la performance a la "fiabilité" par rapport au C (par défaut puisque le C99 a restrict)..

        • [^] # Re: 2 paramètres 'in out' doivent être différents

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Je suis vraiment surpris de voir que les concepteurs d'Ada ont sélectionné un comportement privilégiant la performance a la "fiabilité" par rapport au C (par défaut puisque le C99 a restrict)..

          Surtout qu'en plus, je trouve que le in out sur fonction n'était pas franchement indispensable mais bon, c'est comme partout, il doit y avoir des lobbys :)
          Au passage, pas d'erreur de compilation non plus sur le gnat d'Adacore… :-/

      • [^] # warning donné par GNAT sur les paramètres aliasés

        Posté par  . Évalué à 2.

        Voici le message donné par la dernière version de GNAT (pas la version GPL 2012, mais une version compilée avec les sources à la FSF) :

        test.adb:20:32: warning: writable actual for "Var1" overlaps with actual for "Var2"

        Notez que c'est un avertissement, pas une erreur de compilation, puisque l'erreur serait d'écrire par un chemin et de lire par un autre (cf la section correspondante du Manuel de Référence Ada), ce que le compilateur ne peut en général pas détecter.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.