C++ vs C

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/04/2006, 12h49
davcha

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.
03/04/2006, 12h57
Matthieu Brucher

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.
03/04/2006, 13h07
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 ?
03/04/2006, 14h02
Aurelien.Regat-Barrel

On entre dans un troll Windows vs Linux l�.
03/04/2006, 14h04
Matthieu Brucher

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.
03/04/2006, 14h32
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)
03/04/2006, 15h22
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 :|
03/04/2006, 18h36
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 ><
10/07/2006, 12h11
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
23/08/2006, 01h51
koala01

oui, ... mais non

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 ;)
23/09/2006, 12h58
soleuh

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.
23/09/2006, 14h08
Jean-Marc.Bourguet

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.
23/09/2006, 14h28
soleuh

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:)
23/09/2006, 15h44
Jean-Marc.Bourguet

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.
23/09/2006, 16h05
koala01

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 ;))
23/09/2006, 17h42
soleuh

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
23/09/2006, 18h02
loufoque

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.
23/09/2006, 18h07
gege2061

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:)
23/09/2006, 18h34
soleuh

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).
23/09/2006, 19h00
Jean-Marc.Bourguet

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.

Voir 40 message(s) de cette discussion en une page