Acc�der � la programmation du langage C++ avec la POO, au langage de script JAVASCRIPT et � la structuration Cascading Style Sheets gr�ce � mes travaux
Version imprimable
Acc�der � la programmation du langage C++ avec la POO, au langage de script JAVASCRIPT et � la structuration Cascading Style Sheets gr�ce � mes travaux
Salut,
Quelques r�actions "� chaud" lors d'une premi�re lecture :D
En fait, en C++ on appelle "fonction membre" les fonctions qui font partie d'une classe...Citation:
� savoir une association des donn�es et des proc�dures (qu�on appelle alors m�thodes)
Le terme m�thode est r�serv� (d'apr�s strutroup du moins) pour d�finir une fonction membre virtuelle (n'oublies pas que toute fonction membre n'est pas forc�ment virtuelle, contrairement au java ;))
Hummm...Citation:
L�encapsulation des donn�es pr�sente un int�r�t manifeste en mati�re de qualit� de logiciel. Elle facilite consid�rablement la maintenance : une modification �ventuelle de la structure des donn�es d�un objet n�a d�incidence que sur l�objet lui-m�me ; les utilisateurs de l�objet ne seront pas concern�s par la teneur de cette modification (ce qui n��tait bien s�r pas le cas avec la programmation structur�e).
A vrai dire, l'encapsulation est r�guli�rement utilis�e en C ;)
Penses, par exemple, au pointeur sur FILE, dont on n'a strictement aucun besoin (ni moyen) de savoir de quoi il est compos� !
Par contre, nous pourrions dire que la POO "g�n�ralise" ou plutot "syst�matise" le recours � l'encapsulation ;)
Le chapitre sur l'h�ritage est vraiment "l�ger l�ger" :aie: Un petit mot sur LSP et ce qu'il implique serait sympa ;)
Apr�s tout, l'h�ritage et le polymorphisme sont les deux ingr�dients qui permettent de mettre en place la substituabilit�, et il est r�ellement dangereux d'y recourir pour autre chose (par exemple, pour r�cup�rer du code ) ;)
En fait, je ferais plut�t le contraire:Citation:
Cependant, l�utilisation des symboles d�clar�s dans ce fichier iostream fait appel � la notion d�espace de noms, introduite elle-aussi par la norme. Cette notion sera pr�sent�e ult�rieurement. Pour l�instant, sachez qu�elle oblige � introduire dans votre programme une instruction de d�claration using, dont la port�e se d�finit comme celle de toute d�claration, et qui se pr�sente ainsi :(et les exemples de codes qui pr�c�dent ;))
introduire la notion d'espace de noms et pr�ciser que tout ce qui vient du standard se trouve dans l'espace std
indiquer que l'espace de noms intervient dans la reconnaissance des symboles et qu'il doit donc �tre utilis� de mani�re syst�matique lorsque l'on souhaite acc�der � un symbole qui en fait partie
expliquer que la directive using permet d'�viter d'avoir � pr�ciser l'espace de noms � chaque fois mais
insister sur le fait qu'elle ne doit pas �tre utilis�e n'importe o� et qu'il est pr�f�rable d'y recourir quand on a vraiment affaire � des espaces de noms en cascade ( ex : truc::machin::brol::bidule ;) )
Le code qui suit cette phrase :
Personnellement, j'ai horreur d'avoir plusieurs d�clarations de variables sur une m�me ligne, surtout si ce sont des variables de types diff�rents : il est tellement facile de "passer � cot�" d'une d�claration en faisant cela :aie:
Au fait, le prototype de la fonction main, c'est int main() ou int main( int argc, char * argv[]), faudrait l'indiquer correctement (et ne pas oublier le retour en fin de fonction ;) )
Pour autant que je sache (mais bon, je suis un peu rouill� en C :aie:) on en peut pas d�clarer une fonction au sein d'une fonction en C (et on ne peut d'ailleurs pas non plus le faire en C++ :P ) ;)
Concernant new et delete : attention : new attend un delete et new[] attend un delete[] ;)
concernant les fonction inline pr�ciser que l'on demande au compilateur d'agir de la sorte, mais qu'il reste le dernier � d�cider de le faire ou non (en fonction du nombre d'instructions � inliner, principalement ;))
Concernant la structure point : introduit peut etre la notion de constructeur, pour virer cette horrible fonction "initialise" :D , cela donnera tout de suite "les bonnes habitudes" ;) (n'oublies pas qu'en C++, struct et class sont identique � la visibilit� par d�faut des membres pr�s ;))
Ouh lala... mon dieu!!! non!!!Citation:
On notera que, si un destructeur est priv�, il ne pourra plus �tre appel� directement, ce qui n�est g�n�ralement pas grave, dans la mesure o� cela est rarement utile.
Le destructeur est tout aussi indispensable que le constructeur, autrement, il est impossible d'invoquer delete (ou pire, n'importe quelle instance de la classe cr��e sur la pile ne sera correctement d�truite) ;)
Le destructeur fait partie des "big four" de la forme canonique de coplien, ce n'est pas un hasard ;)
De plus, constructeur et destructeur priv�s ne seront envisageables que si l'on dispose de fonctions membres statiques ou d'amiti�s d�clar�es qui y feront appel, autrement, il sera impossible de cr�er ou de d�truire l'objet, et la classe devient donc inutilisable ;)
concernant system("PAUSE"): donnes peut etre directement les bonnes habitudes en te basant sur la FAQ pour cr�er une pause de mani�re standard ;) (linux, pour ne citer que lui, ne dispose pas de l'instruction syst�me "pause" :D )
je lirai la suite plus tard ;)
suffit de commencer par la fin
La recherche de 'Delannoy' sur ce forum montrera la limite de cette r�f�rence ... (par expl, ici ou ici ou ici).Citation:
CONCLUSION :
Toutefois, pour plus de d�tails, nous vous renvoyons � l�ouvrage de Claude Delannoy � C++ pour les programmeurs C �
Pour apprendre le d�v, Programmation - Principes et pratique avec C++, de Bjarne Stroustrup
Pour sa d�fense, il est autoris� d'omettre le retour � la fin du main ; et alors un return 0; est ajout� implicitement. ;)Citation:
Envoy� par koala01
salut tout le monde,
merci pour vos contributions, j'ai vraiment approuv� et �a me permets de mieux me parfaire.
Par ailleurs pour le :
- retour en fin de ligne, je programme avec DEVCPP, et je pense que c'est g�rer automatiquement mais par contre sous turbo cpp, le retour est g�rer par le programmeur lui m�me.
- Merci 3Darchi pour le tuyau
- Vrai que toutes fonction membre n'est pas forc�ment virtuel sinon �a serait caduque, mais j'ai voulu mettre l'accent que dans une classe on a les membres donn�es et les fonctions membres ou m�thodes car dans la plupart des ouvrages c'est cette appellation que je rencontre.
En parlant de programmation structur�e c'est plut�t le C standard ou le pascal que je faisais allusion mais merci quand m�me.
- Pour initialise(), j'essayais d'introduire petit � petit les notions de fonctions membres et m�me dans la suite je l'ai remplac� par un constructeur. Merci pour la pr�cision avec new et delete
- Pour les constructeurs et destructeurs je comprend pas tr�s bien ce que vous avez voulu dire mais j'ai pr�cis� qu'ils �taient indispensable pour bien encapsuler les donn�es et qu'il serait pr�f�rable de les rendre public pour ne pas avoir a les appeler par d'autres m�thodes
- Merci pour l'astuce avec system("pause"), j'ai l'habitude de programmer sous window avec DEVCPP
Au prix minimum d'un avertissement, voir d'une erreur de compilation si tu compile avec l'option ad-hoc ;)Citation:
Envoy� par Ekleog
DevCpp n'est plus maintenu depuis des ann�es, et ce n'est vraiment pas une bonne id�e de continuer � l'utiliser (et encore moins d'inciter des d�butants � l'utiliser)...Citation:
Envoy� par fallphenix
Tournes toi peut etre vers Code::blocks :D
Quant � TurboCpp, c'est un EDI qui date, ou peu s'en faut, d'avant la normalisation du langage, et c'est donc encore pire que d'utiliser DevCpp ;)
- Merci 3Darchi pour le tuyau
Note que c'est ce que certains langages (que je ne citerai pas :D) ont pris comme principe ;)Citation:
- Vrai que toutes fonction membre n'est pas forc�ment virtuel sinon �a serait caduque,
Cela d�pend vraiment des ouvrages, et de l'approche du lecteur ;)Citation:
mais j'ai voulu mettre l'accent que dans une classe on a les membres donn�es et les fonctions membres ou m�thodes car dans la plupart des ouvrages c'est cette appellation que je rencontre.
Personnellement, je trouve sympa le fait de faire une diff�rence entre une fonction membre (non virtuelle) et une m�thode (fonction membre virtuelle), et j'ai l'impression que de plus en plus de gens sont du m�me avis... Autant en promouvoir l'usage :D
C'est, justement, en pensant au C que j'ai fait la remarque (tu n'as aucun besoin de connaitre le contenu de la structure FILE pour l'utiliser... c'est gr�ce � l'encapsulation :D )Citation:
En parlant de programmation structur�e c'est plut�t le C standard ou le pascal que je faisais allusion mais merci quand m�me.
Le fait est que cela fait penser au "C with classes", et que c'est une approche contre laquelle on se bat depuis des ann�es ;)Citation:
- Pour initialise(), j'essayais d'introduire petit � petit les notions de fonctions membres et m�me dans la suite je l'ai remplac� par un constructeur.
mais de rien ;)Citation:
Merci pour la pr�cision avec new et delete
Quelques petits rappels pour te faire comprendre :Citation:
- Pour les constructeurs et destructeurs je comprend pas tr�s bien ce que vous avez voulu dire mais j'ai pr�cis� qu'ils �taient indispensable pour bien encapsuler les donn�es et qu'il serait pr�f�rable de les rendre public pour ne pas avoir a les appeler par d'autres m�thodes
- M�me lorsque l'on n'a pas recours � l'allocation dynamique de la m�moire, le constructeur est automatiquement appel� lorsque l'on d�clare une variable du type de la classe, et le destructeur est automatiquement appel� lorsque l'on quitte la port�e dans laquelle la variable en question a �t� d�clar�e
- Tout ce qui se trouve dans l'accessibilit� private d'une classe (ou d'une structure, vu que c'est kif kif en C++ ;)) n'est accessible que par les fonctions membres de la classe en question, et par les fonctions statiques de la classes en question.
S'il n'y a pas une fonction statique qui fait appel explicitement au constructeur (ou au destructur) et que celui-ci est priv�, il devient impossible de construire (ou de d�truire) une instance de la classe vis�e...
La classe devient donc totalement inutile ;)
Mais autant donner tout de suite de bonnes habitudes, y compris celle d'utiliser une m�thode permettant d'assurer la portabilit� du programme, chaque fois que possible ;)Citation:
- Merci pour l'astuce avec system("pause"), j'ai l'habitude de programmer sous window avec DEVCPP
Au passage, le fait d'utiliser l'instruction "system" fait d'office appel � un appel au niveau du syst�me d'exploitation, ce qui, pour certaines instructions, risque de plomber litt�ralement les perfs ;)
Tu me diras sans doute qu'appeler system("PAUSE") � la fin d'un programme ne nuira pas aux perfs, mais, si cela implique l'habitude de le faire chaque fois qu'une pause est n�cessaire, voir d'invoquer l'instruction system pour d'autres choses... :aie:
@koala01: Tu as un warning quand tu mets pas de return � la fin d'un main ? Tu as test� avec quoi ? J'ai rien en WAll sous VC++ 2010 et en WAll + WExtra sous gcc (mingw) 4.6.2. C'es completement standard de ne rien mettre � la fin d'un main.
En effet, au temps pour moi...Citation:
Envoy� par Flob90
Je n'avais pas v�rifi� avant de poster, mais, en effet, main est une fonction qui peut ne pas avoir de return :aie:
C'est, finalement, assez �trange quand on sait que, pour tout autre fonction n'ayant pas void comme type de retour, tu auras un avertissement si tu n'a pas le "return" (Gcc 4.7 -wreturn-type ) ;)
Oui ca m'avait un peu choqu� quand j'ai vu ca, mais bon, ca fait partie des petites choses qui font que main est une fonction sp�ciale ^^.
Je vais plus loin, la bonne pratique c'est de configurer/apprendre � se servir de de/mieux choisir son EDI.Citation:
Envoy� par koala01
Certainement pas de parasiter son code avec des pauses.
(tr�s bonne initiative de venir se soumettre � la critique chez les pinailleurs perfectionnistes que nous sommes :))
a- "Comme on peut s�en douter, l�h�ritage facilite largement la r�utilisation de 0produits existants"
Arg.
Toujours ce m�me mensonge des ann�es 80. Tu es une victime de vieux arguments commerciaux qui sont malheureusement � c�t� de la plaque.
Nous savons r�utiliser depuis les routines (gosub, fonctions, & cie).
La force et l�int�r�t premier de l'h�ritage r�side dans la substituabilit�. C'est une n�cessit� en vue de supporter le polymorphisme d'inclusion.
b- "surd�finition"
Elev� au Delannoy ?
La traduction r�pandue de "overloading" est "surcharge". Et "red�finition" (bien que "supplantation" soit plus juste) pour "overriding" -- note qu'en anglais, c'est "over" qui revient et pas la partie de droite ...
c- Euh dans les nouveaux trucs par rapport au C, il y a le RAII, les exceptions, et les templates (dans les trucs les plus visibles qui font toute la diff�rence)
Accessoirement, tu as deux entr�es "sp�cificit�s"
d- "initialise()"
graaaa. Pourquoi parler de comment il ne faut pas faire? (c'est ann�es 90 cette approche, pour ceux qui d�couvraient la POO apr�s 15 ans de C ou de Pascal)
Pars directement sur la bonne fonction -> le constructeur
(tiens j'avais manqu� des messages => +1 pour d�gager initialise)
e- des char* avant std::string
�a sent l'approche historique tout �a...
Modernise ton cours.
Sinc�rement. Cela fait partie des autres trucs contre lesquels on se bat => avoir un C++ maintenable et robuste m�me et surtout chez les d�butants
f- D�cid�ment, je reconnais que trop bien le support sur lequel tu t'appuie.
Je t'invite � consulter un ouvrage moderne d'apprentissage du C++
-> Accelerated C++ de Koenig et Moo chez Addisson-Wesley (non traduit)
-> Je me Lance (plus �dit�) de Francis Glassborrow
-> Pratiques et Principes de Programmation en C++ de Stroustrup
g- Le destructeur de vect appelle le mauvais delete.
C'est une remarque g�n�rale, car je note l'erreur plus d'une fois.
h- On a deux s�mantiques typiques en C++
- entit� (o� l'on interdit la copie et l'affectation, typique des classes o� il y a un h�ritage public)
- valeur (o� l'on supporte copie, affectation, et comparaison)
Quand on traite de la s�mantique de valeur, et que l'on doive sp�cifier la copie, il faut alors toujours sp�cifier �galement l'affectation.
Cf FAQ pour des bonnes fa�ons.
=> Tout �a pour dire que j'en suis aujourd'hui arriv� � la conclusion de deux chapitres un pour les valeurs, un pour les entit�s, et de montrer les bonnes fa�ons de proc�der et accessoirement d'utiliser des exemples typiques de chaque s�mantique.
i- 'int pleine()' C'est du C �a.
En C++ -> "bool est_pleine() const"
La const-correction a �t� pass�e sous silence bien trop longtemps.
Et je vois bien d'autres endroits o� tu n'utilises pas le type bool�en.
j- p63: "delete ( tab + nelet-1);"
quoi ?
Cela n'a pas le moindre sens.
k- exit()
Ne leur montre pas exit(). C'est une fonction fortement d�conseill�e en C++ car elle ne provoque pas la destruction des variables locales. Elle va du coup � l'encontre du RAII. Si le programme doit absolument nettoyer un truc en se terminant, il ne pourra plus forc�ment le faire.
l- je t'invite � lire l'entr�e de la FAQ (c++lite ?) au sujet de l'amiti�.
Tel que tu formules, on pourrait croire qu'il s'agit d'une rupture d'encapsulation alors que c'est tout le contraire.
D'ailleurs quand tu �cris: "une telle d�claration d'amiti� les autorise alors � acc�der aux donn�es priv�es, au m�me titre que n'importe quelle fonction membre", oui c'est exactement pour �a qu'il ne s'agit pas d'une rupture d'encasulation.
BTW, pour matrice * vecteur, il est naturel d'exposer les �l�ments, cela fait parti de leur interface.
Plus loin, enseigne leur de suite le passage par r�f�rence constante et non le passage par copie. Je suis s�r que tu ne veux pas que tes �l�ves soient pris de haut par qu'ils plombent les perfs sur des trucs aussi idiots.
m- de nouveau, tu me sembles avoir un nombre d'heures limit�es -- vu que je n'ai pas vu une seule trace des exceptions&RAII, de la const-correction, etc. Ne le gaspille pas en montrant ce qu'ils ne doivent pas faire. Montre-leur au contraire la fa�on d�finitive de proc�der -> op�rateurs math�matiques surcharg�s et pas mult/add/prod etc.
n- � ce sujet ->lien externe<- vers une �criture (interface) type des op�rations math�matiques.
o- mauvais choix de classe pour illustrer l'h�ritage.
Il y a de beaux m�langes (insolubles! si, si!) entre valeurs et entit�s (induite par l'h�ritage) entre des points et des pointcol
De nouveau une fonction initialisesec ... c'est le mal!
p- initialise() n'est pas une red�finition, c'est une surcharge masquante!
red�finition rime avec virtual.
q- je vois un tableau de d�rivation (public, etc)
Je crois que je m'�tais fait avoir aussi dans le pass�.
Ce n'est pas �a l'important. L�, on parle de syntaxe et pas d'intention.
D'intentions, on n'en a que deux
- importer du code et rien d'autre
- �tre substituable (avec �ventuellement import de code)
cas1 -> h�ritage priv�
cas 2 -> h�ritage public
Le pourquoi ? Eventuellement, tu peux montrer le tableau ... en annexe. Mais ce n'est pas �a l'important.
r- "point (point & p)"
Pas const-correct
Et tu vas dans le mur � vouloir donner une s�mantique de copie (/valeur) � des trucs tir�s d'une hi�rarchie. Le slicing va te rattraper.
Solution ? Prendre un exemple o� il est indubitable que les objets manipul�s sont bien des entit�s et qu'il n'y a aucun sens � les copier.
s- <<que la classe A est "virtuelle">>
Une classe virtuelle ne veut rien dire. -> http://www.developpez.net/forums/d11...e/#post6304603 (4 derni�res lignes)
Attention, tu pars sur un terrain glissant � montrer l'h�ritage multiple sans avoir parler pr�alablement du LSP.
t- Remonte d'un cran ton chapitre sur les fonctions virtuelles, il est 100 fois plus important que celui sur l'h�ritage multiple.
De plus il n'y a pas de red�finition sur des fonctions non virtuelles.
C'est la d�finition.
u- Tr�s bien, il fait parler des std::string
Mais tu le fais beaucoup trop tard.
v- dans la famille la bonne pratique d'abord, fais d�river tes exceptions de std::exception
Ou plus simplement commencer par montrer comment utiliser les exceptions standard, puis �ventuellement comment on �crit une classe d'exception.
Et surtout, initie-les au RAII.
w- s/exit/return/
exit, c'est aussi le mal
x- Ah! j'avais reconnu la patte de l'ouvrage qui a inspir� ton cours.
Ne prends donc pas personnellement toutes les critiques que l'on peut faire. Elle ne viennent pas de toi. Juste d'un support qui appartient � une famille de supports que nous combattons.
R�sultat d'un �chantillonnage.
- main sans type de retour? Si je ne me trompe pas, c'est interdit m�me en C de nos jours.
- change les feuilles de style d�crivant le code. Il y a trop d'espace vertical. (Les autres feuilles de styles sont a revoir aussi par quelqu'un ayant des notions de typographie; du gras italique soulign�, �a fait mal aux yeux)
- indentation al�atoire
- on n'utilise float que quand il faut stocker beaucoup de donn�es, et on fait quand m�me les calculs (et tous les r�sultats interm�diaires autant que possible) en double (sauf cas particuliers qui sont hors sujet vu le reste du cours)
- "La version 3 de C++ a int�gr�", c'est tr�s 1991 (date de la sortie de la version 3, de nos jours a ce niveau la, on se fout de tout ce qui pr�c�de la norme, 1998).
- new de tableau -> a remplacer par des vector, pour moi technique avanc�e hors sujet
- new nothrow -> trop avance a mon avis vu le reste du cours
- pas de mention de la d�coupe en hpp/cpp? C'est pourtant difficile de faire quoi que ce soit sans la mettre en pratique. (A mentionner au minimum: gardes d'inclusion, pas de using dans les hpp, utilisation des declarations plutot que des definitions; a rementionner quand on traite des templates car la d�coupe naturelle n'est pas possible)
Merci � vous tous,
Je constate que j'ai encort des pas � faire dans le C++, en faites j'apprends la programmation tout seul car mon domaine c est l electronique et la t�l�communication et je compte sur vous tous pour les eventuelles contributions.