Gof a écrit 2224 commentaires

Tu dis n'importe quoi.

Biensûr qu'on peux trouver des effet négatifs, mais il y a aussi des effet négatif dans le chocolat et le coca-cola. Ça veux pas dire qu'on dois les interdires. Il faut juste consommer de manière responsable et avec modération.

J'ai l'impression que tu prends les effets psychotropes pour des effets diaboliques.

Mais ces effets sont à cours termes.

La prise de drogue récréative occasionnellement et dans de bonnes conditions est sans danger. Pourquoi veux tu interdire ça ?

Je vie dans un pays ou je rencontre un Francais tous les quinze jours.

Bha c'est pareil pour moi. Donc je trouve ta critique assez déplacée.

J'écris en français sur linuxfr, et j'essaye de corriger toute mes faute pour qu'il y ait le moins possible de mots souligné en rouge dans la prévisualisation. (Je sais que je laisse quelques (beaucoup?) de fautes).

Ce serait bien aussi d'avoir des brouillons pour les commentaire.

Par exemple, si je suis en train d'écrire un long commentaire, je le prévisualise, je le relis et m'apprête à corriger les dernières fautes, mais ma conection saute, ou il y a un crash, ou je ferme l'onglet par mégarde. Et le commentaire est perdu.

L'idée serait de mettre un lien dans la colonne de droite vers le dernier commentaire prévisualisé, mais non posté.

Le nombre de symbole dans les libs C++ étant juste dantesque, tu te retrouves avec des temps de demarrage hallucinant et non ameliorable.

Il est vrai que dès qu'une classe a une fonction virtuelle, on se retrouve avec les vtable et les symboles RTTI (Runtime Type Information)
C'est effectivement un problème.

Petits rappel théorique pour ceux qui sont intéressé: (cedric, tu peux passer ce paragraphe)
Quand on a au moins une fonction virtuel dans une classe, le compilateur crée une vtable (une seule par classe dans tout le programme, pas une par instance de chaque classes). C'est une table qui contient un pointeur vers chaque fonction virtuelle, et aussi des information RTTI.
RTTI permet de faire fonctionner les exceptions, les dynamic_cast ou typeid
Le problème c'est que ces tables de pointeur de fonction doivent être "rellocated" au moment ou la bibliothèque est chargée en mémoire. En effet, les bibliothèques sont en général compilée en "Position Indépendent Code". Ça veux dire que le code est chargée a une position différente en mémoire à chaque fois, donc les pointeurs de fonction ont toujours une adresse différente. Dans le code en lui même, la plupart des référence à d'autre partie du code sont fait de manière relative. Mais les tables virtuelles doivent être en absolue. Donc les bibliothèques contiennent une "table de rellocations" qui donne les instructions au loader pour réécrire toute ces tables au lancement.
Un autre problème vient du fait que les symboles doivent en général doivent être exportés. Et comme ELF permet de remplacer des symboles (avec LD_PRELOAD), le loader doit retrouver chaque symbole par son nom dans les tables de symboles

Un des principes derrière C++ est « zéro overhead ». Mais cette règle est un peu violée par le RTTI.

Une solution est de faire compiler -fno-rtti. Qt n'utilise pas RTTI dans son propre code (pas d'exceptions, pas de dynamic_cast). Mais par défaut il est compilé avec parce que les utilisateurs veulent pouvoir utiliser ces fonctionnalités.
Mais ceux qui utilise Qt sur embarqué peuvent désactiver RTTI.

Par contre, le problème est un peu pareil en C dans une bibliothèque comme GTK, qui réécrit des « table virtuelles » a la main.

D'apres ma memoire, l'ABI du C++ a ete casse avec gcc 4.2 en 2007, donc ca peut pas faire 8 ans ou alors tu m'ecris du futur.

Ah oui c'est vrai.

(Mais on parlais ici d'API, pas d'ABI)

Il n'a pas lu le 1ᵉʳ journal de notre ami sur les conseils aux libriste : celui qui rappelle que l'usage des accents en français n'est pas facultatif.

Et moi je suis pas d'accord avec toi:

Toll N° 1: C vs. C++

On le voit souvent ce troll. Mais le C++ est pour moi mieux que le C.
C'est un langage d'aussi bas niveau que le C, qui offre les mêmes possibilité de performenc et d'être « près de la machine » mais tout an étant beaucoup plus expressif. On est donc beaucoup plus productif en C++ qu'en C.
Et merci a des toolkits tel que Qt d'offrir une API utilisable, c'est vraiment un bonheur.

si on veut fournir une API/ABI stable au cour du temps, on utilise le C

Oui, c'est un peu plus compliqué de garder la compatibilité binaire au cour du temps. On en a déjà discuté. Mais est-ce que c'est un goal en soi? pas vraiment. D'ailleur, même les bibliothèques en C cassent souvant la compatibilité binaire (openSSL, libpng, gtk, …)

LLVM l'a bien compris, seul l'api C sera stable.

J'ai fait un projet utilisant LLVM, et j'ai utilisé l'API C++ et j'en suis bien contant.
Et une autre équipe avait essayé de faire un truc similaire avec l'API C, ils ont déjà passé pas mal de temps à re-wrapper l'api C dans du C++, et au final leur truc marchait mal.

Quand on a envie d'utiliser le C++ pour être productif, on aime utiliser des API en C++. On aime pas utiliser le C.

C++ a aussi un coup d'utilisation CPU et memoire superieur a du C,

Hahaha, mais bien sur, et C++ tues aussi plus de bébés chat que le C. Et le C permet de meilleur performences sexuelles. C'est prouvé :-)

GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme

Euh.. GTK aussi change son API. GTK2 à duré 9 ans. et Qt4 8 ans.

Les applications utilisant Gecko distribuent leur propre copie de Gecko

De même que les applications proprios faites avec Qt sont souvent fournies avec une copie de Qt.

Mais quel est l'avantage de la compatibilité binaire? Tu peux toujours faire tourner tes vielles applis avec la version précédente du toolkit. Et quand tu veux des améliorations, bah de toute façon tu recompile.

Et c'est un peu facile de comparer les site web de 1998, qui contenaient juste du texte statique avec quelques images (au mieux des .gif animés) avec une application, beaucoup plus complexe.
D'ailleurs, si je puis me permettre, beaucoup des sites du début des années 2000 étaient "optimisé IE" et n'ont jamais vraiment fonctionné avec ton Firefox.

Et en C++ il y a des namespaces.

Ça tombe bien. On peut installer Qt3 et Qt4 en même temps.

Je vais un peu défendre Qt, parce que il me semble que tu confonds tout:

Ce toolkit a très tôt enflé pour devenir un cadre complet de développement d'applications,

Bah oui, et c'est un avantage. C'est ce que Qt est, une biblitohèque unifiée pour faire des application (GUI mais pas seulement) en C++ et cross platforme.

Et d'ailleur, GTK+ fait juste partie d'un groupe de bibliothèques qui fait exactement pareil (et ça commence avec glib).

allant jusqu'à remplacer les classes-conteneurs de la libstdc++

À l'époque, ils avaient leurs raison. Il se voulaient crossplatforme alors que la libstdc++ n'était pas complète. Rapellons que Qt existe depuis 1991, C'était longtemps avant la norme C++98.

Ensuite les conteneurs de Qt ont leurs propre raison d'être, mais je ne rentre pas dans les détails ici.

Qt n'a pas compris non plus l'importance de préserver la compatibilité sur le long terme.

Ok, Qt4 a cassé la compatibilité avec Qt3. Mais c'était il y a 7 ans.
Qt5 est quasiment source compatible avec Qt4.
Et c'est pour le mieux. L'API de Qt4 est un énorme progrès par rapport avec son petit frère Qt3.

Résultat, le passage de Qt 3 à Qt 4 a gravement endommagé le projet KDE

Tu mélange tout. KDE était plus que un simple portage à Qt4. Beaucoup de chose ont été réécrite aussi juste parce que ils en avaient l'occasion. Plasma, Akonadi, Nepomuk, Decibel et j'en passe.
C'est je pense ça qui a causé des problème à KDE. Car les projets qui se sont contanté d'être porté tout bêtement de Qt3 à Qt4 n'ont pas eu ce genre de problèmes.

C'est comme si je disait que les gens n'aiment pas le nouveau Gnome Shell à cause de GTK3

Amarok ont préféré passer leur temps à le porter à Qt4 et à toutes sortes de bibliothèques de KDE 4

Non, ils ont aussi passé beaucoup de temps à repenser completement l'interface.
Porter à Qt4 n'est pas si compliqué. C'est ce qu'a fait Celementine, le fork d'amarok basé sur Amarok 1.4.

C'est bien ça.
Le thème GTK utilise GTK lui même pour le rendu.
Et quand on change de thème GTK, les applications Qt changent en même temps.

Bientôt on ne dira plus brononiser, mais jobbsiser

Moi mon coup de gueule c'est que les dev Linux vont retirer le support de x86. Comme le confirme https://lkml.org/lkml/2012/8/23/176

(Source, pour ceux qui auraient oublié: https://linuxfr.org/users/moi1392/journaux/pierre-tramo-2-0 . Bref, ne pas tirer de conclusion hatives en lisant des mailing lists.)

Ça ressemble fort à ce que Qt Creator peut faire quand on travail avec du QML

Justement, le C++ est parfait pour ça. Vu que c'est statiquement typé, un bon IDE peut savoir beaucoup de chose à propos de chaque fonction ou type.
Ça permet notamment d'afficher plein d'informations intéressantes, comme la documentation doxygen par exemple dirrectment dans le tooltip.
Et aussi faire de l'autocompletion sémantique qui donne toutes les information.

C'est pour ça que j'adore KDevelop.

(J'aime tellement KDevelop que j'ai même fait une version online pour lire le code: http://woboq.com/blog/codebrowser-introduction.html )

À partir du moment ou l'attaqueur à la capacité d'écouter le traffic, ça doit pas être difficile de prendre la même IP.

Mais il est fréquent de faire plusieurs requête en même temps légitimement. Par exemple télécharger toutes les images d'une page, ou faire plusieurs requête AJAX en parallèles.
Ça va pas être facile de supporter ça si l'identifient de session change tout le temps.

Le problème c'est que une seule adresse est utilisée lors de la visite du site linuxfr.org.
Donc si IPv6 est utilisé, c'est pas possible de connaitre l'adresse IPV4 (a moins que le clic se fasse via un autre nom d'hôte (sondage.linuxfr.org par exemple) disponible uniquement en ipv4. (avec tous problèmes que ça cause))

Pour le javascript: http://wtfjs.com/

Comme le disait Bjarne Stroustrup:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Personnellement j'ai bien aimé ce film de lui: http://vimeo.com/32146368/
Une mise en abîme assez amusante.

autant ne jamais gérer les problèmes d'allocation et laisser le fichier etre corrompu dans tous les cas ?

Tu m'a mal compris.

Je voulais dire que vu qu'il est toujours possible que ça crash, il faut faire en sorte que les conséquences soient minimes en cas de crash. Merci autosave.

Et que vu que ce n'est pas si grave si ça crash, alors autant laisser crasher dans le cas de OOM.
En effet, gérer proprement toutes les situation de OOM est un travail énorme.

les softs qui n'ont pas d'auto-save

Je préfère des soft qui ont l'auto-save et pas de gestion d'OOM que l'inverse

le soft pourrait planter au milieu de l'auto-save

C'est pourquoi l'enregistrement doit se faire de façon atomique, pour que la sauvegarde précédente soit toujours là.
Pareil pour la configuration.