Discussion :

[Médinoc]

Un petit exemple au sujet du préprocesseur:

Avec ces deux fichiers:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
//Test préprocesseur 1
int uneFonction(void);
 
#define NOMDUNEAUTREFONCTION uneAutreFonction
#define TEST1
#ifdef TEST1
void test1(char*);
#else
void nonTest1(long);
#endif

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#include "TestPreProc1.h"
 
long NOMDUNEAUTREFONCTION(char const *uneChaine)
{
	long unNombre;
	for(long unNombre=0 ; uneChaine[unNombre] != '\0' ; unNombre++)
	{}
	return unNombre;
}

En sortie du préprocesseur, on a ça:

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
18
19
20
21
#line 1 "testpreproc.cpp"
#line 1 "testpreproc1.h"
 
int uneFonction(void);
 
 
 
 
void test1(char*);
 
 
#line 11 "testpreproc1.h"
#line 2 "testpreproc.cpp"
 
long uneAutreFonction(char const *uneChaine)
{
	long unNombre;
	for(long unNombre=0 ; uneChaine[unNombre] != '\0' ; unNombre++)
	{}
	return unNombre;
}

Tu remarqueras que le préprocesseur a également supprimé les commentaires.
Quant aux directives #line, elle servent à se souvenir du numéro de ligne, pour les messages d'erreur.

[Nikolas]

D'accord, c'est encore bien compliqué pour moi, mais au moins je progresse avec vos réponses, merci.


koala01, salut, à mon avis c'est plutôt comparable à apprendre une langue étrangère quand on est adulte plutôt qu'à apprendre la lagnue maternelle, et personellement si je me retrouve dans le pays étranger et que je n'ai pas mon petit dico de poche, je suis dans la mouise.

[David Fleury]

Mes 2 centimes...

En C++, main ne devrait pas vraiment être appelée une fonction car
1. elle ne peut s'appeller récursivement
2. le return 0 n'est pas nécessaire, il est ajouté automatiquement si besoin

Faut pas taper

[Nikolas]

C'est pas évident, je devrais peut-être commencer par le C, la plupart des tutoriaux bien réputés requierent une experience en C.

[koala01]

C'est pas évident, je devrais peut-être commencer par le C, la plupart des tutoriaux bien réputés requierent une experience en C.

Je ne crois pas qu'une première expérience en C soit indispensable pour apprendre le C++...

Au contraire, l'apprentissage du C, surtout si tu l'apprends en prenant de mauvaises habitudes, risque de te compliquer énormément la tache pour l'apprentissage de bonnes habitudes en C++...

Un simple exemple: en C, les chaines de caractères sont d'office des tableaux de caractères... que tu peux, bien sur, utiliser en C++, mais qui sont très avantageusement remplacés par la classe std::string...

On rencontre couremment des gens qui ont une expérience en C qui s'obstinent à utiliser un tableau de caractère "à la mode C" au lieu d'utiliser la classe string...Et ce, même quand on leur a expliqué en long et en large qu'il vallait mieux utiliser la classe string...

De la meme manière, l'utilisation de références apporte énormément d'avantages par rapport à l'utilisation de pointeurs... Or, en C, il n'y a pas de référence, et on travaille avec des pointeurs... Là encore, certains s'obstinent à utiliser les pointeurs au lieu d'utiliser plutot des références...

On peut tres bien etre un "gourou" en C++ et ne rien toucher au C, tout comme l'inverse est égalemet vrai.

Bien plus que la connaissance d'un langage particulier, ce qui est tres utile, c'est la connaissance des concepts propres à la programmation séquentielle qui facilite les choses.

Je suis d'ailleurs personnellement persuadé, meme si je n'oblige personne à etre de mon avis, qu'il est bien plus utile de connaitre certains principes "universels" de programmation, de connaitre différentes manières de créer une logique stricte et correcte (ce que l'on appelle "les méthode d'algorithmie") que n'importe quoi d'autre avant d'attaquer l'apprentissage de n'importe quel langage de programmation, qu'il soit séquentiel ou orienté objet...

En effet, les langages orientés objets utilisent tous les concepts de la programmation séquentielle (boucles, tests, fonctions, utilisation éventuelle de pointeurs) et en rajoutent d'autre qui leur sont propres (classes, constructeurs/destructeurs, visibilité des membres et méthodes, héritage, utilisation de référence...)

En cela, le fait de s'être déjà familiarisé avec les concepts de la programamtion séquentielle permettra tout simplement... de ne plus avoir à s'y familiariser lors de l'étude d'un langage orienté objet, et donc de pouvoir directement s'attaquer aux concepts supplémentaires qui font qu'un langage est "orienté objet"...

L'idée qu'il faut connaitre le C avant de passer au C++ est tout aussi fausse que celle qui voudrait qu'il faille connaitre l'anglais avant d'étudier le flamand ou l'allemand...

Ca peut aider, certes, parce que comme les langues sont fort proches, on retrouve dans l'une des concepts utilisés par l'autre, et donc, l'apprentissage de la deuxieme n'en devient que "plus facile", mais ce n'est surement pas une obligation

[Nikolas]

Je ne crois pas qu'une première expérience en C soit indispensable pour apprendre le C++...

Au contraire, l'apprentissage du C, surtout si tu l'apprends en prenant de mauvaises habitudes, risque de te compliquer énormément la tache pour l'apprentissage de bonnes habitudes en C++...

Un simple exemple: en C, les chaines de caractères sont d'office des tableaux de caractères... que tu peux, bien sur, utiliser en C++, mais qui sont très avantageusement remplacés par la classe std::string...

On rencontre couremment des gens qui ont une expérience en C qui s'obstinent à utiliser un tableau de caractère "à la mode C" au lieu d'utiliser la classe string...Et ce, même quand on leur a expliqué en long et en large qu'il vallait mieux utiliser la classe string...

De la meme manière, l'utilisation de références apporte énormément d'avantages par rapport à l'utilisation de pointeurs... Or, en C, il n'y a pas de référence, et on travaille avec des pointeurs... Là encore, certains s'obstinent à utiliser les pointeurs au lieu d'utiliser plutot des références...

On peut tres bien etre un "gourou" en C++ et ne rien toucher au C, tout comme l'inverse est égalemet vrai.

Bien plus que la connaissance d'un langage particulier, ce qui est tres utile, c'est la connaissance des concepts propres à la programmation séquentielle qui facilite les choses.

Je suis d'ailleurs personnellement persuadé, meme si je n'oblige personne à etre de mon avis, qu'il est bien plus utile de connaitre certains principes "universels" de programmation, de connaitre différentes manières de créer une logique stricte et correcte (ce que l'on appelle "les méthode d'algorithmie") que n'importe quoi d'autre avant d'attaquer l'apprentissage de n'importe quel langage de programmation, qu'il soit séquentiel ou orienté objet...

En effet, les langages orientés objets utilisent tous les concepts de la programmation séquentielle (boucles, tests, fonctions, utilisation éventuelle de pointeurs) et en rajoutent d'autre qui leur sont propres (classes, constructeurs/destructeurs, visibilité des membres et méthodes, héritage, utilisation de référence...)

En cela, le fait de s'être déjà familiarisé avec les concepts de la programamtion séquentielle permettra tout simplement... de ne plus avoir à s'y familiariser lors de l'étude d'un langage orienté objet, et donc de pouvoir directement s'attaquer aux concepts supplémentaires qui font qu'un langage est "orienté objet"...

L'idée qu'il faut connaitre le C avant de passer au C++ est tout aussi fausse que celle qui voudrait qu'il faille connaitre l'anglais avant d'étudier le flamand ou l'allemand...

Ca peut aider, certes, parce que comme les langues sont fort proches, on retrouve dans l'une des concepts utilisés par l'autre, et donc, l'apprentissage de la deuxieme n'en devient que "plus facile", mais ce n'est surement pas une obligation

Un cours qui initie directement au C++, qui soit gratuit, s'accompagnant d'un EDI gratuit ; s'il existait des tutoriels tous prêts qui rempliraient ces trois conditions, j'y plongerais, mais pour l'instant j'en connais seulement qui ne remplissent que les deux dernières conditions que je cite, ou seulement la première.


Maintenant, j'ai pas essayé ce que tu dis, de commencer par la programmation séquentielle : bases dans un langage et pas de mauvaises habitudes de prises, si je t'ai bien suivi.

Il y a un autre langage que j'ai failli essayer, c'est le delphi, mais là encore, les tutos les plus clairs demandent de passer par le pascal avant.

[koala01]

<snip>

Il y a un autre langage que j'ai failli essayer, c'est le delphi, mais là encore, les tutos les plus clairs demandent de passer par le pascal avant.

Et pourtant...

Je ne sais pas quelles langues tu connais, mais tu avoueras que, bien que le fait d'en connaitre une te permette *éventuellement* de "retomber sur tes pattes" dans une autre, tu n'a aucun besoin d'en connaitre une particulière pour en apprendre une autre...

Ceux qui voudraient faire croire le contraire en ce qui concerne les langages de programmation n'auront rien compris.

Finalement, quand tu y penses, tous les langages de "troisième génération" disposent de

• structures de controle (test "vrai/faux" ou test "à choix multiple")
• boucles, incrémentielles ou non (boucles "pour", boucles "tant que", boucle "jusque")
• routines (procédure si elle ne renvoie rien, fonction si elle renvoie quelque chose)
• variables, parfois "globale", parfois "locale", et parfois meme "super locale"

La plupart des langages sont attentifs, à un niveau plus ou moins sévere, au type des données, et certains langages disposent de pointeurs et/ou de références...

Qu'il faille se faire une idée précise de "kiestkoi", c'est un fait... Mais, de là à se dire qu'il faut etre passé par un autre langage pour le savoir, c'est quelque peu excessif

C'est un peu vite oublier que la mise au point d'un code n'est que le fait de fournir une logique, en respectant une syntaxe et une sémantique stricte...

C'est oublier tout aussi vite (et peut etre, d'ailleurs, avec les pires conséquences) que, coder une mauvaise logique avec un langage que l'on maîtrise dans ses moindre recoins produira quelque chose de qualité bien inférieure au fait de coder une logique stricte et bien mise au point dans un langage que l'on maitrise peut etre moins...

S'il est vrai que le C++ rajoute certains concepts (tout ce qui a trait à la programmation orientée objet, en un mot) au C, comme les concepts utilsés par le C sont parfaitement génériques (à part, peut etre, celui de pointeur, qui a été introduit en programmation... par le C), si tu connais ces concepts génériques, tu n'a aucun besoin de passer par le C

Maintenant, que dans un cas particulier, on fasse référence à un code en C pour te faire comprendre quelque chose...

[Luc Hermitte]

Les tutos de C++ qui exigent des bases de C sont rarement recommendables.

[Nikolas]

Justement, depuis le temps, j'ai un peu appris le C mais c'est toujours le C++ que je vise, j'aurais préféré l'apprendre directement mais je ne trouve aucun tuto de C++ à ma hauteur (de sous-sol).


En C, j'arrive à manipuler des variables en binaires, avec fread() et fwrite(), mais j'ai du mal à voir ce qui est l'équivalent de ces deux fonctions pour le C++ avec iostream.

Quelqu'un qui connaît les deux languages pourrait me l'expliquer ?


> La FAQ est indisponible à l'heure ou j'écris ce message.

[Mat.M]

En C, j'arrive à manipuler des variables en binaires, avec fread() et fwrite(), mais j'ai du mal à voir ce qui est l'équivalent de ces deux fonctions pour le C++ avec iostream.

Quelqu'un qui connaît les deux languages pourrait me l'expliquer ?

Bonjour ,
eh bien la différence entre fread/fwrite et l'équivalent avec iostream c'est que d'une part iostream est plus complexe et évoluée.
iostream c'est une classe ( un "conteneur" plus exactement ) qui en plus de gérer l'écriture/lecture de données ( on parle de flux ou "streams" en C++) permet également la gestion d'exception avec des try catch.
Ceci en C ne se fait qu'en testant si fread ouvre bien un FILE sinon retourne NULL..
Avec iostream on peut profiter des méchanismes complexes du C++ comme faire hériter ses propres classes de iostream par ex ce qui n'est pas possible avec de simples fonctions C comme fread.
En plus il n'y pas besoin de "caster" les données avec iostream et de se casser la tête du format de données.

[Nikolas]

(Rapide comme la foudre pour répondre... )

C'est l'avantage de la POO, si j'ai bien compris, mais si je pouvais déjà comprendre comment l'utiliser, je pourrais me réjouir plus tard de ses avantages sur le C qui, je n'en doute pas, sont nombreux.


Il faut utiliser quoi pour écrire/lire un flottant sur 32 bits avec iostream ?

Edit : A moins que l'on puisse utiliser fread() et fwrite() dans le C++ sans problème ?

[Luc Hermitte]

-> std::istream::read/std::ostream::write
Par contre, attention aux problèmes d'endianess pour lire/écrire des entiers stockés sous forme non textuelle.

[Nikolas]

-> std::istream::read/std::ostream::write
Par contre, attention aux problèmes d'endianess pour lire/écrire des entiers stockés sous forme non textuelle.

Comment je précise ; la variable que je veux ecrire/lire, le fichier à utiliser et le boutisme ?


Ce code ne marche pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::ostream::fichierSortie.write(valeur, 2);

C'est con pour de la programmation de devoir coder au pif mais je ne vois pas d'autres solutions, je ne trouve rien sur les moteurs de recherche qui ne fasse que me ramener aux FAQs de developpez.com qui restent inaccessibles.

[nikko34]

s'il n'y a rien en français essaye en anglais? parce que apprendre l'anglais va te servir autant que d'apprendre un langage de prog...

[Nikolas]

Je fini déjà d'apprendre le français et on verra !


Sur un site français, j'ai trouvé une syntaxe qui marche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fichierSortie.write((char*) &valeur, 2);

Ça marche comme fwrite() de cette façon, par contre,

Est-ce quelqu'un saurait m'expliquer le rôle de "(char*)" ?

[Laurent Gomila]

(char*) sert à convertir le pointeur source en char*, puisque c'est ce que prend en paramètre la fonction write.

Par contre :
- const char* est préférable dans ce cas, vu que tu accèdes à ta variable en lecture seule
- reinterpret_cast sera mieux que ce cast de type C

[Nikolas]

C'est quoi la difference entre cast et reinterpret_cast, ça doit s'écrire où dans le code ?

[Laurent Gomila]

http://c.developpez.com/faq/cpp/?pag...s#DIVERS_casts

[Nikolas]

Mais ça change rien dans le résultat de l'écriture ou de la lecture, quel est l'intérêt de l'utiliser ?

[Laurent Gomila]

Les casts C++ sont plus sûrs à utiliser que les casts C. D'autant plus qu'il y a des cas où on ne peut tout simplement pas utiliser de cast C (héritage multiple par exemple).

Mais sinon oui, ça ne change rien à l'exécution.