Gof a écrit 2224 commentaires

Je rajoute que LLVM est son infrastructure sont en fait bien plus qu'un compilateur. Le tout est très modulaire et est en réalité composé d'un ensemble de bibliothèque réutilisables.

Ainsi, grâce à LLVM, on a des truc tel que mesa llvm-pipe qui compile les shaders OpenGL pour un rendu software rapide ou emscripten qui permet de "compiler" du C ou C++ en javascript pour tourner dans un navigateur.

Clang, qui fait le parsing du C et C++, peut être utilisé dans les IDE ou autre outils pour parser le C++.
On peux ainsi faire des outils de refactorisation de code avancé (cpp11-migrate est juste un example).

Par exemple, en utilisant clang j'ai écris un navigateur de code online avec coloration sémantique et tooltips: http://code.woboq.org/

Il décide d'utilisé du binaire. Maintenant il a 10 problèmes.

http://nedbatchelder.com/blog/201204/two_problems.html
http://twoproblems.com

Ta mère est tellement grosse qu'elle aplatit un arbre en une liste en un temps constant.

C'est surtout un problème d'incompatibilité binaire du C++ en fait,

Non. C'est juste Microsoft qui a ces incompatibilités.

De son coté, GCC maintiens une bien meilleur compatibilité binaire.
Le dernier changement date de libstdc++-v3 (libstdc++.so.6) sorti avec GCC 3.4.0 en 2004 (il y a 9 ans!)

Et reste compatible même après le passage à C++11.

(Note que C++11 rajoute quelque règle qui nécessite un changement dans l'ABI, comme le fait que std::list::size soit O(1) ou qui interdit à std::string de faire du « copy on write ». Les dev de GCC ont décidé de repousser ces changements à la prochaine version majeure de la libstdc++)

(Ah, je rajoute que C++11 introduit les « inline namespace », qui permet de facilité la compatibilité binaire des bibliothèque en C++. C'est utilisé par la libc++ du projet llvm)

il s'agissait de faire fonctionner un code compilé avec une libstdc++ récente sur une machine avec des versions plus anciennes

C'est plus problématique, surtout si le programme fait appel à des nouveauté de tr1 ou de C++11

Et pendent ce temps chez Microsoft, on est à la traîne. Microsoft Visual Studio n'implémente toujours pas C99, et son support de C++11 est toujours rudimentaire.

En plus, WinRT ajoute des « extensions » au language (comme par exemple les ref classes qui ajoutent un nouveau mot clef ref et un nouveau type de pointeur ^. Je ne sais pas si ça apporte quelque chose par rapport au shared_ptr.)

Bref, le C++ c'est un peu come le HTML à l'époque de IE6. Merci Microsoft.

Exactement. D'où ma proposition d'utiliser namecoin, comme ça on ne dépends plus d'aucun organisme ou autorité.

DNSSEC est biensur un énorme progrès. Mais est-ce que ça résout complètement le problème ?
On dépends en effet toujours d'une organisation de certification. Comment est-ce que google.ir ou google.cn peuvent faire confiance au DNS?

La solution est: Namecoin https://dot-bit.org/

GCC ne pourra jamais le faire, à moins de revoir profondément son architecture.

Il faut croire que l'architecture de GCC a été revue profondément avec gcc 4.8 alors:

$ gcc -Wall macro.c
macro.c: In function ‘main’:
macro.c:3:6: error: wrong type argument to increment
   var++; \
      ^
macro.c:12:3: note: in expansion of macro ‘MACRO’
   MACRO(struct foo);
   ^

IE8 supporte cette extension, c'est Windows XP qui ne la supporte pas.
Et la prise en charge du serveur n'a rien à voir. Si le client la prends en charge (cet à dire quasiment tous les navigateur de nos jour) , le nom de domaine sera présent en clair dans le premier paquet envoyé par le client.

En pratique, le nom de domaine des sites visité en https passent toujours en clair.

On peux dire que la non conformité à une spécification est un bug. Non?

Le nom de domaine passe en claire dans la négociation TLS. [http://en.wikipedia.org/wiki/Server_Name_Indication]

si un développeur ne sait pas gérer un malloc qui échoue, il devrait apprendre.

La meilleur chose à faire quand un malloc échoue est un crash. Gérrer tous les malloc dans un programme compliqué est un travail important. En plus, il faut s'assurer à bien tester tous ces cas. Et en plus à cause de l'over commit, en général les malloc n'échoue jamais. Donc il est préférable d'ignorer les cas ou malloc échoue.

je ne sais pas comment Qt réagit par exemple.

avec un crash.

Ton programme est en effet une « undefined behaviour » d'après le standard. Je cite:

[C++11] §1.10 21
The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

!f et f = 1 sont dans différent thread, sont deux opérations non atomic, conflictuelles et il n'y a pas de « happens before » selon les définitions données dans la même section.
Le compilateur est donc libre de faire ce qu'il veut.

Si f était de type std::atomic<int> alors ce serait bon.

C'est pour ça que les spin-lock sont à éviter. Même en utilisant des pause ou des sched_yield, tu gaspilles des cycles à attendre, alors que un autre processus pourait les utilisé, ou qu'il pourait ne pas être utilisé du tout et consomer moin d'énnergie.
Un lock sera beaucoup plus simple

Le plus simple c'est d'utiliser std::mutex. Mais il est vrai que tu aura un petit overhead comparé à utiliser des futex directement (genre un appel de fonction).

Le spin-wait a très rarement « du sens ». (en userspace sous linux)

while (!_db_access_allowed)
sched_yield();

Aaa. Évites ça.

Ceci est un spin-lock, qui comme son nom l'indique est un type de lock. Donc si tu croyais que ton algo est lock-free, eh bien il ne l'est pas.

Le spin lock ne devrais jammais être utilisé en user-space. C'est le pire de tous. Car les autres locks sont bien plus économe pour le CPU (consomaion d'énergie) ou sont plus favorable pour les autres processus.

Donne nous les sources d'un vrai benchmark répétable. Sans ça j'ai du mal à te croire, les instruction atomique sont beaucoup plus lente que les instructions non atomiques.
Es-tu sur que le code est exactmenent le même et que tu n'as pas changé la signification ?
Les options de compile sont elles bien les même (avec les optimisations activées) ?

P.S.: Ce n'est pas __sync_* qu'il faut utiliser, mais std::atomic

Avec un mapping clavier pour appeler :Man sur un mot

Ça marche bien quand tu as un langage impératif ou les « mots » ne dépendent pas du contexte. Mais dés que tu as des objects, des namespaces, ou différent manuels en fonction de la bibliothèque utilisée, ça ne marche plus.

image.save("foo.png");

Comment ton simple éditeur fait pour savoir que il faut aller chercher la doc de QImage::save(QString) ?

Un IDE est assez intelligent pour savoir que la fonctione gdk_pixbuf_save est déclarée dans un header gtk et que donc c'est cette doc qu'il faut ouvrir.

Un des gros avantage d'un bon IDE qui « comprends » le language dans lequel on écrit est que ça facilite la lecture et la navigation du code.

Personnellement, il m'arrive de travailler sur des grosses base de code écrit par d'autres. Je passe beaucoup de temps à lire et comprendre le code avant de le modifier. Pour cela, un IDE aide beaucoup grâce aux tooltips qui contiennent des information sur les types ou la documentation. Le fait de pouvoir facilement passer d'un fichier à l'autre et d'une fonction à l'autre est aussi très important ;
Ainsi que pouvoir, en un seul shortcut, aller voir l'implémentation d'une fonction pour être sur de ce qu'elle fait, puis revenir là ou on était.
Trouver tous les endroit où une fonction est utilisée pour savoir si on peux ou pas changer son comportement.

Les IDE propose aussi plus que de la simple coloration syntaxique, mais de la coloration sémantique, qui permet de facilement repérer les erreurs ou de visualiser les types ou scopes.

Cette navigation est pour moi indispensable, qui fait que lire le code sans est vraiment pénible.
(C'est pour ça que j'ai même écrit un site qui permet de naviguer dans le code en ligne comme dans un IDE: http://code.woboq.org )

Lors de l'invention des voitures, il y a au une loi qui obligeait chaque voiture à être précédée par un piéton avec un drapeau rouge. Locomotive_Act

Quand bien même on activerait aucune optimisation (et ce serait bien dommage), le linkeur fait toujours les relocations qui rendent le partage difficile voir impossible.

L'idée serait justement d'exposer ces informations à la couche supérieure. (via de nouvelles interfaces)

Je ne crois pas. Quand une bibliothèque est liée statiquement a un exécutable, seul les fonctions utilisées sont incorporées. Et puis la résolution des adresses sera différente. Même en position independent code il y aura des décalages. Donc en gros, je ne sais pas si des pages pourront être partagées.

J'avais compris que tu disais que le copy on write allait aider dans ce cas.
Mais je ne vois pas comment ça peux aider.

Les libs compilée statiquement ne sont par définition pas partagée.

pour faciliter l'usage de de lib statique plus rapide que les lib dynamique (pour économiser de la ram)

Peux-tu élaborer ?