(post vide pour n'éditer ni le sondage ni le titre)

Lectures à propos:
Incompatibilities Between ISO C and ISO C++
The C/C++ Programming Language
Sibling Rivalry: C and C++ (par Bjarne)
C and C++: Siblings (par Bjarne)
C and C++: Wedding Bells?
 
Désolé, c'est tout en anglais.
 
 
Oui, car...
-La communauté de programmeurs est alors plus grande.
-Du code C peut (souvent) être réutilisé en C++.
-Du code peut être compatible C et C++.
-Le passage de C à C++ peut se faire en douceur.
 
Non, car...
-Cela impose à chaque langage des contraintes issues de l'autre, gênant l'évolution.
-C et C++ ne sont pas les mêmes langages, ils ont une philosophie différente.
-Il semble que dans les faits, il y a deux communautés ayant tendance à s'ignorer.
-Il restera toujours des ambigüités d'interprétation.
 
 
Considérant l'ensemble, je n'arrive pas à me décider.
Cette compatibilité à amené des défauts dans C++, et si C++ n'est plus compatible C, alors autant rompre complètement et le changer en profondeur.
Mais une rupture impliquerait des sacrifices sur les outils de développement communs, et amènerait une scission irréversible.
 
Des avis ?

Je repons non car je pense qu'il ne suffit de pas grand chose pour corriger les défauts les plus génants du C++, mais qu'il n'est pas possible de garder la compatibilité avec le C de cette façon. Et de toute façon, les programmes en C doivent déjà être réécris en C++ pour en profiter. Sinon quel intéret y a-t-il à utiliser un compilo C++ à la place d'un compilo C vu qu'il est déjà possible de lier du code C avec du code C++.
 
Sinon, quelques trucs que je changerais en C++ :
- opérateur = interdit la ou un "boolean" est attendu ( if/while/for ... )
- tous les opérateurs d'affectation sauf = retournent void ( cela inclus ++,++,--,-- et les +=,-= etc... )
- pas de cast à la C, seul subsistent les nouveaux cast C++.
- Suppréssion de l'opérateur -> au profit de l'opérateur . Ca doit être possible et cela permettra de simplifier la syntaxe.
 
Eventuellement, pas de void * mais ça aussi ça pourrais poser quelques problèmes.
 
Je serais même plus radical en disant que seul static_cast et dynamic_cast sont autorisés mais je me ferais pas beaucoup d'amis comme ça

les codes ne sont déjà plus compatible: le C++ supporte le C89/90 alors que C99 est sortit.
 
le plus flaggrant: les tableaux a taille variables. c'étati une nécessité pour le C, le C++ n'en a que faire puisqu'il vaut mieux utiliser les std::vector

tres bons liens musaran.
 
si vous ne comprenez pas ces articles, pas la peine de voter.
d'ailleurs pour moi la question ne se pose pas: 2 langages différents qui ne visent pas le meme type d'application et d'utilisation.
 
mais je sens que ca va partir en troll  

L'inconvénient de la séparation du C et du C++ que je vois (parce qu'il me concerne un peu) c'est pour les autres langanges.
 
Je m'explique : que vous preniez python, perl, ou ruby, tous ont la possibilité d'être étendu par une interface relativement simple en C.
 
Tant que C et C++ sont compatibles, cela ne pose aucun problème, il suffit de déclarer en extern "C" {...} les fonctions a exporter. Ces fonctions sont ensuite récupérée par l'interpreteur du langage qui peut les appeler pour initialiser ses structures.
 
Maintenant imaginons une séparation nette entre C et C++. Je fais comment ? J'impose l'écriture des extensions dans le langage qui me plait, ou je fais 2 interfaces différentes, sachant que quand je dois charger un .so je ne sais pas d'ou il vient, je connais juste le symbole a repérer ?
 
Bref mon avis qui n'engage que moi (cad une personne qui ne fait pas de C++) : foutez leur la paix !

la reponse c'est simplement NON
parceque un jour ou l'autre en C++ y'a toujours besoin d'une lib ecrite en C
 
pour "ameliorer" le C++ il faudrait deja virer tous les compilos de merde qui trainent (genre MS visual C-- , ca ferait du nettoyage...
 
ha oui, le truc qui me vient a l'esprit c'est des erreurs comprehensibles quand on utilise les templates (enfin ca c'est le pb du compilo, pas du language)

ben la réponse est plutot OUI alors, non ?

c'est vrai que "->" c'est horrible (à taper et à lire)
c'est comme le ^. du Pascal... sauf qu'en Pascal si tu mets . au lieu de ^. en général ça passe (du moins sous Delphi).

Il ne faut pas restreindre le langage.
Par contre, c'est très bien d'avoir un environnement qui émette de grosses alertes.
 

Bjarne lui-même en parles, mais ils doivent rester principalement par compatibilité.
 

Impossible. Il faut pouvoir faire la différence:

Ce sera très probablement rattrapé avec la nouvelle norme du C++ qui arrive.  
 
 
A noter qu'on pourrait imaginer une incompatibilité de code source, mais gardant une compatibilité d'édition de liens.

tanguy a écrit a écrit : la reponse c'est simplement NON parceque un jour ou l'autre en C++ y'a toujours besoin d'une lib ecrite en C   pour "ameliorer" le C++ il faudrait deja virer tous les compilos de merde qui trainent (genre MS visual C-- , ca ferait du nettoyage...   ha oui, le truc qui me vient a l'esprit c'est des erreurs comprehensibles quand on utilise les templates (enfin ca c'est le pb du compilo, pas du language)

 
Il y a quand même un problème inhérent au langage, c'est la complexité de sa grammaire. C'est d'ailleurs pour ça qu'il n'y a à l'heure actuelle aucun compilateur c++  complet.
Celle du C++ est nettement plus simple, dans sa spécification et son implémentation.

 
faut croire que la syntaxe est pas encore assez complique :
http://developers.slashdot.org/art [...] ad&tid=156
 
"the first C++ compiler that can actually handle the whole language"
 
et gcc en dehors de export je vois pas trop ce qui manque par rapport au standard
 
Si on enleve tout les trucs un peu complique de C++, ca va donner quoi ? Java ?
- pas de const
- pas de pointeur
- pas d'heritage multiple
- pas de surcharge des operateurs
- pas de template
...

Quand je parle de "rester compatible", il ne s'agit pas de faire régresser C++ au niveau du C, ou de greffer au C toutes les fonctions de C++.
 
Il s'agit simplement de garder synchonisés le C et le sous-ensemble C de C++.
Et ça n'est pas une mince affaire, vu que leur philosophies sont bel et bien différentes.
 
Les compilateurs complets existent (Comeau).
Il suffit d'aller les chercher, si on en a l'utilité...
 
oui: 6
non: 6
Vous le faites exprès pour ne pas m'aider à me décider ?

hein? tu decides quoi ?
 
LeGreg

 
En fait, en quoi la suppression de ces "options" restreint le langage ? C'est simplement pour interdire les trucs du genre :
- if (a=0)
- a = b+= (--a)
 
Je te met au defi de me trouver une situation ou c'est vraiment profitable
 

Impossible. Il faut pouvoir faire la différence:

[/quote]
 
Pointeur amélioré ? Je n'avais pas pensé à ça mais ça n'empeche pas l'opérateur . de fonctionner comme je le pense pour les pointeurs normaux.

Moi-même.
Je pose cette question ici parce que j'arrive pas a me faire une opinion.
Donc je cherche des avis novateurs.
 

Il faut éviter d'encombrer un langage avec des règle spour des cas particuliers.
Soit = renvoie une valeur et je peut l'utiliser partout ou une valeur est attendue.
Soit = n'a pas de résultat et je peut pas du tout l'utiliser dans une expression.
Mais le cul entre deux chaises, c'est pas bien .
 
Simplement, le compilateur doit avertir des bourdes probables.
Pour relever le défi, on peut à la rigueur envisager:

Ça reste des détails...
 

Très Mauvaise Idée®.
Les pointeurs normaux et améliorés se comporteraient différemment pour une même opération, il ne serait plus possible d'écrire du code générique.
 
Il y a un concept, celui de l'indirection.
En C++ il a deux l'incarnations:

• Au plus bas niveau, les pointeurs. L'indirection est explicite, ils peuvent désigner n'importe quoi, y compris nul.
• Au plus haut niveau, les références. Indifférenciables d'un vrai objet.

Grâce au patrons, on peut se composer un type indirect intermédiaire, qui peut:

• être nul...
• partager un objet/compter les références...
• allouer automatiquement l'objet...
• être déréférencé automatiquement...
• parcourir un tableau
• changer de référent

...ou pas.
 
Mais ça pose de sérieux problèmes sur les sens des instructions qui leur sont appliquées.