Gof a écrit 2224 commentaires

Utilisation du goto

Il n'y a rien de problématique avec l'utilisation des goto dans ce code.

mauvaise indentation

L'indentation est bonne dans le reste du project. C'est juste une ligne qui ne va pas.
Peut être qu'ils aurais du avoir un bot qui vérifie l'indentation, C'est vrai.

manque de tests

Je ne sais pas s'ils ont des tests ou pas. Mais avoir un code testé à 100% est difficile voir impossible.

non initialisation de la variable d'erreur

Rien à voir avec cette faille.
C'est vrai que c'est une mauvaise pratique mais ça n'a rien à voir.

non utilisation des accolades

Chacun ces goûts. On peux troller autant qu'on veut sur tab/espace, niveau d'indentation, acolade ou non.

Beaucoup de petites erreurs cumulées

C'est le cas de quasiment toutes les faille ou bugs. Je ne prendrais pas cet example comme une peuve de mauvaise pratique. Des bugs arrivent dans tout les projets.
Peut être aussi que cette « erreur » est volontaire.

Perso, je n'ai quasiment jammais utilsié les exceptions en C++.
Mais si je devais, le code ressemblerais plus à ça:

/* Check that everything is Ok, and throw in case of error */
static void SSLVerifySignedServerKeyExchange(/* ... */) {
{
   std::vector<...> signedHashes = ...;
   std::unique_ptr<...> hashCtx = ...;
   //...
   SSLHashSHA1.update(hashCtx, serverRandom));
   SSLHashSHA1.update(hashCtx, signedParams));
   SSLHashSHA1.final(hashCtx, hashOut));
}

Le problème des exceptions c'est que c'est que ça a un coût (en terme de taille du binaire par example). Pas mal de projets sont compilé avec -fno-rtti.

Sans exception le C++ ressemble à ça:

static OSStatus SSLVerifySignedServerKeyExchange(/* ... */) {
  std::vector<...> signedHashes = ...;
  std::unique_ptr<...> hashCtx = ...;
  OSStatus err;

  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) 
     return err;

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
     return err;

  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    return err;

  return OSStatus::Success:
  // no cleaning necessary
}

Je travaille dans une entreprise, et des collègues utilisent C++11 . Si je comprends rien à leur code, ça va être difficile de coopérer

Pareil si ils utilisent une nouvelle bibliothèque, ou une nouvelle version d'une bibliothèque. Et ce quelque soit le langage.

Malheureusement, Visual Studio 2013 ne supporte toujours pas l'utilisation les nouvelles utilisations du mot clef 'using'…

imagine si tu pouvais inspecter tous les éléments graphiques de GCompris directement dans l'inspecteur DOM de ton navigateur!

Tu peux faire ça avec QML et QtCreator

http://doc-snapshot.qt-project.org/qtcreator-2.8/creator-qml-debugging-example.html

C'est inquiétant. Normalement, dans le Web on prétend offrir une compatibilité quasi éternelle, en tout cas bien plus longue que les cycles d'environ 5 ans entre versions majeures de Qt.

Il y a la théorie et la pratique. En théorie les applications web fonctionnent sous tout les navigateurs. En pratique il faut tester chaque navigateur, y compris quand une nouvelle version d'un navigateur sort.

Si tu avais écrit une application avec Qt 4.0 il y a 8 ans, elle est toujours sensée fonctionner aujourd'hui (avec Qt 4.8 qui est toujours maintenu). Et Qt 5 est pratiquement source compatible.
Biensur on ne peux pas comparer avec les applications web de l'époque car les navigateur ne permettais pas grand chose à l'époque.

Tu auras le droit à un beau message d'erreur du compilateur (l'argument n'est pas un Lvalue-reference)

Comme dit zu, tu n'aura pas d'erreur. Ça passe très bien, et sans copie

Sinon, la grande question est: faut il passer par valeur ou par référence?

imagine un setteur qui en C++03 ressemble à ça:

Contact::setIdentity(const string &firstname, const string &lastname, const string &address) {
   m_first = firstname;  
   m_last = lastname;
   if (m_careAboutAddress)  
          m_address = address;
}

Tu ne va pas te taper 6 variantes avec toutes les possibilité de rvalue ou value. Ce que tu fais c'est:

Contact::setIdentity(string firstname,string lastname,string address) {
   m_first = move(firstname); 
   m_last = move(lastname);
   if (m_careAboutAddress) 
        m_address = move(address);
}

Comme ça, dans le meilleur des cas, il n'y a plus de copie (que des move), quand l'apellant peux faire des moves. Et dans le pire des cas, il n'y a toujours que 3 copies (comme avant). La différence c'est que ces 3 copies sont faite par l'appelant. (Ce qui a l'inconvénient de générer plus de code car chaque appelant doit faire les copie alors que avant les copies étaient mutualisées dans la fonction).

Mais ce n'est toujours pas parfait, car si m_careAboutAddress est false, il n'y avait que 2 copies dans le pire des cas avant, alors que maintenant il y 3 copies dans le pire des cas. Bref, il n'y a pas de solution magique :-(

maintenant on peut dire : return std::move(vec);

Pas besoin de mettre std::move lorsqu'on retourne des objects locaux.

typedef std::function<EventStatus(Entity, EventType, Event*)> EventHandler;

Typedef ? Qu'est-ce que ça veux dire encore ? C'est pas ce truc hérité du C ?

Tu voulais dire:

using EventHandler = std::function<EventStatus(Entity, EventType, Event*)>;

L'avantage de using comparé à typedef est qu'il est sensé être plus intuitif, et il permet d'avoir de faire des alias vers des templates. Par souci d'uniformité, il vaux mieux utiliser using dans du code neuf.

J'imagine qu'il voulais dire ça: http://www.youtube.com/watch?v=MXS3xKV-UM0

La différence c'est que le wolfenqt de 2008 affiche des widgets, qui sont rendu par le même process que celui qui fait tourner le "monde 3D" alors que celle de wayland et Qt5 de la dépêche affiche des fenêtres rendues par d'autres processus.

lorsque l'on utilise des std::thread (C++11), le système de signaux ne peut pas savoir qu'il doit transférer le signal vers un autre thread et il y a toutes les chances qu'en cascade l'interface soit touchée par le mauvais thread. Si on veut utiliser des std::thread, on doit renoncer aux signaux.

Tu as essayé ? Je viens d'essayer et ça marche très bien. Qt s'intègre parfaitement avec std::thread et pas de problème pour faire passer des signaux et slots entre en std::thread et un QThread. Si lo'bject est créé dans le std::thread, ses slots seront executé dans ce thread là.

Un QObject n'est pas copiable/déplaçable,

Oui, un QObject ne peux pas être copié car il est supposé être hérité. En général, ces classes ne sont pas copiable. Tu peux toujours avoir un constructeur de copie dans ta classe héritière, mais je ne pense pas que ça ait du sens.

pointeurs sont préférés à des références, comme pour la création d'un QVariant,

Ah bon? QVariant::fromValue n'a pas besoin de pointeur. Tu n'es pas sensé le constructeur interne qui prends un pointeur.

Il y a clairement une duplication de fonctionnalités au niveau des conteneurs, je ne vois pas ce qu'apportent les QList et semblables.

Oui c'est vrai. L'apport est une API unifiée et plus utilisable pour les utilisateur de Qt. Mais c'est vrai que c'est dupliqué.
Aussi, Qt ne veux pas avoir de type de la STL dans son ABI car Qt conserve une ABI binarie qui est mieux que celle de la standard library. Ainsi, Qt compilé avec libc++ de clang est compatible binaire avec une application qui utilise libstdcpp de gcc, et inversément.

Un QString ne peut pas être affiché sur la sortie standard avec std::cout << monQString;

Il faut écrire l'opérateur soit même. C'est vrai que Qt devrait supporter ça. Tu peux toujours envoyer un patch :-)

Je suis le seul à avoir trouvé Owncloud inutilisable sur un Raspberry?

Oui owncloud est lent sur un Rasberry PI, en particulier avec SQLite come DB.

Le problème c'est que owncloud est en PHP qui est lent par définition. Tout comme pratiquement tout les languages pour faire du web coté serveur. En général on dit: « C'est pas un problème si le language est lent et/ou que les dévelopeurs codent comme des pieds : rajoutez de la RAM et des serveurs, ça coûte moins cher que le temps de dévelopment gagné. » Mais ce n'est pas vrai quand le produit est utilisé par des particuliers sur un rasberry pi.

C'est pas à Brüssel ?

http://isocpp.org/blog/2012/11/modules-update-on-work-in-progress-doug-gregor
http://clang.llvm.org/docs/Modules.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf

Le mot clef export a en effet été suprimmer.

Mais en C++11 il y a extern template

En gros, dans le .h tu fais

template <class T>
void f (T x) {  std::cout << x << std::endl; }

extern template void f<int> (int);
extern template void f<string> (string);

et dans un .cpp

template void f<int> (int);
template void f<string> (string);

extern template dit au compilateur qu'il n'y a pas besoin d'instancier le template dans cette unité de compilation pour int et string car une autre unité de compilation le fait déjà. Ça permet de gagner du temps de compilation, mais aussi d'éviter des doublons des fonctions dans plusieurs bibliothèques.

Et sinon, pour diminuer le temps de complations, il faut utiliser les entêtes pré-compilée. Et bientôt il y aura les modules.

Par ailleurs, il y a des gens qui ont des recommendations pour des logiciels libre de réseau sociaux décentralisés maintenus et qui ressemblent pas complètement à de la blague (pas forcément en terme de nombre d'utilisateurs) ?

https://github.com/nono/linuxfr.org

Oui.

Et ta boulangère accepte les $, les £, les courones, et les ¥ ? Non, alors dois-je en déduire que ce ne sont pas des monnaie?

La réalité c'est que bitcoin est une monnaie car il est accepté par des boutique en lignes. (par example, tu peux acheter ta pizza sur http://pizza.fr avec des bitcoins)

La valeur d'usage du m², elle sera à peu près toujours la même

Si la rue dans lequel il est située deviens super fréquentée, ça augmente quand même grandement sa valeur d'usage pour quelqu'un qui veut y mettre une boutique. Par contre, si il y a une explosion dans une usine chimique juste à coté qui rends la parcelle inhabitable, sa valeur d'usage va diminuer de beaucoup.

miner pour spéculer… c'est très immoral.

Ah bon?

Autre question: jouer au lotto est-il immoral ? Si le donateur avait gagné au lotto tu aurais aussi critiqué ?

Car en fait, il n'y a rien de vraiment égalitaire. Quelque soit la façon dont il a obtenu l'argent.

C++ 11 §3.6.1 [basic.main.start]

1. The function main shall not be used within a program. The linkage of main is implementation-defined. […]

En C++, ton code est invalide. et cette optimisation est valide. Peut être que LLVM ne fait cette optimisation que pour du code en C++?
Je n'ai pas pu trouvé dans le code de LLVM l'endroit ou cette optimisation est faite pour vérifier.

Donc si tu as un paquet qui te fait tout planter, tu crois que tu t'en fous de savoir que ton bsd tient bien le paquet, vu que toute l'infra est par terre

Le but est d'avoir un openBSD stable. Comme ça quand tu passe ton infrastructure en openBSD, ton infrastructure ne tombe pas par terre si un petit malin s'amuse avec des paquets malformés.

Les dev de openBSD n'ont de l'influence que sur les logiciels openBSD et ne veulent peut être pas perdre du temps à débugger ou contourner des problème dans des logiciels tiers pour avoir une infrastructure de test.

un truc qui prend ou perd 400% de sa valeur tout les 2 mois.

Bitcoin est peut être très volatile (et c'est effectivement un problème) mais il ne faut pas exagérer non plus.

Même remarque, si t'es milliardaire (en euros) en Bitcoin un jour, tu peux te retrouver avec juste quelques bits sur ton disque dur le lendemain. C'est pas bon.

Possible, mais c'est assez peu probable.

À condition que la valeur soit au minimum de plusieurs milliers de dollars. Impossible de l'utiliser pour acheter son pain.

Je ne comprends pas ce point. Tu peux payer en µBitcoins si tu veux.

À condition que le vendeur accepte de prendre le risque que ce qu'on lui donnera ne vaille plus rien le lendemain. Personnellement, je ne le ferais pas.

En temps que vendeur, tu peux accepter les bitcoins via un intérmédiaire comme https://coinbase.com ou https://bitpay.com/ qui te payent directement en € sur ton compte. Tu prends très peu de risque.

les premiers n'ont vraiment rien risqué car il suffit de calculer un petit peu pour obtenir un retour sous forme de bitcoin

… pour obtenir un retour sous forme de bitcoin qui ne valait rien du tout à l'époque.

Et quand ils valaient 1€, certains ont choisis de les vendre, d'autre de les garder, et d'autres d'en acheter.
Et quand ils valaient 30€, ils avaient encore le choix entre les vendre et ramasser leurs profit, ou les garder et risquer de tout perdre. Et aujourd'hui ils valent 600€. Est-ce que la bulle va éclater et que il faut qu'ils vendent avant de tout perdre ? Ou est-ce que il faut risquer de les garder ? Bref, ils ont pris un risque.

Le gars qui avait 1 bitcoin quand il valait 100€ et qui a choisis de le garder plutôt que de le vendre a pris le même risque que celui que tu aurais pris en déboursent 100€ pour acheter 1 bitcoin.

Il y a quasiment un nouveau fork de Bitcoin créé chaque jours [https://bitcointalk.org/index.php?board=159.0]. Certains propose des nouveautés, mais la pluspart non, et n'auront jamais de succès. Celui à la mode est le dogecoin qui sous son air ridicule, a augmenté de manière fulgurante en deux mois. Vas-y dépense ton CPU pour ces monnaies sans valeurs et tu sera un « premier ». Si tu choisis la bonne monnaie, tu sera peut être riche, qui sait. Ou tu auras perdu du temps et de l'électricité pour rien. (Mon avis

C'est clair que ceux qui ont cru en bitcoin ont eu de la chance. Personnellement j'ai appris très tôt l'existance des bitcoins. J'ai trouvé le concept intéressant. J'ai téléchargé le client et j'ai reçu 0.05 bitcoins du bitcoin faucet pour jouer avec, mais je n'ai pas pour autant laissé tourner mon CPU (j'avais pas envie), pourant j'aurais du :-).

L'intégration sur mobile est bien plus importante que sur desktop

Va dire aux designers avec lesquels j'ai travaillé. Il te pondent un truc qui ne s'intègrent avec aucun mais et veulent que l'application soit exactement pareil sur toutes les platformes. Parfois le designer aime Apple alors tout les contrôle ressemble à ceux du iPhone mais pas exactement.

Personellement, je suis d'accord que l'intégration est importante sur mobile, mais je ne dirais pas plus importante que sur le desktop. Je dirais que l'intégration est importante dans les deux cas.

N'importe quoi.
Du code Qt se compile avec un compilateur C++ quelconque.
Maintenant il est vrai que il y a les fichiers générés par le moc. Mais dans ton code en gtk, il y a aussi le fichier config.h généré par le configure, il a besoin de macro données par le système de build. Certains projet on même des dépendance à python pour générer du code.
Même subsurface avant qu'il soit porté vers Qt utilisait un générateur de code pour inclure les images dans le binaire: https://github.com/torvalds/subsurface/blob/Gtk/Makefile#L325

```score
1337
```

Cela resulte en du <code> avec une classe score, et CSS fait le reste pour le placer par dessus le score réel.

Youpie