striiiiiiiiiiiiiiing - Page 9

(cross)
squalyl> ouais mais personne ne t'oblige à écrire ça hein.
c'est pas parce que tu peux combiner plein d'opérateurs pour obtenir un truc qui compile que c'est à utiliser

carrément

J'allais le dire, c'est pas parce qu'on peut écrire comme un porc que le langage est foireux en lui-même ^^ Tant qu'on peut coder proprement, c'est l'essentiel (et là, j'ai du boulot...).

Brunni (./237) :
Déjà en Java tu ne passes pas les paramètres par référence, mais toujours par valeur, ce qui te garantit l'absence d'effet de bord comme celui de ta fonction Fibonacci.
Ensuite les objets sont toujours des références, i.e.:

Conclusion: quand tu appelles une fonction y'a plein de trucs qui ne sont pas passés par référence.
Cherche la contradiction dans ton post ^^

En C++ en général tu vas utiliser des pointeurs lorsque les objets sont alloués dynamiquement et partagés dans tout le programme.

J'aurai plutôt dit, quand tu as des objets dynamiques (que l'allocation soit dynamique on s'en fout) et que le pointeur NULL est une valeur utile pour ton programme. Sinon, perso je met des références partout où je peux éviter de mettre des pointeurs (et où, évidemment, je ne peux pas mettre de variable/champ qui ne soit ni une référence ni un pointeur)

Tu vas utiliser des objets sur la pile lorsqu'ils sont locaux et lorsqu'ils ne sont pas trop coûteux à manipuler (chaque passage par paramètre implique une copie de l'objet
!).

Justement non, pas si tes fonctions ont été bien foutues et prennent des valeurs en référence (les const & qui ont l'air si chères à aze).

Quant aux références en général tu ne les utilises que dans des cas particuliers, puisqu'un objet alloué sur la pile va être détruit automatiquement à la fin de la fonction qui te l'a fourni. Du coup tu ne peux pas garder l'objet pour plus tard, et ton code ressemblera plus à de la prog procédurale. C'est pour ça que c'est surtout pour simplifier la syntaxe (éviter l'* et le ->) et éviter la copie (mauvaises performances) qu'on utilise ça.

Oh non, y'a aussi 2-3 autres petits trucs sympas. Par exemple tu es obligé d'allouer une référence, une fois et une seule, donc tu ne risques pas involontairement d'appeler une méthode sur un pointeur NULL ou autre chose de pire encore. Par contre, comme pour les pointeurs, tu peux innocemment exporter un objet local dans un autre endroit du programme, et invoquer le chaos, à l'aide de tes fidèles serviteurs papillons.

En C# les références se font avec le mot clé ref et on les utilise rarement, en Java elles n'existent pas. Donc c'est pour ça que ça ne sert à rien de trop chercher à les utiliser, car ça ne te sera pas vraiment utile pour la suite

En C# les références ne sont pas des références, ce sont des pointeurs sécurisés (l'implémentation bas niveau a un nom à la con faut que je retrouve). Ça veut dire que tu as bien accès à une case mémoire à une certaine adresse, mais tu ne connais pas l'adresse, tu peux juste y lire et/ou y écrire. Malgré ça, c'est vraiment pratique, et... on s'en sert. (PS: un ref MaClasse truc en C# c'est l'équivalent d'un MaClasse **truc en C++)
Mais on a aussi des vrais pointeurs (des pointeurs "natifs") qui te permettent de faire tout et n'importe quoi de manière non [simplement] vérifiable

GoldenCrystal (./244) :
(les const & qui ont l'air si chères à aze).

la const-correctness c'est bon, mangez-en

En C# les références ne sont pas des références, ce sont des pointeurs
sécurisés (l'implémentation bas niveau a un nom à la con faut que je retrouve). Ça veut dire que tu as bien accès à une case mémoire à une certaine adresse, mais tu ne connais pas l'adresse, tu peux juste y lire et/ou y écrire.

c'est quoi qui change concrètement par rapport à une référence ? parce que comme ça je ne vois pas bien la différence

Ce que je voulais dire c'est que référence en C# = pointeur en C++.
Et référence en C++ = comportement standard pour les types référence en C#.
(Pour les types valeurs en .NET, l'utilisation se recoupe +/-, la sécurité en plus côté C# )

Quand au const-correctness j'ai pas de problèmes, je fous déjà des const de partout. (Tant que ça empêche pas le code de compiler, alors c'est que j'ai eu raison d'en mettre ! )

Je l'attendais celle-là
Les paramètres sont toujours par valeur, une référence est une valeur (ou une adresse si tu préfères, c'est à dire un entier passé par copie).
Ensuite oui un objet est toujours une référence, c'est logique si tu codes vraiment en POO (chacun peut affecter l'état d'un objet, car il est considéré comme une entité indépendante, du coup tu ne devrais pas te reposer sur son état interne; ça rejoint la prog par "message" en C dont je parlais plus tôt). Mais là on parle de vrais objets, pas d'enregistrements (struct en C) ou d'objets encapsulant un élément mathématique, qui ne sont pas des objets au sens POO.
D'ailleurs en C# le type struct j'évite vraiment sur le principe, les seuls cas où ça se justifie c'est pour les vecteurs, bigint et autres, mais c'est particulier. Ensuite l'utilisation abusive de ref en C# dénote presque toujours un code de merde, du moins d'un point de vue POO (je ne trouve pas de contre-exemple).
Ensuite utiliser une référence const juste pour améliorer les perfs c'est pas mal sur le principe et on peut justifier que c'est une bonne habitude, mais c'est déjà un truc "avancé" qui est contraignant et pas très bon pour débuter, et je le répète mais ça correspond à une programmation procédurale, pas objet, puisque tu utilises ton objet comme un enregistrement.

Ben si tu vas par là, alors aucun langage n'a de passage de param par référence si tu considère une référence comme une valeur. Mais on ne risque plus d'avancer des masses dans la discussion alors.

Sinon j'ai pas bien compris le reste de ton message.
chacun peut affecter l'état d'un objet si tu codes réellement en POO ? mais non au contraire, irait à l'encontre des principes d'encapsulation si tout le monde est autorisé à modifier un objet privé détenu par un autre objet. Et de la même manière, pourquoi un objet encapsulé dans un autre devrait l'être par référence et pas par valeur ?

sinon pour le passage par const ref au lieu de par valeur, oui c'est une optimisation, mais c'est une bonne habitude à prendre à mon sens

Brunni (./247) :
Je l'attendais celle-là Les paramètres sont toujours par valeur, une référence est une valeur (ou une adresse si tu préfères, c'est à dire un entier passé par copie).

Oui et tout est ultimement une valeur mais si tes objets sont des références, alors tu passes les objets par référence dans les fonctions, c'est tout. Et l'implication de ça c'est que ton objet peut toujours être modifié directement par la fonction (le contrat "const" n'existe ni en Java ni en C#... pour l'instant ).

D'ailleurs en C# le type struct j'évite vraiment sur le principe, les seuls cas où ça se justifie c'est pour les vecteurs, bigint et autres, mais c'est particulier.

C'est pas du tout particulier ça, justsement. Et c'est bon pour les performances quand tu peux en mettre. C'est mieux de stocker 1000 structures de 20 octets dans une liste que 1000 pointeurs (de 8 octets) vers des classes de 20 octets allouées sur le tas.
(C'est aussi valable pour le C++ ce que je dis là hein )

Ensuite l'utilisation abusive de ref en C# dénote presque toujours un code de merde, du moins d'un point de vue POO (je ne trouve pas de contre-exemple).

C'est pourtant pas compliqué, j'en ai un très bon. Depuis que cette méthode existe, j'ai essayé tant bien que mal de trouver des cas où utiliser que l'indexeur [] bête et méchant du dictionnaire s'avérait plus intéressant, mais je cherche encore...

Ensuite utiliser une référence const juste pour améliorer les perfs c'est pas mal sur le principe et on peut justifier que c'est une bonne habitude, mais c'est déjà un truc "avancé" qui est contraignant et pas très bon pour débuter

C'est pas vraiment d'un très haut niveau, mais c'est vraiment une bonne habitude à prendre. Par contre ne pas tomber dans le jeu complètement con de foutre des références sur des types dont la taille est inférieure à ±deux fois celle d'un pointeur, car ça c'est vraiment débile. (Ça n'empêche pas de mettre le const par propreté par contre... Mais le code qui utilise les paramètres en tant que variables c'est cool aussi ! \o/)

et je le répète mais ça correspond à une programmation procédurale, pas objet, puisque tu utilises ton objet comme un enregistrement.

Je vois pas en quoi le fait d'utiliser une référence veut dire que tu utilise ton objet comme un enregistrement mais bon... ^^

[Edit] Cross avec GC
Hmm c'est difficile à mettre le doigt sur la diff, mais pour moi:

void truc(Objet *o) {
   // o est une valeur
   o = NULL;
}
void truc(Objet &o) {
   // o est une référence
}

Puisque dans le premier cas je peux jouer et modifier 'o' sans affecter le programme d'où 'o' vient. Alors que dans l'autre cas je touche direct au 'o' de l'appelant, même sans le vouloir (d'où l'intérêt d'avoir dans ce cas les mots clé in et out, ce que le C++ propose à moitié avec le const).
Mais bon ce n'est pas très intéressant de pinailler pour ça et j'imagine qu'il doit déjà y avoir des millions de trolls sur le net qui en ont débattu, je pensais juste que ça méritait la précision

aze (./248) :
chacun peut affecter l'état d'un objet si tu codes réellement en POO ? mais non au contraire, irait à l'encontre des principes d'encapsulation si tout le monde est autorisé à modifier un objet privé détenu par un autre objet. Et de la même manière, pourquoi un objet encapsulé dans un autre devrait l'être par référence et pas par valeur ?

Houlà non c'est pas ce que j'ai voulu dire. Un objet ne doit pas te mettre à disposition un objet qui lui est privé! C'est pour ça que dans les getters tu fais normalement toujours des .Clone(), ou mieux tu retournes des informations moins spécifiques à l'implémentation interne, et finalement les objets utilisés comme des enregistrements sont immuables.
Sinon un objet encapsulé dans un autre peut l'être par valeur oui (vu que c'est un objet local au sens C++) mais bon ça ne change plus grand chose au final puisque lui seul a la référence, c'est juste plus lent...

bon, je ne suis pas du tout d'accord avec ton premier point, mais t'as raison, on va pas pinailler

ensuite ouais, j'avais pas compris grand chose
Sinon, si tu dois faire un clone dans un getter c'est parce qu'en java il n'y a pas de const-ref c'est ça ? parceque si tu renvoies une const-ref, alors c'est l'appellant qui fera un clone s'il a besoin de la modifier. c'est quand même une perte de temps de faire un clone à chaque fois

Oui et c'est pour ça qu'il faut préférer les 2 autres solutions:
1) ne pas directement exposer tes objets internes mais permettre à un autre objet de demander des infos plus spécifiques plutôt qu'un gros objet avec "voilà un gros machin, ptet qu'il y a ce que tu cherches dedans". Après c'est clair que dans la pratique c'est beaucoup plus agréable, alors on fait un Clone
2) si tu utilises un type pour véhiculer des informations, il y a des chances qu'il soit mieux immuable. Ca veut dire que son état ne peut aucunement changer par la suite, c'est équivalent à dire toutes les méthodes sont const excepté le constructeur. C'est le cas par exemple des chaînes en Java/C#. A ce moment tu peux retourner une référence vers l'objet, pas besoin de const.
Sinon j'ai jamais dit que la POO c'était rapide hein. Mais si Folco veut bosser plus tard, c'est bon d'en avoir des notions (et malgré la réticence qu'il peut avoir, il verra que ça a vraiment des avantages appliqué à certains problèmes qu'il saura reconnaître ensuite ). Et c'est pour ça que pour un maximum d'efficacité je lui aurais conseillé 1) de ranger sa table de cycles du x86 et 2) un langage comme le Java avec lequel il se fera moins chier et qui lui permettront d'apprendre ces concepts plus rapidement pour retourner bidouiller comme il aime après

./249> Ok pour le TryGetValue. C'est joli, même si dans le principe la manière propre de faire serait:

if (dico.ContainsKey(key))
    // Utilisation de la clé
    Object o = dico.GetValue(key);
else
    // Elle n'existe pas
    throw new WTFException();

Donc là on parle purement de perfs, pas vraiment de bonne POO je trouve. C'est clair que dans tous les cas les ref ça accélère le code, mais il est moins compréhensible.

Ouopouté vous m'faites peur, l'assembleur c'était facile niveau concept à côté

aze (./235) :

void swap(int &a, int &b)

void swap(int &a, int &b)
{
    int &c = a;
    a = b;
    b = c;
}

Ce code est faux, c doit être une valeur, pas une référence, sinon ton swap ne marche pas.

Brunni (./237) :
Franchement plus je lis tes questions plus je me dis que tu devrais plutôt te mettre au Java pour commencer la POO pure.

Langage beaucoup moins flexible et plus contraignant.

Déjà en Java tu ne passes pas les paramètres par référence, mais toujours par valeur, ce qui te garantit l'absence d'effet de bord comme celui de ta fonction Fibonacci.

Sauf que…

Ensuite les objets sont toujours des références

… et que donc on peut en avoir plein, d'effets de bord. Il suffit d'ailleurs d'utiliser un int[] ou un Integer boxé pour passer un int par référence.

// En C++, objet implicitement partagé
Objet o;

et tu as tous les avantages: c'est une référence, mais si tu modifies l'objet, c'est comme si c'était une copie (la copie est créée à la modification), donc pas de méchants effets de bord. Et les données pointées sont détruites automatiquement au bon moment (quand le compteur de références atteint 0). Toute la logique est dans la classe. (Il faut évidemment coder la classe de la sorte, mais on peut utiliser par exemple QSharedData et QSharedDataPointer pour obtenir l'effet voulu sans coder toute la logique soi-même.)

Cf. http://doc.qt.nokia.com/4.6/implicit-sharing.html.

En C# les références se font avec le mot clé ref et on les utilise rarement, en Java elles n'existent pas. Donc c'est pour ça que ça ne sert à rien de trop chercher à les utiliser, car ça ne te sera pas vraiment utile pour la suite

Tu sous-entends qu'il compte passer à ces langages moins performants et moins flexibles plus tard, pourquoi?

Brunni (./250) :
C'est pour ça que dans les getters tu fais normalement toujours des .Clone()

Vive le partage implicit!

et finalement les objets utilisés comme des enregistrements sont immuables.

Et bonjour les Vector::append qui recopient tout le vecteur à chaque fois (et retournent une copie qu'il faut assigner explicitement).

C'est tellement plus pratique quand l'objet de données (ce que tu appelles "enregistrement", mais ça peut être un objet beaucoup plus intelligent qu'une structure et avoir des méthodes; pour Qt, un objet de données est tout ce qui n'est pas un QObject, c'est-à-dire tout ce qui ne produit ni ne consomme des évènements) se comporte comme une copie librement modifiable, mais n'est effectivement recopié que quand c'est vraiment nécessaire. Copy on write FTW!

Brunni ./252> c'est marrant je suis complètement en désaccord avec ce que tu racontes
ça doit être parce que j'ai toujours fait du c++ et jamais de java (à part en quelques séances en école, pour apprendre la POO, mais rien d'assez pousser pour aborder ces problématiques)
1) la classe A contient l'objet B dont des infos nous intéressent
pourquoi mettre les accesseurs aux infos de l'objet B dans A alors que tu peux les mettre dans B (là où ils devraient être, pas besoin de les dupliquer dans A) et retourner une référence const vers B ?
2) si ton type est immuable (const au sens c++), alors la seule référence que tu peux retourner vers ton objet est une référence const, puisque qu'une référence non-const impliquerait que tu puisses modifier l'objet

Mais bon, comme java ne supporte pas const, on ne tombera jamais d'accord car les habitudes doivent être complètement différentes

Folco> ben c'est clair, la réflexion ne se fait pas du tout au même niveau.
La semaine prochaine nous parlerons de template meta-programming (là, vous pouvez dire que la syntaxe du c++ est abominable)

Kevin> oops
je me doutais un peu que j'écrivais une connerie

Kevin> Je ne connais pas le partage implicite de Qt donc je ne pourrai pas faire de commentaire, désolé. Mais je vais me documenter.
A propos du vector je suis d'accord, et c'est toujours la merde de retourner ce type d'objets dans d'autres langages. Par contre conceptuellement ça marche bien avec les tableaux natifs.

Aze>
1) Parce que l'application qui utilise ta classe ne devrait pas avoir besoin de toutes les infos de l'objet, qui sont privées justement. Mais le souci c'est que tu exposes trop l'implémentation sous-jacente. Si tu devais changer ton code pour utiliser un autre type d'objet en interne (par exemple une table de hachage plutôt qu'un dictionnaire, ou un objet provenant d'une autre librairie dont les conventions de nommage changent légèrement), tu vas casser tous les programmes qui utilisent ta classe... et dans un bon prog objet c'est à éviter.
2) const objet& en C++ ça ressemble mais c'est différent d'un objet immuable, puisqu'en C++ tu peux avoir un objet conçu comme muable (qui peut évoluer) que tu "figes" avec le mot const, et du coup tu restreins son champ d'action.
Je suis mal placé pour aller à l'encontre, c'est un concept que j'aime bien et que j'utilise, sauf que ça implique beaucoup de choses lourdes pour le codeur. Les objets immuables, bien que moins performants dans certains cas, sont plus naturels d'un point de vue OO et n'ont pas besoin d'avoir 500 concepts associés: il suffit de déclarer "final class" pour avoir automatiquement toute la sécurité autour.

Tiens, quand vous parlez de vector, c'est pas un type défini par la librairie standard ?

J'ai l'impression d'apprendre à l'utiliser au maximum. Sur TI, je me foutais des fonctions de la lib standard parce que j'avais d'autres outils (AMS, kernel). Mais là, je compte pas tout recréer (sans blague ^^) et donc taper au maximum dans les standards. C'est un bon choix ?

#include <vector>
C'est dans la STL, donc la librairie standard C++. C'est assez génial à utiliser, tu verras ^^

Si vous le dites. Merci, j'ai plusieurs chapitres à lire à ce sujet.

ps -> STL == lib standard ? ce ne sont pas que des templates ? il doit forcément y avoir aussi macros et fonctions, non ?

la stl (Standard Template Library) ne sont que des templates, mais ce n'est qu'une partie de la std, la lib standard
mais à l'usage, les types définis dans la stl ne sont pas séparés du reste, tout est dans le namespace std

Brunni (./259) :
#include <vector>C'est dans la STL, donc la librairie standard C++. C'est assez génial à utiliser, tu verras ^^

Ça sux par rapport à QVector.

Je compte m'entrainer dans un premier temps avec des petits programmes en console, pour ne pas avoir à utiliser des APIs me forçant à faire de l'objet "malgré moi".
Ca, ça viendra quand j'y arriverai un minimum, donc j'utiliserai d'abord la lib std.

Tu peux utiliser Qt sans aucune interface graphique aussi, cf. libQtCore et QCoreApplication. Ça reste beaucoup plus agréable que cette horreur de la STL, surtout pour un débutant. (Les raisons: meilleure documentation, utilisation des templates seulement là où ça a un sens (conteneurs génériques), pas n'importe où (std::string étant en réalité std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bonne chance avec les messages d'erreur contenant ce genre d'horreurs en guise de types!), partage implicit (cf. mes messages plus haut dans ce topic), gestion des évènements (signaux et slots), des fonctionnalités auxquelles la STL ne propose aucun équivalent (il faut alors passer à la Boost qui est encore plus bordélique, qui pratique encore plus l'abus de templates et que je déconseille donc fortément aux débutants en C++; les APIs de Qt sont beaucoup plus simples).) Si les gens ont horreur du C++, c'est surtout la faute de la STL!

Bon ok je vais voir. J veux apprendre vite et bien, mais avant tout faire les choses dans l'ordre.

Moi je te conseille de voir aussi autre chose que Qt
Ça te permettra de mieux apprécier sa beauté ensuite #trikevin#

surtout de ne pas en être dépendant et d'être perdu si on l'utilise plus.

Pas khôn comme arguments

par exemple si tu es obligé d'utiliser gecko de Mozilla tu auras pas peur entre les nsIString nsICString nsIArray nsISupportsArray nsIMutableArray, etc (quelle daube)

Je pense aussi qu'il vaut mieux commencer par les API standard, avant de rentrer dans d'énormes librairies prêtes à l'emploi comme Qt
Ca permet de mieux distinguer les concepts, et +1 ./266 et ./267.