Gof a écrit 2224 commentaires

Le "problème" de c++, c'est les appels à la création de mémoire caché à l'utilisateur (selon Linus).

Ah c'est ça le problème ? De quels appels caché parle t on ?

---

Personnellement je pense que C++ est probablement le meilleur langage pour écrire un OS.
Mature et performant, quoi demander de mieux ?

(On me souffle dans l'oreillette plus facile et plus sûr, mais on peut pas tout avoir. :-) (et C n'est pas plus facile ou plus sûr. Plutôt l'inverse) )

Ah merde, je me suis planté, je voulais dire qu'elles n'ont plus de /bin.
Et quand je dis une distribution bien comme il faut c'est un peu pour troller (juste un peu).

Les distributions bien comme il faut et qui sont passée à systemd n'ont plus de /usr/bin. (Comme par exemple sur l'exelentisime Archlinux)

$ which ln
/usr/bin/ln

Que NaCl c'est déjà une connerie, du même style que ActiveX.

Euh, il me semble que NaCl c'est dans une sandbox, alors que ActiveX ne l'était pas.
Aussi, NaCl est plus cross-platforme, puisqu'il a une API et ABI bien définie. C'est restreint à certains processeurs, mais indépendant de l'OS/Navigateur.

rm -rf /bin c’est une demi-journée perdue pour tout réinstaller et tout reconfigurer

Il te faut une demi journée pour faite ln -s /usr/bin /bin ? :-)

Il n'y a pas vraiment de corrélation entre le temps passé en tête d'affiche et le nombre de commentaires.

Tu sors ça d'où ? Juste à cause de ce journal ? C'est pas très scientifique.
Pourrais tu calculer le coefficient de corrélation? https://fr.wikipedia.org/wiki/Corrélation_(statistiques)

Peut être même que plus un journal est longtemps en tête d'affiche, moins il a de commentaires (par exemple parce qu'il a été posté à un moment où il n'y a pas d'activité sur le site)

Attention, le fait que tu observe que les journaux postés le mercredi on en moyenne plus de commentaire ne veux pas dire que en postant ton journal un mercredi, tu auras plus de commentaires que en postant ton journal un autre jour.

(Par exemple, cela signifie peut-être simplement que ceux qui ont un tallant particulier pour poster des journaux qui encourragent les commentaires préfèrent poster le mercredi)

Je peux me tromper, mais ça devrais plutôt être:
« J'ai l'age requis dans le pays qui héberge le service pour … »
non ?
(L'hébergeur/fournisseur de service n'est soumis qu'au lois de son pays)

Au temps pour moi.

Quelques pistes:

• Pour pouvoir taper la phrase de passe de TrueCrypt
• X se fait vieux et les compositeurs Wayland (ou mir) utilisent les même pilotes que la console.
• Quand on a un problème et qu'il faut passer en mode console, alors c'est pratique d'utiliser le clavier auquel on est habitué.

J'aurais l'air malin avec mon clavier PS/2 et mon layout bépo (oui je n'arrive à écrire en bépo que sur mon typematrix) !

C'est une fausse excuse.
(Perso j'ai qu'un seul clavier)

On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.

Pas vraiment. J'ai regardé vite fait la documentation de BMessage et ça ressemble plutôt au système d'événement de Qt.

Dans Qt, chaque QObject est associé à un thread. et on peux poster des messages a un object:

QEvent *event = new MyMessageEvent("hello");
QApplication::postEvent(myObject,  event);

Cela va poster un message qui va être reçu par un autre object: (QObject::event est appelé dans le thread associé à cet object)

bool MyObject::event(QEvent *e) /* override */
{
  if (e->type() == MyMessageEvent::Type) {
      return actOnMessage(static_cast<MyMessage*>(e)->message());
  }
  return BaseClass::event(e);
}

Et ça ressemble fort à ce que j'ai pu voir dans la documentation de Haiku.

Les signaux est slots c'est du « sucre syntaxique » pour des callbacks. Moins de boilerplate, et plus facile à utiliser. C'est censé produire du code plus lisible et moins spaghetti que de la programmation événementielle.
(Ça utilise des événement en interne)

Pas mal.
Mais un site mal intentionné pourrait avoir du javascript qui est notifié à chaque changement du champ password. Et qui envoi via ajax le contenu à un server. Et pourrait donc récupérer la clé maître.

C'était déjà le cas avec Qt 4.0.
Et depuis Qt 5 les widgets sont séparés pour ne pas devoir en dépendre quand on utilise QML

Il y a eu de grosse amélioration dans Qt5 en ce qui concerne l'accessibilité. C' est peut-être pas encore parfait, mais c'est mieux qu'avant

Biensûr que les ondes éléctromagnétiques sont dangereuses !

Restez exposé au soleil en plein été sans crème solaire pour vous en rendre compte. Ou demandez à Marie Curie ce qu'il en est de l'exposition aux rayons X.

Ah bon? On me souffle dans l'oreillette que ça dépends de la fréquence et de la puissance. :-)

Le virus du SIDA fait partie de la nature donc s'y opposer, c'est s'opposer à la nature. Hitler était un homme, un homme c'est la nature, donc s'opposer à Hitler c'était s'opposer à la nature.

Oui. Il n'a pas dit que « s'opposer à la nature » est une bonne ou mauvaise chose.

C'est toi qui commet un raisonnement fallacieux: Appeal_to_nature
Raisonnement qui consiste à penser que si quelque chose est naturel alors c'est bien. Ou la réciproque: si quelque chose n'est pas naturel, alors c'est mal.

comme le futur 'move' du C++

Pourquoi tu dis « futur » ? C'est déjà dans C++11.

Les concepts ne font pas partie de C++14. Mais ils seront peut être dans le standard suivant (C++17?)

GCC n'implémente pas encore cette fonctionalité. Mais c'est déjà en dévelopment dans une branche séparée.

Et dire qu'une simple arrestation dans des activités illégales peut faire chuter la valeur du Bitcoin de 10%

SilkRoad a je crois beaucoup aider pour faire connaître le bitcoin en 2011 à une population non geek.
Je ne suis pas étonné que sa fermeture ait un effet sur le cours du bitcoin.

Cacher des truc dans des macros, utiliser = à la place de ==, utiliser une mauvaise arithmétique de pointeur pour modifier un autre membre dans une structure, mettre ??/ à la fin d'un commentaire d'une ligne. Bref, tout les trucs classique d'obscuration du code.

La surcharge d'opérateur c'est pas bien méchant. Il n'y a pas de différence entre ces deux codes:

mystruct3 = mystruct1 + mystruct2

et

mystruct3 = mystruct_add(mystruct1, mystruct2);

Appart le fait que l'un est plus lisible, tu peux quand même mettre n'importe quoi dans chacune des fonction donc tu dois savoir ce qu'elle font. En général un bon IDE te met un tooltip par dessus l'opérateur et te permet de sauter directement à son implémentation.

Et quand tu implémente un opérateur qui ne fait pas ce qu'il est sensé faire, c'est louche. Il faut avoir de vachement bonne raison pour surcharger l' operator,

Pour l'overloading ou les spécialisation de template, je ne vois pas comment tu peux cacher quoi que ce soit.

Et pour les référence, c'est vrai qu'il faut faire attention à la signature des fonctions. Là encore un bon IDE aide. Quand on respecte des convention sensée dans un programme ce n'est pas du tout un problème.

Bref, je ne penses pas que le C++ aide à cacher des backdoor. Le C lui même est déjà suffisent. Et de bonnes pratiques de programmation aident dans les deux cas.

Je ne pense pas. Il est déjà possible de cacher plein de truc avec des macros ou autre, je ne pense pas que le C++ sois moins facile à relire que du C.
Une surcharge ou un operator douteux est la même chose qu'une macro douteuse.

C'est pas la deuxième réponse car on ne peux pas ajouter des trucs dans le namespace std.
D'est donc la première ou la dernière réponse. Je dirais que les deux sont correcte. Je préfère la première si Example et operator<< sont dans la même partie du code.
J'ai bon?

Je voulais évidemment dire moins prone a l' erreur.

Tu as raison à propos de la tronçonneuse, mais le C est tout aussi dangereux, si pas plus. Ce qu'il faut conseiller à un débutant c'est un language comme Python.

Et pour les erreurs incompréhensible, tu as essayé un compilateur recent? Il y a eu beaucoup de progrès ces dernières années, notamment grâce à clang

Ce que tu pourrais faire en C est bien plus fastidieux, demande beaucoup plus de code boiler plate et est beaucoup plus prône à l'erreur que du code en C++

il vaut mieux ne pas utiliser les fonctionnalités trop récentes, parce qu'elles risquent de n'être supportées que par g++.

Pareil pour C.

Le mangling n'étant pas standardisé, chaque compilo utilise le sien propre.

Il existe un standard (Itanium C++ ABI) qui est respecté par GCC et par clang.
On peux parfaitement lier des binaires clang et GCC ensemble.

Par ailleur, le C n'a pas d'ABI standard non plus. (Les conventions d'appel de fonction en C sont aussi différente en fonction du compilo)

Il n'est pas imaginable de linker deux libs binaires produites par deux compilos différents.

Pas de problème pour lier des libs compilé avec clang et GCC.

Pire, deux versions différentes d'une même suite de compilation peuvent être incompatibles entre elles (c'est le cas de g++, qui pète régulièrement la compatibilité du mangling).

Il ne l'ont plus cassé depuis qu'ils utiliser l'ABI Itanium pour GCC 3.2 en 2002. J'apelle pas ça régulier.

Alors là, je demande à voir. Tu vas faire du extern "C" de toute façon.

Non je ne vais pas utiliser extern "C" de toute façon, je disait que c'était possible.
Pour voir, regarde les bindings python de Qt par exemple.