Je ne vois pas en quoi c'est un standard, beaucoup de projets ont laissé tomber autotools pour CMake parce qu'ils ont découvert qu'il ne fallait pas un doctorat pour s'en servir.
git is great because linus did it, mercurial is better because he didn't
Moi je ne comprends pas qu'ils puissent encore utiliser des outils pourris et dépréciés que sont les autocrap. Pourquoi ne pas utiliser quelque chose de moderne comme CMake ? Scons ?
git is great because linus did it, mercurial is better because he didn't
J'ai tout de suite regardé pour SDL2, et je vois qu'ils ont mal écrit l'auteur de la bibliothèque.
Maintenant ce que je me demande, c'est comment on définit qu'on veut utiliser tel ou tel compilateur, car par exemple sur Windows on a le choix entre diverses options qui ne sont pas du tout compatibles (MSVC et MinGW par exemple).
Mais sinon j'avoue que l'idée est très intéressante et pendant un long moment j'avais envie de coder moi même un truc comme ça !
git is great because linus did it, mercurial is better because he didn't
Personnellement, ma Fedora 21 boot bien plus lentement que mon ancienne Ubuntu 14.10. Et elle boot même plus lentement que ma FreeBSD (et dieu sait à quel point FreeBSD c'est pas ce qui a de plus rapide pour le temps de boot).
git is great because linus did it, mercurial is better because he didn't
l'ABI ne concerne pas tous les langages… Par exemple en python/ruby/perl/js parler d'ABI n'a presque pas de sens. Semver n'est pas destiné qu'aux langages natifs.
De plus l'ABI elle est normalement gérée par le numéro de version de la bibliothèque partagée. Tu sais le dernier numéro de liba.so.0.2. Et ce dernier n'a rien à voir avec la version de la bibliothèque elle même. Lorsqu'on utilise une bibliothèque statique, le problème ne se pose même pas.
git is great because linus did it, mercurial is better because he didn't
Un des seuls langages au monde que je connaisse intégrant Graphviz dans sa bibliothèque standard. J'ai du mal à voir ce que ce module vient faire dans un langage supposé "système".
git is great because linus did it, mercurial is better because he didn't
À part la recherche et le développement, c'est quoi le réel intérêt de minix en 2014 ? Est-ce réellement utilisable pour un individu où ça reste tout simplement des hobbies ?
Pour moi plan9, minix, GNU/Hurd font parti du même lot dont personne voudra.
git is great because linus did it, mercurial is better because he didn't
Tu réalises que je peux très bien faire un jeu Libre mais pas gratuit?
Avec la GPL c'est complètement contradictoire. Puisque la GPL oblige le partage du code source, tu peux très bien dire (en tant qu'auteur) "je te le vends" puis l'acheteur en fait après ce qu'il a envie (puisque c'est GPL) et donc, le redistribuer gratuitement aux autres.
git is great because linus did it, mercurial is better because he didn't
Tes deux exemples ne sont pas du C++ "courant" (qu'on est sûr de retrouver sur tout compilateur C++), car ils viennent de la dernière version de la norme…
C'est un peu gros d' "oublier" de dire que ce que tu proposes n'est pas vraiment connu ni utilisable car pas dispo partout.
Ça c'est ton problème si tu souhaites vivre dans le passé. Même VisualStudio 2012 accepte ce code (qui pourtant supporte très mal C++11).
Moi personnellement, j'utilise les nouvelles technologies au maximum, et tant pis pour ceux qui supportent pas encore ça. Je ne suis pas un dinosaure :-).
git is great because linus did it, mercurial is better because he didn't
Moi je m'en sers depuis plusieurs mois et ça marche parfaitement, en général si ça marche pourquoi changer ?
Après si les distributions le suppriment juste parce qu'il y a plus de commits, je trouve ça ridicule. Il y a des dizaines de projets qui ne sont plus actifs mais qui sont tout simplement fonctionnels.
git is great because linus did it, mercurial is better because he didn't
Mais alors, pourquoi on/nous disons "on a gagné" dans un cas mais "ils ont perdu" dans l'autre, et pas l'inverse?
Par abus de langage… Je vois mal les gens chanter "nous avons gagné ! les doigts dans le nez !".
C'est pareil pour "on arrive". C'est évidemment pas correct mais malheureusement le pronom on a été détourné de son utilisation initiale par simplicité d'expression.
J'avoue moi même dire des fois "on doit faire comment ça", "on a pas le choix", …
git is great because linus did it, mercurial is better because he didn't
Je suis content de voir que les gens prennent la raison, mieux vaut tard que jamais. Il est grand temps d'admettre que Gtk est une erreur et qu'il doit disparaître.
git is great because linus did it, mercurial is better because he didn't
Il y a deux parties qui peuvent être évitées : le RTTI et les exceptions. Mais ça, c'est pas nouveau et il y a déjà des flags pour ça depuis des années.
Est-ce que tu parles des options de compilation qui permettent de désactiver RTTI et les exceptions ?
Je suis assez d'accord pour RTTI mais enlever les exceptions est vraiment dommage, d'ailleurs est-ce que c'est réellement possible ? à part noexcept j'ai jamais trouvé d'options de compilation pour les désactiver.
git is great because linus did it, mercurial is better because he didn't
Ça m'énerve, les nouveautés du C++11 ne font que complexifier le langage plus qu'autre chose. Mais comment voulez vous que des programmeurs apprennent et aient en tête les mille et une fonctionnalités du langage ? Beaucoup de projets font volontairement le choix d'utiliser qu'un sous-ensemble plus ou moins restreint du langage, pour que la barrière d'entré reste relativement basse.
Non, ces nouvelles fonctionnalités sont : 1. Optionnelle, 2. Réponde à un besoin précis. Avec la nouvelle syntaxe de retour on est plus obligé de spécifier le paramètre de retour de type template (très utile dans un DP factory) par exemple.
Au lieu de faire :
Window w = build(myfactory, "foo", "bar", "baz");
On peut maintenant faire :
Window w = build(myfactory, "foo", "bar", "baz")
En utilisant notamment auto -> decltype(myfactory.build()) par exemple
J'ai l'impression qu'ils (les auteurs de la norme C++11) essayent de faire des mécanismes pour obtenir du code ultra-générique mais ne se rendent pas compte que la contre partie est très importante. D'une part, le besoin de faire un code générique ne se rencontre que rarement, et d'autre part, ont perd souvent beaucoup en lisibilité et simplicité. C'est pas comme si c'était déjà difficile d'écrire du code illisible et non maintenable avec ce langage.
Tu as raison, vaut mieux faire du code non générique ou alors avec des void *, c'est génial ça :-). Et puis au passage, écrire des bibliothèque en template ont l'avantage de ne pas surcharger le binaire final si on ne s'en sert pas. "You don't pay for what you don't use"
Et parfois c'est mieux d'avoir à écrire plus de ligne de code pour éviter d'empiler inutilement les couches. Parce qu’on écrit pas du code pour qu'il soit le plus concis possible, mais le plus simple et compréhensible possible.
Je ne vois pas de quelles couches tu parles…
Et non, ce n'est pas un troll, le C++ est beaucoup trop gros et sa courbe d'apprentissage ne fait que s'élever de norme en norme.
Comme je l'ai dit au dessus, tu n'es pas obligé de tout utiliser. On peut très bien développer en C++ sans lambda, sans template et même sans namespaces. Mais lorsqu'on rencontre un problème précis, ça peut être très utile de commencer à apprendre ces fonctionnalités.
git is great because linus did it, mercurial is better because he didn't
Je suis content de voir de plus en plus de projets en C++11 :-). Cependant j'ai vu que votre code était en anglais mais les commentaires en français… Est-ce qu'il y a une raison particulière à ça ?
C'est un peu dommage pour nos amis anglophones et autres.
git is great because linus did it, mercurial is better because he didn't
# C'est vrai
Posté par David Demelier (site web personnel) . En réponse au journal lns: ln -s pour les étourdis. Évalué à 5.
J'avoue que je me trompe tout le temps aussi :-(
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quel est l'interet de GNOME Builder ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche GNOME 3.16 - nettoyage de printemps. Évalué à 5.
Je ne vois pas en quoi c'est un standard, beaucoup de projets ont laissé tomber autotools pour CMake parce qu'ils ont découvert qu'il ne fallait pas un doctorat pour s'en servir.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quel est l'interet de GNOME Builder ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche GNOME 3.16 - nettoyage de printemps. Évalué à 1.
Moi je ne comprends pas qu'ils puissent encore utiliser des outils pourris et dépréciés que sont les autocrap. Pourquoi ne pas utiliser quelque chose de moderne comme CMake ? Scons ?
git is great because linus did it, mercurial is better because he didn't
# Ça commence mal
Posté par David Demelier (site web personnel) . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 1.
J'ai tout de suite regardé pour SDL2, et je vois qu'ils ont mal écrit l'auteur de la bibliothèque.
Maintenant ce que je me demande, c'est comment on définit qu'on veut utiliser tel ou tel compilateur, car par exemple sur Windows on a le choix entre diverses options qui ne sont pas du tout compatibles (MSVC et MinGW par exemple).
Mais sinon j'avoue que l'idée est très intéressante et pendant un long moment j'avais envie de coder moi même un truc comme ça !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: L'argument kitu
Posté par David Demelier (site web personnel) . En réponse au journal systemd: je me lance. Évalué à 2.
Personnellement, ma Fedora 21 boot bien plus lentement que mon ancienne Ubuntu 14.10. Et elle boot même plus lentement que ma FreeBSD (et dieu sait à quel point FreeBSD c'est pas ce qui a de plus rapide pour le temps de boot).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et l’ABI, c’est du poulet ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche Gestion sémantique de version. Évalué à 4.
l'ABI ne concerne pas tous les langages… Par exemple en python/ruby/perl/js parler d'ABI n'a presque pas de sens. Semver n'est pas destiné qu'aux langages natifs.
De plus l'ABI elle est normalement gérée par le numéro de version de la bibliothèque partagée. Tu sais le dernier numéro de liba.so.0.2. Et ce dernier n'a rien à voir avec la version de la bibliothèque elle même. Lorsqu'on utilise une bibliothèque statique, le problème ne se pose même pas.
git is great because linus did it, mercurial is better because he didn't
# Graphviz
Posté par David Demelier (site web personnel) . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
Un des seuls langages au monde que je connaisse intégrant Graphviz dans sa bibliothèque standard. J'ai du mal à voir ce que ce module vient faire dans un langage supposé "système".
git is great because linus did it, mercurial is better because he didn't
# Intérêt
Posté par David Demelier (site web personnel) . En réponse au journal Conférence d'Andrew S. Tanenbaum. Évalué à 1.
À part la recherche et le développement, c'est quoi le réel intérêt de minix en 2014 ? Est-ce réellement utilisable pour un individu où ça reste tout simplement des hobbies ?
Pour moi plan9, minix, GNU/Hurd font parti du même lot dont personne voudra.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Séparateur de chiffre
Posté par David Demelier (site web personnel) . En réponse au journal C++14. Évalué à 2.
http://fr.wikipedia.org/wiki/Espace_(typographie)#Sens_du_mot_espace_au_masculin_et_f.C3.A9minin
git is great because linus did it, mercurial is better because he didn't
[^] # Re: En vrac
Posté par David Demelier (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 0.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Licence
Posté par David Demelier (site web personnel) . En réponse au journal Soya 3D version 3 arrive... (en images !). Évalué à 1.
Avec la GPL c'est complètement contradictoire. Puisque la GPL oblige le partage du code source, tu peux très bien dire (en tant qu'auteur) "je te le vends" puis l'acheteur en fait après ce qu'il a envie (puisque c'est GPL) et donc, le redistribuer gratuitement aux autres.
git is great because linus did it, mercurial is better because he didn't
# Licence
Posté par David Demelier (site web personnel) . En réponse au journal Soya 3D version 3 arrive... (en images !). Évalué à 0.
Vraiment dommage de choisir GPL comme licence. Pour une bibliothèque / framework la LGPL reste un gros avantage et est bien moins contraignante.
Beaucoup de personnes vont fuir ton projet si tu garde la GPL, crois moi :-). C'est dommage car en plus il a l'air sympathique.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le bon bash des familles
Posté par David Demelier (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 1.
Ça c'est ton problème si tu souhaites vivre dans le passé. Même VisualStudio 2012 accepte ce code (qui pourtant supporte très mal C++11).
Moi personnellement, j'utilise les nouvelles technologies au maximum, et tant pis pour ceux qui supportent pas encore ça. Je ne suis pas un dinosaure :-).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le bon bash des familles
Posté par David Demelier (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 1.
EDIT: avec clang il faudra peut-être rajouter l'entête locale aussi.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le bon bash des familles
Posté par David Demelier (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 1. Dernière modification le 23 juillet 2014 à 08:49.
Tu veux dire std::u32string ?
Et aussi std::codecvt_utf8 ?
Pour ma part, j'utilise ce code pour faire la conversion UTF-8 UCS-4
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et m....
Posté par David Demelier (site web personnel) . En réponse au journal Antispam sans DSpam. Évalué à 2.
Moi je m'en sers depuis plusieurs mois et ça marche parfaitement, en général si ça marche pourquoi changer ?
Après si les distributions le suppriment juste parce qu'il y a plus de commits, je trouve ça ridicule. Il y a des dizaines de projets qui ne sont plus actifs mais qui sont tout simplement fonctionnels.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: On ?
Posté par David Demelier (site web personnel) . En réponse au journal Voilà c'est fini.. Évalué à 2.
Par abus de langage… Je vois mal les gens chanter "nous avons gagné ! les doigts dans le nez !".
C'est pareil pour "on arrive". C'est évidemment pas correct mais malheureusement le pronom on a été détourné de son utilisation initiale par simplicité d'expression.
J'avoue moi même dire des fois "on doit faire comment ça", "on a pas le choix", …
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Debian GNU/kFreeBSD Wheezy dans une jail FreeBSD
Posté par David Demelier (site web personnel) . En réponse à la dépêche Ça bouge du côté de la virtualisation chez FreeBSD. Évalué à 4.
Oui c'est basé sur un billet plus vieux http://www.demelierdavid.fr/index.php/debian-dans-une-jail-freebsd/
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Bien
Posté par David Demelier (site web personnel) . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à 6.
Reste plus qu'à faire un QNOME :p.
git is great because linus did it, mercurial is better because he didn't
# Bien
Posté par David Demelier (site web personnel) . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à 2.
Je suis content de voir que les gens prennent la raison, mieux vaut tard que jamais. Il est grand temps d'admettre que Gtk est une erreur et qu'il doit disparaître.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Syntaxe étonnante
Posté par David Demelier (site web personnel) . En réponse au journal C++Now 2014. Évalué à 2. Dernière modification le 27 mai 2014 à 14:04.
Est-ce que tu parles des options de compilation qui permettent de désactiver RTTI et les exceptions ?
Je suis assez d'accord pour RTTI mais enlever les exceptions est vraiment dommage, d'ailleurs est-ce que c'est réellement possible ? à part noexcept j'ai jamais trouvé d'options de compilation pour les désactiver.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Syntaxe étonnante
Posté par David Demelier (site web personnel) . En réponse au journal C++Now 2014. Évalué à 2.
Oui pardon, j'ai pas réussi à mettre le code en avec les chevrons en bloc. :-(
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Syntaxe étonnante
Posté par David Demelier (site web personnel) . En réponse au journal C++Now 2014. Évalué à 3. Dernière modification le 26 mai 2014 à 09:19.
Non, ces nouvelles fonctionnalités sont : 1. Optionnelle, 2. Réponde à un besoin précis. Avec la nouvelle syntaxe de retour on est plus obligé de spécifier le paramètre de retour de type template (très utile dans un DP factory) par exemple.
Au lieu de faire :
Window w = build(myfactory, "foo", "bar", "baz");
On peut maintenant faire :
Window w = build(myfactory, "foo", "bar", "baz")
En utilisant notamment auto -> decltype(myfactory.build()) par exemple
Tu as raison, vaut mieux faire du code non générique ou alors avec des void *, c'est génial ça :-). Et puis au passage, écrire des bibliothèque en template ont l'avantage de ne pas surcharger le binaire final si on ne s'en sert pas. "You don't pay for what you don't use"
Je ne vois pas de quelles couches tu parles…
Comme je l'ai dit au dessus, tu n'es pas obligé de tout utiliser. On peut très bien développer en C++ sans lambda, sans template et même sans namespaces. Mais lorsqu'on rencontre un problème précis, ça peut être très utile de commencer à apprendre ces fonctionnalités.
git is great because linus did it, mercurial is better because he didn't
# Rust
Posté par David Demelier (site web personnel) . En réponse à la dépêche « Triple poignée de main », faille dans le protocole TLS. Évalué à 1.
Génial personne va s'en servir \o/. Ou alors il reste à espérer qu'ils fassent au moins une interface C.
git is great because linus did it, mercurial is better because he didn't
# Commentaires en français
Posté par David Demelier (site web personnel) . En réponse à la dépêche Libération de navitia : un calculateur d’itinéraire pour les transports en communs. Évalué à 2.
Bonjour,
Je suis content de voir de plus en plus de projets en C++11 :-). Cependant j'ai vu que votre code était en anglais mais les commentaires en français… Est-ce qu'il y a une raison particulière à ça ?
C'est un peu dommage pour nos amis anglophones et autres.
git is great because linus did it, mercurial is better because he didn't