Gof a écrit 2224 commentaires

Non.

Je ne savais pas ce qu'était le polymorphisme paramétrique, donc j'ai recherché. Mais apparemment, ça correspond juste aux fonction templates ou aux overloads en C++ qui sont de base dans le langage.

Ce que cet article essaye de décrire (assez mal je trouve) c'est le « type erasure ». Mais on est sur un blog dédié au C++, il faut s'attendre à du C++ porn.
En pratique, les développeurs utilisent simplement QVariant ou boost::any pour faire du « type erasure » sans même avoir besoin de connaître le terme.

Il n'avait pas testé son code une seule fois, et n'avait fait que dans le structurel brut. […] et rien de fonctionnais lors du test.

Donc en gros tu préfère un truc qui ne fonctionne pas ?

Elle avait parfaitement structuré les choses, de façon souple et générique. Et donc, à démontré une connaissance avancé en programmation, en structurel et pas uniquement fonctionnel.

Mouais, l'important c'est d'avoir un truc qui marche, pas d'avoir un truc « souple et générique », en particulier quand cette fameuse généricité rends les choses plus compliqué que ce qu'elle ne devrait l'être.

À lire aussi: http://sebastiansylvan.com/2013/08/16/the-perils-of-future-coding/

Tu n'es pas obligé d'utiliser l'héritage multiple si tu trouves que ce n'est pas nécésaire.
En général on en a pas besoin, sauf quand justement on arrive sur un cas où c'est utile. Il est vrai que j'utilise rarement l'héritage multiple. Mais parfois il y a des cas où l'héritage multiple convient parfaitement et on a la chance de l'avoir dans le langage. Là ou dans d'autre language on a besoin de ressortir à des hacks imondes.

(Par contre, je n'ai jamais eu de cas où j'ai eu besoin de l'héritage virtuel)

Et encore, il a fallut ressortir des typeof ou des expressions { } qui sont des extantions GCC non standard. (Forcément, avec un langage minimal il faut des extensions pour faire quoi que ce soit :-))

Mais d'après toi il y a plus de cerveau capable de comprendre cette jolie macro que de comprendre cette ligne de code:

template<class T> struct Node { Node *right; Node *left; T value;  };

(Je ne sais pas ce que tu essaye de faire avec ton static_cast qui serait si intuitif dans un autre language.)

Je n'ai pas dit qu'il était impossible d'écrire des bugs en C++.

Je m'exprime peut être mal car apparemment je n'ai pas été compris.

Ce que je veux dire c'est que en C comme en C++ il y a des difficultés. Mais le langage courrant qu'un développeur C++ est amené à utiliser en pratique est plus simple d'utilisation que le C.

La preuve en est est que personne n'utilise/ne connaît tout

Mais ce n'est pas un problème. Il n'est pas nécessaire de tout utiliser.
Oui, le C++ est multi-paradigme. Et c'est un avantage.

C++ « makes it harder » grâce au fait qu'il est plus strictement typé et à une bonne gestion des resources (destructeurs). Et je ne comprends pas ce qu'il veut dire par « blows your whole leg off ». Peut être juste parce que le langage est plus puissant. Mais c'est juste une plaisenterie qu'il ne faut pas prendre sérieusement. (Il l'explique ici)

Bjarne à aussi dit:
« There are only two kinds of languages: the ones people complain about and the ones nobody uses. »

Tu veux dire que le compilo ne vérifie pas le type d'une fonction si la notation K&R est utilisé ?

Oui, car la fonction n'a pas de prototype. C'est comme déclarer

int foo();
// Ne pas confondre avec  int foo(void);

Et ni clang ni gcc me donnent un warning. (Il me mettent juste un warning car j'utilise printf sans <stdio.h>)

je n'ai jamais eu besoin d'utiliser un "void *",

Tu ne fait jamais appel à malloc ou memcpy ? Tu n'as jamais de callback qui prennent un void *userdata ? Jamais de macro pour implémenter des liste ou table avec des void* un peu partout ?

Quel genre de code fait tu?

m'étonnerait beaucoup qu'il ne génère pas de warning avec un code pareil

Essaye et sois étonné. :-) Pas de warning pour moi avec -Wall (mis a part le fait d'utiliser printf sans inclure stdio, et que j'ai oublié les return)

Ça compile, parce que c'est une fonction sans prototype dont type ne sont pas testé à la compilation.
Donc bar met des int sur la stack (ou dans les registre) et foo les interprette comme des double et donc ça donne n'importe quoi comme résultat.
Le code en C++ interdit la syntaxe K&R, donc tu ne peux pas écrire la même chose en C++.

Autre exemple:

struct A { int i; }; struct B { int i; };
int foo(struct A *a, struct B *b) {
    a->i = 108;
    b->i = 45;
    printf("%d\n",  a->i);
}

int main() {
    int i;
    void *q = &i;
    foo(q, q);
}

C++ ne compilera pas ce code car on ne peux pas caster implicitment par void* en C++. Alors qu'on fait tout le temps ça en C.
Et d'après toi, qu'est-ce que ce programme affiche ? Tu penses 45 peut être, puisque a et b pointent vers le même entiers. Mais pourtant gcc -O2 m'affiche 108. (Voilà ce qui arrive quand on fait de l'alias de type)

Il n'y a pas tout les pitfals.
Par example:

int foo(a, b) double a, b; { return a + b; }
int bar() { return foo(4,5); }  /* les paramettres on les mauvais type. Erreur bizzare à l'éxécution */

Et tu me dira que c'est du K&R et que personne utilise ça et tu auras raison. De la même manière, le C++ s'utilise différamment et les pitfalls du C ne sont donc pas directement gênantes en pratique.

Par ailleurs, si tu veux un langage sans pitfals, tu prends le brainfuck. Une spécifications qui tiens en une page, clair et facile à comprendre. Mais ça ne rends pas la programmation plus facile.
De même, le C++ est plus complex que le C, avec plus de pitfalls, mais en même temps plus facile à utiliser.

Je conseil aux « fanboys » C comme toi de lire un bouquin pour apprendre le C++ moderne, et faire un peu de code en C++. Et tu verra que après ça tu ne voudras plus retourner au C.

Qu'est-ce que tu essaye de démontrer ?
Oui, il y a des pitfals en C++ comme en C.
C++ est plus gros et a donc plus de pitfals. Mais un développeur normal n'utilise pas tout le langage et en particulier n'utilise pas de la même manière les fonctions du C. Mettant les deux langage à égalité en pratique.

Par contre, les fonctionnalités du C++ rendent le dévelopemment plus confortable, moins fastidieux, et plus sûr. Ce qui rends le langage C obsolète face au C++.

Le C n'est plus simple que pour quelqu'un qui a plus d'expérience en C et peu en C++. La bonne nouvelle c'est que l'expérience s'aquiert vite quand on y met du sien.

C’est quoi l’équivalent pour les templates C++ ?

Bah le compilateur. Quand il y a un truc louche il te donne une erreur détaillée avec une « backtrace » des instentiations.

Pour quelqu'un qui connais bien le C et n'a jammais appris le C++ je comprends que les templates peuvent parraître difficile. Mais un dévelopeur C++ est sensé apprendre le language pour l'utiliser. Après la lecture du chapitre « template » du bouquin qu'il utilise pour apprendre le C++, les templates ne seront plus une bête noir qui fait peur.

C++ a exactement le même préprocesseur que C.
Je serais curieux de savoir quelle notion de "compliquée" de C n’existe pas en C++…

Les notions compliquées du C existe aussi en C++ mais elles sont moins importante.
En C++ on fait moins appel au préprocesseur pour implémenter des conteneurs ou méthode générique car on a les template en C++.
En C++ on fait moins de casting vers void* car on a un système de type correct, et donc on a moins de problème de type aliasing ou de se tromper de type ou se genre de chose. En C++ on a des smart pointer et donc on a moins de problème de memory leak.

Le C reste un langage petit et léger qui pourrait être un langage d'assemblage moderne.

C: a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language

Typiquement, une fonctionnalité très appréciée est le template mais ça induit une complexité énorme derrière et son usage est particulièrement vaste en terme de possibilité comme en difficulté dans sa gestion et le débogage.

Parce que des macro c'est plus facile à débugger peut être ?
Au moins les templates sont typées et pas avec des (void*) à tout bout de champs.
Bref, plus sûr et plus confortable. (Et pas plus compliquée que d'autre notions du C)

echo "foo(a, b) int a, b; {return 8;}" | clang -fsyntax-only -ansi -pedantic -std=c11 -xc -Wall -
<stdin>:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
foo(a, b) int a, b; {return 8;}
^~~

GCC et Clang acceptent sans problème le style K&R, et le même le fait d'omettre le type de retour n'est qu'un warning. Normal le standard dit que c'est autorisé.

Merci mais ici la macro I est une constante.

Oui mais on peux redéfinir des constantes dans une autre scope. Si I était juste une constante, le code compilerais sans problème. Le problème c'est que les macros polluent tout et ne respectent pas les scopes.

Enfin de toute façon c'est du pinaillage. Mais ça prouve que même si le C est simple comme tu dit. Tu ne connais pas tout non plus. (Pour ta défense, tu n'as jamais dit que tu maîtrisais tout le C).

tu as pas mal de manières de faire une tâche donnée, ce qui peut rendre le code plus sale.

Bah tout les langages de programmation on plusieurs manières. là encore C et C++ sont au même niveau.

Bref, tout les inconvénients que tu attribues au C++ le sont juste parce que tu a plus d'expérience en C. Et tu passe totalement à coté des nombreux aventages du C++.

Bah c'est facile, ma sœur de 5 ans peut mieux connaitre le C++ du C si je lui apprends les bases du C++.

Tu parlais de moi. Pas de ta sœur.

Je parle personnellement de connaitre de manière exhaustive un langage

Mais personne (pratiquement) ne connais de manière exhaustive le C.

Le type complex est déprécié depuis C11

Non. Pas déprécié, juste facultatif.

Tu utilises la notation pré-ANSI, interdite depuis C90

Interdite par qui ? Pas par le standard en tout cas. (même si les fonction sans protoype sont marqué comme obsolète, ils font toujours partie du standard. C'est loin d'être interdit)

Tu redéfinies une constante préalablement définie dans l'en-tête.

Non plus.
J'utilise une macro (car I est une macro). Et le truc c'est que c'est pas évident de voir en lisent le code ou les message d'erreur que c'est le cas.

Tu en veux d'autres ?

Oui je veux bien.

Non, car personne ne nomme ses variables en une seule lettre majuscule

Et moi je prétends au contraire que tout développeur C utilise parfois des variable d'une lettre. Qui de nous deux à raison ?

Pour la majuscule ça dépends du coding style. Par exemple, dans LLVM, les variables commencent par une majuscule. Et il y a beaucoup de variables d'une lettre.

(Hop, un contre exemple pour ta proposition. Arrivera tu a trouver un exemple de projet dans lequel il n'y a aucune variable d'une lettre?).

Je veux montrer que même le C est compliqué et a des messages d'erreurs difficile à comprendre.

En général on fait

#include <complex.h>
#include "monheader.h"

Et on se retrouve avec une erreur de compilation incompréhensible dans monheader.h

---

Par ailleurs, le brainfuck par exemple a une bien plus petit standard, mais ça n'en fait pas un langages plus facile.

Bien vu, c'est une erreur de compilation. (Le K&R c'était pour induire en erreur :-)). Mais tu vois quel est le problème?
(Après avoir corrigé le warning avec s/complex /double complex /g )

Pourquoi l'interdire ? C'est pratique pour des itérateurs par exemple.

En cherchant rapidement dans les sources de OSv, j'ai pas trouvé d' operator+ Par contre, j'ai vu de la surcharge pour ==, ++ , * , -> , et <

tu peux appréhender les 700 pages de la norme du langage C pour connaitre ses limites et les nuances délicates. En C++ tu ne peux pas, pas de manière aussi exhaustive.

Raté, Je connais mieux le C++ que le C.

Personne ne peux connaître parfaitement aucun des deux standards. Si tu n'utilise pas les exception ou ne fait pas de métaprogrammation, tu peux sauter cette partie.

Petit jeux: si tu prédends si bien connaître le C, voici un petit exercice: trouve l'erreur dans ce code en C

#include <complex.h>
complex foo (C, N) complex *C; int N; {
    complex S = 0;
    for (int I = 0; I < N; ++I) S += C[I];
    return S;
}

---

Bof, là encore je pense que c'est discutable par moment.

Meilleure vérification des types, smart pointers, destructeurs, templates (au lieu de macro non sûr), et j'en passe. Je ne vois pas comment tu peux discuter ça.

En C++, c'est bien plus délicats.

Non, en C++ c'est exactement pareil.
Dans les deux cas il y a des nuances compliquées. (Mais c'est normal que un expert en C qui ait des années d'expérience en C comme Linus soit plus habitué au nuances du C qu'à celle du C++.)

Et c'est sans parler de la correspondance instruction / binaire qui est également délicat

Pareil en C et C++.

Bah si, c'est un fait que le C est plus rapide à porter sur une architecture donnée

Un code en C est en général plus verbeux qu'un code en C++. Donc je dirais que c'est l'inverse.

(ou alors tu m'expliques comment un langage avec une norme de 1700 pages fait pour être porté plus vite qu'un langage de 700 pages de normes…).

Parce que tu ne réécris pas le compilateur quand tu porte. Tu réécris seulement le backend. Par exemple, dans le cas de LLVM tu ne réécris que la partie de génération de code, qui est la même pur C et C++

Bref, le C n'est pas parfait et le C++ non plus.

Oui, mais le C++ est mieux. Plus confortable et plus sûr.
C'est pour ça que je pense que le C++ est le meilleur choix.
(Pas qu'il est parfait, et peut être que dans 5 ans il existera un meilleur pour faire un OS. (rust?))

C'est très discutable, en tout cas maitriser la norme C++ et ses sous-ensembles est humainement impossible

C n'est pas facile non plus. Même les experts on du mal a prédire son comportement. (undefined behaviour, ….)

Même Linus se fait avoir: http://lwn.net/Articles/478657/

Avoir du C standard est plus rapide à porter sur n'importe quelle architecture, pour le C++ le travail sera plus long (ou limité à une fraction du standard).

Euh non, pourquoi ?

Sinon j'ai trouvé des exemples de OS écrit en C++: Symbian / Haiku.
Les nouveaux OS ne sont plus écrit en C

On parlais du C++ là, pas du C. Il s'agit de deux langages différents je te rappel.

C'est caché pour quelqu'un qui ne connait pas le C++ peut être. En attendant, le code en C++ est plus clair et moins prône à l'erreur.

C'est faux. Il y en a pleins. Tu sélectionnes ce qui t'arrange

Non, ce que je vois c'est juste les délires d'un vieux grincheux qui a peur de ce qu'il ne connait pas. Il n'y a que du subjectif dans son mail et aucun vrai argument..

Les kernels majeurs sont écrits en C

Parce que ils ont été écrit dans les années 90 avant même que C++ ne soit standardisé.
Maintenant on est en 2013, il faut évoluer.

Même des trucs aussi anodin que « b = a » ou « c = a + b ».

Pourquoi tu dis que c'est anodin ? C'est si difficile à comprendre que chaque opération est un appel de fonction ?

Les 2 posts

Ces deux postes ont déjà été écrit maintes fois. Les postes n'ont aucun arguments et sont juste des préférence. « Ugly » et « Utter crap » ne sont pas des arguments. Linus a l'habitude du C et il est trop vieux pour changer peut être. RMS m'aime peut être pas le hard rock (« too harsh »), ça m'empêche pas d'en écouter.

Cela reste à prouver…

Bha il me semble que ce projet le prouve.

De mémoire, il me semble qu'un passage d'objet par valeur fait un appel à calloc/malloc.

Oui en effet, il est possible que le constructeur de copie de certains object alloue de la mémoire. C'est la responsabilité du développeur de le savoir. Il doit connaître l'API des object qu'il utilise et c'est documenté.

Mais bon, pour utiliser un langage il faut l'apprendre. Un peu comme si je disais "Le problème en C c'est que ça crash tout le temps"

ça c'est faux. Il suffit de voir la taille des normes respectives.

La taille des normes ne veux rien dire. C'est parce que le C++ a une plus grosse bibliothèque standard qui fait plus de chose. Le standard est plus gros car le développeur dois faire moins.