Gof a écrit 2224 commentaires

Clang est un frontend a LLVM pour compiler la famille des langages dérivés du C.

Si tu veux compiler du fortran ou du ADA avec LLVM, il faut utiliser un autre frontend, comme par exemple dragonegg (qui utilise GCC comme frontend)

Faire un frontend fortran utilisant uniquement l'architecture de LLVM ne doit pas être si difficile à faire. Mais il n'y aurais sans doute pas beaucoup de partage de code entre Clang et un frontend ADA ou Fortran car ses langages sont différents.

Bref, ce que je veux dire est que ce n'est pas la vocation de clang de comprendre des langage non dérivés de C.

Je donnais juste quelques explication pour justifier que ce qui est facturé est bien plus que le salaire que reçoi l'employé.
(Et j'ai oublié le salaire en inter-contrat)

Et là tu me sort une tartine disant que c'est normal qu'il payent, on est bien d'accord. Mais alors que reproche tu aux SSII exactement ?

Si j'ai bien compris, tu penses que sans les SSII, il serait plus facile pour les indépendants de trouver des clients car ils n'auraient plus la concurrence des SSII. C'est un argument valide. Mais sans SSII, il y aurais peut être aussi plus d'indépendants en compétition aussi.

Et tout le monde n'a pas envie d'être indépendants et de prendre le risque de se retrouver sans contrat.

Qu'est-ce qui est illégal au juste dans l'activité des SSII ?

J'ai le droit de penser qu'une entreprise a un rôle social

C'est sur ce point que mon opinion diffère. Pourquoi une entreprise devrait elle avoir un rôle social ?
Le but d'une entreprise c'est de faire du fric, pas d'employer des gens.

La SSII paye les gens qui vont trouver les client pour toi. Elle paye ton ordinateur portable et sa maintenance. Elle paye aussi tes frais de déplacement quand le travail est chez le client, ou la location de bureaux et le chauffage quand ce n'est pas le cas. Et finalement, c'est la SSII qui paye les taxes sur le travail.

Si tu veux te passer de SSII, libre à toi. (C'est ce que je fais). Trouver des clients n'est pas tellement difficile tout compte fait. Mais bon, c'est tout de même plus risqué. C'est à toi de voire.

Eh bien si tu es si malin, pourquoi ne rachètes tu pas cette usine que tu prétends rentable ?
Les « patrons » ne sont pas là pur faire de l'humanitaire, ils sont là pour gagner leur vie.
Si ils gagnent mieux en utilisant des travailleur indiens, ils ont tout intérêt à le faire.
Tu critiques les financiers, mais qu'est-ce que tu fais à pars te pleindre pour éviter le chaumage et la précarité ? Est-ce que tu donnes ta partie du salaire au dessus du smic pour aider ceux qui ont moins ?

Bref, j'ai l'impression que tu est tout simplement jaloux parce que les riches ont plus que toi.

Et les indépendants (comme moi), tu les mets dans quelle catégorie ?

Le principe de QML est une intégration forte entre le code C++ et le code javascript. Des objects écrit en C++ peuvent être utilisé très facilement par le javascript, permettant d'utiliser chacun des language quand il est adéquoi.

Alors que il est plus compliqué d'intégrer du code natif au code java.

J'ai du mal à croire au fait que ça améliore tant que ça la vitesse de ton appli en général.
Mais le problème est que tu dis dans ta dépêche que le port à Qt5 était compliqué à cause de ça alors que c'était pas du tout nécessaire de changer tout les connect()

Le portage n'a pas été facile (compatibilité de certains connect() difficile car la surcharge n'est pas autorisée),

Euh… L'ancien connect est toujours là et n'est même pas déprécié. Le nouveau connect() est un ajout qui a ces avantages, mais l'ancienne méthode existe toujours et il n'est pas du tout nécessaire de changer tout ton code. Si tu as choisis de le faire c'est bien, mais c'est pas honnête de dire que ça rends le port vers Qt5 difficile.

(Et la surcharge est autorisée, c'est juste que ça rend la syntaxe un peu (beaucoup) plus lourde)

Je suis par ailleurs intéressé de connaître les autres difficultés rencontrées.

Les message d'erreur C++ ont beaucoup évolués ces dernière années. Il faut que tu essayes clang. (et même GCC 4.7 a largement améliorer ces message d'erreurs, motivé par la concurrence)

typedef int My_Int;
void Test() {
    My_Itn Ma_Var = 14;
    std::cout << "Ma var = " << Ma_Var << std::endl;
}

$ clang++ test.cc
test.cc:6:5: error: unknown type name 'My_Itn'; did you mean 'My_Int'?

Et en image:

attend de voir les spéculateurs dégainer des supercalculateur pour émettre très rapidement sur un laps de temps très court, dès que ça les arrange.

Non, pas possible. En moyenne il y a seulement génération de 25 BTC toutes les 10 minutes, Et la difficulté est calculée en fonction de ça.
Pour réussir à tricher, il faudrait avoir plus 50% de la puissance de calcul de tout le réseau.

Comme dit plus haut le compilateur doit être capable d'instancier les template pour les type particuler.
Je propose 3 solutions:

1- Comme déjà proposé, mettre l'implémentation dans le fichier entête (URI.hpp)

2- Si tu sais à l'avance quels type seront utilisé, tu peux faire une instentiation explicite dans URI.cpp

template std::pair<std::string, std::string> URI::splitScheme (const std::string & str);
template std::pair<std::wstring, std::wstring> URI::splitScheme (const std::wstring & str);

Cela dit au compilateur de générer le code pour ton template pour les type donnés lors de la compilation de URI.cpp, et permettra au linkeur de les trouver lors de l'édition des liens.

3- export template: dans ton header rajoute le mot clef export

export template<class STR> std::pair<STR, STR> splitScheme (const STR & str);

Mais oublie cette dernière technique, car quasiment aucun compilateur ne supporte ce mot clef. Et il a d'ailleurs été retiré en C++11:
http://en.wikipedia.org/wiki/C++#Exported_templates

Le problème est que l'API de cURL n'était pas bonne.
Tous les documents sur comment réaliser une API précise que une bonne API est « consistent » (cohérente) et « hard to misuse » (difficile à utiliser incorrectement) [1] [2] [3] [4]

Or ici l'API n'est pas cohérente puisque CURLOPT_SSL_VERIFYPEER est un boolean et CURLOPT_SSL_VERIFYHOST un entier. Et elle induit les gens en erreur, ce qui est le contraire de « hard to misuse »

Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation…

En même temps, tout les languages avec typage fort que je connais convertisse automatiquement true à 1.

Par ailleurs, la documentation de cURL: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYHOST

When the value is 1, libcurl will return a failure. It was previously (in 7.28.0 and earlier) a debug option of some sorts, but it is no longer supported due to frequently leading to programmer mistakes.

Donc cURL a été corrigé, et mettre la valeur à 1 ne désactive plus la vérification.

Pas tout à fait: le sous-système de gestion du temps devrait être plus robuste.

Je suis pas d'accord. En quoi devrait-il être plus robuste ?
Si l'application utilise le temps local au lieu du temps UTC, c'est un bug de l'appli.
Si l'application ne réagis pas correctement aux changement d'horloges, c'est un bug de l'appli.

oh la synchro de l'agenda qui droppe tout car les données du serveur sont plus récentes

Rien à voir avec Linux… C'est purement un bug dans ton application d'agenda.

En gros, pas moyen de savoir si on est connecté. Cas typique, vous êtes associé en wifi, mais le wifi sort pas

Oui, mais c'est normal: c'est au applications d'essayer de se connecter pour savoir si oui ou non le serveur qu'on veux joindre est joignable.

Il y a aussi Qt5.0RC sorti aujourd'hui: http://blog.qt.digia.com/blog/2012/12/06/qt-5-0-release-candidate/

On t'avais déjà prévenu il y a environ 5 ans. MSN c'est proprio, tu es au bon vouloir de Microsoft.
Il peuvent bloquer les clients libre d'un jour à l'autre. Il peuvent vendre tes données. Ils peuvent censurer tes messages (et le font).

Maintenant ils te forcent à passer à Skype. Eh bien ce n'est pas notre problème. Skype et MSN: même différences.

pour une seule architecture "virtuelle"

Sauf que le bytecode LLVM n'est pas indépendent de l'architechture.

Tous les pointeurs sont déjà convertis en 32 ou en 64 bits. Et les trucs comme sizeof() sont déjà calculer.
Sans même parler des instruction asm dans le code, ajoutons le fait que il y a l'étape du préprocesseur:

#if LITTLE_ENDIAN

Donc cet objectif me parraît impossible.

les optims spécifiques à son CPU (i386/i686, Altivec, SSE, armhf/armel, etc.)

Il y a effectivement beaucoup d'extensions de l'architecture x86_64 qui ne sont pas utilisées car le binaire doit être suffisamment générique.

Cepandent, il faut relativiser: Quel est le gain réel que l'on peut espérer ici ? en sachant que la vectorisation en général est assez difficile à faire par le compilateur, et que les bibliothèques bas niveau profitent déjà de ces optimisations grâces au intrinsics et une vérification au runtime.

Qu'en pensez-vous ?

Je pense que il y airais peut-être un avantage à distribuer du bytecode LLVM pour permettre de faire du Just In Time. Et ré-optimiser les parties de code fréquemment utilisée avec plus d'inlining et de caching et ce genre de choses.

Il y a des exceptions:

A loop that, outside of the for-init-statement in the case of a for statement,
- makes no calls to library I/O functions, and
- does not access or modify volatile objects, and
- performs no synchronization operations (1.10) or atomic operations (Clause 29)
may be assumed by the implementation to terminate. [ Note: This is intended to allow compiler transfor- mations, such as removal of empty loops, even when termination cannot be proven. — end note ]

Je copie ton premier programme dans dlfp.c et j'essaye, sans optimisation

$ gcc  dlfp.c && ./a.out
Segmentation fault

Crash, stack overflow… Normal: Récursion infinie, et chaque étape de la récursion prends un peu plus de mémoire sur la stack.

Mais attends,.. toutes tes fonctions sont des Récursion_terminale ce qui fait que, avec des optimisation, le compilateur transforme les appels de fonction en simple sauts, qui ne prennent plus aucune mémoire sur la stack.

gcc -O2 dlfp.c && ./a.out 
^C

Avec des optimisation, le programme de crash plus et est coincé dans une boucle infinie. Je dois faire Ctrl+C pour l'arrêter.

Mais un programme C correct ne peut pas entrer dans une boucle infinie
La spécification du C est très claire à ce sujet.
Un compilateur assez intelligent peut remarquer que ce programme n'a pas d'effet secondaire, et juste retourner 0.

$ clang -O2 dlfp.c && ./a.out 
$

Avec clang, tout le code a été optimisé et le programme ne fait plus rien et termine immédiatement.

À lire aussi: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Si tu lances une pièce de monnaie maintenant, la valeur sera pile ou face avec une probabilité de 50% chacune.Pour moi, la pièce est dans la superposition des états pile et face. Et c'est uniquement quand tu envoies un commentaire pour me dire comment est la pièce que il ne reste que un seul état possible.

Mais la différence c'est que même si je ne connais pas encore le résultat, la pièce est déjà dans un état précis chez toi, alors que d'après l'interprétation de Copenhage ce n'est pas le cas, si j'ai bien compris. Les deux états (ou plutôt aucun état) ne sont pas encore décidés du tout. Et c'est ça qui n'a pas de sens.

Cela ne fonctionne que parce que les états sont liés, normalement en mécanique quantique, la mesure ne perturbe pas l'état et sa probabilité d'apparition si l'état mesuré est indépendant de l'autre état de la particule.

Je ne comprends pas cette phrase. Je pensais justement que la mesure perturbe l'état.

Je n'écris pas ce commentaire pour critiquer le fait que c'est un peu bizarre de faire une depêche pour un simple choix nom de code.
Ce que je veux, c'est dénoncer le fait que le chat de Schrödinger est détourné.

En effet, j'ai l'impression ce chat est souvent utilisé pour expliquer l'interprétation de Copenhage la théorie de la mécanique quantique. La théorie qui dit que les plusieurs états existent en même temps et que c'est en mesurant que l'un des états est choisis. Alors que justement, Erwin Schrödinger n'y croyais pas. Il donne justement l'exemple du chat dans sa boîte pour mettre en évidence l'absurdité de la théorie. En effet, comment un chat peut-il être vivant et mort à la fois ? C'est absurde.

Mais le chat est maintenant détourné. Et on apprends même au gens que oui, « on peut être à la fois mort et vivant comme le chat, c'est Schrödinger qui l'a dit. » Alors qu'en fait c'est l'inverse.

Les physiciens me corrigerons si j'ai tort.

En général le CLA contient une clause qui dit que le projet à le droit de changer la licence des contributions.

Tant qu'à faire, autant écrire du code en C++.