David Demelier a écrit 676 commentaires

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

Au passage, on dit une espace ce qui donne donc « la disgracieuse espace ».

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

La dernière fois que j'ai fait du c++, je n'ai pas réussi à linker un pointeur de fonction vers une fonction compiler avec un compilateur c

1. PEBKAC
2. Idée absolument stupide

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

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

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

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

Par exemple j'aimerais bien retrouver la séparation byte/unicode de Python3 dans le C++ avec un type chaîne correct.

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

#include <string>
#include <codecvt>

std::string toUTF8(const std::u32string &s)
{
        std::wstring_convert<std::codecvt_utf8<char32_t>, char32_t> cv;

        return cv.to_bytes(s);
}

std::u32string toUCS4(const std::string &s)
{
        std::wstring_convert<std::codecvt_utf8<char32_t>, char32_t> cv;

        return cv.from_bytes(s);
}

int main(void)
{
    return 0;
}

git is great because linus did it, mercurial is better because he didn't

Y'a quoi comme alternative ?

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

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

Reste plus qu'à faire un QNOME :p.

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

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

Ç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

Le langage Rust est envisagé pour l’implémentation car c’est un langage système et que sa gestion mémoire est sûre.

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

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

Avec les plateformes comme github, bitbucket le fork est une manière de travailler et parfois la meilleure pour fournir des innovations sur un projet existant.

Sur ces plateformes là le fork est peut-être mal nommé, en fait on pourrait très bien dire qu'il s'agisse simplement d'un clone local où on va développer puis envoyer les diffs via pull-requests. C'est un peu comme si on avait cloné le dépôt hors github puis travaillé dessus en local (sans que ce soit un vrai fork). Les DCVS sont vraiment parfaits pour ça :).

Mais il est vrai que dans le cas de ce projet, l'idée initiale était un vrai fork à part entière :).

git is great because linus did it, mercurial is better because he didn't

Joli tes icônes, sur le mien elles sont toute pourries et ne prennent pas du tout en compte celles de Gtk.

git is great because linus did it, mercurial is better because he didn't

C'est vrai que les nouveaux styles de Visual Studio et office me rendent fou. entre les menu en CAPITABLE M'AVEZ VOUS BIEN VU et ces thèmes sans aucun dégradé on se croirait plusieurs années en arrière.

Sur mon smartphone ça me dérange pas, mais sur mon PC de bureau beaucoup ! Heureusement qu'il existe pas mal de thème Qt :-).

git is great because linus did it, mercurial is better because he didn't