David Demelier a écrit 670 commentaires

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

Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).

En parlant de ça, j'ai un bug qui date d'au moins plusieurs années (mais peut-être c'est ma configuration). Quand je découpe la fenêtre en deux, si j'entame un commentaire sur la fenêtre du haut, la fenêtre du bas devient 100% en couleur de commentaire (normal puisque j'ai pas terminé le commentaire). Mais quand je termine d'écrire mon commentaire, la fenêtre du bas garde la couleur de commentaire ce qui est assez énervant.

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

Pour être utilisateur du C++ je partage certains avis. Je rigole même quand j'entends Bjarne Stroustrup voulant un langage "facile à apprendre". Ce n'est pas le cas, C++ est extrêmement compliqué. Et il le devient encore plus quand on joue avec des aspects poussés du C++ comme le principe SFINAE + std::enable_if. Honnêtement, je m'en sers jamais, à mes yeux ça représente plus souvent de la masturbation intellectuelle qu'autre chose.

Par contre, il existe des choses vraiment bien en C++ et qui ne me feront pas retourner au C, comme le mot clé auto, les variadic templates, les lambdas, etc…

Il est vraiment convivial de pouvoir faire :

for (auto p : avector)
    p.use();

Par contre, je pense que le nommage du C++ est toujours horrible, et je ne parle pas de std::enable_shared_from_this, oui oui c'est bien une classe.

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

Bien, ça sera plus simple :-)

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

Encore un projet qui a compris :-)

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

Malheureusement ça fait des années que c'est comme ça. Mageia vient avec le passé de Mandrake Linux qui avait un bureau KDE par défaut et tous ces outils codés en Gtk. Vive la cohérence :-).

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

Je sais pas si on peut beaucoup parler de performances avec FreeBSD. En toute honnêteté, FreeBSD est légèrement moins réactif qu'un Linux pour ma part. Les compilations sont un poil plus longues et la réaction des environnement graphiques aussi.

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