Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 150 sur 182 PremièrePremière ... 50100140142143144145146147148149150151152153154155156157158160 ... DernièreDernière
Affichage des résultats 4 471 à 4 500 sur 5434
  1. #4471
    Mouais ça va. Genre un véhicule c'est un concept (un truc qui transporte des trucs), une voiture c'est un véhicule mais s'pas un concept c'est concret et ça respecte la contrainte du concept (ça transporte des trucs). Donc pourquoi pas.

    Sinon l'idée pour aller plus loin c'est de faire de la méta programmation, donc en gros tu peux même caser des <if> et autres calculs dans le tas.

    Donc imaginons que tu implémentes un calcul de racine carré, tu pourrais balancer un if qui selon le concept produira telle ou telle méthode plus optimisée.
    L'idée finale étant d'optimiser au maximum avant le runtime. Tu "bake" tout l'information disponible compile time pour avoir les meilleures perfs runtime.

  2. #4472
    Tu aurais voulu appeler ça comment ? "class" comme en Haskell ? On aurait enfin trouvé une utilité à ce mot-clé.

    En fait ce vocabulaire était déjà utilisé avant mais sans faire parti du langage (par exemple l'ancien "concept" Iterator, maintenant renommé "named requirements" LegacyIterator pour ne pas le confondre avec le nouveau concept input_or_output_iterator).

  3. #4473
    Citation Envoyé par Cwningen Voir le message
    Tu aurais voulu appeler ça comment ? "class" comme en Haskell ? On aurait enfin trouvé une utilité à ce mot-clé.
    Je l'aurais appelé bêtement prerequisite. Puisque ce n'est pas vraiment un « concept » (pour moi une classe est déjà un concept) mais une liste de prérequis pour d'autres choses (qui pourraient être plus générale d'ailleurs et qu'on aurait pu imaginer être appliqué à d'autres choses qu'aux templates).
    Le problème c'est que c'est un outil pour les template uniquement, il aurait donc fallut que ce soit clair que ça rentre dans ce cadre (template_prerequisites ?) mais ce n'est pas très limpide.

    De fait, entre le fait que c'est uniquement destiné aux template alors qu'on pourrait imaginer des usages plus généraux, et le fait que sur la forme c'est un peu obscur entre le terme et l'usage, je trouve que ça donne le sentiment d'un machin certes très intéressant mais peut-être encore un peu mi-cuit...

    Mais bref je pinaille, c'est déjà bien que ça existe.

    Citation Envoyé par Kamikaze Voir le message
    Sinon l'idée pour aller plus loin c'est de faire de la méta programmation, donc en gros tu peux même caser des <if> et autres calculs dans le tas.
    D'ailleurs à la fin on aboutira à un truc avec des #if #elif pour faire faire des choses au compilateur durant les premières étapes de la compilation en fonction de diverses condi... oh wait ...


  4. #4474
    Haha nan mais en vrai t'as pas tort, c'est d'ailleurs une des critiques régulière de Jonathan Blow, il bosse sur son nouveau langage et il veut pouvoir faire du compile time nativement avec son langage sans avoir une syntaxe dédiée, ce qui me parait tout à fait raisonnable.

    Je retrouve plus la vidéo mais il montre un truc rigolo ou quand il lance la compilation ça lance un jeu, et la compilation/l'assert ne réussit que s'il bat le jeu

    - - - Mise à jour - - -

    Chui encore circonspect de l'intérêt (mis à part le confort évident).

    Au final je trouve qu'en programmation on manque pas mal de recherche théorique en algorithmique/maths du coup au final c'est dur de distinguer un choix solide et pertinent, d'une décision arbitraire quand on parle de langage.

    On a l'air d'avancer à taton concernant ce qui serait la meilleure syntaxe sans faire de grandes avancées.

    - - - Mise à jour - - -

    Y'a cette vidéo sympa de Jason Turner où il applique les nouveautés du langage (c++17 ici) à un projet existant, et il regarde le gain de perf et l'impact en termes de lignes de code.

    C'est donc à taton, mais au moins une mesure quantifiable de mieux ou moins bien, contrairement à un choix arbitraire avec une maigre tentative de justification

    https://www.youtube.com/watch?v=nnY4e4faNp0

  5. #4475
    Je ne vois pas quel sens ça aurait en dehors des génériques. Ce sont des contraintes sur les types, jamais sur les valeurs. Tu ne peux pas t'en servir pour exprimer des préconditions.

    Pour le nom, dans la pratique un concept est lui-même un template donc c'est toujours écrit "template<...> concept = ...". Tu voudrais "template<...> template_concept = ..." ? Après on parle d'un langage dans lequel on écrit "noexcept(noexcept(...))", ça aurait pu passer.

  6. #4476
    Bof tu aurais pu l'étendre à n'importe quoi avec la même syntaxe : je dis que ma fonction X ses deux premiers arguments doivent répondre à telle ou telle contrainte, et à la limite même si ma fonction en question à des arguments au type fixe et non des types changeant, ça permettrait de mettre en place des autoverif de son code à moindre cout (un peu de la même manière que les const, d'ailleurs ça pourrait être placé au même endroit).

    La remarque de Kamikaze est également pertinente sur la syntaxe, on pourrait imaginer que ça ne fasse pas que des tests en début de compilation mais également en utilisant des bouts de code du même langage pour faire passer des tests complexe sans dépendre d'une autre syntaxe.

    - - - Mise à jour - - -

    Citation Envoyé par Kamikaze Voir le message
    Au final je trouve qu'en programmation on manque pas mal de recherche théorique en algorithmique/maths du coup au final c'est dur de distinguer un choix solide et pertinent, d'une décision arbitraire quand on parle de langage.
    C'est particulièrement le cas dans les dernière version de C++ je trouve où on enchaine des nouveauté toutes les quelques années actuellement. Pas certains que l'écart court entre deux versions permettent d'avoir des retours suffisants pour mettre les choses à plat.

  7. #4477
    Citation Envoyé par Nilsou Voir le message
    Bof tu aurais pu l'étendre à n'importe quoi avec la même syntaxe : je dis que ma fonction X ses deux premiers arguments doivent répondre à telle ou telle contrainte, et à la limite même si ma fonction en question à des arguments au type fixe et non des types changeant, ça permettrait de mettre en place des autoverif de son code à moindre cout (un peu de la même manière que les const, d'ailleurs ça pourrait être placé au même endroit).
    Et on pourrait appeler ça "assert" !

    Citation Envoyé par Nilsou Voir le message
    La remarque de Kamikaze est également pertinente sur la syntaxe, on pourrait imaginer que ça ne fasse pas que des tests en début de compilation mais également en utilisant des bouts de code du même langage pour faire passer des tests complexe sans dépendre d'une autre syntaxe.
    Autant je veux bien que la syntaxe soit un peu lourdingue, mais ce serait très clairement une mauvaise idée de mélanger la syntaxe entre ce qui est compile-time et ce qui est run-time.
    A ce compte-là on fait tout au runtime et on s'appelle python.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  8. #4478
    Citation Envoyé par Lazyjoe Voir le message
    Et on pourrait appeler ça "assert" !
    Oui ben je disais qu'on pouvait avoir un truc unifié justement

    - - - Mise à jour - - -

    Citation Envoyé par Lazyjoe Voir le message
    Autant je veux bien que la syntaxe soit un peu lourdingue, mais ce serait très clairement une mauvaise idée de mélanger la syntaxe entre ce qui est compile-time et ce qui est run-time.
    A ce compte-là on fait tout au runtime et on s'appelle python.
    Nan mais c'est du compile time, c'est juste que c'est la même syntaxe interne, te permettant de faire n'importe quoi. (comme le montre l'exemple de Kamikaze, on pourrait même lancer un jeu et compiler ou non en fonction du résultat du jeu haha)

  9. #4479
    Citation Envoyé par Nilsou Voir le message
    Oui ben je disais qu'on pouvait avoir un truc unifié justement
    Ben c'est quoi l'intérêt réel d'avoir une syntaxe commune ? Faire de la méta-méta-programmation ?
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  10. #4480
    Bah pourquoi avoir une syntaxe distincte?

    Dans Jai, Jonathan Blow a fait le choix d'utiliser une balise, tout ce qui est sous #run ça sera compile time, c'est fait via un interpréteur/compilo rapide, donc certes moins performant mais c'est interactif. Et quand tu passes en mode release ça compile plus sérieusement avec optimisations et tout le tintouin

    M'enfin j'ai pas un avis particulièrement solide sur le sujet, me parait normal d'avoir la même syntaxe partout

  11. #4481
    Sauf que les concepts n'ont pas la même utilité que assert/static_assert.

    Code:
    template<std::integral T>
    void foo(T value) {
      // version de la fonction utilisant des entiers
    }
    
    template<std::floating_point T>
    void foo(T value) {
      // version de la fonction utilsant des flottants
    }
    
    int main() {
      foo(1); // utilise la première version avec T = int -> ok
      foo(1.0); // utilise la seconde version avec T = double -> ok
      foo("blabla"); // pas de version foo qui correspond -> erreur
    }
    Le non-respect des contraintes ne génère pas d'erreur en lui-même, il empêche seulement de considérer la fonction dans la résolution de la surcharge. L'erreur de foo("blabla") n'est pas que const char[7] ne respecte pas les contraintes, c'est qu'il n'existe pas de version de foo qui accepte un const char[7].

  12. #4482
    Citation Envoyé par Cwningen Voir le message
    Le non-respect des contraintes ne génère pas d'erreur en lui-même, il empêche seulement de considérer la fonction dans la résolution de la surcharge. L'erreur de foo("blabla") n'est pas que const char[7] ne respecte pas les contraintes, c'est qu'il n'existe pas de version de foo qui accepte un const char[7].
    Ce qui est exactement la même chose hein
    Foo ne compile pas parce qu'aucune version disponible ne respectent les contraintes. Le fait que ça se mix avec le mécanisme de surcharge est ici hors propos, on peut tout à fait imaginer ce dont on parlait se mixer avec le mécanisme de surcharge de même. Donc si, c'est bel et bien la même chose en définitive et on pourrait imaginer la même syntaxe.

  13. #4483
    Mais "foo(1)" et "foo(1.0)" ne génèrent pas d'erreurs, alors qu'ils ne respectent pas les contraintes de l'autre version. Un static_assert aurait donné une erreur.

  14. #4484
    Oui ben c'est le mécanisme de surcharge quoi ...

  15. #4485
    Citation Envoyé par Nilsou Voir le message
    Oui ben c'est le mécanisme de surcharge quoi ...
    Certes mais là ça fait beaucoup de boulot à pas cher.
    Par exemple std::floating_point ça ne désigne pas simplement le type float, mais tous les types à virgule flottante donc float, double et long double.

    Donc là avec
    Code:
    template<std::floating_point T>
    void foo(T value)
    Le compilateur va pouvoir instancier les trois variantes de foo pour ces trois types. Et ne les instanciera réellement que si le code les utilise avec ces types, aucun gâchis.

    Après ça reste un usage un peu basique, on peut faire des trucs bien plus avancés notamment avec le mot-clé requires qui permet de filtrer les objets qui peuvent évaluer les expressions de ton choix.

    Par exemple tu pourrais définir le concept "possède une opération d'addition et de multiplication"
    Code:
    template<typename T>
    concept HasAddandMul = requires (T a, T b) { 
        a + b; 
        a * b;
    };
    A partir de là, si un objet valide ce concept tu sais qu'il pourra évaluer ces opérations... donc tu peux écrire une fonction 100% générique qui ne se base que sur ces propriétés.
    Par exemple un produit scalaire sur des vecteurs
    Code:
    template<typename T> requires HasAddandMul<T>
    T dotProduct(std::vector<T> a, std::vector<T> b) { 
    ...}
    (disclaimer : ma syntaxe est peut-être voire probablement pas bonne, c'est pour illustrer l'idée )

    Et là tu peux donner absolument n'importe quelle classe à ce dotProduct si elle valide le concept, donc ça marchera avec le types arithmétiques de base mais n'importe quoi d'autre que tu aurais pu définir, des complexes, des quaternions, des entiers astronomique en 437 bits...
    Dernière modification par Lazyjoe ; 12/12/2021 à 14h48.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  16. #4486
    à chaque fois que je vois vos exemple de code en C++, je me dis que je suis bien content d'être resté sur du Java...

  17. #4487
    Citation Envoyé par Lazyjoe Voir le message
    ....
    Ouais mais tout ce que tu dis n'a aucun rapport avec la discussion. On peut très bien imaginer mettre tout ça dans un système unifié de définition de pré-requis qui serait mêlée avec le système de concept, par exemple.

  18. #4488
    Citation Envoyé par Lazyjoe Voir le message
    Par exemple tu pourrais définir le concept "possède une opération d'addition et de multiplication"
    Code:
    template<typename T>
    concept HasAddandMul = requires (T a, T b) { 
        a + b; 
        a * b;
    };
    A partir de là, si un objet valide ce concept tu sais qu'il pourra évaluer ces opérations... donc tu peux écrire une fonction 100% générique qui ne se base que sur ces propriétés.
    Par exemple un produit scalaire sur des vecteurs
    Code:
    template<typename T> requires HasAddandMul<T>
    T dotProduct(std::vector<T> a, std::vector<T> b) { 
    ...}
    (disclaimer : ma syntaxe est peut-être voire probablement pas bonne, c'est pour illustrer l'idée )

    Et là tu peux donner absolument n'importe quelle classe à ce dotProduct si elle valide le concept, donc ça marchera avec le types arithmétiques de base mais n'importe quoi d'autre que tu aurais pu définir, des complexes, des quaternions, des entiers astronomique en 437 bits...
    Et le top c'est que ça marchera avec n'importe quoi qui surcharge * et +, y compris avec une sémantique complètement différente de la multiplication et de l'addition, pour donner un dotProduct qui n'a aucun sens mais qui fait quand même des trucs.

    Moi je suis bien content d'être passé au C finalement, c'est un niveau de zen sans commune mesure.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  19. #4489
    C'est clair que quand il s'agit de reprendre le code d'un autre, le C++ peut réserver bien des surprises. J'ai effectivement plus de confiance quand je bosse sur de gros projet en C

    Pourtant j'aime le C++, mais quand j'écris mon propre code ou que j'utilise un code que je connais à 100%


    Citation Envoyé par Kamikaze Voir le message
    Y'a cette vidéo sympa de Jason Turner où il applique les nouveautés du langage (c++17 ici) à un projet existant, et il regarde le gain de perf et l'impact en termes de lignes de code.

    C'est donc à taton, mais au moins une mesure quantifiable de mieux ou moins bien, contrairement à un choix arbitraire avec une maigre tentative de justification

    https://www.youtube.com/watch?v=nnY4e4faNp0
    J'ai vu l'ensemble de la vidéo, ben c'est pas glorieux. La plupart des features qu'il test n'apporte globalement pas grand chose et il n'y en a qu'une ou deux qui se démarquent...

    Bon après c'est loin d'être très scientifique, c'est beaucoup de doigt mouillé son analyse...
    Dernière modification par Nilsou ; 13/12/2021 à 02h07.

  20. #4490
    Citation Envoyé par William Vaurien Voir le message
    à chaque fois que je vois vos exemple de code en C++, je me dis que je suis bien content d'être resté sur du Java...
    Quoiqu'en ce moment c'est pas la fête...

  21. #4491
    C'est clair que ça craint un max... les très nombreuses applis de ma boîte utilisent logback, nous nous contentons de regarder le monde trembler autour de nous...

  22. #4492
    Ce qui sauve un peu le truc c'est en effet que le logger par défaut de Spring Boot c'est Logback, donc utilisé par beaucoup de monde.
    - La version 3 est arrivée !

  23. #4493
    Yes, ça craint pas tant que ça, bcp de monde s’excite en se demandant s'il a un projet qui utilise log4j, et tu en as qui pensent avoir un soucis car ils ont log4j-api. log4j-api n'est pas vulnérable (c'est la spec), c'est log4j-core (l'implémentation) qui l'est, or les projets Spring Boot utilisent plutôt logback par défaut depuis pas mal de temps, donc c'est safe de ce côté.

    Mais ce qui me fait hurler de rires, ce sont les gens qui se demandent (publiquement, sur le blog de Spring notamment) si leur projet est vulnérable, en mentionnant les versions de leurs libs log4j, spring boot etc. Là, tu réalises que leurs libs ont 5 ou 6 ans (j'ai même vu du spring boot v1, sérieux, et même pas la dernière version de la branche 1.x...), donc 1/ oui ils sont sûrement affectés par la vulnérabilité 2/ vu qu'ils n'ont rien mis à jour depuis 6 ans, ce n'est pas la seule vulnérabilité à craindre ^^.

    Le gouvernement canadien a pris la bonne décision : couper tous les sites gouvernementaux (plus de 3000) le temps de faire l'inventaire et corriger ce qui doit l'être.
    Coté français je ne sais pas. J'ai juste une pensée pour mes anciens collègues d'un gros site gouvernemental, qui doivent sûrement rusher pour fixer ça, et une autre pensée à mes anciens chefs/managers sur ce projet, qui m'ont chié à la figure quand je voulais du temps pour garder le projet à jour (malgré un listing des CVE à la clef).
    Dernière modification par gros_bidule ; 13/12/2021 à 15h21.

  24. #4494
    Ouais c'est la guerre, le nombre de mails depuis ce matin c'est une blague.

  25. #4495
    En plus pas mal de monde commence à être en vacances là
    Et une pensée aux instances Confluence concernées par la faille, d'autant qu'upgrader un Confluence ça ne se fait pas en 5min, et ça impacte le boulot de bcp de monde quand toute ta doc & specs sont dessus. Chez nous c'est derrière un VPN, mais bon... gaffe quand même, un poste infecté pourrait se faire plaisir.

  26. #4496
    Désolé, j’en remets une couche… Mais je mets pas d’extrait de code

    Citation Envoyé par Kamikaze Voir le message
    Pouah j'ai enfin commencé à toucher aux concept en c++20 (oui je suis en retard).
    Je pense pas que tu sois en retard. Certains en sont encore à comprendre les smart ptr…

    Citation Envoyé par Kamikaze Voir le message
    Dans Jai, Jonathan Blow a fait le choix d'utiliser une balise, tout ce qui est sous #run ça sera compile time, c'est fait via un interpréteur/compilo rapide, donc certes moins performant mais c'est interactif.
    Ça existe aussi en C++. C’est pas standard mais ça existe. https://www.circle-lang.org/. (Dispo aussi dans compiler explorer).

    Citation Envoyé par rOut Voir le message
    Et le top c'est que ça marchera avec n'importe quoi qui surcharge * et +, y compris avec une sémantique complètement différente de la multiplication et de l'addition, pour donner un dotProduct qui n'a aucun sens mais qui fait quand même des trucs.
    À ce moment-là, le compilo serait bien incapable de distinguer un floating point d’un integral.

    Le standard liste explicitement les types rentrant dans ces catégories et permet d’en ajouter explicitement.

    Citation Envoyé par Kamikaze Voir le message
    Au final je trouve qu'en programmation on manque pas mal de recherche théorique en algorithmique/maths du coup au final c'est dur de distinguer un choix solide et pertinent, d'une décision arbitraire quand on parle de langage.

    On a l'air d'avancer à taton concernant ce qui serait la meilleure syntaxe sans faire de grandes avancées.
    Je pense pas qu’on ne manque de recherche en théorie des langages et dans les domaines associés. Par contre, ça se fait forcément à tâtons, c’est le principe de la recherche. Le C++ en a bénéficié notamment grâce à Stepanov concepteur de la STL qui y a introduit des concepts aujourd’hui mainstream (itérateur, sentinelle, concept).

    C’est juste qu’il est compliqué pour un langage vieux de 36 ans de se révolutionner et ce sans chambouler une industrie gigantesque.

    Je pense que les avancés que tu cherches sont à trouver dans des langages plus récents (Rust, Haskell, Julia — Liste pas du tout exhaustive).
    Dernière modification par Raplonu ; 14/12/2021 à 09h36.

  27. #4497
    Je suis Sean Baxter sur twitter depuis un moment ouais, je connaissais, mais bon s'pas encore officiel supporté ni rien, si (ah oui "pas standard" comme tu l'as déjà dit)? Mais oui prometteur.

    Concernant la recherche, l'utilisation de valeurs sentinelles c'est un gain algorithmique, c'est tout simplement l'implémentation la meilleure dans certains cas. Mais s'pas vraiment un élément de langage (en c++ en tout cas, curieux de savoir si ça l'est dans d'autres?)

    Pour les itérateurs (et le reste) justement je me demande si y'a une telle justification algorithmique.

  28. #4498
    'Fin quoiqu'on pourrait dire que les strings null-terminated c'est un élément de langage ouais

  29. #4499
    Citation Envoyé par Kamikaze Voir le message
    Pour les itérateurs (et le reste) justement je me demande si y'a une telle justification algorithmique.
    Bah l'idée de base des itérateurs c'est de s'abstraire de la structure de donnée sous-jacente. Tu as un algo qui traite tes valeurs à travers un itérateur, tu peux lui filer une liste, un vector, une liste doublement chaînée de matrices à 14 dimensions...
    Bon tu me diras c'est très spécifique, mais c'est un peu l'idée qui sous-tend tout ce qui est template et la STL : empiler des éléments de langage génériques pour pouvoir donner un vision très haut niveau tout en laissant la possibilité (ou de préférence en la délégant au compilateur) de gérer l'optimisation dans ses détails à relativement bas niveau.

    Et c'est globalement la direction que prend notamment la STL : faire de l'algo à haut niveau et laisser le compilo gérer l'implémentation bas niveau.
    Dans le contexte du HPC c'est un peu le graal, on commence à voir des approches mûres du genre Kokkos où l'idée est d'écrire les "boucles" en tant qu'algo de haut niveau, et tu laisses après au compilo le travail de définir comment tes données sont rangées en mémoire et dans quel ordre elles sont parcourues, ce qui va changer du tout au tout notamment quand tu veux passer du CPU au GPU, mais aussi quand tu veux faire du multithreading ou de la vectorisation sur le CPU.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  30. #4500
    Mouais je considère pas que ça fasse partie de la syntaxe, pour chaque structure de donnée tu vas devoir implémenter un comportement pour pouvoir fournir cette abstraction.
    Mais bon la limite est toujours grise entre librairie standard, langage, etc.

    Pour donner un exemple, on pourrait avoir un langage qui a nativement une forte considération quant à l'architecture sous jacente, par exemple un CPU spécifique et l'organisation de son cache etc. Et qui va nativement proposer des abstractions cohérentes avec l'archi sous jacente.

    Genre un langage qui te forcerait à déclarer un bloc mémoire avant de déclarer tes variables locales. Comme ça nativement tu serais forcé de faire un choix en terme de modèle de mémoire.

    Donc un truc comme: https://en.cppreference.com/w/cpp/he...emory_resource

    Serait forcé par le langage.

    C'est un exemple (pas forcément très bon) parmi d'autre, mais y'a tout un tas de bonnes pratiques et de choses connues qui ne sont pas reflétées dans les langages existants et j'ai pas l'impression que y'ait encore de langage qui révolutionne vraiment le tout.

Page 150 sur 182 PremièrePremière ... 50100140142143144145146147148149150151152153154155156157158160 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •