Discussion :

[davcha]

La JVM est standard.

Non, il y a un monopole de sun et une spécification dont ils sont les seuls maitres. Ce devient beaucoup plus facile pour mettre tout le monde d'accord.

Ok, donc il n'y a pas de norme ISO, mais une norme unique définie par SUN... Donc c'est standard, quoi.

Concernant la meilleure portabilité de Java par rapport au C/C++, je vais dire ça autrement pour que ça soit clair : un mec qui n'est pas technicien ou mieux, bref un utilisateur lambda qui n'y connait rien en informatique, à part "démarrer...word", "démarrer...logiciel de compta" et qui aimerait bien un logiciel de "je ne sais pas quoi" écrit soit en C, C++ ou Java... Lui il s'en fiche que ça soit du C, du C++ ou du Java, tout ce qui l'intéresse c'est de pouvoir faire : "démarrer.... logiciel en C, C++ ou Java" et que ça marche sans qu'il ait besoin de compiler (alors qu'il ne sait même pas ce que signifie "compiler") ou autre manip qui sera perçue, par lui, comme étant de la haute voltige en informatique.

Bref...

Le troll initial ce n'était pas C vs C++ ?

Ce troll était débile, fallait bien le faire évoluer.

[Matthieu Brucher]

Concernant la meilleure portabilité de Java par rapport au C/C++, je vais dire ça autrement pour que ça soit clair : un mec qui n'est pas technicien ou mieux, bref un utilisateur lambda qui n'y connait rien en informatique, à part "démarrer...word", "démarrer...logiciel de compta" et qui aimerait bien un logiciel de "je ne sais pas quoi" écrit soit en C, C++ ou Java... Lui il s'en fiche que ça soit du C, du C++ ou du Java, tout ce qui l'intéresse c'est de pouvoir faire : "démarrer.... logiciel en C, C++ ou Java" et que ça marche sans qu'il ait besoin de compiler (alors qu'il ne sait même pas ce que signifie "compiler") ou autre manip qui sera perçue, par lui, comme étant de la haute voltige en informatique.

D'où les programmes d'installation.

[davcha]

Lesquels ?

Les programmes du genre "setup.exe" suivi d'un assistant d'installation qui prend tout en charge ou bien les makefile si chers aux utilisateurs des systèmes unix ?

[Aurelien.Regat-Barrel]

On entre dans un troll Windows vs Linux là.

[Matthieu Brucher]

Lesquels ?

Les programmes du genre "setup.exe" suivi d'un assistant d'installation qui prend tout en charge ou bien les makefile si chers aux utilisateurs des systèmes unix ?

Non, je parle bien de programme d'INSTALLATION, pas de compilation.
Pour MacOS, il y a un format, pour Windows, il y a pleins de solutions, pour Linux, il a la série des apt sous Debian et dérivés,yum poour FC, ... Tout est automatique pour ces bestiaux.

[davcha]

Oui, dans ce cas, on est d'accord.

Enfin, il restera peut-être l'avantage à Java que l'utilisateur n'aura pas trop à se poser la question "bon, c'est lequel que je dois télécharger" quand il sera face à la longue liste d'installeurs (qui n'existera donc pas en java)... M'enfin bon, ça c'est vraiment négligeable comme "avantage".

(à noter que je ne suis pas un grand fan de java, mais pour d'autres raisons :p)

[Matthieu Brucher]

Ben si, il faut bien l'installer, la JVM, donc on va prendre laquelle ? Pour installer OOo, il ne suffit pas de le copier sur le disque dur

[Invité]

[HS : Le sujet dérive, on est plus du tout dans le C vs C++ mais dans le C++ est-il portable...]

L'argument "si le programmeur fait n'importe quoi c'est plus portable" n'est pas recevable. Sans connaitre en profondeur le java, je me doute qu'il y a des tas de trucs qui ne marchent que sur un système donné (ou une JVM donnée).
Le C++ dispose d'un comité de normalisation. Mettons-nous d'accord : quand on parle de C++, c'est bien sûr du C++ respectant cette norme (tout comme le java avec sa propre norme).
Un programme écrit en C++ est potentiellement utilisable sur n'importe quelle machine où un compilateur a été porté, si les librairies qu'il utilise y ont été portées aussi (sauf bien sûr si on utilise que la STL, qui est portée évidement sur tous les systèmes où un compilateur est implémenté). C'est pareil pour le java, et même tout autre langage : le java est portable sur toute machine qui dispose d'une JVM avec toutes les librairies dont le programme a besoin.

C'est là normalement qu'on sort un "pour revenir au sujet" ou formule équivalente, mais le débat en question est un peu loin maintenant ><

[Startux]

Bonjour à tous,

Je voulais intervenir dans cette discussion forte intéressante parce que je développe beaucoup plus en C++ alors qu'au début je le faisait en C.
Voici la remarque que je pourrais faire. J'ai eu quelques projets de développement à réaliser et la plupart du temps en effectuant des recherches sur internet je trouvais des SDK (de DirectX ou de WMP ou encore de Pocket PC) qui sont fait grâce à des interfaces (C++). Ce qui nous oblige à passer au C++ plutôt que rester en C. Pour moi, l'intérêt est là, pourquoi s'obstiner à rester en C alors que le développement s'oriente de plus en plus vers le C++.

---

Un travail semble bien réalisé que si on le présente sous ses beaux jours

[koala01]

Bonjour à tous,

Je voulais intervenir dans cette discussion forte intéressante parce que je développe beaucoup plus en C++ alors qu'au début je le faisait en C.
Voici la remarque que je pourrais faire. J'ai eu quelques projets de développement à réaliser et la plupart du temps en effectuant des recherches sur internet je trouvais des SDK (de DirectX ou de WMP ou encore de Pocket PC) qui sont fait grâce à des interfaces (C++). Ce qui nous oblige à passer au C++ plutôt que rester en C. Pour moi, l'intérêt est là, pourquoi s'obstiner à rester en C alors que le développement s'oriente de plus en plus vers le C++.

---

Un travail semble bien réalisé que si on le présente sous ses beaux jours

Je suis, pour une grande partie d'accord avec toi, mais, il existe aussi quelques de bibliotheques qui sont exclusivement écrites en C, et dont l'usage en Orienté Objet ne va pas *forcément* sans poser problème...

A titre d'exemple, je prendrais simplement la bibliotheque OpenGl (et descendants directs: glut en tete) que je n'ai jamais réussi, pour le peu que j'ai essayé, à intégrer à une programmation orientée objet en C++ (et dont l'intégration dans un projet orientée objet est très mal documentée sur le net...Mais peut etre n'ai-je simplement pas cherché au bon endroit?)...

D'autant que, à choisir, j'aurais autant aimé éviter les inconsistances entre windows et linux (dans les parametres fournis à main, entre autres)

Maintenant, c'est peut etre tout simplement parce que je m'y suis très mal pris (je dirais presque que c'est très surement le cas)...Mais, actuellement, c'est mon avis et je le partage

[soleuh]

La JVM est une plateforme. Java ne tourne (officiellement) que sur la JVM. La JVM est portable, mais java ne l'est pas

Sinon, quelqu'un parlait de coder un kernel en C++ dans le thread. J'ai bien peur que ce ne soit pas si simple. C'est tout à fait faisable (voir les efforts faits sur L4) mais uniquement avec un sous ensemble du C++ (Je ne sais plus ce qu'il ne faut pas utiliser exactement, mais les exceptions en sont un exemple). Donc sans l'utilisation des exceptions, la STL me semble difficile à utiliser. De plus l'argument souvent énoncé contre le C++ dans les kernel est le fait de savoir ce que fait exactement le programme, lors d'un new par exemple (dans un kernel il faudrait surcharger le new, comme on utilise pas malloc mais kmalloc, sinon utiliser le kmalloc en question et ne plus faire du C++).

Et l'argument de la métaprogrammation ne me semble pas pertinent dans le cadre d'un kernel, mais je me trompe peut être.

[Jean-Marc.Bourguet]

Sinon, quelqu'un parlait de coder un kernel en C++ dans le thread. J'ai bien peur que ce ne soit pas si simple. C'est tout à fait faisable (voir les efforts faits sur L4) mais uniquement avec un sous ensemble du C++ (Je ne sais plus ce qu'il ne faut pas utiliser exactement, mais les exceptions en sont un exemple).

Pourquoi? Il faut implémenter un certain support -- soit la gestion des tables des "zero-cost exceptions", soit l'équivalent de setjmp/longjmp, soit une autre structure encore -- mais ce n'est pas très difficile (j'ai travaillé sur un moniteur temps réel qui avait un système d'exceptions, on le programmait en assembleur mais je ne vois rien qui empècherait un compilateur d'utiliser une infrastructure semblable).

Donc sans l'utilisation des exceptions, la STL me semble difficile à utiliser.

Tout dépend ce que tu entends pas la STL. J'utiliserais les algorithmes sans hésiter. Les conteneurs, certainement pas; j'en écrirais avec la même interface mais réglé différemment.

De plus l'argument souvent énoncé contre le C++ dans les kernel est le fait de savoir ce que fait exactement le programme, lors d'un new par exemple (dans un kernel il faudrait surcharger le new, comme on utilise pas malloc mais kmalloc, sinon utiliser le kmalloc en question et ne plus faire du C++).

En quoi est-ce un argument contre le C++? Au contraire d'autres langages, le C++ permet justement de gérer ce niveau là en restant dans le langage.

Et l'argument de la métaprogrammation ne me semble pas pertinent dans le cadre d'un kernel, mais je me trompe peut être.

La méta-programmation est une technique parfois utile. Pas trop souvent en pratique en C++ car elle est trop complexe à mettre en oeuvre et trop fragile à mon goût, mais je ne vois pas pourquoi elle serait moins pertinente pour un kernel qu'ailleurs.

[soleuh]

Pourquoi? Il faut implémenter un certain support -- soit la gestion des tables des "zero-cost exceptions", soit l'équivalent de setjmp/longjmp, soit une autre structure encore -- mais ce n'est pas très difficile (j'ai travaillé sur un moniteur temps réel qui avait un système d'exceptions, on le programmait en assembleur mais je ne vois rien qui empècherait un compilateur d'utiliser une infrastructure semblable).

http://www.codeproject.com/cpp/exceptionhandler.asp
Pour cette raison à priori. Si tu utilise "throw" avec un compilateur standard, je crois bien que tu vas avoir du mal à faire fonctionner ton kernel. Maintenant, tu peux peut-être utiliser une macro façon C, mais ce n'est plus vraiment les exceptions du C++...

Tout dépend ce que tu entends pas la STL. J'utiliserais les algorithmes sans hésiter. Les conteneurs, certainement pas; j'en écrirais avec la même interface mais réglé différemment.

C'est ce qui a été fait dans fiasco, d'après ce que j'ai pu voir du code, en ce qui concerne les conteneurs, et les auto_ptr.

En quoi est-ce un argument contre le C++? Au contraire d'autres langages, le C++ permet justement de gérer ce niveau là en restant dans le langage.

http://www.linuxjournal.com/article/6930
Il y a aussi le vmalloc... et kmalloc utilise des flags. Bref les new me semblent difficile en mode kernel. Encore une fois, on peut surement imaginer quelque chose à base de factory, je ne dis pas le contraire. C'était le premier exemple qui me passait par la tête, sachant que nombreux sont les arguments qui n'en sont pas vraiment. Il s'agit souvent d'une méconnaissance du C++ (et de l'assembleur généré par le compilateur).

La méta-programmation est une technique parfois utile. Pas trop souvent en pratique en C++ car elle est trop complexe à mettre en oeuvre et trop fragile à mon goût, mais je ne vois pas pourquoi elle serait moins pertinente pour un kernel qu'ailleurs.

Je ne sais pas, c'est juste une impression !
Maintenant, j'ai lu du code de kernels, je n'en ai jamais codé moi même, donc les réponses d'un spécialise seraient certainement plus précises (voir infirmeraient les miennes ? )

[Jean-Marc.Bourguet]

http://www.codeproject.com/cpp/exceptionhandler.asp
Pour cette raison à priori.

Je n'ai survollé que rapidement la page. Je ne vois pas en quoi la technique d'implémentation des exceptions de VC++ empèche son utilisation dans un kernel -- elle a besoin du support du runtime et il faut écrire ce support, mais c'est quelque chose qui devrait être à la portée de qui envisage d'écrire un kernel. D'autre part il y a au moins deux autres techniques qui sont utilisées, et je ne vois pas non plus ce qui empècherait leur utilisation dans un kernel.

Si tu utilise "throw" avec un compilateur standard, je crois bien que tu vas avoir du mal à faire fonctionner ton kernel.

Pourquoi? VC++ met des frames un peu particulière, il suffit de les
interpréter dans le kernel quand on jette une exception. Mais si j'avais à
faire un kernel en C++, je n'utiliserais pas VC++ mais g++ qui serait
beaucoup plus facile à adapter pour cet usage -- en particulier on pourrait
modifier la génération de code pour les exceptions si aucune des techniques qu'il support ne convient (mais j'en doute).

http://www.linuxjournal.com/article/6930
Il y a aussi le vmalloc... et kmalloc utilise des flags. Bref les new me semblent difficile en mode kernel. Encore une fois, on peut surement imaginer quelque chose à base de factory, je ne dis pas le contraire. C'était le premier exemple qui me passait par la tête, sachant que nombreux sont les arguments qui n'en sont pas vraiment. Il s'agit souvent d'une méconnaissance du C++ (et de l'assembleur généré par le compilateur).

Qu'est-ce qui gène? Surcharger l'opérateur new et remplacer l'opérateur new global, ce n'est pas de la magie noire, c'est quelque chose de supporté par tous les compilateurs conformes -- et je doute qu'il y en ait beaucoup qui ne le soit pas sur ce point.

[koala01]

(...). Je ne vois pas en quoi la technique d'implémentation des exceptions de VC++
(...)
g++ qui serait beaucoup plus facile à adapter pour cet usage -- en particulier on pourrait modifier la génération de code pour les exceptions si aucune des techniques qu'il support ne convient (mais j'en doute).

Heu... Dans le cadre de la création d'un noyau linux car c'est de cela que parle
(AMHA) soleuh, ce serait plutot effectivement g++...

Mais, de fait, la surcharge de new et de delete n'est pas *si* compliquée que cela...

Par contre, je peux concevoir que l'utilisation des exceptions STL puisse présenter quelques problemes... Meme si certains de ceux que j'envisage sont sans doute tout à fait faux (je n'ai en effet qu'une tres vague idée du fonctionnement du noyau linux )

[soleuh]

Je n'ai survollé que rapidement la page. Je ne vois pas en quoi la technique d'implémentation des exceptions de VC++ empèche son utilisation dans un kernel -- elle a besoin du support du runtime et il faut écrire ce support, mais c'est quelque chose qui devrait être à la portée de qui envisage d'écrire un kernel. D'autre part il y a au moins deux autres techniques qui sont utilisées, et je ne vois pas non plus ce qui empècherait leur utilisation dans un kernel.

Tout simplement parceque la résolution de l'exception passe par le kernel..

Qu'est-ce qui gène? Surcharger l'opérateur new et remplacer l'opérateur new global, ce n'est pas de la magie noire, c'est quelque chose de supporté par tous les compilateurs conformes -- et je doute qu'il y en ait beaucoup qui ne le soit pas sur ce point.

Rien ne me gène, et je sais comment fonctionne la surcharge d'opérateur, merci. Mais, comme, dans linux en tous cas, il existe plusieurs moyens d'allouer de la mémoire (kmalloc, vmalloc, je crois qu'il y en a d'autres...). Je ne vois pas de raison d'utiliser de new du tout (pourquoi en favoriser un plutôt qu'un autre ?)

Je n'ai pas dis que je comprennais pas le C++, je n'ai pas dit que c'était impossible de faire un kernel en C++, d'ailleur il existe des patchs pour le noyau linux permettant d'ajouter des modules en C++, et des implémentations du L4 en C++. Mais je ne suis pas persuadé de la pertinence de ce choix (par contre, j'aurai bien aimé essayé de le faire, si j'avais eu les compétences et surtout le temps). En effet, que reste-t-il une fois que l'on a enlevé les exceptions, le new, une grande partie des méthodes virtuelles.. ? Même si c'est pour les réimplémenter à sa sauce, on utilise peu des possibilités du C++. Si c'est pour faire du C sur un compilateur C++, je ne vois pas l'interêt.

Mais, de fait, la surcharge de new et de delete n'est pas *si* compliquée que cela...

Ce n'est pas compliqué du tout même, mais ça a été conçu pour fonctionner en espace utilisateur....

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

http://kerneltrap.org/node/2067

[loufoque]

des implémentations du L4 en C++

C'est pas vraiment du beau C++ par contre.

L'intérêt principal du C++, c'est le RAII et la définition de sémantiques de valeur propres pour des types utilisateurs.

Linus Torvalds a écrit : [...]

C'est pas parce qu'il a écrit un noyau à la mode que tout ce qu'il dit c'est forcément bien.

[gege2061]

C'est pas parce qu'il a écrit un noyau à la mode que tout ce qu'il dit c'est forcément bien.

Nan mais il a tout de même un minimum d'expérience dans ce domaine (plus que dans le choix d'un environnement de bureau, j'espère )

[soleuh]

C'est pas vraiment du beau C++ par contre.

Assez d'accord, c'est pourquoi, AMHA, l'interêt du C++ sur le C dans un kernel est minimal. D'ailleur il nécessite une certaine connaissance du C++ que tout le monde ne possède pas........

C'est pas parce qu'il a écrit un noyau à la mode que tout ce qu'il dit c'est forcément bien.

Tout ce qu'il dit, non. Mais en l'occurence, il parle de développement de kernel là. Comme le dit gege2061, ça n'est tout de même pas le premier venu. Il dit qu'il a essayé, que ça n'avait pas d'interêt (en plus qu'à l'époque le C++ n'était pas encore assez mure pour ce genre de developpement).

[Jean-Marc.Bourguet]

Tout simplement parceque la résolution de l'exception passe
par le kernel..

Et? Si on est dans le kernel, qu'est-ce qui gène?

Rien ne me gène, et je sais comment fonctionne la surcharge d'opérateur, merci. Mais, comme, dans linux en tous cas, il existe plusieurs moyens d'allouer de la mémoire (kmalloc, vmalloc, je crois qu'il y en a d'autres...). Je ne vois pas de raison d'utiliser de new du tout (pourquoi en favoriser un plutôt qu'un autre ?)

À quoi sert la syntaxe de placement new et la possibilité de définir des
opérateurs new par classe si ce n'est à offrir des variantes?

Je n'ai pas dis que je comprennais pas le C++, je n'ai pas dit que c'était impossible de faire un kernel en C++, d'ailleur il existe des patchs pour le noyau linux permettant d'ajouter des modules en C++, et des implémentations du L4 en C++. Mais je ne suis pas persuadé de la pertinence de ce choix (par contre, j'aurai bien aimé essayé de le faire, si j'avais eu les compétences et surtout le temps). En effet, que reste-t-il une fois que l'on a enlevé les exceptions,

Je suis toujours loin d'être convaincu que les exceptions ne sont pas utilisables.

le new,

Je ne vois toujours rien de génant

une grande partie des méthodes virtuelles.. ?

Qu'est-ce qui gène ici?

Même si c'est pour les réimplémenter à sa sauce, on utilise peu des possibilités du C++. Si c'est pour faire du C sur un compilateur C++, je ne vois pas l'interêt.

Même si on n'utilise que les virtuelles (c'est utiles dans le noyeau, tous les réinvente), les templates et le fait qu'en général on a une meilleure encapsulation qu'on n'est pas obligé de sacrifier à l'autel des performances... on a gagné quelque chose par rapport au C. Il ne faut pas oublier que le C++ s'est d'abord répandu en tant que "better C" et ensuite on a commencé à se servir des possibilités supplémentaires.

The fact is, C++ compilers are not
trustworthy. They were even worse in 1992, but some fundamental facts
haven't changed:

En 1992, je n'aurais pas peut-être pas plus utilisé du C++, le langage
étant alors trop en évolution.

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.

Là il faudrait argumenter un peu plus. J'aimerais bien savoir ce qui est
cassé.

- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.

Quelle construction du C++ fait des allocations mémoires toute seule?

- you can write object-oriented code (useful for filesystems
etc)

Là nous sommes d'accord.

in C,

On peut tout faire en C, il suffit d'écrire une machine virtuelle qui se comporte comme on veut... on peut même généralement utiliser des méthodes plus efficaces que ça...

_without_ the crap that is C++.

Précision?

In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems

Visiblement... mais je ne vois pas trop l'intérêt du C++ pour un module dans un noyeau écrit pour le reste en C; l'échelle est trop petite pour que les intérêts majeurs du C++ se manifestent, et les inconvénients d'avoir une partie écrite dans un langage non maîtrisé par le reste des mainteneurs sont certains.