Ton point de vue se tient, mais ici, je m’en remettrai à celui de Qt. Pas parce que je pense qu’ils ont plus raison que toi, mais parce que ce sont les détenteurs des droits, et que, si eux disent qu’ils pensent que c’est autorisé, à minima ils ne pourront pas te reprocher de l’avoir fait.
Mais vu que tu ne l’autorises pas toi, je ne me risquerai pas à le faire pour ton projet.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
emplace_back construit un objet avec les paramètres qu’on lui donne. Mais c’est une construction classique, ce que ça évite, c’est de construire l’objet puis le copier, en deux étapes. Lorsque qu’un vecteur réalloue, il copie puis détruit (ou il déplace).
Pour marquer qu’un objet n’est pas copiable, il faut « deleter » son constructeur de copie, ainsi que l’opérateur d’affectation :
Pour faire des vecteurs de classe non-copiable, il faut que l’objet soit movable, c’est à dire, qu’il ait un constructeur de mouvement défini. Une autre solution est de passer par un unique_ptr, comme tu l’as fait.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je ne connais aucun compilateur qui ne fait pas de "return value optimization". Gcc, Clang, Visual Studio, PGI, Intel font tous ces optimisations.
J’ai eu des cas avec Visual Studio où l’optimisation n’était pas faite, et donc de gros changements de perf en changeant la signature. Je ne sais plus si c’était spécifique au debug ou si c’était aussi le cas en release, mais ça rendait le code tellement lent que de toute façon, débugger devenant un enfer, il fallait faire autrement.
Par contre, c’était il y a pas loin de 10 ans, avec Visual Studio 2003 ou 2005, je ne sais plus lequel des deux. À cette époque, passer par référence était une bonne pratique. Le langage a bien changé depuis :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
D'ailleurs, pourquoi ne pas allouer cette mémoire "ailleurs" tout en étant en RAII ? De toute façon mettre des objets de tailles variables dans la pile est une très mauvaise idée. (je me rend compte que cela doit revenir à utiliser un vector<> dans la pile)
La seule bonne raison de le faire est quand tu :
- es sûr que l’allocation tiendra dans la pile
- ne veux pas d’allocation dynamique
Dans un système critique, par exemple, les allocations dans le tas durant l’exécution peuvent être interdites. Du coup, allouer un tableau tampon temporaire dans la pile, si tu es sûr qu’il tient, a du sens.
Cela dit, je ne sais plus si les VLAs de C permettent de contrôler la taille du tableau avant l’allocation. Il me semble que non, et que c’est justement pour ça que c’est une mauvaise idée.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
l'arrière plan devrait être transparent afin de s'adapter au fond de la CSS utilisée.
Si ta css met un fond noir, le dessin sera illisible. De manière générale, soit tu fixes l’arrière plan et l’avant plan, soit tu n’en fixes aucun, mais en fixer un seul sur les deux, c’est très pénible (quiconque a déjà utilisé un thème « sombre » pour naviguer maudit les dev webs qui ne prennent pas cette précaution élémentaire).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
En fait le truc, c’est que dans la vraie vie, tu t’en tapes. C’est à dire que le « problème » n’intervient que si le constructeur (de copie) a des effets de bord. Or c’est une très mauvaise pratique qu’il en ait.
On pourrait imaginer dans le futur pouvoir « marquer » de tels constructeurs, pour que le compilateur n’applique pas ces optimisations dessus. Toutefois, le fait que ça ne soit pas le cas montre surtout que le besoin est plutôt inexistant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Ce n’est pas une question de langage, c’est aussi une question que certaines choses ne sont pas une bonne idée. Un grand classique, c’est le coup de si B dérive de A, alors vector dérive de vector qui est en réalité une très mauvaise idée (violation flagrante du LSP).
La question, c'est plutôt "est-ce que des projets réels vont utiliser ça"?
Ça m’est arrivé. Personnellement, je ne vois pas ça comme des incompatibilités, mais des complémentarités. Après, quand tu commences à voir les bénéfices du polymorphisme statique, tu as tendance à ne vouloir utiliser plus que ça :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je vais essayer de reformuler ce que j’ai compris. Tu souhaites que :
Foo foo;
foo.baz = "toto";
rajoute statiquement un membre baz de type string dans l’instance foo, et uniquement celle-ci ?
Ça casse tout le modèle de compilation C++, et c’est contraire à tout ce à quoi je m’attends quand je lis du C++ (c’est pour ça que je parlais de « casser le langage »). En plus, tu peux très bien obtenir ce résultat en surchargeant l’opérateur [] :
foo["baz"] = "toto";
Ce qui certes fait 3 caractères de plus à taper, mais est aussi lisible et beaucoup plus « dans l’esprit » du langage. Quant à l’idée que ce ne serait pas optimal, dans tous les cas, c’est un lookup dans une table de hachage (ou un dictionnaire), je ne suis pas sûr que l’intégrer au compilateur gagnera grand chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je ne suis pas trop d’accord avec toi (du moins, avec ce que tu as écris). Tu donnes l’impression que ouvert et fermé s’opposent, alors que dans l’OCP, ils se complètent (n’agissent pas sur la même dimension). L’article wikipédia en français est assez clair là-dessus.
La complexité du code n’a pas nécessairement grand chose à voir là-dedans (au contraire, bien mis en œuvre, l’OCP a tendance à simplifier l’architecture globale car il réduit les effets de bord).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Il n'y a pas une seule bibliothèque C++ aujourd'hui qui sache faire de la sérialisation sans avoir à déclarer chaque champs 2 fois (une fois pour la compilation "statique" et une fois pour le runtime). C'est assez pénible.
Certes, mais en même temps, exposer dans ta sérialisation le nom du membre (côté programme) est vraisemblablement une mauvaise idée. Outre que suivant le type de sérialisation voulue, celui ci peut nécessiter une transformation (par exemple, pour sérialiser vers xml, on aura tendance à transformer les « _ » en « - » ). Donc devoir le définir deux fois mais pas à proprement parler un soucis, en tout cas pas majeur.
De plus, si les objets sont simplement des conteneurs sans intelligence (par exemple, des objets correspondant à des enregistrements dans une base SQL), le code est souvent généré automatiquement.
Lorsque le compilateur rencontrerait un membre non présent, il appellerait l'opérateur "." (qui peut static_asserter si le nom n'est pas acceptable, ou remplir les champs au runtime.
Ça c’est une très mauvaise idée. Si j’appelle un membre qui n’existe pas, je m’attends à une erreur de compilation, pas une erreur à l’exécution. Changer ça dans le contexte de C++, c’est, quelque part, casser le langage.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Donc c'est une extension de son sens. Là où le lien entre une châtaigne et une erreur est inexistant. On a juste voulu faire du français à tout prix et être phonétiquement proche.
Ce n’est pas forcément choquant. Le français a absorbé plein de mots petit à petit, en francisant l’orthographe pour rester phonétiquement proche tout en respectant les contraintes d’écriture du français (condottière, que mon correcteur orthographique a la pédanterie de me refuser, est une forme tout à fait correcte et un exemple de francisation récente). Ce qui est plus choquant, c’est que pour reprendre un mot existant, on a changé la prononciation. « Beugue » est moche, mais phonétiquement plus proche de ce que les gens emploient que « bogue ».
De manière similaire, l’anglais a bien décliné rendez-vous en « rendezvoused ». Je ne vois pas trop de raison autres que la pédanterie de me refuser le droit à employer « committer », par exemple, surtout que l’usage s’impose, faute d’alternative. La richesse d’une langue se mesure aussi à ses emprunts.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.
Mais les deux ne sont pas même pas forcément sur le même serveur. Servir les templates statiques et le js est très peu coûteux en charge serveur. C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes.
C’est vrai que j’ai tendance à oublier que certains réussissent à faire des horreurs comme rueducommerce qui rame horriblement côté client. Mais mon expérience (côté dev) est quand même souvent que quand ça rame, c’est parce que le serveur est lent à répondre, et au contraire, je trouve que le chargement asynchrone des données améliore l’« expérience utilisateur », car le site s’affiche, même partiellement, tandis que dans un templating côté serveur, le plus souvent tant que les données n’ont pas été récupérées rien ne s’affiche (pas pour rien qu’on recourt quasiment systématiquement à un cache du html dans ce cas).
Ça reste subjectif cela dit, je manque de données objectives de comparaison. Si tu en as je suis intéressé.
Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources.
Je pense pas que ça soit significativement plus consommateur de ressources qu’un moteur de templating classique (en gros, c’est juste manipuler du dom avec du js). phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Merci pour l’explication, c’est plus clair. Hormis la problématique du référencement (je t’avoue que je n’ai pas encore regardé comment on faisait le référencement pour une appli angularjs, pour parler de technos que je connais), j’ai du mal à voir l’intérêt de faire un rendu serveur.
Les arguments contre que je vois sont :
- la charge sur le serveur est celle qui coûte, celle sur le client est gratuite (sauf exceptions)
- les dimensions du client sont connues par… le client, qui saura donc le mieux faire le layouting qui va bien (adaptation mobile / tablette, par exemple)
J’ai presque envie de dire que si la problématique est une problématique de cache / rapidité, la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.
Après, il faut dire que j’ai tendance à structurer mes applications webs en tant que un front angular, et un back en json (soit jsonrpc, soit api http), ce qui fait que côté « serveur » la notion même de html n’existe plus. De mon point de vue, le templating côté serveur n’est pas l’avenir, mais plutôt restreint à des niches (clients avec très peu de puissance de calcul). Je ne connais pas du tout turbolinks dont tu parles, il faudra que j’y jette un œil à l’occasion (mais l’écosystème rails m’est complètement étranger).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Que l'application réponde aussi bien en front qu'en back. Si l'app est chargée dans mon browser c'est une app client-side, je navigue dans mon browser. Mais si j'arrive sur n'importe quelle url directement elle est rendue par mon back. Et je ne parle pas d'avoir une pseudo génération du front dans mon back, mais bien que l'app soit exécutée aussi bien côté front que back.
Désolé mais je n’ai toujours pas compris. Dans les deux cas l’application s’exécute et s’affiche dans le navigateur, non ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Lorsque je dis que C++ est un langage orienté objet
Tu commets une première erreur :).
ça ne fait pas de C++ un langage fonctionnel.
Ce n’est pas non plus ce que j’ai dit. Je répondais simplement à
ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?
En faisant remarquer qu’un pan entier du langage suivait ces paradigmes…
Néanmoins, C++ est multiparadigme (et donc, C++ n’est pas un langage « orienté objet », il est un langage intégrant parmi d’autres le paradigme objet), et de plus en plus, les paradigmes fonctionnels trouvent leur place dans le langage. Je suis très surpris d’ailleurs que les tenants des langages fonctionnels y trouvent matière à critiquer, en fait, ils devraient au contraire s’en réjouir :).
Les langages fonctionnels purs n’existent de toute façon que pour faire de la preuve mathématique : dès que tu travailles sur un système, tu introduis à minima les problématiques d’aliasing et de mutabilité (même si ton langage l’interdit au niveau variable, tu peux l’avoir au niveau système de fichier par exemple, des ressources systèmes, de la console, etc.), ce qui casse toute la « pureté » de ton langage. C’est d’ailleurs je pense une des raisons de l’échec (relatif, bien entendu) des langages fonctionnels : leur niveau d’abstraction ne correspond finalement pas tant que ça à la réalité à laquelle est confronté le programmeur.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Si tu as une fonction qui peut retourner soit le type A soit le type B, tu doit faire attention à gérer chacun des 2 types partout ou utiliser des fonctions ou des opérateurs qui peuvent prendre ces 2 types en paramètre. C'est en ça qu'ils sont polymorphiques. Le polymorphisme dans le paradigme fonctionnel ne s'appuie pas sur une hiérarchie de classe, mais sur le fait de pouvoir prendre un type parmi d'autres. C'est ce qu'ils appellent les union type si je ne m'abuse (mais je crois que je m'abuse, c'est un autre nom).
Si je comprends bien, c’est un l’équivalent d’un variant, mais implicite ? Le polymorphisme dans les langages fonctionnels repose sur le duck typing (c’est le cas en python, et aussi en go si je ne me plante pas, ce n’est pas lié au paradigme fonctionnel), mais ce que tu dis c’est que là le compilateur s’autorise à créer de nouveaux types ?
Il me semble qu’ocaml fait du multiple dispatch (j’en suis sûr pour Haskell) en fonction du type réel des arguments. Est-ce à dire que si tu as une fonction f qui peut renvoyer soit un A, soit un B, et deux surcharges de g, l’une pour A, l’autre pour B, cela va fonctionner correctement de chaîner les appels g(f("toto")) ? Ce serait élégant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Ton problème, c’est que soit tu trolles de mauvaise foi, soit tu ne sais pas lire:
Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?
Il n’est pas marqué ça sur le site. Il est marqué que les lambdas sont apparues dans le langage C++ depuis la version C++11. C’est pour ça que je dis que tu es de mauvaise foi, ou que tu ne sais pas lire.
Il existait déjà bien auparavant boost::function.
ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?
Si tu connaissais un peu le C++, tu verrais qu’il y a beaucoup de choses qui relèvent de la programmation fonctionnelle dès qu’on fait de la métaprogrammation. Il y a même une syntaxe presque aussi horrible que celle d’Haskell :) (dans un style différent, certes).
Mais plus généralement, tu juges de la compétences des concepteurs d’un langage (ne me dis pas que tu poses seulement une question, la tournure est loin d’être innocente et tu le sais très bien) que tu ne connais pas sur une mauvaise lecture que tu fais (probablement volontairement) de documentations sur un site web qui n’est pas en lien avec le comité en charge de l’évolution du langage. Il y a des limites à ce qui acceptable comme troll :).
À part ça, pour shared_ptr, j’ai déjà répondu (avec des exemples). C’est un partage de responsabilité de la durée de vie. Ton idée de liste chaînée ou de tableaux persistants est (de ce que j’en ai compris) un peu à côté de la plaque de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C
C++ est plus performant que C (à code comparable). L’exemple typique est std::sort vs qsort, parce std::sort n’a pas le coût associé au pointeur de fonction. C++ te permet de faire à la compilation des optimisations dont tu ne peux même pas rêver en C.
On peut utiliser massivement les templates sans utiliser la moindre méthode virtuelle (c’est d’ailleurs à de nombreux endroits le cas dans la STL). Il existe des raisons (pas forcément les meilleures, certes) d’avoir des méthodes virtuelles dans une classe mais un destructeur non virtuel (dans ce cas, il faut théoriquement mettre le destructeur de la classe de base en protégé).
Le choix par défaut de C++ est celui qui ne coûte pas. Si ton propos est de dire que le compilateur devrait et péter un gros warning quand tu as un destructeur non virtuel public dans une classe ayant une méthode virtuelle, je suis tout à fait d’accord. En revanche, s’il est que tout doit être virtuel par défaut, non. Ce n’est pas l’esprit du langage, il y en a d’autres pour ça. Don’t pay for what you don’t use.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Pour conclure, je veux bien un cas d'usage quotidien de shared_ptr. Si je peux être détrompé, tant mieux.
Quelques cas. Un premier, c’est de transférer la propriété sur un objet non movable (c’est à dire, en remplacement de std::unique_ptr, pour des objets pas prévus pour / du code legacy). Je t’accorde que je triche, mais il ne faut pas oublier que shared_ptr est antérieur à unique_ptr, et que pour cet usage il était très largement supérieur à auto_ptr.
Un deuxième, c’est typiquement quand tu veux passer un observateur optionnel à un objet qui fait un traitement. Dans ce cas, ça peut être le couple weak_ptr / shared_ptr qui peut être utile (si tu souhaites que ce soit l’appelant qui gère la durée de vie de l’objet, mais qu’il puisse supprimer l’observateur en cours de traitement).
Sinon, c’est je par exemple aussi beaucoup utilisé dans les frameworks de futures (parce que dans ce type de frameworks, la responsabilité de la durée de vie des callbacks est clairement partagée).
Bref, comme beaucoup de choses en C++ : ce n’est pas le truc à tout faire, mais il y a des cas d’utilisation pour lesquels c’est l’outil le plus adapté.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Licence commerciale pour iOS, pas tout à fait
Posté par whity . En réponse à la dépêche GCompris Qt sort en version 0.70. Évalué à 2.
Ton point de vue se tient, mais ici, je m’en remettrai à celui de Qt. Pas parce que je pense qu’ils ont plus raison que toi, mais parce que ce sont les détenteurs des droits, et que, si eux disent qu’ils pensent que c’est autorisé, à minima ils ne pourront pas te reprocher de l’avoir fait.
Mais vu que tu ne l’autorises pas toi, je ne me risquerai pas à le faire pour ton projet.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Je me lance !
Posté par whity . En réponse à la dépêche Concours « jeu de mots » et cadeaux pour Noël. Évalué à 2.
Dans le même genre, il y a aussi les opérateurs tadpoles, peu connus :). cf ici
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: questions sur les constructeurs et les vecteurs
Posté par whity . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.
emplace_back construit un objet avec les paramètres qu’on lui donne. Mais c’est une construction classique, ce que ça évite, c’est de construire l’objet puis le copier, en deux étapes. Lorsque qu’un vecteur réalloue, il copie puis détruit (ou il déplace).
Pour marquer qu’un objet n’est pas copiable, il faut « deleter » son constructeur de copie, ainsi que l’opérateur d’affectation :
Pour faire des vecteurs de classe non-copiable, il faut que l’objet soit movable, c’est à dire, qu’il ait un constructeur de mouvement défini. Une autre solution est de passer par un unique_ptr, comme tu l’as fait.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Value Semantics Rocks
Posté par whity . En réponse à la dépêche C++17 garantit le court-circuit de copie (suite de la précédente dépêche). Évalué à 1.
J’ai eu des cas avec Visual Studio où l’optimisation n’était pas faite, et donc de gros changements de perf en changeant la signature. Je ne sais plus si c’était spécifique au debug ou si c’était aussi le cas en release, mais ça rendait le code tellement lent que de toute façon, débugger devenant un enfer, il fallait faire autrement.
Par contre, c’était il y a pas loin de 10 ans, avec Visual Studio 2003 ou 2005, je ne sais plus lequel des deux. À cette époque, passer par référence était une bonne pratique. Le langage a bien changé depuis :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: What you see is not what you get
Posté par whity . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.
La seule bonne raison de le faire est quand tu :
- es sûr que l’allocation tiendra dans la pile
- ne veux pas d’allocation dynamique
Dans un système critique, par exemple, les allocations dans le tas durant l’exécution peuvent être interdites. Du coup, allouer un tableau tampon temporaire dans la pile, si tu es sûr qu’il tient, a du sens.
Cela dit, je ne sais plus si les VLAs de C permettent de contrôler la taille du tableau avant l’allocation. Il me semble que non, et que c’est justement pour ça que c’est une mauvaise idée.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: 0xB16B00B5p0
Posté par whity . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 4.
Il ne peut pas, cette constante vient de Microsoft : pour référence
Par contre, elle pourrait être écrite 2976579765u. Plus de problème.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Typo
Posté par whity . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 5.
Au moins deux.
Si ta css met un fond noir, le dessin sera illisible. De manière générale, soit tu fixes l’arrière plan et l’avant plan, soit tu n’en fixes aucun, mais en fixer un seul sur les deux, c’est très pénible (quiconque a déjà utilisé un thème « sombre » pour naviguer maudit les dev webs qui ne prennent pas cette précaution élémentaire).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: euh ?
Posté par whity . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 5.
En fait le truc, c’est que dans la vraie vie, tu t’en tapes. C’est à dire que le « problème » n’intervient que si le constructeur (de copie) a des effets de bord. Or c’est une très mauvaise pratique qu’il en ait.
On pourrait imaginer dans le futur pouvoir « marquer » de tels constructeurs, pour que le compilateur n’applique pas ces optimisations dessus. Toutefois, le fait que ça ne soit pas le cas montre surtout que le besoin est plutôt inexistant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: 0xB16B00B5p0
Posté par whity . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 4.
T’as quand même intérêt à faire bien gaffe à la prononciation. « n » et « m » sont des sonorités proches, un malentendu serait vite arrivé…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: 0xB16B00B5p0
Posté par whity . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 6.
Oh la blague pourrie…
0xEp1< 0xfa1LMes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nouveau langage
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3.
Ce n’est pas une question de langage, c’est aussi une question que certaines choses ne sont pas une bonne idée. Un grand classique, c’est le coup de si B dérive de A, alors vector dérive de vector qui est en réalité une très mauvaise idée (violation flagrante du LSP).
Ça m’est arrivé. Personnellement, je ne vois pas ça comme des incompatibilités, mais des complémentarités. Après, quand tu commences à voir les bénéfices du polymorphisme statique, tu as tendance à ne vouloir utiliser plus que ça :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nouveau langage
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 2.
J’ai un peu de mal à te suivre.
Je vais essayer de reformuler ce que j’ai compris. Tu souhaites que :
Foo foo;
foo.baz = "toto";
rajoute statiquement un membre baz de type string dans l’instance foo, et uniquement celle-ci ?
Ça casse tout le modèle de compilation C++, et c’est contraire à tout ce à quoi je m’attends quand je lis du C++ (c’est pour ça que je parlais de « casser le langage »). En plus, tu peux très bien obtenir ce résultat en surchargeant l’opérateur [] :
foo["baz"] = "toto";Ce qui certes fait 3 caractères de plus à taper, mais est aussi lisible et beaucoup plus « dans l’esprit » du langage. Quant à l’idée que ce ne serait pas optimal, dans tous les cas, c’est un lookup dans une table de hachage (ou un dictionnaire), je ne suis pas sûr que l’intégrer au compilateur gagnera grand chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Je m'y colle...
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3.
En attendant, il y a une explication relativement claire en français ici.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Retour arrière sur l'OCP
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 1.
Je ne suis pas trop d’accord avec toi (du moins, avec ce que tu as écris). Tu donnes l’impression que ouvert et fermé s’opposent, alors que dans l’OCP, ils se complètent (n’agissent pas sur la même dimension). L’article wikipédia en français est assez clair là-dessus.
La complexité du code n’a pas nécessairement grand chose à voir là-dedans (au contraire, bien mis en œuvre, l’OCP a tendance à simplifier l’architecture globale car il réduit les effets de bord).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nouveau langage
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3.
Certes, mais en même temps, exposer dans ta sérialisation le nom du membre (côté programme) est vraisemblablement une mauvaise idée. Outre que suivant le type de sérialisation voulue, celui ci peut nécessiter une transformation (par exemple, pour sérialiser vers xml, on aura tendance à transformer les « _ » en « - » ). Donc devoir le définir deux fois mais pas à proprement parler un soucis, en tout cas pas majeur.
De plus, si les objets sont simplement des conteneurs sans intelligence (par exemple, des objets correspondant à des enregistrements dans une base SQL), le code est souvent généré automatiquement.
Ça c’est une très mauvaise idée. Si j’appelle un membre qui n’existe pas, je m’attends à une erreur de compilation, pas une erreur à l’exécution. Changer ça dans le contexte de C++, c’est, quelque part, casser le langage.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# Syntaxe ?
Posté par whity . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3.
Merci pour cette dépêche. Je suis un peu surpris par la syntaxe choisie. Je me serais attendu à quelque chose comme
static_if<cond> {un peu sur le modèle du
static_assert.Quelqu’un sait ce qui a motivé le choix de cette syntaxe ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: italiques
Posté par whity . En réponse à la dépêche Kalliope, votre assistant personnel vocal. Évalué à 3.
Ce n’est pas forcément choquant. Le français a absorbé plein de mots petit à petit, en francisant l’orthographe pour rester phonétiquement proche tout en respectant les contraintes d’écriture du français (condottière, que mon correcteur orthographique a la pédanterie de me refuser, est une forme tout à fait correcte et un exemple de francisation récente). Ce qui est plus choquant, c’est que pour reprendre un mot existant, on a changé la prononciation. « Beugue » est moche, mais phonétiquement plus proche de ce que les gens emploient que « bogue ».
De manière similaire, l’anglais a bien décliné rendez-vous en « rendezvoused ». Je ne vois pas trop de raison autres que la pédanterie de me refuser le droit à employer « committer », par exemple, surtout que l’usage s’impose, faute d’alternative. La richesse d’une langue se mesure aussi à ses emprunts.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Ruby <3
Posté par whity . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 2.
Mais les deux ne sont pas même pas forcément sur le même serveur. Servir les templates statiques et le js est très peu coûteux en charge serveur. C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
C’est vrai que j’ai tendance à oublier que certains réussissent à faire des horreurs comme rueducommerce qui rame horriblement côté client. Mais mon expérience (côté dev) est quand même souvent que quand ça rame, c’est parce que le serveur est lent à répondre, et au contraire, je trouve que le chargement asynchrone des données améliore l’« expérience utilisateur », car le site s’affiche, même partiellement, tandis que dans un templating côté serveur, le plus souvent tant que les données n’ont pas été récupérées rien ne s’affiche (pas pour rien qu’on recourt quasiment systématiquement à un cache du html dans ce cas).
Ça reste subjectif cela dit, je manque de données objectives de comparaison. Si tu en as je suis intéressé.
Je pense pas que ça soit significativement plus consommateur de ressources qu’un moteur de templating classique (en gros, c’est juste manipuler du dom avec du js). phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Ruby <3
Posté par whity . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 2.
Merci pour l’explication, c’est plus clair. Hormis la problématique du référencement (je t’avoue que je n’ai pas encore regardé comment on faisait le référencement pour une appli angularjs, pour parler de technos que je connais), j’ai du mal à voir l’intérêt de faire un rendu serveur.
Les arguments contre que je vois sont :
- la charge sur le serveur est celle qui coûte, celle sur le client est gratuite (sauf exceptions)
- les dimensions du client sont connues par… le client, qui saura donc le mieux faire le layouting qui va bien (adaptation mobile / tablette, par exemple)
J’ai presque envie de dire que si la problématique est une problématique de cache / rapidité, la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.
Après, il faut dire que j’ai tendance à structurer mes applications webs en tant que un front angular, et un back en json (soit jsonrpc, soit api http), ce qui fait que côté « serveur » la notion même de html n’existe plus. De mon point de vue, le templating côté serveur n’est pas l’avenir, mais plutôt restreint à des niches (clients avec très peu de puissance de calcul). Je ne connais pas du tout turbolinks dont tu parles, il faudra que j’y jette un œil à l’occasion (mais l’écosystème rails m’est complètement étranger).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Ruby <3
Posté par whity . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 3.
Désolé mais je n’ai toujours pas compris. Dans les deux cas l’application s’exécute et s’affiche dans le navigateur, non ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Jai: Language for game programmming
Posté par whity . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 3.
Tu commets une première erreur :).
Ce n’est pas non plus ce que j’ai dit. Je répondais simplement à
En faisant remarquer qu’un pan entier du langage suivait ces paradigmes…
Néanmoins, C++ est multiparadigme (et donc, C++ n’est pas un langage « orienté objet », il est un langage intégrant parmi d’autres le paradigme objet), et de plus en plus, les paradigmes fonctionnels trouvent leur place dans le langage. Je suis très surpris d’ailleurs que les tenants des langages fonctionnels y trouvent matière à critiquer, en fait, ils devraient au contraire s’en réjouir :).
Les langages fonctionnels purs n’existent de toute façon que pour faire de la preuve mathématique : dès que tu travailles sur un système, tu introduis à minima les problématiques d’aliasing et de mutabilité (même si ton langage l’interdit au niveau variable, tu peux l’avoir au niveau système de fichier par exemple, des ressources systèmes, de la console, etc.), ce qui casse toute la « pureté » de ton langage. C’est d’ailleurs je pense une des raisons de l’échec (relatif, bien entendu) des langages fonctionnels : leur niveau d’abstraction ne correspond finalement pas tant que ça à la réalité à laquelle est confronté le programmeur.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Jai: Language for game programmming
Posté par whity . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 0.
Si je comprends bien, c’est un l’équivalent d’un variant, mais implicite ? Le polymorphisme dans les langages fonctionnels repose sur le duck typing (c’est le cas en python, et aussi en go si je ne me plante pas, ce n’est pas lié au paradigme fonctionnel), mais ce que tu dis c’est que là le compilateur s’autorise à créer de nouveaux types ?
Il me semble qu’ocaml fait du multiple dispatch (j’en suis sûr pour Haskell) en fonction du type réel des arguments. Est-ce à dire que si tu as une fonction f qui peut renvoyer soit un A, soit un B, et deux surcharges de g, l’une pour A, l’autre pour B, cela va fonctionner correctement de chaîner les appels g(f("toto")) ? Ce serait élégant.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Jai: Language for game programmming
Posté par whity . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 0.
Ton problème, c’est que soit tu trolles de mauvaise foi, soit tu ne sais pas lire:
Il n’est pas marqué ça sur le site. Il est marqué que les lambdas sont apparues dans le langage C++ depuis la version C++11. C’est pour ça que je dis que tu es de mauvaise foi, ou que tu ne sais pas lire.
Il existait déjà bien auparavant boost::function.
Si tu connaissais un peu le C++, tu verrais qu’il y a beaucoup de choses qui relèvent de la programmation fonctionnelle dès qu’on fait de la métaprogrammation. Il y a même une syntaxe presque aussi horrible que celle d’Haskell :) (dans un style différent, certes).
Mais plus généralement, tu juges de la compétences des concepteurs d’un langage (ne me dis pas que tu poses seulement une question, la tournure est loin d’être innocente et tu le sais très bien) que tu ne connais pas sur une mauvaise lecture que tu fais (probablement volontairement) de documentations sur un site web qui n’est pas en lien avec le comité en charge de l’évolution du langage. Il y a des limites à ce qui acceptable comme troll :).
À part ça, pour shared_ptr, j’ai déjà répondu (avec des exemples). C’est un partage de responsabilité de la durée de vie. Ton idée de liste chaînée ou de tableaux persistants est (de ce que j’en ai compris) un peu à côté de la plaque de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Donc pour résumer…
Posté par whity . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 6.
C++ est plus performant que C (à code comparable). L’exemple typique est std::sort vs qsort, parce std::sort n’a pas le coût associé au pointeur de fonction. C++ te permet de faire à la compilation des optimisations dont tu ne peux même pas rêver en C.
On peut utiliser massivement les templates sans utiliser la moindre méthode virtuelle (c’est d’ailleurs à de nombreux endroits le cas dans la STL). Il existe des raisons (pas forcément les meilleures, certes) d’avoir des méthodes virtuelles dans une classe mais un destructeur non virtuel (dans ce cas, il faut théoriquement mettre le destructeur de la classe de base en protégé).
Le choix par défaut de C++ est celui qui ne coûte pas. Si ton propos est de dire que le compilateur devrait et péter un gros warning quand tu as un destructeur non virtuel public dans une classe ayant une méthode virtuelle, je suis tout à fait d’accord. En revanche, s’il est que tout doit être virtuel par défaut, non. Ce n’est pas l’esprit du langage, il y en a d’autres pour ça. Don’t pay for what you don’t use.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Donc pour résumer…
Posté par whity . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 1.
Quelques cas. Un premier, c’est de transférer la propriété sur un objet non movable (c’est à dire, en remplacement de std::unique_ptr, pour des objets pas prévus pour / du code legacy). Je t’accorde que je triche, mais il ne faut pas oublier que shared_ptr est antérieur à unique_ptr, et que pour cet usage il était très largement supérieur à auto_ptr.
Un deuxième, c’est typiquement quand tu veux passer un observateur optionnel à un objet qui fait un traitement. Dans ce cas, ça peut être le couple weak_ptr / shared_ptr qui peut être utile (si tu souhaites que ce soit l’appelant qui gère la durée de vie de l’objet, mais qu’il puisse supprimer l’observateur en cours de traitement).
Sinon, c’est je par exemple aussi beaucoup utilisé dans les frameworks de futures (parce que dans ce type de frameworks, la responsabilité de la durée de vie des callbacks est clairement partagée).
Bref, comme beaucoup de choses en C++ : ce n’est pas le truc à tout faire, mais il y a des cas d’utilisation pour lesquels c’est l’outil le plus adapté.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0