Qu'est-ce qu'on s'en fout, il est en général indispensable d'adapter le code de l'année d'avant quand on change de version de gcc de toutes manières…
C’est avec ce genre de remarques que tu décrédibilises totalement ton propos. S’il y a effectivement du code qui peut être cassé à chaque évolution du langage, on est très loin de ce que tu décris et de la fréquence que tu sembles indiquer.
Peut-être justement parce que :
Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc). Il y a du code de 40 ans qui compile grâce à ces trucs?
oui. Et qu’en plus, on veut pouvoir compiler la même base de code avec le dernier compilateur moderne et aussi la vieille antiquité d’il y a 10 ans qui compile pour notre microcontrôleur spécifique, de préférence sans avoir à faire des #ifdef dans tous les sens.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Là où tous les autres langages ajoutent des fonctionnalités sereinement dès qu'il en est question en C++, on voit un « non, mais attends tu ne te rend pas compte de comment c'est compliqué… ».
Peu de langages ont un modèle de compilation séparé (puisqu’on parle des inclusions).
Je crois que c’était une bonne idée en 1970, quand C a été créé, puisque ça permettait de compiler des programmes beaucoup plus gros que la mémoire dont on disposait à l’époque. Aujourd’hui, C++ doit vivre avec cet héritage (remettre en cause ce modèle n’est pas à l’ordre du jour, ça casse trop de chose). Mais il y a des évolutions, les propositions sur les modules vont dans ce sens.
Du coup, oui, d’autres langages font autrement, plus simplement, mais c’est aussi parce qu’ils ont des contraintes différentes :). Quand on parle du poids de l’historique, oui, c’est clair que C++ a un lourd passé.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Prend par exemple le char** dans le main(). C'est quand même super paradoxal, non? Ça ne semblerait pas plus cohérent de pouvoir obtenir un std::vector<std::string>? Le langage envoie des signaux contradictoires tout le temps.
main fait partie de l’API C. Passer un std::vector<std::string> impliquerait :
* de forcer à compiler avec la STL (donc support des exceptions, rtti, exécutable plus gros, etc).
* un overhead au démarrage lié à la construction de ce vecteur à partir de l’API C.
Ce serait donc contraire à la philosophie C++ de ne payer que pour ce qu’on utilise.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Tu peux aussi remplacer C++ par développement en général. La conception logicielle, ce n’est pas simple, les APIs pourries ou les fautes de conception il y en a dans tous les langages.
C’est aussi pour ça que C++ évolue lentement : pour se prémunir d’erreurs dans le standard (c’est boost qui essuie les plâtres).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Par copiable, tu entends par l'opérateur d'affectation ou par le constructeur de copie? Ça m'est déja arrivé de faire des fonctions virtual Base * clone(const Base ) = 0; qui sont explicitées dans les classes filles en appelant le constructeur de copie par un new(this), et ça ne m'avait pas choqué.
Les deux. L’usage d’une fonction clone est problématique aussi (qu’est censé faire Derived::clone(Base const& b) si on lui donne un Base& qui est de type Derived2 ? Un assert ? pas terrible…).
Copier la partie Base d’un Derived un autre Base peut avoir du sens, en revanche, copier dans un Derived une partie Base en a beaucoup moins. Et je ne sais pas autoriser l’un sans autoriser l’autre.
Il y a des cas où on en arrive à faire ça (une hiérarchie de classes copiables), mais en général par soucis de simplificité (comprendre, flemme :) ) et c’est source de problèmes. Ce n’est pas quelque chose de conceptuellement très correct.
Tu veux dire de définir une struct connue de ta classe seule qui contiendrait tous les membres copiables de la classe, ce qui permettrait de pouvoir copier tous les membres d'un coup? Ça ne fonctionne que si tu n'as pas une hiérarchie qui ajoute des membres, autrement c'est presque pire.
Ce n’est pas du tout à ça que je pensais. Je ne vois pas trop comment faire un exemple simple, mais l’idée, c’est plutôt de passer par un mécanisme de copie non-standard (appel de fonction statique, pex) pour se prémunir d’un usage imprévu / susceptible de poser des problèmes (à la place d’une copie implicite potentiellement problématique, tu as une erreur de compilation, c’est beaucoup mieux).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
L'exemple typique qui me vient en tête, c'est une classe où un seul membre ne doit pas être recopié tel quel. Il faut se farcir un constructeur de copie et un opérateur d'affection au code trivial et dupliqué, y compris dans les classes filles
Si ta classe fait partie d’une hiérarchie polymorphe, elle ne devrait pas être copiable. Sinon, tu t’assures de faire de la merde et des bugs à un moment où un autre.
Si tu pars sur une hiérarchie non polymorphe (typiquement, avec CRTP), il est possible de factoriser le tout (en délégant la copie de la partie concernée de ta structure).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Je suis dubitatif sur ton deuxième exemple. g++ le compile sans broncher, mais je pense qu’il a tort. Je n’ai pas de visual sous la main pour vérifier, mais je pense que c’est clang qui a raison de le refuser (et ce indépendamment de la version de c++, je ne vois pas ce qui aurait changé dans la norme qui provoquerait un changement de comportement).
Si tu pars sur des extensions / tolérances du compilateur, tu ne peux pas reprocher au langage lui-même qu’un autre compilateur n’ait pas les mêmes tolérances ;).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
L'absence de programmation générique. J'aimerais c'est pouvoir automatiquement dériver des comportements pour mes classes. À la louche, l'itération, l'affichage, la sérialisation, la comparaison, les relations d'ordre, le hash, l'enumeration, … Je recode ces trucs là pour presque chaque classe et c'est du temps perdu, du code en plus, des tests en plus, des bugs en plus, de la maintenance en plus.
As-tu des exemples de langage dans lesquels ce que tu fais manuellement est fait automatiquement ? J’ai un peu de mal à suivre où tu veux en venir.
Un système de type limité et hyper verbeux ce qui fait que on essaye de ne pas créer de nouveau type parce que c'est complexe. Je le retrouve tous les jours au travail ou en formation, un développeur C++ est heureux quand il a une classe suffisamment générique pour traiter tous ses cas, alors que moi je serais heureux quand j'aurais 100 classes suffisamment spécifiques pour traiter tous mes cas avec une bonne sécurité. Mais je ne le fais pas parce que maintenir 100 classes en C++ versus une, c'est l'horreur. Faire de la délégation en C++ c'est lourd.
Euh, non, le découpage en petites unités fonctionnelles est très présent en C++. C’est ce que tout le monde recommande aujourd’hui (loi de Déméter, à l’esprit de tous les devs c++ compétents). C’est parce qu’il y a deux fichiers que c’est « trop compliqué de créer un classe » ? C’est un problème d’environnement de dev dans ce cas, pas de langage.
Les valeurs par défaut. Beaucoup de classes de la STL imposent que votre type soit default constructible, comme par exemple le deleter de std::unique_ptr. Cela force à mettre des constructeur par défaut complètement abscons à beaucoup d'endroits.
Euh, non. Tu peux très bien mettre un type non default constructible dans un unique_ptr. Depuis c++11, on peut même dans un vector, suivant comment on l’utilise (tant qu’on n’utilise pas resize). En plus, comme on peut le defaulter quand ça a du sens, ce n’est franchement pas la mer à boire.
Tout est mutable par défaut ;( Là c'est clairement un point subjectif de ma part, mais je n'aime pas.
À mettre en balance avec le fait que C++ offre un const vérifié statiquement. Bien utilisé, c’est beaucoup de bugs ou de prises de tête en moins.
La communauté. N'allez surtout pas sur IRC si vous n’êtes pas un dieu du C++, vous vous ferez allumer et traiter d’incompétent. Expérience personnelle que j'ai mal vécue : je suis aller sur #C++ sur irc.freenode.net pour discuter une subtilité du langage qui m'avait étonnée et on m'a envoyer paître en me traitant d’incompétent qui ne comprenait pas la philosophie du langage.
Je ne suis jamais allé sur freenode, donc je ne peux pas dire. En revanche, la communauté française est très ouverte.
Pour le reste de tes critiques, je suis assez d’accord (sauf le pattern matching dont je trouve qu’à part l’effet trocool, ça ne sert pas à grand chose). Mais la question qui est toujours en suspens, c’est quelle alternative à c++ ? Pour du dev jetable, plein. Pour un truc censé durer 10 ans (c’est pas si long que ça dans le domaine du développement logiciel), il y a c# et java, si on peut se permettre le GC. Sinon…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)
Pas vraiment. Ou alors j’ai mal compris le nouveau modèle. De ce que je comprends du nouveau modèle GTK+, on s’autorise à casser les APIs tous les 3 ans, on ne maintient plus les anciennes.
La notion de LTS dans Qt est assez différente : elle consiste juste à maintenir les correctifs de sécurité, sans aucune évolution fonctionnelle, pendant 3 ans. Mais la version 5.7, sortie après, de même que la 5.8, garderont la compatibilité source et binaire. Par contre, elles vont pouvoir, par exemple :
* supprimer le support d’anciens compilateurs (la 5.7, typiquement, requiert un compilateur c++11, ce qui n’est pas le cas de la 5.6).
* supprimer le support de certains environnements (windows CE si je ne me trompe pas).
Pour te donner un aperçu de la durée de vie des APIs sous Qt, Qt3 est sorti en 2001, Qt4 en 2005, Qt5 en 2012. Qt6 devrait sortir en 2018. On est donc plutôt à 5 ans entre chaque changement d’API non compatible, sachant que les versions sont maintenues en parallèle (Qt 4.8.7, normalement la dernière de Qt4, est sortie en mai 2015, soit 10 ans après la sortie de Qt4). Il faut bien voir qu’une appli conçue pour Qt4.0.0 fonctionne encore avec Qt4.8.7, sorti 10 ans après.
Si le nouveau modèle GTK+ correspond bien à ça (c’est à dire que la branche 4 sera maintenue bien au-delà de l’apparition de la branche 5), alors c’est une excellente nouvelle.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.
Sincèrement, j’aime beaucoup le bureau gnome, mais par contre, pour développer, je recommande largement plus Qt. J’ai plein de choses à lui reprocher, mais la stabilité des APIs, ça fait toute la différence.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
La fonctionnalité « aperçu » (le truc qui affiche toutes les fenêtres en mosaïque) est infiniment supérieure à la barre des tâches ou au alt-tab pour un nombre de fenêtre compris entre 5 et 25 (estimation à la rache). Au-delà, ça redevient la merde, mais ça commence à faire vraiment beaucoup de fenêtres sur le même bureau.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Certes, mais combien d’utilisateurs pour la version libre ?
Je l’ai fait personnellement, de mettre en place un odoo avec la version libre uniquement (pas de budget pour ça à l’époque, je m’étais dit que quand les affaires iraient mieux, on pourrait basculer sur l’offre payante). C’est une vraie galère, même si les documentations étaient plutôt bonnes.
Et certains points sont vraiment problématiques :
* la procédure de mise à jour. Un ERP qu’on ne peut pas mettre à jour, c’est juste inenvisageable
* la complexité à configurer certaines choses pourtant simples. Par exemple, dans la gestion des notes de frais, j’ai besoin que les prix unitaires soient en millimes (millièmes d’euros, pour les frais kilométriques), tandis que le total doit être en centimes. De même, il faut pouvoir corriger la TVA pour qu’elle corresponde à ce qui est sur le ticket (arrondi supérieur ou inférieur, suivant les cas, par exemple, 9,99€ TTC à 20%-> 8,33€ HT + 1,67€ TVA -> 10€TTC -> fail).
Je suppose qu’il y a des solutions pour ça. Je suppose que quand on prend la version payante, quelqu’un vient vous régler tous ces problèmes. Ce n’est pas vraiment un soucis si c’est assumé. Odoo prend de plus en plus le chemin d’un logiciel propriétaire (je pense que l’existence du fork agressif tryton y contribue aussi), c’est un choix que je peux tout à fait comprendre (il faut bien pouvoir vivre de son activité).
En revanche, quand la présentation continue à le présenter sous forme d’un logiciel libre, pleinement utilisable gratuitement, je tique un peu. J’ai même entendu le terme « arnaque » de la part d’un concurrent (en gros, on vous appâte avec du gratuit, et à la fin on vous fait raquer). C’est un peu fort, mais ce n’est pas anodin d’en arriver là.
Ce qui est certain, c’est qu’aujourd’hui, je ne peux pas recommander Odoo dans sa version libre comme quelque chose de crédible. Dans la version payante, je ne sais pas, mais du coup, la version libre ne fait pas spécialement une bonne pub.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Sauf que ça te coupe de beaucoup de cas d’utilisation. Typiquement, lire une vidéo sur un dossier réseau. Je comprends la logique, mais elle ne correspond pas à mes cas d’utilisation.
Accessoirement, certaines de ces applications sont plus des jouets qu’autre chose. Dans le sens où elle ne fonctionnent pas dans la vraie vie (essaie d’utiliser Music avec une collection conséquente, par exemple…).
J’utilise gnome3, et j’aime beaucoup l’ergonomie du shell, mais les choix faits pour les nouvelles applications me laissent un peu dubitatifs.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
La question, c’est est-ce que le moyen employé (forker gnome 2 et le moderniser) était le meilleur moyen d’arriver au résultat que l’on a aujourd’hui ?
Il y a des arguments pour (par exemple, le fork de nautilus a conservé des fonctionnalités qui ont été enlevées dans les dernières versions), de même que des arguments contre (se taper la transition gtk2 -> gtk3, c’est beaucoup de boulot qui a déjà été fait par ailleurs).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
De là à traiter les autres de « blague de gamins », c’est un peu fort. Le support de la complétion C++ a longtemps été foireux dans visual studio (je n’ai pas testé avec les dernières versions, je suppose que ça s’est amélioré). Côté libre, avec clang on a des choses vraiment très bien (notamment dans qtcreator). Eclipse, il y a des gens qui font des trucs de fou avec. Trop lourd à mon goût, mais si ça plaît à autant de gens (dont certains sous windows), ce n’est pas totalement pour rien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Le choix du terme est loin d’être neutre, le message est malheureusement très clair.
Il m'arrive de faire des rétro-portages entre noyau ayant plus de 5 ans d'écart et c'est loin d'être si mouvant.
C’est possible, mon expérience est un peu différente. Chaque fois que j’ai eu besoin de recompiler un pilote, ça a été la merde parce que des apis avaient changé (mais c’est aussi une expérience biaisée : si je me retrouvais à devoir essayer de recompiler le noyau, c’est vraisemblablement parce que un truc avait été pété — les fois où rien n’est pété sont totalement transparentes pour moi).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Cela arrive à tous les OS un jour, Windows comme Linux, mais dans l'un tu es tributaire du constructeur pour la maintenance, dans l'autre n'importe qui peut intervenir si nécessaire.
Je ne vais réagir qu’à ce point là car il est faux.
Sous windows, les pilotes libres sont ultra-minoritaires mais ils existent.
Sous linux, les pilotes propriétaires sont présents (nvidia principalement, mais aussi amd avec la gamme firepro, et aussi pas mal de matos professionnel hors de prix pour lequel le constructeur fournit un support).
Le fait de ne pas être tributaire du constructeur pour la maintenance dépend uniquement du fait que le pilote soit libre, et les specs du matériel données. Ça n’a rien à voir avec l’os utilisé.
En revanche, le fait que les constructeurs ne fassent pas de pilotes pour linux dépend de plusieurs choses :
- la PDM faible
- l’instabilité des APIs du noyau
- le noyau lui-même, qui globalement te dis « fuck t’es un méchant proprio je veux pas de toi »
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
La licence de ZFS (la CDDL) est libre, reconnue par l’OSI.
Le fait qu’elle soit incompatible avec la GPL (ce qui est la source de la non inclusion de ZFS dans le noyau linux) est plus lié à des détails juridiques techniques qu’autre chose. Mais c’est une licence libre, il n’y a pas de tigre caché sous le tapis.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Le problème est vraiment complexe car si les puriste exagèrent dans le fond ils ont raison de sonner l'alarme car il y a des problèmes de fond possiblement du côté de SystemD.
Tu veux dire, comme pallier l’absence d’API de configuration pour tout un tas de paramètres du système ?
Rien que quelque chose comme « savoir si l’ordinateur est en phase d’éteignage » est une merde infâme et non portable dans le monde UNIX. systemd (qui est bien plus qu’un système d’init) a au moins le mérite d’apporter une solution.
Accessoirement, il est tout à fait possible de fournir des services dbus compatibles avec les APIs systemd pour faire tourner les bureaux qui en ont besoin. Le truc, c’est que bien souvent, la pratique est compliquée car on se rend compte que les services demandés ne sont pas disponibles sur le système (cf l’exemple de savoir si on est en phase d’éteignage / de mise en veille / etc), ou en fait posent des problèmes de sécurité si mal implémentés, etc.
La réalité, c’est que si systemd s’impose, c’est parce qu’il simplifie grandement la vie de ses premiers utilisateurs : les programmeurs. Qui l’imposent à leurs utilisateurs en retour, parce que ça leur simplifie la vie.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
J’ai dû faire renouveler une imprimante car celle-ci ne fonctionnait plus sou Windows 7.
Les pilotes ne sont généralement pas compatibles d’un windows à l’autre. En revanche, les applications prévues pour une version n fonctionnent en général bien sur une version n+1 (les changements ME -> XP et XP vers Vista ayant été les plus problématiques de ce point de vue).
Sous linux, les pilotes ne sont pas compatibles d’un noyau à l’autre, mais comme ils sont open-source, des gens se tapent les adaptations à chaque release (faire et refaire c’est toujours travailler). Et les applications, ça dépend mais en général, une appli compilée pour une distribution n ne fonctionnera plus sur la version n+1 (sauf à conserver les libs de la version n, ce qui se passe lors d’une màj, mais sur une installation fraîche c’est mort).
D’un point de vue de développeur tiers, l’écosystème microsoft est beaucoup plus stable (que ce soit pilote ou applications) que celui de linux (stable au sens de : la prochaine évolution ne va pas m’obliger à redistribuer une nouvelle version).
Le fait que le vieux matos (genre, ton imprimante) soit mieux supporté sous linux que sous windows est dû à une seule chose : les pilotes sont open-source.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
ne parlons pas des nouvelles distros qui réclament une ABI GCC 5 sinon crève,
Oui enfin côté ABI c++, microsoft pète la compatibilité à chaque release de visual studio. Par contre, ils fournissent le moyen d’avoir en parallèle plusieurs ABIs distinctes (les fameux « visual c++ redistributable »). De toute façon, g++ n’avait pas d’autre choix que de péter son ABI (le standard ayant évolué, celle-ci n’était plus conforme, le COW sur std::string est un exemple mais je crois que ce n’est pas le seul).
Après, tu peux effectivement reprocher aux distributions de ne plus fournir la libc++ avec l’ancienne ABI. C’est d’autant plus regrettable que techniquement absolument rien ne l’empêche. C’est aussi pour cette raison que les entreprises paient pour des red-hat : le support 10 ans.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Ah ben oui comme le passage reussi de Qt4 a Qt5… Enfin je dis ca je dis rien. Je vais juste acheter un paquet de popcorn.
J’ai l’impression que ta phrase est ironique, alors du coup, tu reproches quoi au passage Qt4 -> Qt5 ?
Parce que pour avoir fait la migration sur un projet assez conséquent (closed-source, à titre pro), ça se passe assez bien. Et ce alors qu’on utilisait entre autres du qtquick1 (le truc déprécié), et le système de plugin (qui fait partie des trucs qui ont changé de manière incompatible).
Et garder une base de code compilable à la fois avec Qt4 et Qt5 (nécessaire pendant la transition) n’a pas demandé des efforts insurmontables, loin de là.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Même si je ne suis pas certain de bien comprendre la nuance qui rend le php or de la GPL.
En fait la différence vient du fait que l’application n’a plus besoin d’être distribuée. Si elle fonctionne sur un serveur qui t’appartient, le fait de la mettre à disposition en tant que service n’est pas à proprement parler une distribution de l’application.
Du coup, les contraintes de la GPL, qui ne s’appliquent que lors de la distribution d’une application, n’ont pas d’effet. La licence AGPL a été conçue spécifiquement pour ce cas.
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é à 2.
C’est avec ce genre de remarques que tu décrédibilises totalement ton propos. S’il y a effectivement du code qui peut être cassé à chaque évolution du langage, on est très loin de ce que tu décris et de la fréquence que tu sembles indiquer.
Peut-être justement parce que :
oui. Et qu’en plus, on veut pouvoir compiler la même base de code avec le dernier compilateur moderne et aussi la vieille antiquité d’il y a 10 ans qui compile pour notre microcontrôleur spécifique, de préférence sans avoir à faire des #ifdef dans tous les sens.
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é à 2.
Peu de langages ont un modèle de compilation séparé (puisqu’on parle des inclusions).
Je crois que c’était une bonne idée en 1970, quand C a été créé, puisque ça permettait de compiler des programmes beaucoup plus gros que la mémoire dont on disposait à l’époque. Aujourd’hui, C++ doit vivre avec cet héritage (remettre en cause ce modèle n’est pas à l’ordre du jour, ça casse trop de chose). Mais il y a des évolutions, les propositions sur les modules vont dans ce sens.
Du coup, oui, d’autres langages font autrement, plus simplement, mais c’est aussi parce qu’ils ont des contraintes différentes :). Quand on parle du poids de l’historique, oui, c’est clair que C++ a un lourd passé.
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é à 4.
C’est quelque chose du genre, que tu cherches ?
main fait partie de l’API C. Passer un
std::vector<std::string>impliquerait :* de forcer à compiler avec la STL (donc support des exceptions, rtti, exécutable plus gros, etc).
* un overhead au démarrage lié à la construction de ce vecteur à partir de l’API C.
Ce serait donc contraire à la philosophie C++ de ne payer que pour ce qu’on utilise.
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.
Tu peux aussi remplacer C++ par développement en général. La conception logicielle, ce n’est pas simple, les APIs pourries ou les fautes de conception il y en a dans tous les langages.
C’est aussi pour ça que C++ évolue lentement : pour se prémunir d’erreurs dans le standard (c’est boost qui essuie les plâtres).
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é à 2.
Les deux. L’usage d’une fonction clone est problématique aussi (qu’est censé faire Derived::clone(Base const& b) si on lui donne un Base& qui est de type Derived2 ? Un assert ? pas terrible…).
Copier la partie Base d’un Derived un autre Base peut avoir du sens, en revanche, copier dans un Derived une partie Base en a beaucoup moins. Et je ne sais pas autoriser l’un sans autoriser l’autre.
Il y a des cas où on en arrive à faire ça (une hiérarchie de classes copiables), mais en général par soucis de simplificité (comprendre, flemme :) ) et c’est source de problèmes. Ce n’est pas quelque chose de conceptuellement très correct.
Ce n’est pas du tout à ça que je pensais. Je ne vois pas trop comment faire un exemple simple, mais l’idée, c’est plutôt de passer par un mécanisme de copie non-standard (appel de fonction statique, pex) pour se prémunir d’un usage imprévu / susceptible de poser des problèmes (à la place d’une copie implicite potentiellement problématique, tu as une erreur de compilation, c’est beaucoup mieux).
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é à 2.
Je viens de réaliser un truc en relisant :
Si ta classe fait partie d’une hiérarchie polymorphe, elle ne devrait pas être copiable. Sinon, tu t’assures de faire de la merde et des bugs à un moment où un autre.
Si tu pars sur une hiérarchie non polymorphe (typiquement, avec CRTP), il est possible de factoriser le tout (en délégant la copie de la partie concernée de ta structure).
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é à 0.
Souvent, les gens qui critiquent n’ont qu’une connaissance partielle du problème, et ont négligé certains aspects.
Et sérieusement, je ne pense pas que ce soit spécifique à C++, dans tous les langages des gens critiquent les choix qui ont été faits.
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é à 0.
Je suis dubitatif sur ton deuxième exemple. g++ le compile sans broncher, mais je pense qu’il a tort. Je n’ai pas de visual sous la main pour vérifier, mais je pense que c’est clang qui a raison de le refuser (et ce indépendamment de la version de c++, je ne vois pas ce qui aurait changé dans la norme qui provoquerait un changement de comportement).
Si tu pars sur des extensions / tolérances du compilateur, tu ne peux pas reprocher au langage lui-même qu’un autre compilateur n’ait pas les mêmes tolérances ;).
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é à 3.
As-tu des exemples de langage dans lesquels ce que tu fais manuellement est fait automatiquement ? J’ai un peu de mal à suivre où tu veux en venir.
Euh, non, le découpage en petites unités fonctionnelles est très présent en C++. C’est ce que tout le monde recommande aujourd’hui (loi de Déméter, à l’esprit de tous les devs c++ compétents). C’est parce qu’il y a deux fichiers que c’est « trop compliqué de créer un classe » ? C’est un problème d’environnement de dev dans ce cas, pas de langage.
Euh, non. Tu peux très bien mettre un type non default constructible dans un unique_ptr. Depuis c++11, on peut même dans un vector, suivant comment on l’utilise (tant qu’on n’utilise pas resize). En plus, comme on peut le defaulter quand ça a du sens, ce n’est franchement pas la mer à boire.
À mettre en balance avec le fait que C++ offre un const vérifié statiquement. Bien utilisé, c’est beaucoup de bugs ou de prises de tête en moins.
Je ne suis jamais allé sur freenode, donc je ne peux pas dire. En revanche, la communauté française est très ouverte.
Pour le reste de tes critiques, je suis assez d’accord (sauf le pattern matching dont je trouve qu’à part l’effet trocool, ça ne sert pas à grand chose). Mais la question qui est toujours en suspens, c’est quelle alternative à c++ ? Pour du dev jetable, plein. Pour un truc censé durer 10 ans (c’est pas si long que ça dans le domaine du développement logiciel), il y a c# et java, si on peut se permettre le GC. Sinon…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
Pas vraiment. Ou alors j’ai mal compris le nouveau modèle. De ce que je comprends du nouveau modèle GTK+, on s’autorise à casser les APIs tous les 3 ans, on ne maintient plus les anciennes.
La notion de LTS dans Qt est assez différente : elle consiste juste à maintenir les correctifs de sécurité, sans aucune évolution fonctionnelle, pendant 3 ans. Mais la version 5.7, sortie après, de même que la 5.8, garderont la compatibilité source et binaire. Par contre, elles vont pouvoir, par exemple :
* supprimer le support d’anciens compilateurs (la 5.7, typiquement, requiert un compilateur c++11, ce qui n’est pas le cas de la 5.6).
* supprimer le support de certains environnements (windows CE si je ne me trompe pas).
Pour te donner un aperçu de la durée de vie des APIs sous Qt, Qt3 est sorti en 2001, Qt4 en 2005, Qt5 en 2012. Qt6 devrait sortir en 2018. On est donc plutôt à 5 ans entre chaque changement d’API non compatible, sachant que les versions sont maintenues en parallèle (Qt 4.8.7, normalement la dernière de Qt4, est sortie en mai 2015, soit 10 ans après la sortie de Qt4). Il faut bien voir qu’une appli conçue pour Qt4.0.0 fonctionne encore avec Qt4.8.7, sorti 10 ans après.
Si le nouveau modèle GTK+ correspond bien à ça (c’est à dire que la branche 4 sera maintenue bien au-delà de l’apparition de la branche 5), alors c’est une excellente nouvelle.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 6.
Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.
Sincèrement, j’aime beaucoup le bureau gnome, mais par contre, pour développer, je recommande largement plus Qt. J’ai plein de choses à lui reprocher, mais la stabilité des APIs, ça fait toute la différence.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Gestionnaire de fenêtre des années 90
Posté par whity . En réponse à la dépêche Sortie de MATE 1.16. Évalué à 1.
La fonctionnalité « aperçu » (le truc qui affiche toutes les fenêtres en mosaïque) est infiniment supérieure à la barre des tâches ou au alt-tab pour un nombre de fenêtre compris entre 5 et 25 (estimation à la rache). Au-delà, ça redevient la merde, mais ça commence à faire vraiment beaucoup de fenêtres sur le même bureau.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Odoo Studio?
Posté par whity . En réponse à la dépêche Odoo Experience: lancement de Odoo 10. Évalué à 7.
Certes, mais combien d’utilisateurs pour la version libre ?
Je l’ai fait personnellement, de mettre en place un odoo avec la version libre uniquement (pas de budget pour ça à l’époque, je m’étais dit que quand les affaires iraient mieux, on pourrait basculer sur l’offre payante). C’est une vraie galère, même si les documentations étaient plutôt bonnes.
Et certains points sont vraiment problématiques :
* la procédure de mise à jour. Un ERP qu’on ne peut pas mettre à jour, c’est juste inenvisageable
* la complexité à configurer certaines choses pourtant simples. Par exemple, dans la gestion des notes de frais, j’ai besoin que les prix unitaires soient en millimes (millièmes d’euros, pour les frais kilométriques), tandis que le total doit être en centimes. De même, il faut pouvoir corriger la TVA pour qu’elle corresponde à ce qui est sur le ticket (arrondi supérieur ou inférieur, suivant les cas, par exemple, 9,99€ TTC à 20%-> 8,33€ HT + 1,67€ TVA -> 10€TTC -> fail).
Je suppose qu’il y a des solutions pour ça. Je suppose que quand on prend la version payante, quelqu’un vient vous régler tous ces problèmes. Ce n’est pas vraiment un soucis si c’est assumé. Odoo prend de plus en plus le chemin d’un logiciel propriétaire (je pense que l’existence du fork agressif tryton y contribue aussi), c’est un choix que je peux tout à fait comprendre (il faut bien pouvoir vivre de son activité).
En revanche, quand la présentation continue à le présenter sous forme d’un logiciel libre, pleinement utilisable gratuitement, je tique un peu. J’ai même entendu le terme « arnaque » de la part d’un concurrent (en gros, on vous appâte avec du gratuit, et à la fin on vous fait raquer). C’est un peu fort, mais ce n’est pas anodin d’en arriver là.
Ce qui est certain, c’est qu’aujourd’hui, je ne peux pas recommander Odoo dans sa version libre comme quelque chose de crédible. Dans la version payante, je ne sais pas, mais du coup, la version libre ne fait pas spécialement une bonne pub.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un avis
Posté par whity . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
Sauf que ça te coupe de beaucoup de cas d’utilisation. Typiquement, lire une vidéo sur un dossier réseau. Je comprends la logique, mais elle ne correspond pas à mes cas d’utilisation.
Accessoirement, certaines de ces applications sont plus des jouets qu’autre chose. Dans le sens où elle ne fonctionnent pas dans la vraie vie (essaie d’utiliser Music avec une collection conséquente, par exemple…).
J’utilise gnome3, et j’aime beaucoup l’ergonomie du shell, mais les choix faits pour les nouvelles applications me laissent un peu dubitatifs.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Intérêt de MATE ?
Posté par whity . En réponse à la dépêche Sortie de MATE 1.16. Évalué à 10.
Tu n’as pas compris la question.
La question, c’est est-ce que le moyen employé (forker gnome 2 et le moderniser) était le meilleur moyen d’arriver au résultat que l’on a aujourd’hui ?
Il y a des arguments pour (par exemple, le fork de nautilus a conservé des fonctionnalités qui ont été enlevées dans les dernières versions), de même que des arguments contre (se taper la transition gtk2 -> gtk3, c’est beaucoup de boulot qui a déjà été fait par ailleurs).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: HS
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 4.
VS est un très bon produit.
De là à traiter les autres de « blague de gamins », c’est un peu fort. Le support de la complétion C++ a longtemps été foireux dans visual studio (je n’ai pas testé avec les dernières versions, je suppose que ça s’est amélioré). Côté libre, avec clang on a des choses vraiment très bien (notamment dans qtcreator). Eclipse, il y a des gens qui font des trucs de fou avec. Trop lourd à mon goût, mais si ça plaît à autant de gens (dont certains sous windows), ce n’est pas totalement pour rien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 2.
wl: module license 'MIXED/Proprietary' taints kernel.
taint = gâter, dénaturer, entacher, vicier, souiller…
Le choix du terme est loin d’être neutre, le message est malheureusement très clair.
C’est possible, mon expérience est un peu différente. Chaque fois que j’ai eu besoin de recompiler un pilote, ça a été la merde parce que des apis avaient changé (mais c’est aussi une expérience biaisée : si je me retrouvais à devoir essayer de recompiler le noyau, c’est vraisemblablement parce que un truc avait été pété — les fois où rien n’est pété sont totalement transparentes pour moi).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 4.
Je ne vais réagir qu’à ce point là car il est faux.
Sous windows, les pilotes libres sont ultra-minoritaires mais ils existent.
Sous linux, les pilotes propriétaires sont présents (nvidia principalement, mais aussi amd avec la gamme firepro, et aussi pas mal de matos professionnel hors de prix pour lequel le constructeur fournit un support).
Le fait de ne pas être tributaire du constructeur pour la maintenance dépend uniquement du fait que le pilote soit libre, et les specs du matériel données. Ça n’a rien à voir avec l’os utilisé.
En revanche, le fait que les constructeurs ne fassent pas de pilotes pour linux dépend de plusieurs choses :
- la PDM faible
- l’instabilité des APIs du noyau
- le noyau lui-même, qui globalement te dis « fuck t’es un méchant proprio je veux pas de toi »
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Et ZFS
Posté par whity . En réponse à la dépêche L’après PC-BSD : TrueOS. Évalué à 5.
La licence de ZFS (la CDDL) est libre, reconnue par l’OSI.
Le fait qu’elle soit incompatible avec la GPL (ce qui est la source de la non inclusion de ZFS dans le noyau linux) est plus lié à des détails juridiques techniques qu’autre chose. Mais c’est une licence libre, il n’y a pas de tigre caché sous le tapis.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: SystemD la cause de la discorde...
Posté par whity . En réponse à la dépêche L’après PC-BSD : TrueOS. Évalué à 10.
zut, c’est lundi, pas vendredi…
Tu veux dire, comme pallier l’absence d’API de configuration pour tout un tas de paramètres du système ?
Rien que quelque chose comme « savoir si l’ordinateur est en phase d’éteignage » est une merde infâme et non portable dans le monde UNIX. systemd (qui est bien plus qu’un système d’init) a au moins le mérite d’apporter une solution.
Accessoirement, il est tout à fait possible de fournir des services dbus compatibles avec les APIs systemd pour faire tourner les bureaux qui en ont besoin. Le truc, c’est que bien souvent, la pratique est compliquée car on se rend compte que les services demandés ne sont pas disponibles sur le système (cf l’exemple de savoir si on est en phase d’éteignage / de mise en veille / etc), ou en fait posent des problèmes de sécurité si mal implémentés, etc.
La réalité, c’est que si systemd s’impose, c’est parce qu’il simplifie grandement la vie de ses premiers utilisateurs : les programmeurs. Qui l’imposent à leurs utilisateurs en retour, parce que ça leur simplifie la vie.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 5.
Les pilotes ne sont généralement pas compatibles d’un windows à l’autre. En revanche, les applications prévues pour une version n fonctionnent en général bien sur une version n+1 (les changements ME -> XP et XP vers Vista ayant été les plus problématiques de ce point de vue).
Sous linux, les pilotes ne sont pas compatibles d’un noyau à l’autre, mais comme ils sont open-source, des gens se tapent les adaptations à chaque release (faire et refaire c’est toujours travailler). Et les applications, ça dépend mais en général, une appli compilée pour une distribution n ne fonctionnera plus sur la version n+1 (sauf à conserver les libs de la version n, ce qui se passe lors d’une màj, mais sur une installation fraîche c’est mort).
D’un point de vue de développeur tiers, l’écosystème microsoft est beaucoup plus stable (que ce soit pilote ou applications) que celui de linux (stable au sens de : la prochaine évolution ne va pas m’obliger à redistribuer une nouvelle version).
Le fait que le vieux matos (genre, ton imprimante) soit mieux supporté sous linux que sous windows est dû à une seule chose : les pilotes sont open-source.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 5.
Oui enfin côté ABI c++, microsoft pète la compatibilité à chaque release de visual studio. Par contre, ils fournissent le moyen d’avoir en parallèle plusieurs ABIs distinctes (les fameux « visual c++ redistributable »). De toute façon, g++ n’avait pas d’autre choix que de péter son ABI (le standard ayant évolué, celle-ci n’était plus conforme, le COW sur std::string est un exemple mais je crois que ce n’est pas le seul).
Après, tu peux effectivement reprocher aux distributions de ne plus fournir la libc++ avec l’ancienne ABI. C’est d’autant plus regrettable que techniquement absolument rien ne l’empêche. C’est aussi pour cette raison que les entreprises paient pour des red-hat : le support 10 ans.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: GTK+4
Posté par whity . En réponse à la dépêche Firefox 49 en chansons. Évalué à 2.
J’ai l’impression que ta phrase est ironique, alors du coup, tu reproches quoi au passage Qt4 -> Qt5 ?
Parce que pour avoir fait la migration sur un projet assez conséquent (closed-source, à titre pro), ça se passe assez bien. Et ce alors qu’on utilisait entre autres du qtquick1 (le truc déprécié), et le système de plugin (qui fait partie des trucs qui ont changé de manière incompatible).
Et garder une base de code compilable à la fois avec Qt4 et Qt5 (nécessaire pendant la transition) n’a pas demandé des efforts insurmontables, loin de là.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Licence GPL ?
Posté par whity . En réponse à la dépêche L'Air du Bois devient Open Source !. Évalué à 1.
En fait la différence vient du fait que l’application n’a plus besoin d’être distribuée. Si elle fonctionne sur un serveur qui t’appartient, le fait de la mettre à disposition en tant que service n’est pas à proprement parler une distribution de l’application.
Du coup, les contraintes de la GPL, qui ne s’appliquent que lors de la distribution d’une application, n’ont pas d’effet. La licence AGPL a été conçue spécifiquement pour ce cas.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Licence GPL ?
Posté par whity . En réponse à la dépêche L'Air du Bois devient Open Source !. Évalué à 4.
C’est pour ça qu’il parlait de l’AGPL, qui est spécifiquement conçue pour ce cas.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0