Vos questions sur la suite des cours

Citation : M@teo21
Hum, je ne suis sûrement pas expert en C++ mais passé à coté des templates, c'est se fermer la porte :

• de toute la partie de la STL concernant les conteneurs (et de boost à plus forte raison)
• des choses bien pratiques dans le style singleton adaptable à n'importe quelle classe
• de la métaprogrammation (mais bon là c'est une autre histoire)

En revanche ça "oblige" à surcharger ses fonction à n'en plus finir.

Ceci dit je crois aussi qu'il y a plus urgent.

Et puis Qt en est bourré (façon de parler et plus en utilisation quand nombre) : QList, QHash, QPointer, QVector, QMap

C'est quand même là qu'on voit le paradoxe du C++. D'un côté on essaie de donner aux gens un moyen d'éviter de réinventer la roue et de l'autre chaque toolkit y va de sa sauce pour les containers et autres string.

Garuma, c'est un autre débat. Pour info, si Qt réinvente la roue c'est pour deux raisons : certaines implémentations de la STL sont incomplètes et/ou bugguées, et pour ajouter deux-trois fonctionnalités. Le tout en STL-compatible.


Selon moi, le C++ n'est rien d'autre que du C polymorphique, avec une librairie standard plus évoluée.
Le polymorphisme se scinde en deux grandes parties :
- polymorphisme statique, avec les templates et la surcharge
- polymorphisme dynamique, avec les méthodes virtuelles

Eliminer du cours les templates, c'est éliminer 50% de ce que le C++ apporte au C (et 100% de la STL, qui, rappelons le, signifie Standard Template Library).

Citation : NilatOn peut très bien utiliser la STL sans savoir comment faire un template. A utiliser, c'est d'une simplicité remarquable. A le faire, j'en sais rien.

La SL (sans T -- car c'est bien plus qu'un sous-ensemble de la STL historique) est importante et ne doit pas écartée. Je rejons shuss : il n'est pas nécessaire de savoir écrire des classes et fonctions génériques/templates pour savoir s'en servir. En particulier celles de la bibliothèque standard -- que je trouve plus importantes à voir que les pointeurs au début.

La SL est un compromis entre généricité, stabilité (même face aux exceptions) et rapidité. A écrire, ce n'est pas si simple. A.Stepanov a des notes sur le sujet que j'avais trouvées en explorant le wiki d'ASL d'Adobe.

C'est clair qu'il n'est pas compliqué de placer un std::vector<int>... Mais manipuler des choses qu'on ne comprend pas (en l'occurrence <>) est très mauvais.
Ce n'est pas un concept difficile à comprendre, c'est beaucoup plus abordable que le polymorphisme dynamique.

Mateo21 est ce que les cours C/C++ seront terminé a la fin de l'été ?
Merci beaucoup pour ce beau tutoriel et bon continuation

h_raf

Ben il reste la partie C++ a finir, et la partie QT a écrire. Sachant qu'il alterne avec le tuto linux et que en ce moment il est occupé, ça m'étonnerais beaucoup que ce soit fini à la rentrée

Euh, je m'y emploierai, mais je ne pense pas avoir tout à fait terminé. En ce moment mon stage m'occupe pas mal (ce qui explique l'absence de nouveaux cours), il faut que j'arrive à trouver mon propre rythme et pour le moment je ne l'ai pas encore trouvé<

prends ton temps, le principal étant que la qualité de tes tutos perdure

Citation
Citation
Citation

Faudrait peut-être savoir, non ? L'ordre n'est pas forcément important tout ça, mais bon voilà.

J'ai corrigé pour le qcm, pour le reste c'est parfaitement cohérent.

Bonjour,
C'est toujours d'actu la lib QT4?
Merci pour ce site, et de tous les effors que vous faitent pour le tenir à jour.

cette question à été posé au moins 50 fois depuis le début du forum! et oui c'est toujours prévue. comme le dis souvent un de mes prof, à force de répétition, ça va finir par rentrer!

Qt4 n'est pas une lib, c'est un Framework, ça aussi faut répéter pour que sa rentre.

En même temps un framework est un ensemble de bibliothèques alors...

Bonjour,

Je viens de voir le nouveau chapître sur les opérateurs. Voici mes commentaires pour M@teo21 -- et les autres qui veulent lire, même si je pense que vais surtout réveiller ceux qui veulent les dates des prochains chapîtres

a- L'utilisation des valeurs par défaut ne peut pas fonctionner (ne compilera
pas).
D'abord l'"affectation" doit être réalisée dans la déclaration et non dans la définition de la fonction
Ensuite, s'il y a une valeur par défaut pour chacun des paramètres, alors le constructeur devient le constructeur par défaut, or tu déclares déjà un constructeur par défaut sans paramètres. C'est l'un ou l'autre, cela ne pourra jamais compiler.
(Perso je voterai pour gicler l'opérateur par défaut sans paramètres)

EDIT2: cela peut compiler à coups sûrs sous certaines circonstances qui mériteraient des explications qui dépassent très certainement le cadre d'un tuto. AMHA, la bonne pratique est de définir les valeurs par défaut des paramètres lors de la déclaration de la fonction membre, pas durant sa définition. Cf mon autre post sur la page suivante pour un chouilla plus de détails.

b- Code : C++
n'est pas une déclaration qui définit et construit un objet. C'est une déclaration de fonction. Il faut dégager les parenthèses vides pour que cela corresponde bien à une déclaration+construction de variable.

c- Définir des opérateurs binaires comme fonctions membres est possible, mais rarement conseillé. C'est d'autant plus déconseillé lorsqu'il y a possibilité de promotion à la volée d'un des deux paramètres. Typiquement:
Code : C++
En définissant l'opérateur binaire comme membre, la première ligne compilera, la seconde non.
C'est pour ce soucis de symétrie que la communeauté a convergé vers la définition des opérateurs binaires comme des fonctions libres (non membre). Du coup, l'écriture canonique devient tout simplement:
Code : C++
Remarque, cette définition s'appuie sur l'existance de l'opérateur d'incrémentation +=(), et ne requiert aucune amitié.

Les "vieux" cours n'ont pas toujours le recul là dessus et préfèrent montrer toutes les syntaxes (en préférant à tord les versions membres) plutôt que les syntaxes canoniques et justes.

NB: pour ne pas autoriser "d + 42", il aurait fallu que le constructeur pouvant se manipuler comme un constructeur de conversion à 1 argument soit déclaré "explicit".

(Même combat pour la comparaison)

d- Au fait, pour ce genre de classes, il n'est pas rare que l'on préfère se simplifier la vie pour ne manipuler qu'un seul attribut (démonstration qu'un accesseur retourne une propriété, et qu'à toute propriété ne correspond pas un et seul attribut et vice versa)
Code : C++

e- Citation : M@teo21
"égaux" serait plus juste qu'"identique". L'identité est la chose qui nous intéresse dans la sémantique d'entité, l'état est la chose qui va plus nous intéresser dans la sémantique de valeur.
i et j deux entiers peuvent être égaux sans que i et j soient identiques (altérer l'un n'altèrera pas l'autre). Tandis que pPerso1 et pPerso2 peuvent être deux pointeurs référençant le même personnage ; dans ce cas, il y a identité. De même pBob et pRenee peuvent pointer vers deux personnages différents, mais ayant le même état -- les voir comme des jumeaux.

f- Je l'avais déjà signalé dans ma précédente tartine (que je ne suis pas sûr que tu aies lue) : l'opérateur d'affectation aurait dû être traité en même temps que le constructeur de copie et les problèmes de dangling pointers pour lesquels tu avais fait de jolis schémas.
Ici, l'intérêt de l'opérateur d'affectation est vite limité vu que celui généré par défaut non seulement, suffit mais en plus il est à préférer.

g- À propos d'opérateur d'affectation, c'est une référence vers l'objet courant qui devrait être renvoyée, pas une copie.

h- L'opérateur d'injection (<<) devrait prendre une référence constante (cela fait parti des habitudes à prendre tôt)

i- Bien l'esquive de l'amitié via la fonction membre afficher().
Au fait, il la faudrait const.

j- Concernant le QCM : quand on surcharge les opérateurs, on peut leur faire renvoyer n'importe quoi. On peut très bien imaginer que le modulo entre deux durées soit un nombre. La réponse que tu attends est la réponse canonique.

k- Très très bien de rappeller que la surcharge des opérateurs doit servir le but d'avoir un programme lisible et maintenable. En gros que les sémantiques que l'on donne doivent rester proches des sémantiques naturelles -- une sémantique mathématique/arithmétique dans le cadre des durées prises en exemple.
C'est certanement la leçon la plus importante du chapitre.

EDIT: prise en compte de la remarque de shuss : j'avais oublié un '+'.
EDIT2: un opérateur n'est pas une variable mais une fonction ^^'. Plus j'avais dis des choses incorrectes au sujet des valeurs par défaut pour des paramètres.

Je n'avais pas attendu ce cours pour utiliser les opérateur (puisque Kayl les utilisait, donc il me restait plus qu'à m'en inspirer), mais je dois dire que c'est plus clair maintenant.

Sinon, je me demandais quelques trucs :

Les opérateurs << et >> sont appelé "opérateurs de flux" (puis "opérateurs d'injection par notre ami"). Mais je les ai déjà vu comme opérateurs binaires (décalage binaire, qui correspond à une multiplication par 2ⁿ). Donc quelle utilisation est "légitime", est-ce que les "opérateurs de flux" ne viennent pas d'un visuel graphique de ces opérateurs là, ou est-ce que cet opérateur est clairement l'un ou l'autre selon les types de variables.

La deuxième chose, c'est sur les valeurs retournée. Peut-on retourner n'importe quelle valeur, c'est à dire faire retourner un type totalement différent que les variables "additionnées", faire retourner autre chose qu'un type logique avec un opérateur logique ... ? (bien sûr, dans les limites du compréhensible, il faut que cela garde une certaine logique).

La troisième est que je me demandais s'il existe un opérateur logique qui définit l'attitude d'une condition sur un type donné. Par exemple, si je fais if(heure), est-ce que je peux faire en sorte que si l'heure est 00:00:00, ça me fasse comme if(false) ?


PS : le c) de lmghs m'intrigue beaucoup ... faudrait que je teste ça. Mais par contre :Code : C++Il ne devrait pas y avoir un + après operator ?

J'aurais une petite suggestion qui ne concerne pas le cours en cours (...), et comme je ne sais pas où la placer, je propose ici:

Serait-il possible de rajouter une annexe avec tous sur les opérateurs, c'est-à-dire :

• Précédence
• Utilisation, ce qui inclue:
  • Cas où on l'utilise
  • Unaire/Binaire/Ternaire pour chaque cas
  • Surchargeable ou non (voire si possible une forme générique de surcharge
• D'autres choses utiles auxquelles je n'aurais pas pensé

Voilà, je trouve que ça ne serait pas mal d'avoir ceci de disponible directement sur le sdz, ce serait une référence pour qui veut manipuler les opérateurs.

Si cela est réalisé, merci beaucoup en tout cas

@shuss: Tu as parfaitement raison : j'ai oublié le '+'. Je vais corriger en conséquence. Merci.

Les opérateurs << et >> sont initialement utilisés en C pour les décalages de bits. Les flux C++ se les ont appropriés en effet. Probablement pour l'aspect visuel je pense aussi.
Dans le contexte des flux, on peut parler d'injection (<<) et d'extraction (>>).

Ce qui n'empêche pas que l'on peut les définir autant pour des décalages (l'argument droit sera un nombre, et le gauche un truc décalable), que pour des flux (l'argument gauche sera un flux). Dans ces deux cas, ils sont asymétriques. Leur donner une signification symétrique serait perturbant.


On peut renvoyer ce que l'on veut tant que l'on est capables d'établir un ensemble de paramètres uniques dans un référentiel lexical (espace de noms, et autres classes) donné - i.e., tant que l'on est capables de savoir lequel appliquer et quand (*). Même aux opérateurs logiques. Il y a quelques temps, je m'étais amusé à voir ce que l'on pouvait en faire : http://www.developpez.net/forums/showthread.php?t=207859 (message # 12) (c'est limite de l'ofuscation, mais ... c'est possible)

(*) Un Code : C++
pourrait très bien être utilisé pour signifier que Roger tape sur Bob, et renvoyer le nombre de points de vie restants de bob. Est-ce possible ? Oui. Est-ce une bonne idée ? Certainement pas! C'est la principale leçon à retenir avec les opérateurs : savoir les surcharger avec parcimonie, et seulement dans les cas où cela a un sens acceptable et clair.


Enfin, il est tout à fait possible de renvoyer un truc qui s'évalue implicitement à vrai ou faux (e.g. if (date)). Mais là le C++ montre ses limites. Sur artima et ailleurs ("Imperfect C++", et dans quantités d'autres articles ; chercher "safe bool" dans un contexte C++), il y a eu des tentatives pour définir proprement un opérateur booléen d'évaluation de l'état d'un objet qui sache limiter les effets de bord indésirables. C'est possible, mais il n'y a pas de recette ultime encore. Avoir une fonction membre bien nommée n'est pas déconnant.

Besoin d'aide svp :
http://www.siteduzero.com/forum-83-147371-p1-c-sdl-gestion-des-evenements.html

Citation : Jangkun

Ouai mais nan, ici on parle que du cours en lui-même
Si tout le monde se mettait à poster ici dès qu'ils avaient un problème où personne ne répond, on s'en sortirait pas

Au fait, je voudrais savoir, pourquoi m@téo, dans sa classe durée, n'a pas fait un seul constructeur avec les valeurs par défaut déclarées dans la déclaration de la classe ?

Citation : psychoh13

Oui, et alors? C'est un ensemble en effet, mais ce n'est tout de même pas une lib. C'est d'ailleurs pour ça que le terme Framework existe...

Ça fonctionne de la même manière, de loin et en passant vite. Au lieu de prendre 15 bibliothèques séparées on les met en une seule, mais sinon on les utilise de la même façon.

Bref laisse tomber, là c'est même plus la peine que je continue... c'est perdre mon temps....

Citation : psychoh13

PAS DU TOUT.

Un framework est un ensemble de modules interconectés pensés et crés dans une même logique ,selon la même organisation.
Il ne s'agit pas du tout de mettre 15 bibliotheques différente dans le même paquet et de dire "ceci est un FrameWork".

Bordel mais ça change quoi sur le fait qu'on utilise ça de la même façon ?!
Si on crée un framework c'est bien pour réunir des bibliothèques qui ont un rapport entre elles pour les traiter en un seul bloc ! On dit exactement la même chose depuis tout à l'heure, mais vous voulez juste chipoter sur le fait "non c'est pas une bibliothèques c'est plusieurs bibliothèques interconnectées dans une même logique"

Je sais bien qu'on va pas mettre deux trucs qui n'ont aucun rapport ensemble ! Le truc c'est qu'au final tu linkes le framework à ton projet comme tu linkerais l'une de ses bibliothèques et tu utilises les méthodes contenues dans le framework comme tu utiliserais les méthodes contenues dans une bibliothèques. C'est pour ça que je dis que le framework c'est COMME une bibliothèque, il faut bien insister sur le "COMME", ça veut dire qu'ils ont pas mal de points communs mais que c'est PAS LA MÊME CHOSE.

"PAS DU TOUT" tu vas me dire que ce n'est pas un ensemble de bibliothèques peut-être ?!
Parce que même si ces bibliothèques sont interconnectées et on un rapport logique entre elles, il s'agit bien de bibliothèques DIFFÉRENTES, à quoi ça servirait de faire un framework contenant 15 fois la même bibliothèque, je te le demande !!!

Non,ce n'est pas un ensemble de blibliotheque.
C'est une seul et même blibliothèque découpé en module.
C'est totalement différent.

D'ailleur si tu link ton framework dynamiquement , tu peux ne linker que certains modules.

Bon... On va arrêter ce dialogue de sourd parce qu'on n'arrête pas de répéter les mêmes choses que l'autre...
Répondons maintenant à une autre question. Dans la classe "durée" pourquoi il y a deux constructeurs ? (un sans paramètres et l'autre avec 3 paramètres qui ont une valeur par défaut), alors qu'on pourrait dans la déclaration de la classe, ne mettre qu'un seul constructeur avec les 3 valeurs par défaut ?