Journal CPP Con sur Youtube

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
14
21
oct.
2014

Les vidéos prises lors de la CPP Con 2014, LA conférence C++ de l'année, à Bellevue WA, commencent à arriver sur Youtube.

Parmi mes préférées, la présentation de l'équipe Microsoft Office sur leur approche pour partager autant de code que possible pour tourner sous Windows 32 et 64 bits, MacOSX, iOS, Android, WinRT, et peut-être un jour iWatch, était tout à fait intéressant. Bon, et manifestement, le support de GNU/Linux n'est pas sur leur feuille de route.

D'autres présentations, par exemple sur le Join Strike Fighter ou encore sur le Mars rover, sont également à voir. En terme de processus qualité, c'est autre chose que le tertiaire!

Pour les fondus de performances, voir également la présentation d'Andrei Alexandrescu, "Optimization tips". Étonnant les optimisations possibles dans un shared_ptr!

La liste des vidéos de la CppCon

  • # Joint Strike Fighter

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

    (et non Join Strike Fighter, au passage)

    Maintenant, je sais pourquoi le programme du F-35 est un tel succès ! Ils n'auraient peut-être pas dû changer leurs technos, finalement :D

    • [^] # Re: Joint Strike Fighter

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

      Tout à fait d'accord, surtout quand on voit dans les slides les différentes classes de bugs qui sont censés être évités.
      Je vais pas tous les passer en revue mais franchement :
      - page 9 : réécrire une bibliothèque pour faire des allocateurs sur pool de mémoire, ça me semble pas être un gain de temps… Surtout avec l'apparition des storage pools dans le norme suivante du précédent langage
      - page 21 : Ils savaient que leur chaîne de compilation précédente faisait directement ces vérifications ?

      Tout ça, pour au final, pour finir avec des retards colossaux et un budget largement explosé (cf. Wikipedia)

      • [^] # Re: Joint Strike Fighter

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

        Surtout que qualifier du C++ est super complexe si on utilise des objets, il aurait mieux fait d'utiliser SCADE :) ( https://de.wikipedia.org/wiki/SCADE seul la version allemande existe, je crois que la version française a été détruite plusieurs fois pour manque de pertinence du sujet)

        "La première sécurité est la liberté"

        • [^] # Re: Joint Strike Fighter

          Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 22 octobre 2014 à 09:54.

          Surtout que qualifier du C++ est super complexe si on utilise des objets

          Et surtout, ce n'est normalement pas qualifiable suivant la DO-178B, ce qui a conduit il y a quelques années à l'écriture des documents OOTiA et à l'écriture de la DO-178C.
          Mais bon, comme là, c'est du militaire, c'était pas grave :D

          il aurait mieux fait d'utiliser SCADE

          ou la méthode B :)

          • [^] # Re: Joint Strike Fighter

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

            La méthode B est peu utilisé. Les seuls exemples connu sont dans le ferroviaire.

            L'article de wikipedia parle de la DO178, mais je n'en ai jamais vu.

            "La première sécurité est la liberté"

          • [^] # Re: Joint Strike Fighter

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 22 octobre 2014 à 11:03.

            L'objet en avionique c'est possible : j'ai déjà bossé avec de l'objet sur un logiciel niveau A de la DO178B : un FlightManager (l'équivalent du GPS de la voiture pour aller vite) chez Thalès.
            Alors, c'était pas du C++ mais de l'Ada. Mais c'était du vrai objet, avec classes dérivées, factory maison qui crée les objets etc.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Joint Strike Fighter

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

              Avec de l'héritage ? Le problème avec l'objet est de faire la traçabilité, en gros, il faut pouvoir montrer que l'on sait quelle est la méthode derrière chaque appel polymorphique.

              Tu sais si le projet a été réellement certifié au final ?

              "La première sécurité est la liberté"

              • [^] # Re: Joint Strike Fighter

                Posté par  (Mastodon) . Évalué à 6.

                Oui, l'EASA l'a certifié en 2012 : http://en.wikipedia.org/wiki/Sukhoi_Superjet_100 (c'est la suite avionique complète de Thalès)

                Mais ensuite, héritage ne veut pas dire "bin on sait jamais vraiment ce qui se passe", ça reste parfaitement déterministe. Donc tout se démontre, tout se teste, de manière finalement similaire à du procédural "de base". En tous cas j'ai pas eu souvenir qu'on ait dû utiliser des outils spécifiques : RTRT par exemple te fais la même analyse de couverture de code.

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # CPP Con

    Posté par  . Évalué à 9.

    Les vidéos prises lors de la CPP Con 2014

    La conférence pour les gens intelligents ?

    • [^] # Re: CPP Con

      Posté par  . Évalué à 1. Dernière modification le 24 octobre 2014 à 13:50.

      C'est Point Point Con, comme remarque.

      En fait c'est une conf' marseillaise. La CPP, con.

      (C'est vendredi, j'ai le droit. Que dis-je, le devoir!)

  • # C++

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

    D'autres présentations, par exemple sur le Join Strike Fighter ou encore sur le Mars rover, sont également à voir. En terme de processus qualité, c'est autre chose que le tertiaire!

    J'ai bien rigolé

    Slide page 35 :

    So we limited our code to “Embedded C++” constructs Exceptions: none
    Templates: none
    Iostream: none
    Multiple inheritance: none
    Operator overloading: almost none (only “new” and “delete”).
    Dynamic Allocation: Guarantee no system heap corruption using a dedicated memory pool and Placement New.

    En gros, ils ont fait du C… Comme à chaque fois que tu veux des perfs et de la sureté, ils font du C en C++.
    A ce régime là autant utiliser compcert

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: C++

      Posté par  . Évalué à 6.

      Comme à chaque fois que tu veux des perfs et de la sureté, ils font du C en C++.

      Je suis pas d'accord, tu peut obtenir d'excellentes performances en C++ qui n'ont rien à envier à leur équivalent C.
      Pour la sureté, le typage de C++ est tout de même plus pratique et puissant que celui du C.

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

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: C++

      Posté par  . Évalué à 5.

      En gros, ils ont fait du C…

      M'est avis que tu dois sur-estimer les capacités du C toi… le C, c'est quand même le langage dont le typage est tellement sûr, que tu peux transformer l'adresse d'un float en chaîne de caractères ou plus drôle encore, en pointeur de fonction, et le tout, sans warning, même en -Wall -Wextra.

      En C++ aussi, c'est vrai, parce que C++ est capable de compiler les horreurs du C, mais si on utilise sagement les améliorations du C++, à savoir [static|dynamic|reinterpret|const]_cast, on sait au moins quand on est en train de faire une grosse connerie time-bomb section de code très dangereuse: c'est le seul moment ou l'on utilise reinterpret_cast ou const_cast.

      Rien que pour ça, le C++ bats le C à plate couture (je me demande d'ailleurs s'il existe des warning pour avertir de la présence casts C-style dans du code C++…).

      • [^] # Re: C++

        Posté par  . Évalué à 8.

        (je me demande d'ailleurs s'il existe des warning pour avertir de la présence casts C-style dans du code C++…)

        -Wold-style-cast ?

      • [^] # Re: C++

        Posté par  . Évalué à 5.

        Hum, le fait que tu doives transtyper en utilisant un truc du genre (type)var c'est quand même parce qu'un compilateur C bien configuré (genre -Wall -Wextra -pedantic -Werror) va te jeter si tu transtypes n'importe comment. Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais ». On te donne une corde, tu peux t'en servir pour t'empêcher de tomber du haut de la falaise, mais si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises.

        Après je suis bien d'accord pour dire que le typage fort du C++ et ses méthodes alternatives de transtypage sont quand même plus sûres — mais reinterpret_cast ou static_cast ne sont pas non plus la panacée.

        • [^] # Re: C++

          Posté par  (site web personnel) . Évalué à 0. Dernière modification le 22 octobre 2014 à 18:10.

          Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais »

          Ha ha…
          Ca peut être aussi "le client veut 0 warning dans sa config du compilo, ben on va lui faire plaisir".
          Bon, certes, ce n'est pas complètement contre ton "ta gueule, je sais ce que je fais", mais ça veut dire plutôt "ce que je fais est faire plaisir au client" que "ce que je fais, je connais son impact sur le code" qui est plutôt sous-entendu, me trompe-je?

          On te donne une corde, tu peux t'en servir pour t'empêcher de tomber du haut de la falaise, mais si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises.

          Tu peux aussi t'en servir pour faire croire que tu va empécher la personne de tomber de haut de la falaise pour lui faire plaisir et qu'il se lance, mais vaut mieux pas qu'il en ai besoin, on est pas sûr que la corde ne soit qu'une ficelle. Pas aussi binaire que tu le penses, et ne pas savoir arrive plus souvent que tu le penses.
          Oui, on peut faire n'importe quoi avec un cast, et c'est bien le problème : n'importe qui peut, alors que tu minimises ("si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises", tout de suite…)

          Bref, tout ça pour dire que les gens (moi compris) savaient tout le temps ce qu'ils font quand ils castent à coup de "(type)var", c'est plus ton rêve que la réalité, et que c'est pour ça que certains préfèrent l'interdire complètement dans leur politique de code.

          • [^] # Re: C++

            Posté par  . Évalué à 5.

            Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais »

            Ha ha…

            Ca peut être aussi "le client veut 0 warning dans sa config du compilo, ben on va lui faire plaisir".
            Bon, certes, ce n'est pas complètement contre ton "ta gueule, je sais ce que je fais", mais ça veut dire plutôt "ce que je fais est faire plaisir au client" que "ce que je fais, je connais son impact sur le code" qui est plutôt sous-entendu, me trompe-je?

            En fait, oui. :) Je n'ai jamais dit que j'avais systématiquement raison lorsque je transtypais. :) Par contre, oui, si j'active tous les warnings et que je les convertis en erreur, alors je dois gérer les « unsigned compared with unsigned », les « pointer assigned to integer », etc., et donc je me dois de réfléchir sur le coup à ce que je suis en train de faire. Si c'est pas évident, c'est le bon moment de laisser une trace sous forme de commentaire pour expliquer pourquoi je dois faire un truc « contre nature » (genre uint64_t v = (uint64_t)ptr). Très souvent, les transtypages « crades » sont faits dans l'urgence, « parce que ça va plus vite », mais aussi très souvent, on peut faire un compromis en utilisant des unions, etc., ce qui force le programmeur à penser le nom des champs de l'union, à explicitement dire quelle « point de vue » d'une variable il veut utiliser, etc.

          • [^] # Re: C++

            Posté par  . Évalué à 3.

            Bref, tout ça pour dire que les gens (moi compris) savaient tout le temps ce qu'ils font quand ils castent à coup de "(type)var", c'est plus ton rêve que la réalité, et que c'est pour ça que certains préfèrent l'interdire complètement dans leur politique de code.

            Personnellement je considère surtout ça comme une faiblesse dans la modélisation du programme. Si à un moment donné, tu est obligé de dire "bon en fait mon mon machin, on va dire que c'est un truc", c'est que la conception n'est pas génial.

            Ça dépend bien sûr beaucoup du typage du langage.

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

        • [^] # Re: C++

          Posté par  . Évalué à 4.

          parce qu'un compilateur C bien configuré (genre -Wall -Wextra -pedantic -Werror) va te jeter si tu transtypes n'importe comment.

          Bof, bof

          Avec ton jeu d’option, le code suivant va passer sans aucun souci (aussi bien avec clang que gcc) :

          #include <stdint.h>

int main(void)
{
    int64_t big = 4398046511104LL;
    int32_t small = big;
    return 0;
}

          Il faut ajouter -Wconversion si tu veux un warning.

          • [^] # Re: C++

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

            Et oui, comme l'indiquent si bien leurs noms, -Wextra et -Wall n'activent pas tous les warnings !

          • [^] # Re: C++

            Posté par  . Évalué à 0.

            True. En même temps, gcc gueule avec ton code car:

            szuckerm@evans201g:~/Programming/sigsegv$ gcc -std=c99 -Wall -Wextra -pedantic -Werror -o fail fail.c
fail.c: In function ‘main’:
fail.c:6:13: error: unused variable ‘small’ [-Werror=unused-variable]
     int32_t small = big;
             ^
cc1: all warnings being treated as errors

            Bon je chipote, il suffit de renvoyer small depuis main() et avec ma config gcc est content. ;-)
            Le compilateur d'Intel avec les mêmes options est aussi muet que clang et gcc.

            Avec clang, -Weverything m'économisera plein de frappes au clavier…

            • [^] # Re: C++

              Posté par  . Évalué à 3.

              Bon je chipote,

              Pire, tu dis n'imp :) ce warn n'est absolument pas lié au problème qui nous intéresse ici…

              • [^] # Re: C++

                Posté par  . Évalué à 3.

                Ce que je voulais dire, c'est que le compilateur m'empêche d'obtenir mon binaire dans tous les cas. Donc il ne gueule pas contre le transtypage, mais contre une variable non utilisée (et comme j'utilise -Werror ben …). Je ne cherchais pas à dire que c'était lié. :)

        • [^] # Re: C++

          Posté par  . Évalué à 3.

          c'est quand même parce qu'un compilateur C bien configuré

          Admettons. Et pour le cast vers et depuis du void*, tu rétorques quoi? (casts qui sont obligatoires dès lors que l'on veut interagir avec une lib dynamique au runtime, et non au démarrage de l'appli, pour rappel, à moins qu'il existe autre chose que dlsym?)

          Franchement, j'aimerai beaucoup qu'il y ait plus sécurité au niveau des casts en C. Parce que dans les langages qui ont des capacités de plus haut niveau, on subit cette faiblesse quand on doit utiliser une lib codée en C, pour une raison X ou Y (j'ai pris l'exemple de dlfcn.h ici, mais ce n'est qu'un exemple, hein, ça pourrait être une lib maison qu'il est obligé d'utiliser, peu importe.).

          mais reinterpret_cast ou static_cast ne sont pas non plus la panacée.

          Comme je l'ai dis. D'ailleurs le reinterpret_cast est l'égal du transtypage du C, à un très gros avantage près: il est super long à taper (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est…)/lire, et du coup, ça décourage :)

          • [^] # Re: C++

            Posté par  . Évalué à 8.

            Résumé: void* est un type générique qui sert (dans un langage faiblement typé) à passer des zones mémoire d'un bout du programme à un autre. Il a été explicitement créé pour être transtypé dans un sens ou dans l'autre. Le transtypage silencieux d'un type pointeur à void* (ou le contraire) est donc logique.
            En règle générale, je préfère le typage fort du C++ dès qu'on parle de manipulation un tant soit peu de haut niveau, mais dès qu'il s'agit de programmation réellement bas-niveau, je trouve que le typage force une écriture plus lourde qu'en C.

            En règle générale, tout transtypage d'un type pointeur vers un type « intégral » (virgule flottante ou entier) fera que le compilateur te gueulera dessus.

            Transtypage depuis void*:

            void* ptr est le type générique du C. Du coup, comme tu ne peux pas écrire *ptr (qui n'a strictement aucun sens), tu sais que tu es en train de manipuler un objet qui va finir par être transtypé en quelque chose d'autre. Comme le typage est faible, alors évidemment, tu dois indiquer (dans la doc de ta fonction, dans le nom de ta variable, etc.) à quel type on se réfère (puisque le transtypage implicite fonctionne). Je trouve qu'au moins dans ce cas, on sait qu'on doit faire gaffe.

            Transtypage vers void*:

            Tout type « intégral » (entier ou double) lèvera un warning ou une erreur. Pour les autres, il s'agit de généraliser le type d'un pointeur, ce qui est exactement ce pour quoi void* a été créé. Gueuler contre ça, c'est (selon moi) équivalent à gueuler contre Java qui permet de transtyper un objet vers le type Object (après, nous sommes d'accord, dans l'autre sens si tu transtypes mal ça coincera en Java, alors que C te laissera faire).

            De toute manière de ce que j'ai pu voir en C++, dès qu'on commence à parler de manipuler des octets et des notions bas-niveau, on retombe sur des tableaux de char exactement comme en C. Sauf qu'en plus maintenant on se traîne le typage fort de C++ lorsqu'on passe de char[] à void* etc pour effectuer certaines manipulations, ce qui alourdit le code (je trouve).

          • [^] # Re: C++

            Posté par  . Évalué à 4.

            (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est…)

            As tu testé YouComplteMe ? C'est un autocompléteur qui fait de la recherche dans les sous-séquences, et utilise clang pour la complétion sémantique.

    • [^] # Re: C++

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

      So we limited our code to “Embedded C++” constructs

      Tu sais, même les dévelopeurs C s'imposent parfois à un subset du langage C.

      (Ex: Pas de goto (considered harmfull?), pas déclaration de fonction à la K&R, toujours utiliser des accolades même pour les blocs d'une lignes, interdiction d'utiliser certaines fonctions de la bibliothèque standard)

      Bref, que ce soit en C ou en C++, les devs choisissent un subset et un style propre.

  • # A defaut de GNU, il y a Linux

    Posté par  . Évalué à 7.

    Leur approche pour partager autant de code que possible pour tourner sous Windows 32 et 64 bits, MacOSX, iOS, Android, WinRT, et peut-être un jour iWatc

    puis

    Bon, et manifestement, le support de GNU/Linux n'est pas sur leur feuille de route.

    Mais il supporte quand même un Linux, ce qui est notable !

    • [^] # Re: A defaut de GNU, il y a Linux

      Posté par  . Évalué à 2.

      Et comme pour compiler linux il faut GCC, ça supporte GNU/Linux? (je sais, c'est moyen, mais je me souviens qu'on m'avait répondu ça, un jour, je ne sais plus où…)

      • [^] # Re: A defaut de GNU, il y a Linux

        Posté par  . Évalué à 2.

        Je suis sûr qu'avec beaucoup de patience du dois pouvoir réussir à compiler Linux sur Visual Studio.

        • [^] # Re: A defaut de GNU, il y a Linux

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

          Linux n'est pas en C standard, ça utilise plein d'extensions GCC, bref c'est rigolo pour des gens râlant sur Microsoft et ses extensions non standards de faire en fait exactement pareil.

          Bref, pas la faute de Microsoft, mais des codeurs Linux qui s'amusent à faire du non standard. Les standards, c'est que quand l'autre ne fait pas comme on veut, sinon on s'en fout ;-).

          • [^] # Re: A defaut de GNU, il y a Linux

            Posté par  . Évalué à 3. Dernière modification le 23 octobre 2014 à 16:06.

            En même temps, faire un kernel en C standard c’est pas franchement possible. Rien que la directive asm pour inclure du code assembleur dans du C c’est une extension donc bon…

            Utiliser des extensions dans du code kernel ça ne me choque pas, dans du code applicatif c’est déjà plus discutable.

            • [^] # Re: A defaut de GNU, il y a Linux

              Posté par  (site web personnel) . Évalué à -9. Dernière modification le 23 octobre 2014 à 16:10.

              pour l'ASM, dans pas mal de projets, on peut voir des "#if" qui se balade justment pour ça : fallback sur du C standard si pas supporté par le compilo (ou que l'ASM n'a pas été fiat pour tel CPU). ASM compris donc (d'ailleurs, ça m'étonnerai qu'il y a du code ASM non optionnel dans Linux, vu toutes les machines à supporter…)

              Bref, c'est surtout une question de volonté (note : je comprend que les développeurs s'en foutent de faire du standard, pas leur priorité, je m'amuse juste sur les incohérences des gens qui demandent du standard chez les autres quand ils en ont besoin mais pas pour leur poulain quand ils n'ont pas besoin, ici Visual C++ devrait être capable de compiler out of the box si le code était standard, car Visual C++ compile pas mal de C standard quand même. Quand on dit que d'avoir plein de trucs différents c'est bien, on "oublie" que Linux ne compile que sur un seul compilo).

              • [^] # Re: A defaut de GNU, il y a Linux

                Posté par  . Évalué à 10. Dernière modification le 23 octobre 2014 à 16:23.

                fallback sur du C standard si pas supporté par le compilo (ou que l'ASM n'a pas été fiat pour tel CPU).

                Exemple con et basique : tu implémentes le context-switch, tu dois sauvegarder les registres : c’est quoi ton fallback en C standard ?

                C’est pas une question de volonté, certaines choses ne sont pas faisable en C

                ASM compris donc (d'ailleurs, ça m'étonnerai qu'il y a du code ASM non optionnel dans Linux, vu toutes les machines à supporter…)

                Bah raté, il y en a.

                Visual C++ devrait être capable de compiler out of the box si le code était standard, car Visual C++ compile pas mal de C standard quand même.

                Mouarf, faut rester en C89 alors.
                Le C99 est pas supporté et ne le sera jamais (sauf bout qui les intéresse), et niveau C11 ça risque d’être la même…

              • [^] # Re: A defaut de GNU, il y a Linux

                Posté par  . Évalué à 0.

                On n'a jamais dit le contraire…

            • [^] # Re: A defaut de GNU, il y a Linux

              Posté par  . Évalué à 3.

              Utiliser des extensions dans du code kernel ça ne me choque pas, dans du code applicatif c’est déjà plus discutable.

              L'arrivée de clang à permis d'en nettoyer une partie… et d'implémenter dans clang une partie des extensions gnu. Malgré tout ça, il y à encore pas mal de paquets qui ne compilent pas, au moins sous Debian, avec clang (5.7% aux dernières news).

              Et sinon, je me demande quelle est la proportion moyenne des kernels *BSD qui n'est pas écrite en C standard? Quelqu'un aurait une info la dessus? (après tout, il s'agit des seuls kernels libres capables d'être utilisés au quotidien sur un bureau que je connaisse, en plus de linux, et donc les seuls dont les stats soient d'une certaine pertinence?)

            • [^] # Re: A defaut de GNU, il y a Linux

              Posté par  . Évalué à 10.

              Le mot-clé asm n'est effectivement pas standard, mais rien n'oblige
              son utilisation pour pouvoir appeler du code assembleur depuis
              du code C.

              Tu peux parfaitement lier ton programme écrit en C à des objets qui ont
              été précédemment assemblés depuis des fichiers .S ou .s et appeler
              les fonctions qui y sont présentes.

              Il y a de nombreux systèmes d'exploitation qui ont été écrits pour des
              compilateurs C ne supportant pas du tout l'assembleur inline.

              • [^] # Re: A defaut de GNU, il y a Linux

                Posté par  . Évalué à 1.

                Exact, c’est aussi une possibilité

                • [^] # Re: A defaut de GNU, il y a Linux

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

                  Là encore c'est utiliser des extensions du standards.
                  Le standard C ne défini pas d'ABI. Et donc les .s vont dépendre de l'ABI choisie par le compilateur utilisé.

                  Mais le code écrit en C est valide. Ou l'est il vraiment ? Le standard précise que le symbole en question doit apparaître dans une autre translation unit (C99 §6.7.4 8 / §6.9 5), et une translation unit est définie à partir du code en C (§5.1.1.1).
                  Bon, c'est vraiment du chipotage.

              • [^] # Re: A defaut de GNU, il y a Linux

                Posté par  . Évalué à 3.

                Moui enfin, d'un autre côté, ça reviens à foutre dans une lib (statique) le code non portable, donc on déplace le problème du fait que le kernel comporte du code qui n'est pas faisable en C standard.

                • [^] # Re: A defaut de GNU, il y a Linux

                  Posté par  . Évalué à 5.

                  dans une lib (statique) le code non portable

                  Donc il te suffit de porter cette lib pour porter l'ensemble, c'est tout de même vachement plus agréable pour porter un logiciel.

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

                  • [^] # Re: A defaut de GNU, il y a Linux

                    Posté par  . Évalué à 3.

                    Jamais je n'ai remis en question la pertinence de mettre le code non portable le plus loin possible du code portable :)

                    C'est d'ailleurs une chose que j'essaie de faire au maximum, et ce, même avec les lib: ne pas inclure une lib partout, limiter son usage à un set de classes qui ne vont faire quasiment que s'en servir. Et ce pour chaque lib, comme ça le jour ou, pour une raison ou un autre, il faut changer la lib, ben pas besoin de refaire la totalité du programme. (d'ailleurs, c'est pour ça que je ne ressens pas le besoin d'utiliser des frameworks, voire que je considère ces outils comme quasi-néfastes, mais c'est un sujet pour un vendredi… oups :) )

                    • [^] # Re: A defaut de GNU, il y a Linux

                      Posté par  . Évalué à 3.

                      (d'ailleurs, c'est pour ça que je ne ressens pas le besoin d'utiliser des frameworks, voire que je considère ces outils comme quasi-néfastes, mais c'est un sujet pour un vendredi… oups :) )

                      Ça n'a pas vraiment de rapport. Tu peut très bien écrire un programme pour Qt qui passera facilement à autre chose. C'est une question de design plus qu'autre chose. Mais la lourdeur de l'écriture peut aussi se ressentir sur les performances (tu crée une couche entre le core de appli et la ou les biblio que tu utilise).

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

                      • [^] # Re: A defaut de GNU, il y a Linux

                        Posté par  . Évalué à 2.

                        tu crée une couche entre le core de appli et la ou les biblio que tu utilise

                        Pas vraiment, c'est juste qu'en général, l'usage d'une lib n'est utile que dans une couche donnée de l'application, par exemple l'IHM.
                        Le cœur de l'application et les autres couches n'ont pas à utiliser voire même juste connaître les outils utilisés par les autres couches. Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM (et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur…), alors que la tentation est quand même vachement forte (ceci étant dit, je considère C++/Qt comme étant quasiment un langage différent de C++).

                        Je m'amuse pas à faire une lib d'interfaçage à chaque projet pour chaque lib, sinon on en finit pas :)

                        • [^] # Re: A defaut de GNU, il y a Linux

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

                          Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM

                          QString ne fait pas partie de QtGui, mais de QtCore qui est dédié aux bases d'un programme (donc les libs, pa graphiques).
                          Ta lib qui utilises QString ne dépendra donc pas d'une lib graphique, mais d'une lib de base ("Core").
                          Qt != QtGui, on l'oublies assez souvent certes.

                          et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur

                          En effet ;-).

                        • [^] # Re: A defaut de GNU, il y a Linux

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

                          Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM (et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur…)

                          Tu peux détailler un peu plus ?
                          J'avoue ne pas vraiment comprendre pour quelle raison tu souhaites ne pas utiliser les QString dans des classes d'IHM de Qt…

                          • [^] # Re: A defaut de GNU, il y a Linux

                            Posté par  . Évalué à 3.

                            J'avoue ne pas vraiment comprendre pour quelle raison tu souhaites ne pas utiliser les QString dans des classes d'IHM de Qt…

                            C'est plus de l'ordre du réflexe en fait, j'ai une tendance à préférer utiliser ce qui est standard en priorité, l'avantage étant que plus tu utilises le matériel standard, moins le temps d'embrayage d'un nouveau sur le projet est long s'il ne connaît que le langage.
                            Accessoirement, même si, à l'heure actuelle, Qt est très modulaire (je ne l'ai pas utilisé depuis la v3, mais j'ai un croisé les dépêches qui en parlent), ça n'a pas toujours été le cas, je me trompe?

                        • [^] # Re: A defaut de GNU, il y a Linux

                          Posté par  . Évalué à 3.

                          Pas vraiment, c'est juste qu'en général, l'usage d'une lib n'est utile que dans une couche donnée de l'application, par exemple l'IHM.

                          Tes données viennent bien ou vont quelque par, il faut que tu fasse cette conversion. Tu parle des QString, dans ton code, tu utilise aussi une (ou plusieurs) classe(s) pour stocker des chaines de caractères et tu fais la conversion quand tu veux récupérer ou sortir tes données de la partie Qt.

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

                          • [^] # Re: A defaut de GNU, il y a Linux

                            Posté par  . Évalué à 3.

                            Et? Je ne vois pas où tu veux en venir: si tu utilises, disons, Qt d'une part, et, par exemple, libpq (lib qui permets d'interroger postgresql) il va bien falloir qu'à un moment tu la fasses, cette conversion…
                            Du coup, si tu utilises au maximum les fonctionnalités fournies par le standard, c'est bien plus simple de combiner l'usage de différentes libs.

                            Si ce qui t'ennuies, c'est ce genre de choses: QString -> std::string -> QString -> std::string -> QString -> std::string -> QString pour une donnée unique, c'est que peut-être que les relations entre les classes de ton programmes sont mal faites? Peut-être qu'avec une meilleure architecture ce serait évitable?
                            Pas toujours, c'est vrai, mais j'ai parlé d'éviter, et de cas généraux. Si je dois, pour une raison ou une autre, manipuler en permanence un type non-standard dans un code, alors tant pis. Mais ça arrive assez rarement, et quand ça m'arrive je constate qu'en général, il est intéressant de l'encapsuler. Du coup, j'utilise toujours du non-standard, c'est vrai, mais seule l'encapsulation est dépendante de la lib externe.
                            Conséquence, s'il faut porter le projet, ou changer de techno sous-jacente, il y à moins de code à revoir.

              • [^] # Re: A defaut de GNU, il y a Linux

                Posté par  . Évalué à 4.

                Le mot-clé asm n'est effectivement pas standard […]

                Tu peux parfaitement lier ton programme écrit en C à des objets qui ont
                été précédemment assemblés depuis des fichiers .S ou .s et appeler
                les fonctions qui y sont présentes.

                Et donc ? Le code des fichiers .s est-il écrit selon un standard quelconque ?
                Vu que le monde GNU a choisi la syntaxe AT&T au détriment de la syntaxe Intel (utilisée par d'autres comme Microsoft), j'en doute.

                • [^] # Re: A defaut de GNU, il y a Linux

                  Posté par  . Évalué à 0.

                  Tu peux utiliser l'assembleur que tu souhaites, à partir du moment où le code machine généré respecte la même ABI que les autres objets.

                  • [^] # Re: A defaut de GNU, il y a Linux

                    Posté par  . Évalué à 3.

                    Certes… La discussion porte sur la possibilité d'un noyau codé en C standard. Si on écrit tout ce qui est hors-standard dans un autre langage que le C, c'est une façon un peu ridicule de répondre à la question.

        • [^] # Re: A defaut de GNU, il y a Linux

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

          Avec visual studio pas.

          Mais avec clang, oui : http://llvm.linuxfoundation.org

Suivre le flux des commentaires

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