Quel problème peut-il y avoir si en passant de C à C++ on continue à
utiliser :
- printf("..."); au lieu de cout << "...";
- #define N 64 au lieu de const int n = 64;
- int f(void) au lieu de int f()
Habitué à programmer en C, je pensais qu'en C++ je pouvais continuer à
utiliser tout ça sans aucun problème. Mais j'ai eu plusieurs fois la
remarque "ça ressemble à du C".
Cette utilisation d'instructions et de fonctions typiques du C peut
t-elle poser des probèmes ?
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
Jean-Marc Bourguet
Gaël Jaffré writes:
Bonjour,
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser : - printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de scope, clash possibles avec d'autres symboles avec des effets plus ou moins bizarres et facile a debugger et symbole generalement inconnu du debugger.
- int f(void) au lieu de int f()
Uniquement un probleme de style.
Habitué à programmer en C, je pensais qu'en C++ je pouvais continuer à utiliser tout ça sans aucun problème. Mais j'ai eu plusieurs fois la remarque "ça ressemble à du C".
Le dernier points n'est qu'un probleme de style, les autres ont aussi des implications plus graves.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gaël Jaffré <jaffre@irit.fr> writes:
Bonjour,
Quel problème peut-il y avoir si en passant de C à C++ on continue à
utiliser :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de
verification la correspondance de type entre ce qui est attendu et ce
qui est reellement passe et pas de possibilite d'utiliser des classes.
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de
scope, clash possibles avec d'autres symboles avec des effets plus ou
moins bizarres et facile a debugger et symbole generalement inconnu du
debugger.
- int f(void) au lieu de int f()
Uniquement un probleme de style.
Habitué à programmer en C, je pensais qu'en C++ je pouvais continuer
à utiliser tout ça sans aucun problème. Mais j'ai eu plusieurs fois
la remarque "ça ressemble à du C".
Le dernier points n'est qu'un probleme de style, les autres ont aussi
des implications plus graves.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser : - printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de scope, clash possibles avec d'autres symboles avec des effets plus ou moins bizarres et facile a debugger et symbole generalement inconnu du debugger.
- int f(void) au lieu de int f()
Uniquement un probleme de style.
Habitué à programmer en C, je pensais qu'en C++ je pouvais continuer à utiliser tout ça sans aucun problème. Mais j'ai eu plusieurs fois la remarque "ça ressemble à du C".
Le dernier points n'est qu'un probleme de style, les autres ont aussi des implications plus graves.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Samuel Krempp
le Monday 24 May 2004 17:23, écrivit :
Gaël Jaffré writes:
Bonjour,
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser :
les points que tu cites sont effectivement des exemples classiques où la façon de faire du C a des réels inconvénients. à priori on peut trouver des détails dans des comparaisons C/C++ .
en regardant dans la 'faq-lite' de C++, on trouve aussi des réponses :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
voir aussi http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.1
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de scope, clash possibles avec d'autres symboles avec des effets plus ou moins bizarres et facile a debugger et symbole generalement inconnu du debugger.
le Monday 24 May 2004 17:23, jm@bourguet.org écrivit :
Gaël Jaffré <jaffre@irit.fr> writes:
Bonjour,
Quel problème peut-il y avoir si en passant de C à C++ on continue à
utiliser :
les points que tu cites sont effectivement des exemples classiques où la
façon de faire du C a des réels inconvénients.
à priori on peut trouver des détails dans des comparaisons C/C++ .
en regardant dans la 'faq-lite' de C++, on trouve aussi des réponses :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de
verification la correspondance de type entre ce qui est attendu et ce
qui est reellement passe et pas de possibilite d'utiliser des classes.
voir aussi
http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.1
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de
scope, clash possibles avec d'autres symboles avec des effets plus ou
moins bizarres et facile a debugger et symbole generalement inconnu du
debugger.
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser :
les points que tu cites sont effectivement des exemples classiques où la façon de faire du C a des réels inconvénients. à priori on peut trouver des détails dans des comparaisons C/C++ .
en regardant dans la 'faq-lite' de C++, on trouve aussi des réponses :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
voir aussi http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.1
- #define N 64 au lieu de const int n = 64;
Les problemes du preprocesseur. En particulier pas de controle de scope, clash possibles avec d'autres symboles avec des effets plus ou moins bizarres et facile a debugger et symbole generalement inconnu du debugger.
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
Sans parler de l'extensibilité, ni la séparation des concernes -- la gestion du flux de caractères est séparée du formattage en iostream.
Dans la pratique, même si le potentiel d'erreur avec printf est elevé, je ne me rappelle pas d'y avoir eu de problèmes réels. En revanche, je ne crois pas d'avoir jamais écrit une application sans au moins un surcharge de l'opérateur <<, et sans au moins un streambuf sur mésure. Deux choses complétement impossible avec printf.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxbd64t3l2r.fsf@news.bourguet.org>...
Gaël Jaffré <jaffre@irit.fr> writes:
Quel problème peut-il y avoir si en passant de C à C++ on continue à
utiliser :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de
verification la correspondance de type entre ce qui est attendu et ce
qui est reellement passe et pas de possibilite d'utiliser des classes.
Sans parler de l'extensibilité, ni la séparation des concernes -- la
gestion du flux de caractères est séparée du formattage en iostream.
Dans la pratique, même si le potentiel d'erreur avec printf est elevé,
je ne me rappelle pas d'y avoir eu de problèmes réels. En revanche, je
ne crois pas d'avoir jamais écrit une application sans au moins un
surcharge de l'opérateur <<, et sans au moins un streambuf sur mésure.
Deux choses complétement impossible avec printf.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quel problème peut-il y avoir si en passant de C à C++ on continue à utiliser :
- printf("..."); au lieu de cout << "...";
Tout les problemes habituels de printf. En particulier pas de verification la correspondance de type entre ce qui est attendu et ce qui est reellement passe et pas de possibilite d'utiliser des classes.
Sans parler de l'extensibilité, ni la séparation des concernes -- la gestion du flux de caractères est séparée du formattage en iostream.
Dans la pratique, même si le potentiel d'erreur avec printf est elevé, je ne me rappelle pas d'y avoir eu de problèmes réels. En revanche, je ne crois pas d'avoir jamais écrit une application sans au moins un surcharge de l'opérateur <<, et sans au moins un streambuf sur mésure. Deux choses complétement impossible avec printf.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
