striiiiiiiiiiiiiiing - Page 12

J'en sais rien justement, j'ai juste lu ça dans une remarque de mon bouquin, va surtout pas me demander pourquoi (et tout comme toi, ya aucune différence qui ne m'ait sauté aux yeux )

GC -> Pas une raison, c'est crade Tu sais jamais si ça merdera pas ici ou là en cas de recompilation ^^

ça doit être qu'au début, le compilateur ne se faisaient même pas chier à appeler par défaut les constructeurs de copie des membres, même s'ils en possédaient

tu trouves ça crade, l'optimisation des valeurs de retour ? c'est pourtant fait par tous les compilateurs
Et sinon c'est le pb du c++, le code que tu écris correspond rarement avec le code executé

./330> Pour les types primitifs ça ne change rien, mais si tu as un 'string' ou un 'vector' que tu utilises comme une valeur, la copie memberwise appellera le constructeur par copie. La copie bitwise fera de la merde et ça va planter plus tard

oui, je sais bien ça ^^
c'est juste que je ne pensais pas qu'au débit ils faisaient une copie bit à bit bourine même sans se soucier des éventuels constructeurs de copies des sous-membres
(e qui était quand même vachement crade )

aze (./332) :
tu trouves ça crade, l'optimisation des valeurs de retour ? c'est pourtant fait par tous les compilateurs

non, l'optimisation en soi est très bien, c'est évident. Mais le fait de renvoyer un pointeur ou une référence sur un objet visiblement détruit dans le code (fin de fonction), oui, je trouve ça très crade.

Mais peut-être que tu sais parfaitement ce que tu fais, et que tu veux utiliser cette fonctionnalité pour accéder de manière détournée aux valeurs sur la pile !

+1 bon point mauvaise foi

./335> ah pardon
ouais, c'est totalement incorrect ^^

Brunni (./316) :
Je vois pas pourquoi ce serait interdit?

Déréférencer NULL est du comportement non défini, même si c'est pour le stocker dans une référence.

Je viens de tester et mon compilo l'accepte en tous cas.

Il n'est pas obligé de donner une erreur parce que c'est du comportement non défini. En revanche, il a le droit de compiler le code en absolument ce qu'il veut, s'il a envie de compiler ton code en system("sudo rm -rf /");, c'est son droit, ce serait parfaitement conforme au standard.


Et sinon, pour l'histoire des copies, la meilleure manière d'éviter les recopies inutiles est le partage implicit (QSharedDataPointer).

Tant qu'à faire du reference counting autant apprendre un paradigme propre: celui du Java. Justement le problème dont parle Folco n'existe pas en Java, où il est tout à fait normal de renvoyer un objet déclaré localement puisque les données sont en fait dans l'espace managé et détruites non pas à la fin de la fonction contrairement au stack, mais quand plus personne ne les référence.

(et sinon pour ton sudo rm -rf / ok. Heureusement que tous les compilateurs ne font pas ce genre de choses quand on utilise un truc non spécifié, parce qu'il n'y aurait pas beaucoup de code qui marcherait même dans un langage comme Ada où on essaie de spécifier le maximum).

Oui mais le problème ne se pose pas en java étant donné que t'as pas de gestion de mémoire. t'as qu'à serrer les fesses très très fort en espérant que l'algo de libération soit bien foutu. Et bye le real time en java au passage

[Et merde j'ai édité au lieu de reposter bon bah tant pis c'était pas important de toute façon]

Il existe des implémentations de Java destinées au temps réel.

Ah ok.

Mais ça ne doit pas être implémenté de la manière dont l'a décrit Brunni auparavant

Folco> Mais je parlais surtout du paradigme, pas tant de ce que tu en feras. A l'école on voit des langages useless dans la pratique mais ça n'empêche que les solutions qu'ils offrent à divers problèmes sont intéressantes, et c'est nécessaire de savoir les émuler dans ton langage favori (enfin, ça te fait économiser beaucoup de temps).

Par exemple tu peux faire de l'objet en ASM mais ça n'a pas souvent de l'intérêt car c'est très très compliqué et tu préféreras écrire des solutions en procédural (normal). Si tu prends un langage pensé pour l'objet alors tu vas voir les bénéfices que ça apporte (ça va t'ouvrir sur tout un tas de problèmes que tu n'aurais même pas imaginés solubles auparavant), et ensuite tu pourras les adapter à ton langage favori.

Là c'est pareil, le QSharedDataPointer est une implémentation de ce que propose C#, en plus contraignant (donc moins intéressant par rapport à se faire chier avec des mélanges byval/byref). C'est pas le meilleur moyen d'apprendre ça ^^

Sasume (./343) :
Il existe des implémentations de Java destinées au temps réel.

...qu'aucun développeur embarqué digne de ce nom n'utilise

(je kiffe grave adonfe ton nouvel avatar )

Brunni (./345) :
Par exemple tu peux faire de l'objet en ASM mais ça n'a pas souvent de l'intérêt car c'est très très compliqué et tu préféreras écrire des solutions en procédural (normal). Si tu prends un langage pensé pour l'objet alors tu vas voir les bénéfices que ça apporte (ça va t'ouvrir sur tout un tas de problèmes que tu n'aurais même pas imaginés solubles auparavant), et ensuite tu pourras les adapter à ton langage favori.

Je me rends compte qu'on peut faire parfaitement de l'objet en asm, ce n'est qu'une question de discipline personnelle (tant qu'on ne fournit pas de lib, de module objet etc... à un tiers). L'avantage d'un langage conçu pour, c'est la concision, la clarté qui en découle, et la productivité.

Brunni (./345) :
Là c'est pareil, le QSharedDataPointer est une implémentation de ce que propose C#, en plus contraignant

C'est moins contraignant, parce que tu n'es pas obligé d'utiliser ce modèle, tu as aussi d'autres modèles:[ul][li]partage explicit (QExplicitlySharedDataPointer) – d'ailleurs c'est ça que le Java, le C# et le VB implémentent, pas le partage implicit! Il n'y a pas de copy-on-write en Java, .NET ni en VB classique![/li][li]classe non copiable, toujours référencée par pointeur (Q_DISABLE_COPY, c'est utilisé pour les QObject, notamment)[/li][li]classe/structure sur la pile, passée par valeur, pratique pour les classes suffisamment petites pour que la copie soit plus efficace que le partage implicit (par exemple QPair)[/li][/ul]

En effet j'avais mal lu. Le copy-on-write du QSharedDataPointer peut être puissant et j'ai jamais vu ça ailleurs, je l'admets.

Oui, ça évite les bogues vraiment "space" qu'on peut avoir avec le partage explicit, où on détruit accidentellement un objet qui appartient à quelqu'un d'autre parce qu'on a oublié le clone() et on ne s'en rend même pas compte parce que la syntaxe fait croire qu'il s'agisse d'une copie.

Ben c'est comme si en C tu fais:

char *str1 = "Hello", *str2 = str1;
str2[1] = 'u';
printf("%s", str1);    // Hullo

C'est un piège lié aux références en soi.

en java y'a que des références et c'est très bien documenté/connu/etc

si tu veux faire des copies t'implémentes Cloneable ou tu fais un constructeur de copie.

En Java, c'est particulier car ce qu'on appelle référence correspond a un pointeur en C++.
Il n'y a pas de référence au sens C++.

Les références de Java ne sont pas constantes, c'est ça ?

Plus ou moins. Java à fait un choix radical pour se dispenser de la plupart des complexités du C++ : tous les objets ne peuvent être manipulés que par pointeur(mais en java on parle de référence).

ethode();

Le code :MaClasse monObjet = new MaClasse();
monObjet.maM

bjet->maMethode();

équivaut en C++ à:MaClasse *monObjet = new MaClasse();
monO

On dit que monObjet est une référence a un objet de type MaClasse.
Mais ce qu'on appelle référence en java est en fait un pointeur qui peut être null ou modifiée(sauf si elle est déclarée final)

sauf que c'est un "pointeur logique", non ? nulle part, il n'est dit que ça doit correspondre à un pointeur au niveau de l'implémentation, et la VM peut très bien organiser ça comme elle veut, tant que ça répond aux specs, si je ne m'abuse)

Ok.

(je croyais que final était pour les classes non dérivables)

Aussi.

Nil (./356) :
sauf que c'est un "pointeur logique", non ? nulle part, il n'est dit que ça doit correspondre à un pointeur au niveau de l'implémentation, et la VM peut très bien organiser ça comme elle veut, tant que ça répond aux specs, si je ne m'abuse)

En effet la JVM est libre de gérer ca comme elle le veux.
Je parlais de pointeur car le fonctionnement est identique, mais en effet ca ne contient forcément pas une adresse mémoire, c'est encore une notion dont Java c'est débarrassé.

Folco (./357) :
(je croyais que final était pour les classes non dérivables)

final a 2 sens :
- non modifiable quand il est appliqué aux variables.
- non dérivable quand il est appliqué aux classe ou aux méthodes.

Mais attention quand on déclare une référence final, ca veux dire qu'on ne peut la modifier, mais on peut toujours modifier les attributs de l'objet, il n'y a pas d'équivalent aux méthodes const. Encore une simplification : c'est moins puissant que le const mais réduit également la complexité du concept.

Nil : les références java, perso je vois ça comme des HANDLE de nos TIs ^^