Discussion :

[Invit�]

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

[gege2061]

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.

[Newgaia]

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

[davcha]

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.

[Matthieu Brucher]

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.

[Luc Hermitte]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

S�lectionner tout - Visualiser dans une fen�tre � part

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

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

[djimi_roland]

en c je crois que les objet, ou d'ailleurs leurs types sont definis par des structures et en en c++ pas les class, l avantage est que en c++ on peux utilise le polymorphisme.Peux etre j ai pas aussi compris dequoi il s agit.

Du courage,

[koala01]

en c je crois que les objet, ou d'ailleurs leurs types sont definis par des structures et en en c++ pas les class, l avantage est que en c++ on peux utilise le polymorphisme.Peux etre j ai pas aussi compris dequoi il s agit.

Du courage,

En fait, le mot cle class et le mot cle struct sont, exception faite de la visibilit� par d�faut des membres et foncitons membres, tout � fait �quivalents en C++

Pour etre pr�cis, si tu ne pr�cise aucune restriction de visibilit� � l'aide des mots cle private, public ou protected, les membres d'une structure seront public alors que ceux d'une classe seront priv�s:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
struct mastruct
{
    int i;
};
class maclass
{
    int i;
};
int main()
{
    mastruct s1;
    masclass c2;
    s1.i=2; //OK i est accessible car public
    c2.i=2; //ERREUR i n'est pas accessible car privé
    return 0;
}

A part cela, il n'y a aucune autre diff�rence entre les classes et les structures en C++

Et tu peux tres bien impl�menter de l'h�ritage et du polymorphisme sur une structure

Par contre ce qui est vrai, c'est que, si tu d�finis une structure en C, tu ne d�clare pas automatiquement le type correspondant, alors que la d�finition d'une structure en C++ cr�era automatiquement le type corrsepondant:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/* en C */
struct mastruct
{
   int i;
};
/* cr�ation du type */
typedef struct mastruct montype;
int main
{
    mastruct s1;//erreur mastruct n'est pas un type connu
    struct mastruct s2;//ok, on signale que c'est une structure
    montype s3; //ok c'est bien un type comme int, du fait du typedef
    return 0;
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
/* en C++ */
struct mastruct
{
    int i;
};
typedef mastruct montype;//cr�e tout simplement un alias
                         // (un autre nom pour repr�senter la meme chose)
int main()
{
    mastruct s1;//ok, mastruct est d�j� un type
    montype s2;//ok: montype==mastruct
    return 0;
}