Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ C++ ou Java ??

C++ ou Java ??

21 réponses
Avatar
fredPPP
Bonjour,

j'ai programmé actuellement essenssiellement en C pour des DSP ,
microcontroleur etc..
J'ai un nouveau projet qui va bientot démarré sur une prateforme PC (
Windows XP ou Linux non choisi actuellement )
Ne connaissant pas Java et certaines personnes me le conseillant , j'aimerai
savoir quels sont les avantages de l'un par rapport à l'autre
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Jonathan Mcdougall
Luc Hermitte wrote:
"Jonathan Mcdougall" wrote in
news:9YDib.36894$:

C++ > table["toto"] = 4;
Java > table.putValue("toto", new Integer(4));

Il me semblait qu'il fallait tester l'existence d'une valeur pour cet
index avant. Je m'étais peut-etre trompé.


En fait, c'est put() et non putValue(). De plus, les valeurs sont
remplacées si la clé existe déjà. Mais ce n'est pas un cours de Java ici.


et pour la retirer
int valeur = ( (Integer) table.getValue("toto") ).intValue();


"récupérer" tu veux dire !?


Hé. Désolé.


Jonathan


Avatar
kanze
Luc Hermitte wrote in message
news:...
jerome moliere wrote in news:bmeka1$2r07$1
@biggoron.nerim.net:

Je ne qualifirai pas Java de plus haut niveau. Il suffit de voir
les pirouettes qu'il nous oblige à accomplir si on veut exprimer
des trucs comme : [...]
ou enforcer des pre- et post-conditions au niveau des interfaces.


ah bon qu'il y a t'il en C++ pour faire cela ?


Héritage multiple de classes abstraites dont l'interface publique se
résume à des fonctions non virtuelles réalisant le pattern "template
method".


J'aimerais bien qu'on s'arrête de parler du modèle template quand on
parle de la programmation par contrat. Il y a des ressemblances
supérficielles, mais le but en est bien différent. Dans le modèle
template, la classe de base a un comportement important, qui est
customisé par des fonctions virtuelles définies dans la classe dérivée ;
la dérivation sert à la customisation. Dans la programmation par
contrat, la classe de base n'a pas de comportement du tout, et toute
l'implémentation se trouve dans les fonctions virtuelles définies dans
la classe dérivée.

tu penses pas a assert.h quand meme...


Non en effet.


Bien qu'on peut s'en servir. Mais l'important, c'est où on s'en sert, et
comment.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16



Avatar
kanze
Fabien LE LEZ wrote in message
news:...
On Tue, 14 Oct 2003 00:34:42 +0200, Luc Hermitte
wrote:

C++ > table["toto"] = 4;
Java > table.putValue("toto", new Integer(4));

Il me semblait qu'il fallait tester l'existence d'une valeur pour cet
index avant.


En C++, non -- elle est créée si elle n'existe pas.
En Java, aucune idée.


En Java, c'est pareil. Et le nom de la fonction est put.

Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou au
moins, pourait l'être : le problème, c'est dans des expressions du genre :

int i = table[ "toto" ] ;

La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par défaut. Du
coup, tu ne peux pas le faire sur une table const.

Dans ce cas-ci, en ce qui concerne C++, il n'y a pas de solution
«@correcte ». Alors, l'utilisation des fonctions (avec des noms)
permettraient à implémenter des sémantiques diverses, et permettrait à
l'utilisateur de choisir celle qui lui convient.

En Java, c'est moins un problème ; table.get( "toto" ) renvoie un
pointeur, qui est null si l'objet n'y était pas.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


Avatar
Luc Hermitte
wrote in
news::

Héritage multiple de classes abstraites dont l'interface publique se
résume à des fonctions non virtuelles réalisant le pattern "template
method".


J'aimerais bien qu'on s'arrête de parler du modèle template quand on
parle de la programmation par contrat. Il y a des ressemblances
supérficielles, mais le but en est bien différent. Dans le modèle
template, la classe de base a un comportement important, qui est
customisé par des fonctions virtuelles définies dans la classe dérivée
; la dérivation sert à la customisation. Dans la programmation par
contrat, la classe de base n'a pas de comportement du tout, et toute
l'implémentation se trouve dans les fonctions virtuelles définies dans
la classe dérivée.


Moui...
Je ne sais pas si la distinction est si importante là. Car l'algorithme
en termes "d'opérations abstraites" reste : 1- vérifier les
pré-conditions et invariants 2- réaliser les "traitements demandés"
(j'ai pas trouvé de meilleur terme) 3- vérifier les post-conditions et
invariants

C'est juste que le modèle n'est pas exactement employé pour implémenter
l'algorithme des "traitements demandés". On emploi bien ce modèle, mais
on n'est pas au même niveau de raffiment en effet.

--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>


Avatar
kanze
Luc Hermitte wrote in message
news:...
wrote in
news::

Héritage multiple de classes abstraites dont l'interface publique
se résume à des fonctions non virtuelles réalisant le pattern
"template method".


J'aimerais bien qu'on s'arrête de parler du modèle template quand on
parle de la programmation par contrat. Il y a des ressemblances
supérficielles, mais le but en est bien différent. Dans le modèle
template, la classe de base a un comportement important, qui est
customisé par des fonctions virtuelles définies dans la classe
dérivée ; la dérivation sert à la customisation. Dans la
programmation par contrat, la classe de base n'a pas de comportement
du tout, et toute l'implémentation se trouve dans les fonctions
virtuelles définies dans la classe dérivée.


Moui...

Je ne sais pas si la distinction est si importante là.


Je trouve que oui, parce que...

Car
l'algorithme en termes "d'opérations abstraites" reste : 1- vérifier
les pré-conditions et invariants 2- réaliser les "traitements
demandés" (j'ai pas trouvé de meilleur terme) 3- vérifier les
post-conditions et invariants


Justement, l'importance des vérifications, dans la programmation par
contrat, c'est qu'elles n'ont aucune influence sur le comportement.
Selon l'implémentation, d'ailleurs, on peut les supprimer dans les
versions de production. Tandis que dans le modèle template, le
comportement est vraiment dans la classe de base -- la rôle de la classe
dérivée se limite à la customisation.

Il y a aussi une différence quand on se met à considérer les
alternatifs. Dans le cas du modèle template, je considère toujours
l'alternatif d'utiliser la délégation -- l'utilisation du modèle
template est en fait assez rare chez moi, parce que je préfère en
général la délégation. Or, cet alternatif n'a aucun sens quand on parle
de la programmation par contrat.

Mais surtout, à mon avis, c'est la motivation qui diffère. Et je crois
que quand on parle des modèles de programmation, et quand il faut s'en
servir, la motivation a une importance primordiale.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16



Avatar
Michel Michaud
Dans news:,
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou au
moins, pourait l'être : le problème, c'est dans des expressions du
genre :

int i = table[ "toto" ] ;

La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par
défaut. Du coup, tu ne peux pas le faire sur une table const.


En Java, tu n'as pas la syntaxe avec []. En C++, tu peux faire
pareil et utiliser les fonctions membres pour ajouter ou chercher
une valeur, si tu n'aimes pas que [] l'ajoute automatiquement. Je
ne vois pas en quoi c'est mieux en Java, puisque tout est possible
aussi en C++ et qu'on a simplement une opération (souvent utile)
en plus.

Dans ce cas-ci, en ce qui concerne C++, il n'y a pas de solution
« correcte ». Alors, l'utilisation des fonctions (avec des noms)
permettraient à implémenter des sémantiques diverses, et
permettrait à l'utilisateur de choisir celle qui lui convient.


Mais elles sont là ces fonctions ! (je crois que je ne comprends
probablement pas bien de toi tu parles...)

En Java, c'est moins un problème ; table.get( "toto" ) renvoie un
pointeur, qui est null si l'objet n'y était pas.


Et m.find("...") renvoie un end(). C'est quoi la différence ?

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
kanze
"Michel Michaud" wrote in message
news:<Ziejb.7429$...
Dans news:,
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou au
moins, pourait l'être : le problème, c'est dans des expressions du
genre :

int i = table[ "toto" ] ;

La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par
défaut. Du coup, tu ne peux pas le faire sur une table const.


En Java, tu n'as pas la syntaxe avec [].


Ce que je considère, dans ce cas-ci, un avantage:-).

En fait, un AssocArray était une des premières classes que j'ai écrite,
et je lui ai bien donné un opérateur [] avec la même sémantique que
celui de la STL -- c'était après tout la sémantique qu'avait les
tableaux en AWK, et donc, celle dont j'avais l'habitude. Depuis, je me
suis rendu compte, et avec le mien, et avec celui de la STL, que ce
n'était pas une bonne chose. (Malheureusement, dans les deux cas, il y a
assez de code existant pour interdire une modification maintenant.)

En C++, tu peux faire pareil et utiliser les fonctions membres pour
ajouter ou chercher une valeur, si tu n'aimes pas que [] l'ajoute
automatiquement.


J'utilise surtout std::map comme classe d'implémentation des maps à
moi. Plusieurs maps différents, avec des interfaces différentes. Et en
effet, je n'utilise pour ainsi dire jamais (maintenant) l'opérateur[]
sur map.

Le problème, c'est qu'il est là, et qu'il est donc temptant, et qu'il
n'est pas intuitif ce qu'il fait. Et AMHA, une condition nécessaire pour
justifier le surcharge d'un opérateur, c'est que sa signification soit
intuitive -- j'ai déjà des doutes sur l'opérateur '+' des chaînes de
caractères (opérateur qui n'est pas ce que moi j'entends sous la vocable
« opérateur additif »). Alors, c'est un abus du surcharge.

Je ne vois pas en quoi c'est mieux en Java, puisque tout est possible
aussi en C++ et qu'on a simplement une opération (souvent utile) en
plus.


Tout est possible, mais rien ne se fait d'une façon naturelle.

Dans ce cas-ci, en ce qui concerne C++, il n'y a pas de solution
« correcte ». Alors, l'utilisation des fonctions (avec des noms)
permettraient à implémenter des sémantiques diverses, et
permettrait à l'utilisateur de choisir celle qui lui convient.


Mais elles sont là ces fonctions ! (je crois que je ne comprends
probablement pas bien de toi tu parles...)


D'abord, certaines d'entre elles ne sont pas là -- au moins, pas sous un
nom habituel (comme par exemple « contains »). Mais ce n'était pas
vraiment ce que j'essayais à dire -- l'avantage de Java, ici, c'était
justement que dans ce cas précis (parce que globalement, c'est un
désavantage), l'absense du surcharge des opérateurs a empèche un abus de
l'opérateur -- et la sémantique de référence a donné une solution
évidente à ce qu'il fallait faire dans le cas où l'élément n'a pas été
trouvé.

En Java, c'est moins un problème ; table.get( "toto" ) renvoie un
pointeur, qui est null si l'objet n'y était pas.


Et m.find("...") renvoie un end(). C'est quoi la différence ?


Simplement que la solution Java est plus intuitive. Dans la contexte du
langage, d'ailleur, c'est la solution à laquelle arrivera tout le
monde. Que la solution C++ renvoie un itérateur, ça pourrait aller
encore, mais que pour avoir l'élément référencié, il faut écrire
iter->second, plutôt que *iter, on a un peu dépasser les limites.

Je crois, en fait, qu'une partie du problème, c'est que la STL a forcé
std::map à être une collection, alors qu'intuitivement, il ne l'est pas.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


Avatar
Fabien LE LEZ
On 16 Oct 2003 01:15:18 -0700, wrote:

En Java, tu n'as pas la syntaxe avec [].


Ce que je considère, dans ce cas-ci, un avantage:-).


Ben oui, c'est une caractéristique de C++ : on peut tout faire, y
compris les pire conneries. C'est au programmeur de se prendre en main
et de n'utiliser que les bons outils au bon moment ;-)

--
http://www.giromini.org/usenet-fr/repondre.html


Avatar
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message
news:<Ziejb.7429$...
Dans news:,
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou
au moins, pourait l'être : le problème, c'est dans des
expressions du genre :

int i = table[ "toto" ] ;

La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par
défaut. Du coup, tu ne peux pas le faire sur une table const.


En Java, tu n'as pas la syntaxe avec [].


Ce que je considère, dans ce cas-ci, un avantage:-).


Ah bon. Alors là évidemment... Mais je trouve la sémantique de cette
syntaxe est, au contraire, tout à fait conforme à l'idée que je me
fais d'une table associative utile.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/



Avatar
Mickael Pointier
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou
au moins, pourait l'être : le problème, c'est dans des
expressions du genre :

int i = table[ "toto" ] ;

La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par
défaut. Du coup, tu ne peux pas le faire sur une table const.


En Java, tu n'as pas la syntaxe avec [].


Ce que je considère, dans ce cas-ci, un avantage:-).


Ah bon. Alors là évidemment... Mais je trouve la sémantique de cette
syntaxe est, au contraire, tout à fait conforme à l'idée que je me
fais d'une table associative utile.


J'abonde dans ton sens.
Autant je n'aime pas les .first et .second (pas intuitif pour un sous),
autant la syntaxe avec crochets me parait évidemment comprénsible. Ce
qui l'est moins c'est que ca crée automatiquement l'élément s'il
n'existe pas... mais bon, je suppose que ca ne doit pas être évident de
distinguer la lecture et l'écriture.

Mike




1 2 3