C++ vs C

Citation:

---

Envoyé par Caine

Bonjour,

Les vectors sont utiles quand on veut une donée extensible facilement et sûre, avec les mêmes performances d'accés et simpliciter d'ecriture qu'un tableau.

Cependant, même si la taille est statique, il est intéressant de passer par la classe vector, pour les opérations de recherche...

Mias, on ne dévie pas un peu du sujet là :)

---

A ce sujet, boost::array permet d'avoir les avantages d'un vector pour un tableau de taille fixe, tout en étant plus rapide puisque le redimensionnement n'est pas géré ;)

Citation:

---

Il n'y a absolument aucun algorithme que l'on ne peut résoudre que en programmation orientée objet.

---

Citation:

---

Une machine de turing peut résoudre n'importe quel algorithme.

---

ps: une machine de turing est séquentielle.

Citation:

---

Bonjour,
qlq'un connaitrait il un exemple d'algorithme qui ne pourrait etre resolu qu'en programmation OO (ou alors tres difficilement par un autre type de programmation)?

---

Normalement le concept objet et d'orienter la programmation autour des données ,ce qui fait que les donnés sont reutlisables pour des traitements differents .Tu pourraiias aussi ecrire du code c a l'interieur du c++:

Code:

---

1 2 3 4

extern "c"{ declarations en c }

---

Citation:

---

Envoyé par boulde

si j'ai bien compris en C++ les références permettent de simplifier l'utilisation des pointeurs, pas besoin de se demander si c'est un pointeur ou pas:

Citation:

---

&double fonction( int &a, char &name) ???

---

mais je me suis toujours pas décidé a remplacer mes * par des & ... :?

---

Au contraire, les références nuisent à la lisibilité du code: tu lis ceci:

Code:

---

1 2 3

cout << a.b; fonction(a); cout << a.b; // ?? a.b vient de changer? C'est pourtant pas un pointeur!!

---

Et si tu lis ceci:

Code:

---

1 2 3

printf("%08X", a.b); // PS: comment on fait de l'hexa sur 8 chiffres avec cout ? fonction(&a); //Ah, un pointeur. S'il n'est pas const, il pourrait bien modifier... printf("%08X", a.b); //Ah, ben oui il modifie...

---

Pour moi, les références, c'est à n'utiliser que là où les pointeurs ne marchent pas : Les surcharges d'opérateurs, par exemple (et encore, attention aux plaisantins qui s'amusent à modifier une valeur qu'on ne s'attend pas à ce que l'op modifie...

Mais les références mises à part, le C++ est plein d'avantages. La facilité de programmation orientée objet est bien utile.

Personnellement je trouve que les références rendent le code plus facile à lire.

Mais elles sont là surtout pour empécher de passer des pointeurs nuls. Finis la programmation défensive à outrance sur (pointeur != NULL).

Citation:

---

Envoyé par Médinoc

Au contraire, les références nuisent à la lisibilité du code: tu lis ceci:

Code:

---

1 2 3

cout << a.b; fonction(a); cout << a.b; // ?? a.b vient de changer? C'est pourtant pas un pointeur!!

---

---

Quand je lis ceci, je trouve que des baffes se perdent. On n'appelle pas une fonction "fonction". Plus sérieusement, bien que cela soit la même idée, il est bon que le rôle de la fonction, et/ou ce qu'elle va faire de ses paramètres, transparaisse dans son nom. Au pire dans tous les cas, c'est documenté.

Et puis on n'appelle pas une fonction sans savoir ce qu'elle fait, non ? Si dans la signature j'ai une référence non constante, je sais que le paramètre en en [out], voire [in,out]. Mais certainement pas en [in]. Et quand ce n'est pas le cas, j'ai tendance à faire savoir que c'est n'importe quoi et je remets les consts oubliés.

En général, j'ai des pointeurs bruts quand la sémantique des opérations mises en oeuvre le requiert.

Citation:

---

Envoyé par Luc Hermitte

Et puis on n'appelle pas une fonction sans savoir ce qu'elle fait, non ?

---

J'ai jamais dit que c'était moi qui l'appelais... Quand tu regardes le code d'un autre et que tu essaies de le comprendre (surtout s'il n'est pas assez commenté) C'est pas évident...

(quant à la signature de fonction, on n'a pas toujours une IDE qui l'affiche...)

C'était un exemple je pense ;). Vu que souvent les fonctions sont mal nommées ça se défend. Si les pointeurs pouvaient lever l'ambiguité, ce serait un plus. Si ils pouvaient... Car ton argumentaire ne tient pas:

Code:

---

fonction(&a); //Ah, un pointeur. S'il n'est pas const, il pourrait bien modifier...

---

il pourrait, mais on n'en sait rien, strictement rien. Pour être fixé, il faut aller regarder le prototype de fonction, si c'est

Code:

---

void fonction( const A * );

---

alors c'est pas modifié, si c'est

Code:

---

void fonction( A * );

---

alors c'est certainement modifié. Et avec les références, c'est exactement la même chose. Si c'est

Code:

---

void fonction( const A & );

---

alors c'est pas modifié, si c'est

Code:

---

void fonction( A & );

---

alors c'est certainement modifié.
Donc les référence peuvent peut être dissimuler la modification d'une variable (si le nom de la fonction est mal choisi etc...), mais les pointeurs à l'inverse font systématiquement penser que la variable est modifiée. Donc faut pas se fier à ça pour déterminer si une var est modifiée ou non.

En effet, il ne faut pas forcément s'y fier. Mais le & encourage à regarder le prototype, alors que quand on vient comme moi du C, on n'a pas encore forcément le réflexe de se dire "mince, ça pourrait bien être une référence, donc j'ai intéret à regarder".
Quand en C, on regarde le code d'un autre avec des tas de fonctions, on n'a pas toujours le temps de faire ça...

Enfin, c'est un réflexe supplémentaire à prendre. C'est toujours mieux que "int &b = a" (l'esprit humain a tendance à interpréter le code en "assume no aliasing"). On finit par s'y retrouver, mais je trouve les pointeurs plus explicites (malgré leur inconvénient de pouvoir être NULL en paramètre).

Citation:

---

on n'a pas encore forcément le réflexe de se dire "mince, ça pourrait bien être une référence, donc j'ai intéret à regarder".

---

Oui je comprend, je pensais ça aussi fut un temps. Maintenant je me dis que c'est pas sur ce mécanisme qu'il faut s'appuyer, mais sur des commentaires / choix judicieux de noms. En tous cas, je me souviens pas d'avoir été piégé à ce niveau. Par contre les pointeurs erronés...

Code:

---

1 2 3 4 5 6 7 8 9 10

// initialiser A A a; if ( !read_from_config_file( a ) ) { // erreur }   // afficher print_infos( a );

---

ce genre de code parle de lui même je pense. Si print_infos a un effet de bord et modifie a, c'est que c'est mal fichu. Avec ce code:

Code:

---

print_infos( &a );

---

si tu as le réflexe d'aller voir le prototype de print_infos, je comprends pas pourquoi tu ne l'as pas avec la version sans pointeur.

+1 à la réponse d'Aurélien. Dans tous les cas il doit (*) y avoir des "const". Qu'il s'agisse de pointeur ou de référence.

En ce qui me concerne, les passages de paramètres se font par :
- référence-constante : "gros" objet en lecture seule
- référence : objet en lecture et/ou écriture
- valeur : "petit" objet en lecture seule ET qui dispose qu'une sémantique de valeur en général, ou juste copiable parfois seulement. (je ne suis pas trop un adepte de l'optimisation systématique proposée par H.Sutter et A.Alexandrescu dans leur bouquin de qualité)
- pointeur (brut ou intelligent) : pour les paramètres optionnels ou qui sont vraiment des pointeurs dont la responsabilité doit migrée ou être partagée.

Je peux aussi garder des pointeurs quant il s'agit de référencer des objets dont on veut s'assurer que la durée de vie exède celle du référant.

(*) Et quant ils ne sont pas explicites, on perd une après-midi à rendre const-correct ce qui ne l'est pas -- largement récompensé, AMHA, par les doutes et les traques de bugs qui nous seront épargnés.

Bonjour

Avec énormément de retard sur la discution, juste pour réagir à ceci :

Citation:

---

Sinon en codant en C ou C++ avec des bibliothèques portables, on arrive à faire fonctionner un executable sur autant de plate-formes que Java

---

Oui mais cela nécessite une recompilation. En java non.

Citation:

---

Envoyé par hegros

Oui mais cela nécessite une recompilation. En java non.

---

Ah, que fait la JVM ? :-)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Citation:

---

Envoyé par hegros

Oui mais cela nécessite une recompilation. En java non.

---

Ah, que fait la JVM ? :-)

---

Ca me semble plus souple pour le developpement.
De plus elle interprete du code ce n'est qu'après qu'elle le compile et une seule fois biensur.

M'enfin y'a du pour et du contre comme toujours je suppose :wink:

Citation:

---

Envoyé par hegros

Citation:

---

Envoyé par Jean-Marc.Bourguet

Citation:

---

Envoyé par hegros

Oui mais cela nécessite une recompilation. En java non.

---

Ah, que fait la JVM ? :-)

---

Ca me semble plus souple pour le developpement.
De plus elle interprete du code ce n'est qu'après qu'elle le compile et une seule fois biensur.

---

Quoi ?

Un programme écrit en C/C++ doit être recompilé pour marcher sur une autre plate-forme. Mais cela peut-être fait simplement par exécution d'un makefile... En ce point, ça ne difère pas beaucoup de la JVM, simplement un temps d'attente et puis après c'est parti (et pas besoin de recompiler à chaque fois).
Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit à cette dénomination.

Par contre, il est vrai qu'il y a des différences de vitesse (parfois négligeables) entre le C/C++ et le java, et qu'elles existeront toujours (le java est trop éloigné du système, notament avec les pointeurs qui sont (mal) camouflés (mais on peut faire la même remarque pour les références en C++)).

Citation:

---

Envoyé par remram44

Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit à cette dénomination.

---

On parle de portabilité au niveau des sources, je trouve que ça reflète bien la chose.

slt,
Je reprendra ce qui a été pour plus d'emphase, Tu peux écrire oo en C.

En n'oublies pas Java bien et C tant mieux 8O

Citation:

---

Envoyé par remram44

Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit à cette dénomination.

---

La JVM est standard. Le C/C++ peut l'être également, mais assez souvent on se retrouve face à un makefile qui déconne parce que :
- pas le même compilo
- librairies pas standard utilisées dans le programme à compiler
- non respect de la norme (à mettre en rapport avec "pas le même compilo")
...

Bref, le java est certainement plus portable que le C/C++, parce qu'il y a quand même un nombre non négligeable de programmeurs qui font plus ou moins n'importe quoi ou se moquent de la portabilité de leur code.

C'est sûr que l'avantage du Java, c'est que ça tourne sur n'importe quoi - il faut juste toute la JVM pour être sûr, ce qui n'est pas le cas sur nombre d'implémentations - et il existe même des processeurs qui traitent directement le byte code Java.
Mais dire que le C/C++ n'est pas portable...
Java est portable, mais l'inconvénient majeur, c'est que c'est Java qui fait le pont entre les différents systèmes quand c'est au programmeur de le faire en C/C++ - GUI, réseau, thread, ... -, ce qui fait que même si Java était compilé comme le C/C++, il serait plus lent.

Citation:

---

Envoyé par 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.

Code:

---

1 2	Le C/C++ peut l'être également, mais assez souvent on se retrouve face à un makefile qui déconne parce que : - pas le même compilo

---

aap, bjam, scons, etc sont nos amis

Code:

---

- librairies pas standard utilisées dans le programme à compiler

---

Ca quand les gens se fichent du portable, ou sont mal éduqués, on n'y peut rien. Et Java n'est pas épargné non plus. Cf ce qui s'était passé avec OOo

Code:

---

- non respect de la norme (à mettre en rapport avec "pas le même compilo")

---

Il faut mettre à jour ses compilos. De la même façon, un code qui utilise les générics ne fonctionnera pas en Java 1.4


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

Citation:

---

Envoyé par Luc Hermitte

Citation:

---

Envoyé par 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...

Citation:

---

Envoyé par Luc Hermitte

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

---

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

Citation:

---

Envoyé par davcha

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.

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 ?

On entre dans un troll Windows vs Linux là.

Citation:

---

Envoyé par 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 ?

---

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.

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)

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 :|

[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 ><

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++. :mouarf:

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

Citation:

---

Envoyé par 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++. :mouarf:

---
:lahola:
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 ;)

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

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.

Citation:

---

Envoyé par soleuh

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).

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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++...

Citation:

---

Envoyé par Jean-Marc.Bourguet

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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).

Citation:

---

Envoyé par Jean-Marc.Bourguet

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 ? :roll:)

Citation:

---

Envoyé par soleuh

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.

Citation:

---

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).

Citation:

---

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

(...). 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 ;))

Citation:

---

Envoyé par Jean-Marc.Bourguet

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..

Citation:

---

Envoyé par Jean-Marc.Bourguet

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.

Citation:

---

Envoyé par koala01

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....

Citation:

---

Envoyé par Linus Torvalds

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

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoyé par loufoque

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 :roll:)

Citation:

---

Envoyé par loufoque

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........ :roll:

Citation:

---

Envoyé par loufoque

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).

Citation:

---

Envoyé par soleuh

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?

Citation:

---

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?

Citation:

---

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.

Citation:

---

le new,

---

Je ne vois toujours rien de génant

Citation:

---

une grande partie des méthodes virtuelles.. ?

---

Qu'est-ce qui gène ici?

Citation:

---

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.

Citation:

---

Envoyé par Linus Torvalds

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.

Citation:

---

- 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é.

Citation:

---

- 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?

Citation:

---

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

---

Là nous sommes d'accord.

Citation:

---

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...

Citation:

---

_without_ the crap that is C++.

---

Précision?

Citation:

---

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.