Gof a écrit 2210 commentaires

Je pense qu'ils payent les charges patronales. Pas moyen d'éviter ça si tu emploie des personnes en France.

Bah si. Qu'est-ce qu'ils utilisent et ne payent pas ?

Les plans d'évasion sont là pour ne pas payer ce pour quoi il ne doivent pas payer.

J'ai pas de chiffres, non. Je suis un expert en informatique, pas en politique ou en économie.

Par contre je pense que la situation atteint toujours un état d'équilibre. Et, comme en chimie, quand on change une composante, une réaction se fait pour rétablir l'équilibre en faisant changer les autres paramètres. Et le système est très compliqué car il y a beaucoup de paramètres. Donc il n'est pas forcément facile de savoir intuitivement dans quel sens le système ira si on change tel paramètre.

Juste pour être clair: Je ne pense pas que l'évasion fiscale soit une bonne chose, bien au contraire.

Super, on va avancer vite, avec un péage à chaque intersection

j'ai habité dans un pays ou presque chaque ville a un péage. Il n'y as pas de rallentissement au péages. Les plaques sont prise en photos et tu reçois la facture, ou les voiture sont munies d'un appareil qui enregistres les passages.

ou avec une vignette.

Donc un impot !

Plutôt une redevance. Tu payes si tu utilises les routes et pas en fonction de ton salaire que tu aies une voiture ou non. Les règles sont plus simples et l'évasion plus difficile.

N'importe quoi.

Je vais appliquer ton raisonnement à Carrefour

Et moi je vais appliquer ton raisonnement à L'industrie du cinéma:
« Il y a beaucoup de piratage qui représente un énorme manque à gagner. Il faut faire plus de répressions pour que les pirates payent pour les œuvres qu'il volent et utiliser des DRM pour empêcher le piratage. »

Biensûr que l'évasion fiscale est embêtante.
En même temps, il faut voir si la situation serait différente si l'évasion fiscale était impossible.
Si vraiment les entreprise ne trouve pas de moyen de réduir leurs impôts en France, soit elle devront délocaliser dans d'autres pays où ce sera moins cher et payeront encore moins d'impots en France et offriront aussi moins de travail, soit ils devront augmenter le prix de leur produits vendu en France pour compenser le prix des taxes, et au final c'est le citoyen qui paye plus.

La principale victime du système actuel est la petite entreprise qui n'a pas de succurcale à l'étranger et qui doit payer plein d'impôts tout en étant en concurrence avec les grosses entreprises qui en payent moins.

Sans route, sans écoles, sans hôpital, sans médecin, sans police, sans magistrat/juge, etc

On peux payer les routes avec des péages, ou avec une vignette. On peux payer les écoles avec des frais d'inscriptions. Les médecins et hôpitaux sont payés quand tu y va (et il y a des assurances)
Il n'y a pas besoin d'impôts pour tout.

Les ultralibéraux, c'est tous les même, sont les derniers à payer, mais les premiers à utiliser les résultats.

Ils sont prêts à payer pour ce qu'ils utilisent.

Là encore c'est utiliser des extensions du standards.
Le standard C ne défini pas d'ABI. Et donc les .s vont dépendre de l'ABI choisie par le compilateur utilisé.

Mais le code écrit en C est valide. Ou l'est il vraiment ? Le standard précise que le symbole en question doit apparaître dans une autre translation unit (C99 §6.7.4 8 / §6.9 5), et une translation unit est définie à partir du code en C (§5.1.1.1).
Bon, c'est vraiment du chipotage.

Avec visual studio pas.

Mais avec clang, oui : http://llvm.linuxfoundation.org

So we limited our code to “Embedded C++” constructs

Tu sais, même les dévelopeurs C s'imposent parfois à un subset du langage C.

(Ex: Pas de goto (considered harmfull?), pas déclaration de fonction à la K&R, toujours utiliser des accolades même pour les blocs d'une lignes, interdiction d'utiliser certaines fonctions de la bibliothèque standard)

Bref, que ce soit en C ou en C++, les devs choisissent un subset et un style propre.

Tu peux détourner la blockchain de bitcoin pour y stoquer des signatures datées.

Sinon, pour des contrats génériques : Ethereum

Critiquer c'est un manque de respect ?

Non, une critique constructive n'est pas un manque de respect.

Par contre là c'est juste une critique du genre « J'aime pas ton style, c'est moche. »

On peu discuter aussi longtemps qu'on veux pour savoir si la programmation fonctionelle est meilleur que la programation object ou impérative. Mais à l'époque, le style à la mode était à la programmation impérative avec des variables globales. À l'époque ou le code a été écrit, les fonctions prétendues plus sûres n'existaient pas encore et les développeur utilisaient les fonctions existantes en faisant attention.

Ça ne rends pas le code mauvais. Juste vieux.

Faire des audits et financer des relectures c'est utile.
Dire que leur code est « moche », c'est pas très utile et c'est un manque de respect.

Il y a peut être quelque chose à apprendre, mais il ne faut pas non plus tirer des conclusions hâtives.

Bash commence par la lettre 'B'. Et il contiens une faille de sécurité ! Conclusion: Il ne faut pas utiliser de programmes dont le nom commence par la lettre B.

Et les médias parlent de cette faille désastreuse. Vite ! Il faut créé une nouvelle loi pour que ça ne se reproduise pas. Dorénavant il est interdit de donner un nom qui commence par 'B' à un programme sous peine de prison.

Il faut que tu prouves que le style du code de bash soit une cause de la faille. Parce que c'est vraiment une critique gratuite : « Bouh, ils n'utilisent pas le dernier style à la mode, quels incapables ! »

On est sûr qu'il n'y a pas de faille qui traine dedans depuis 20 ans ?

Je n'ai pas dit ça. Et je n'ai pas dit non plus que du vieux code était forcément parfait et bien éprouvé. Ce serait tomber dans un extrême inverse.

Par contre, le poste critique bash car il utilise pas le dernier style de codage à la mode. Est-ce là raison de shellshock ? Probablement pas.

Je suis un partisent du « Ne corrige pas si ce n'est pas cassé ». Ça ne veux pas dire qu'il ne faut pas chercher à améliorer les vieux truc. Mais ça veux dire que refactoriser pour le plaisir n'est pas toujours une bonne idée. Pour un programme tel que bash, un petit changement de comportement peux casser plein de script. Il vaux mieux être prudent.

Je vais prendre un en exemple la CVE-2007-1381 dans PHP, où un développeur voulant rendre le code plus « sécure » a remplacé une utilisation parfaitement valide de strncpy par un emploi erroné de strlcpy causant un trou béant de sécurité. Et parce que cette leçon n'est pas suffisante, php refait une erreur similaire 4 ans plus tard en remplaçant un strcat par un strlcat https://bugs.php.net/bug.php?id=55439
Vive les bonne pratiques, hein !

C'est juste que bash a été écrit il y a 25 ans. C'est normal que le style de code soit un peux viellot. Mais ça ne veux pas dire que ce soit du mauvais code. Par contre c'est du code bien éprouvé.

Une classe est déclarée dans des entêtes. Si cet entête change, même de manière anodine (par ex. ajout d'un saut de ligne pour aérer le code), alors cela va nécessiter la recompilation de tous les fichiers sources qui référencent directement ou indirectement ce fichier. Alors que si le fichier d'entête était "compilé" en un .class contenant juste l'ABI (et éventuellement le code pour les fonctions inline) de sorte d'avoir une représentation unique quelque soit l'organisation de l'entête, alors les temps de recompilation serait grandement réduit !

Même si les en têtes était pré compilé dans un fichier .class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.

Oh! Et les en-tête précompilée ça existe déjà. Ça s'appelle .gch avec GCC et .pch avec clang. Et ça améliore effectivenement le temps de compilation car le compilateur ne dois pas recompiler le header pour chaque fichier qui le contiens.

Les entête pré-compilés ont leur propre problèmes, mais marchent assez bien en pratique.

Mais l'avenir nous offre une solution presque parfaite: les Modules. Déjà partiellement implémentés dans clang.
http://clang.llvm.org/docs/Modules.html

Tu as raisons. (Puisque tu peux simuler facilement des printf avec un bon débugger, utiliser les printf est un sous ensemble d'utiliser un débugger)

Cependant, je pense que la tache qui prends le plus de temps et d'effort est le point 1. (essayer d'imaginer ce qui peut se passer).
L'art de débugger consiste à déterminer l'endroit ou mettre les printf / breakpoint: pauser des hypothèses et les vérifier. Ne pas trop so focaliser sur les symptomes mais essayer de trouver la cause d'un problème. Et bien comprendre le problème.

Considérant ça, printf ou un débugger c'est un peu pareil. L'avantage de printf est que c'est écrit dans le même langage que le produit et que tu à accès à toute les bibliothèques pour afficher les valeurs que tu veux. L'inconvénient c'est qu'il faut recompiler et relancer. (Ce que tu devras quand même faire si tu cherche à corriger le problème)

Comme le disait Bjarne Stroustrup, le créateur de C++: « Il y a deux sorte de languages de programmation: ceux dont on se plaint, et ceux que personne n'utilise »

Toujours d'après Stroustrup, L'une des caractéristique qui contribue au succès de C++ est la compatibilité avec le C. Le fait que du code écrit il y a plusieurs décénies peux être utiliser avec du C++ moderne.

Il est tout à fait possible d'utiliser le C++ sans utiliser les fonctionalités rétrogrades.
Et le C++ moderne n'est pas si horrible.

Les languages « meilleurs » qui ont retiré la compatibilité n'ont pas eu beaucoup de succès. (Exemple: D.) (Et je suis curieux de voir ce que va devenir Rust.)

Exactement. Exemple:

enum MySuperEnum {
#define X(NAME, VALUE, ACTION)  SuperEnum_##NAME = VALUE,
#include "super_values.def"
#undef X
};

/* ... Plus loin  ...   */

vod MyClass::maFunction(MySuperEnum foo) {
  switch (foo) {
#define X(NAME, VALUE, ACTION) case SuperEnum_##NAME : ACTION; break; 
#include "super_values.def"
#undef X
 }
}

Le premier bout de code est dans un header mais le tout fini dans la même translation unit

Le fichier super_value.def ressemble à ça:

X(Addition, 13,  Val0 = Val1 + Val2)
X(Division, 21,  Val0 = Val1 / Val2)
X(SelfAddition, 42,  Val0 += Val1)
// ...

(possiblement auto-généré)

Je debug quasi uniquement à l'aide de printf qDebug()

Sans oublier que MSVC, le compilateur C++ de Microsoft, est l'équivalent de IE en ce qui concerne le support des standard.
C++11 est normalisé depuis 3 ans. MSVC est terriblement en retard comparer aux équivalent libre (clang et GCC). Même la dernière version ne supporte pas encore tout.

Les compilateurs modernes reconnaissent les include guards et effectuent la même optimisation que pour #pragma once.

(mais je ne veux pas dissuader l'utilisation de #prama once qui est bien moins sujet à l'erreur)

planter lamentablement (kdevelop, c'est de toi que je parle).

Chez moi ça marche très bien.
Quelle version de KDevelop as tu utilisé ? Pourquoi plantait-il ?

C'est bien joli en effet.

Notez que le but original du projet ownCloud était aussi de regrouper toutes les applications dans un même site.
D'ailleurs, owncloud dispose aussi d'un lecteur RSS et d'une application qui intègre Roundcube. Toutes les activités sont accessible via le menu de owncloud.

(le projet owncloud est même en train de développer un nouveau webmail: https://github.com/owncloud/mail )