Gof a écrit 2224 commentaires

• une base de code existe déjà en C pour le projet,

Ok. C'est un bon point. Mais pas quand on commence un nouveau projet.

• on a besoin de portabilité,

Quel genre de portabilité ? C++ est très portable.

une librairie dynamique (les problèmes de mangling en C++, c'est super pénible),

En quoi c'est pénible ? Il y a des bibliothèques qui font la conversion des noms de symboles pour toi.

• une librairie qui sera bindée dans plusieurs language de plus haut niveau (Java, C++, Python, …),

Déjà tu peux toujours utiliser extern "C" pour exporter une interface plus « simple ».
Ensuite, Python et Java étant des langage objets eux aussi, c'est plus facile de mapper le concept d'objet d'un langage vers l'autre en C++ qu'en C. Dans tous les cas tu dois faire un effort pour faire des bindings. (Passage du type string d'un langage vers char* ou vers std::string c'est le même travail. Mais pour le second, la gestion de la mémoire est claire.)

Le premier article est en effet un très bonne critique du C++.
Note que les article compare le C++ par rapport à des langage de haut niveau. Pas avec le C.
Des argument tel que « Le C++ c'est trop difficile à apprendre » sont un peu légés. Particulièrement vis à vis du C. (Ça demande plus d'apprentissage d'écrire une lettre avec un ordinateur et tous ces virus, tous ces menus, et crashes. Ça ne veux pas dire qu'il faut conseiller une machine à écrire mécanique car c'est plus simple à première vue)

presque toutes sont complètement fausses, ou dangereuses, ou non maintenables, voire les trois en même temps.

Pareil pour le C. Faire des cast de type à tout bout de champ par exemple.

Tu dis ça parce que tu ne sait pas coder :-)

Chaque langage a ses forces et ses faiblesses. Pour une tâche donnée, certains langages seront mieux adaptés que d'autres.

Entièrement d'accord. Et ce que je dis c'est que le C est dans quasi tout les cas moins bien adapté que le C++.
(Ok, quand on programme pour un microcontrôleur avec quelques K de mémoire pour lequel il n'y a pas de compilateur C++ disponible, alors le C est plus adapté. Mais pour le reste?)

par exemple la surcharge d'opérateur qui ne se combine pas super bien avec les namespaces.

Tu peux élaborer ?

Mais en général, il est vrai que le C++ a plein de petits défauts, le C aussi. Mais rien qui ne rebute un bon programmeur, comparé au plaisir d'utiliser les possibilité offerte par le C++

Faux!
Tu contrôles bien plus le design de ton object en C++ car tout est possible. Tu as le choix entre plein de méthode

struct MyClass {
   // le plus classique, une fonction virtuelle
    virtual int myVirtualFunction(double);
  // un pointeur de fonction comme en C
    int (*myPointer)(double);
  // une table virtuel manuelle
   struct VTable {
         int (*firstFunction)(double)
   };
    VTable *vtable;

  // boost::signals
    signals<int(double)> mySignal;
  // Qt signals (c'est tricher?)
  signals:  int myQtSignal(double);
};

/* et enfin, le static polymorphise via le Curiously recurring template pattern  qui a l'avantage d'être plus performent car il peux inliner les appels.  Vas-y pour faire ça en C */
template<class Derived> struct Base {
  int myFunction(double a) 
  { return static_cast<Derived*>(this)->myFunction(a); }
};

Bref, plein de possibilité offerte en C++, chacune adaptée à son usage. Mais dans tout les cas, la manière de faire en C++ est moins fastidieuse, plus facile à écrire et relire, et moins prône à l'erreur.

Bref, le C est un mauvais choix.

comparé à C++, le C est un langage simple et cohérent

Un boulier compteur est plus « simple et cohérent » qu'une calculatrice électronique. Mais je préfère utiliser une calculatrice.

Tu conseilles d'utiliser la forme de new qui renvoie des NULL?

C'est un autre sujet, mais, en fonction du type d'application, je conseil de ne pas geré de cas de out of memory, et de simplement laisser l'application segfaulter. (Mais que l'application soie conçue pour ne pas perdre des données en cas de crash, et d'avoir une restauration rapide)

Dans ce cas, ça va être assez dur d'utiliser la biblitohèque standard, boost ou Qt, comme tu lui suggères

Je suggère de ne pas créé sois même de classe/fonction template.

Il est aujourd'hui ridicule de choisir le C face au C++. Je m'explique: Le C++ étant multi-paradigmes, it est à la fois de bas niveau et de haut niveau. Prenant le meilleur des deux mondes.

En C, tu es forcément limité à gérer la mémoire de façon manuelle, fastidieuse et prône à l'erreur. (crash, leak).
En C++, tu as l'aide des destructeurs et des smart pointers et tu codes bien plus vite sans te tracasser de bien faire tout tes free(). En C, chaque fois que tu veux une structure de donnée simple, tu dois tout refaire à la main, alors que en C++ tu disposes des structures de donnée de base dans les bibliothèque standard quasi aussi performantes que celle que tu pourais faire à la main. (Et pour les rare cas où de structures de donnée plus compliquées ou plus perfomantes, tu peux toujours les faire à la main comme en C).

La bibliothèque standard du C++ est déjà bien fournie. Mais tu peux aussi utiliser Qt ou boost qui sont de bonnes bibliothèques. Et toutes les bibliothèques C sont aussi accessible via C++.

Si tu trouves que le C++ est trop compliqué, tu n'est pas obligé d'utiliser les exceptions ou des templates dans ton application.

Ma recommandation est donc d'utiliser C++, y compris les nouveauté de C++11 tel que auto ou les fonctions lambda.

Tu as raison, mais il ne faut pas comparer le nombre de bits des clefs symétriques et assymétriques.

Il existe des attaques sur les algo de clefs assymétrique qui font que, pour une taille de clef égale, les algo symétriques sont bien plus résistants.

On ne dit plus « SSL » on dit « TLS ».
Ça fait 10 dans que SSL est obsolète et que plus personne ne l'utilise.

Zenitram, pourquoi tant de haine sur le bitcoin?
(On aurait du en discuter plus en vrai.)

Il y a des inégalité dans le monde. ( 20% des gens ont 80M des richesses )
Bitcoin n'as jamais eu pour prétention de supprimer les inégalités. Le but est de créé un système d'échange de valeur décentralisé. (Et un peu de se débarasser du monopole des banque.) Je ne pense pas que le bitcoin crée plus d'inégalités que ce qui existe.

Alors oui, les créateurs du bitcoins sont maintenant très riches. Mais les créateurs de Microsoft sont aussi très riches et ça ne t'empèche pas d'utiliser Windows que je sache.
Satoshi a eu de la chance, mais c'est en quelque sorte une récompense pour un travail fourni (créé bitcoin). En un sens, il mérite un peu sa fortune. Plus que celui qui est riche juste parce qu'ils sont nés prince dans un pays avec du pétrole.

Il y a eu pas mal de propositions de monnaie décentraliser avant bitcoin, mais aucune de ces monnaie ne pouvais fonctionner à cause de problème technique.

L'idée de la blockchain est en ce sens révolutionaire. (distributed timestamp)

Voir aussi namecoin (décrit par Aaron Swartz ), qui se base directement sur les idée du bitcoin pour inventer un système de nomage décentalisé avec des nom facile à retenir, alors que on pensai que c'était impossible https://en.wikipedia.org/wiki/Zooko's_triangle

On en reparlera dans quelques années quand Bitcoin se pètera la gueule bien comme il faut.

On verra bien dans quelque années en effet.
Note que certains on dit la même chose en 2009 et 2010, et maintenant, quelque années plus tard, ils le regrètent peut être.

Personnellement je ne crois que même si bitcoin se pète la gueule, ça valait la peine pour les avancées qu'il apporte. Et je crois que si ce n'est pas bitcoin qui l'emporte, ce sera alors un des nombreux fork directement basé sur les principe du bitcoin.

Je ne pense pas que le bitcoin ait pour but de remplacer toutes les monnaie. Elle circulera en parallèle avec les autres monnaie. Et en parallèle avec les autres monnaie dérivées du bitcoin (Litecoin, PPCoin, …)

Pour que ce soit une arnaque, il faut qu'il y ait tromperie. (par définition de « arnaque »). Or, vu que tout est publique et documenté, on peux difficilement parler de tromperie ou d'arnaque.

Les Bitcoins perdus le sont définitivement.

Si quelqu'un perds la clef privée, il est n'est normalement pas possible de dépenser les bitcoin envoyé à cette addresse.
Si quelqu'un envoit les bitcoin à une addresse « invalide » (ou tout autre output invalide) les bitcoins sont définitivement détruit.

Note: J'ai posté un journal il y a quelque mois qui explique comment bitcoin fonctionne sous le capot:
https://linuxfr.org/users/gof/journaux/comment-fonctionne-bitcoin

En fait c'est

0. Blackbery rachète QNX

Et on peux aussi noter que Blackberry utilise Qt pour ses interfaces.

Quand tu as des futex_wait ou des pthread_mutex ta structure de donnée n'est pas lock-free
Lock-free veux dire sans aucun lock.

Aussi, il y a des erreurs:

while ( _a c ce ss _en ab led && * ptr < generation ) {
    _waiting = 1;
    // [ici]
    futex_wait (& _waiting , 1);
}
_waiting = 0;

Et

// Wake other threads waiting for us
if ( _waiting )
    futex_wake (( void *)& _waiting );

Ce n'est pas comme ça que les futex fonctionnent, il faut mettre à jour la valeur de _waiting.
Par exemple, il y a une race condition si le code de réveil est exécuter là ou il y a le ici.
Lis ce document si ce n'est déjà fait: http://www.akkadia.org/drepper/futex.pdf

Quand tu fait un ftruncate pour agrandir ton fichier, tu dois refaire unmmap pour que les nouvelles pages
soit prises en compte. Bonne chance pour faire ça de façon lockfree.

Je vois aussi que tu utilise le mot clé volatile de temps en temps. Volatile ne doit pas être
utiliser pour la communication entre threads.

Enfin tu dis que tu utilise C++03, mais C++03 ne permet pas de faire de la programmation multi-thread.
En effet: le standard ne mentionne pas les thread et la concurrence.
Ce n'est que à partir de C++11 qui introduit un modèle de mémoire qui fonctionne avec des thread.
Et donc tu peux utiliser std::mutex et std::atomique, ça rends le code plus lisible et portable.

kWh, pas kW/h

Vas tu pouvoir te pardonner une erreur pareil ?

L'idée du mélange est assez intéressante.

Il y a d'autres algo qui pouraient servir. Par example, le concept de Mental poker qui consiste à mélanger un jeu de carte de façon à ce que aucun joueur ne connaisse l'ordre des cartes, mais qui permet de vérifier que toutes les cartes sont dans le jeu et pas en double.

Ce dont tu parle c'est CRIME, et ça ce basait sur la compression fait par SSL qui comprimme les headers.
Là maintenant, "BREACH" est une variante qui se base sur la compression du contenu, et non plus des en-tête. http://breachattack.com/

Tes articles en lien sont peut être sensationelles et alarmistes, mais en pratique rien de bien grave.

Çe ne sont pas les nœuds de sortie qui sont compromis, mais des services TOR. Et la compromission est un exploit pour Firefox qui permet apparemment d'avoir l'IP des visiteurs.

SSL n'est pas beaucoup plus compromis qu'avant. Il y a toujours des attaques, possible uniquement sous certaines conditions et qui sont parable. (Ici, c'est une attaque qui doit être active et ciblée, pas un truc qui peux se faire de manière passive chez tout les citoyen.

Bref, ce n'est ni « Tor », ni « SSL » qui sont compromis, mais juste une utilisation de ces dernier qui pose problèmes.

D'ailleur, c'est à peu près l'idée derrière Namecoin [http://namecoin.info/]

Namecoin permet d'associer des données arbitraires à un identifieur. En bonus, l'identifieur a un sens.

En particulier namecoin permet d'associer a un identifiant des données comme adresse email ou autre: http://dot-bit.org/Namespace:Identity

Mais pour pouvoir vérifier la validité de la chaine, il faut pouvoir vérifier tous les hashes, de tout les bloc jusque le bloc initial qui est hard-codé. Donc on a besoin de toute les transactions.

Donc si on élague la chaine, il faut trouver un autre moyen de savoir quel sont les blocs valides.

s/exactement/en moyenne/

Est puni d'un an d'emprisonnement et d'une amende de 150 000 euros […], le fait pour toute personne […] possédant en connaissance de cause des informations privilégiées sur la situation ou les perspectives d'un émetteur dont les titres sont négociés sur un marché réglementé ou sur les perspectives d'évolution d'un instrument financier ou d'un actif […] admis sur un marché réglementé, […]

Le bitcoin n'est pas (encore?) un marché réglementé. Donc cette loi ne s'y applique pas.