[F] [mOved] Mon langage est mieux que le tien - Page 145

En pratique c’est pas terrible, surtout que les objets sont censés pouvoir être construits sur la pile aussi. Il me semblait même que pour un précédent standard ce n’était pas défini comme comportement, et au moins un compilo (MSVC?) se chiait dessus si tu faisais ça (car il pouvait générer du code qui accède à this après l’appel à ta méthode, dans le cas d’appels virtuels jesaisplustropquoi).

C’est pourquoi que tu veux faire ça ?

J'en ai pas besoin, la question était purement réthorique ^^

    QString source       = ui->ComboSource->currentText();
    QGridLayout* glayout = static_cast<QGridLayout*>(ui->BoxDestinations->layout());
    int column           = 0;
    int row              = 0;

    for (int i = 0; i < this->destcount; i++, column++) {
        QBoxLayout* blayout = static_cast<QBoxLayout*>(glayout->itemAtPosition(row, column));
        QString dest        = static_cast<QLabel*>(blayout->itemAt(1)->widget())->text();
        if (source == dest) {
            QCheckBox* checkbox = static_cast<QCheckBox*>(blayout->itemAt(0)->widget());

Ce qui est lamentable, quand on écrit des horreurs, c'est que ça marche quand même. Il serait normal que le programme s'auto-kill, ou que ça brique le PC.
Bon, ne vous inquiétez pas, je vais revoir un peu mes structures de données, sinon je n'en dormirai pas de la nuit.

---

Question bonus, dans la déclaration d'un constructeur je veux faire ça : truc::truc() : a(new A), b(new B(a))C'est garanti que a soit alloué avant b ? J'ai besoin de a pour construire b...

Folco (./4322) :
Ce qui est lamentable, quand on écrit des horreurs, c'est que ça marche quand même. Il serait normal que le programme s'auto-kill, ou que ça brique le PC.
Bon, ne vous inquiétez pas, je vais revoir un peu mes structures de données, sinon je n'en dormirai pas de la nuit.

C'est un peu le principe du C et du C++. Ces langage ne sont pas du tout prévu pour empêcher les erreurs.
Si tu veux des langage qui empechent de faire des conneries, il faut regarder du coté du Rust ou de l'Ada.

1 JavaScript
2 Python
2 Java
4 PHP
5 C#
6 C++
7 Ruby
7 CSS
9 TypeScript
9 C
11 Swift
12 Objective-C
13 Scala
13 R
15 Go
15 Shell
17 PowerShell
18 Perl
19 Kotlin
20 Haskell

Flan va être content

(heureusement, tout commence à #0 en informatique, et le 68k s'adjuge cette place d'autorité )

()

Lua disagree

Zerosquare (./4324) :
Flan va être content

Brunni encore plus

Les threads, ça a l'air d'être la solution magique à plus d'un problème.
Sur le papier.
Parce qu'en fait, ça vient avec son lot d'emmerdements que j'avais pas forcément prévu au design et en lisant de la doc

Ça c'est des trucs qu'on apprend bien en école d'ingénieur (clés : mutex, sémaphore, barrières, …). Ada est un bon langage pour découvrir les joies des threads.

Faut des cours pour appendre à utiliser ça ?? oO

Il ne "faut" jamais, mais en tous cas c'était bien cool et pratique ^^

En fait, j’ai jamais vu de cours d’info, faudrait que j’essaye d’en lire pour voir ce que ça m’apporte.
Si un volontaire veut bien dépoussiérer et scanner ses archives, merci d’avance

Folco (./4329) :
Les threads, ça a l'air d'être la solution magique à plus d'un problème.
Sur le papier.
Parce qu'en fait, ça vient avec son lot d'emmerdements que j'avais pas forcément prévu au design et en lisant de la doc

C'est là où le Rust est aussi intéressant (et emmerdant), car il ne te laisse pas faire ce que tu veux avec les thread.

En gros, a la compilation il s'assure qu'une donnée ne peut être accédée que par le thread qui l'a créé, si on veut la transmettre à un autre on perd son accès. Ça elimine le gros des problèmes de multithreading mais t'oblige à bien penser a ce que tu fais de tes variables.

Folco: te faut des mutex pour synchroniser les accès.

Bizarement, vous metez le doigt là où ça chie, étonnant hein

En clair, J'ai une classe C, qui a un membre M.
C possède aussi un membre T, un thread.
T doit travailler sur M.

MAIS !!!

Donner un pointeur de M à T (même pour des accès read-only), c'est la ruine de l'encapsulation.
Donc on peut vouloir passer par des méthodes publiques de C. Ca fait exposer à C des méthodes qu'on a pas forcément envie de voir publiques.

Et quid d'un Mutex X ? A part en faire une variable globale, que les deux flux d'exécution vont s'approprier comme il se doit, je ne vois pas trop comment faire.
Je n'utilise jamais de variables globales, du coup j'ai l'impression que c'est pas du tout la bonne approche.


Les exemples que j'ai trouvé sont très théoriques, évidemment que faire clignoter un pixel ça me poserait pas de problème. Mais quand il s'agit de partager des données de façon safe, c'est plus pareil ^^

Tu ne partage pas des pointeurs entre thread si tu cherche a faire du "thread safe". C'est le meilleur moyen d'exploser en vol si tu n'as aucun moyen de forcer des synchronisation.

Si tu dois vraiment partager de cette maniere, tu partage une structure avec deux éléments:

Un mutex, et ton pointeur, et ton code ne fait pas access au pointer sans chercher a prendre le mutex.

Sinon il y a plus simple que les mutex si ce sont des operations simples:

Les operation atomique. Le C11 propose meme des types et fonction juste pour ca:

https://en.cppreference.com/w/c/atomic

Les mutex n'ont rien de compliqué, c'est pas le problème. Je reformule la question :
"Comment une classe peut-elle déléguer à un thread qu'elle possède une partie de ses données sans violer l'encapsulation ?"

Tu peux pas avec un objet global qui encapsule trop de choses.

Dans ce cas je mettrais les trucs utilisés répétitivement par le thread dans un objet séparé, genre une Task ou WorkItem, et en plus tu peux balancer ces objets entre threads avec des FIFO/queues.

Ok j'y réfléchis, merci !

Édit -> Bon t’as raison, un objet intermédiaire muni d’un mutex, dans un singleton pour éviter un passage d’adresse entre flux d’exécution principal et worker thread, et ca devrait le faire

Tiens, je viens de lire cette définition dans Qt:

Calling this function multiple times on the same mutex from the same thread is allowed if this mutex is a recursive mutex. If this mutex is a non-recursive mutex, this function will dead-lock when the mutex is locked recursively.

Donc un deadlock, c'est quand un même thread essaye d'obtenir un mutex qu'il a lui-même locké. Evidemment c'est pas malin de s'auto-attendre.
Mais comment peut-on arriver à ça ? C'est pas possible de tester l'état de "lockacité" d'un mutex ? Ou de dire "bon ben je peux pas locker, je fais autre chose".
Pourquoi faut-il des fonctions du type try_lock() cf (https://doc.qt.io/qt-5/qmutex.html#try_lock ) ? Pourquoi ça n'a pas été inventé depuis toujours pour que les deadlocks n'existent pas ?

Ça n'est qu'une des variantes possibles de deadlock (et probablement la plus simple). Un cas plus réaliste, c'est deux threads (A et B) et deux mutexes (1 et 2), chacun des threads ayant besoin de verrouiller les deux mutexes pour pouvoir travailler. Si A verrouille 1 et que B verrouille 2, alors A attend que B libère le mutex 2, mais B attend que A libère le mutex 1, donc tu as un deadlock aussi.

Quand à l'existence des mutexes non récursifs, c'est tout simplement parce que le mutex "de base" n'inclut pas la notion de propriétaire, juste d'état (verrouillé ou pas), ce qui correspond directement à une instruction atomique du CPU (par exemple TAS pour le 68000). Les mutexes récursifs sont plus compliqués à implémenter.

Ok merci

---

prout,

J'ai une question en C++ :
Quand je fais A truc(A::méthodeStatique());, ça utilise un constructeur de recopie. La copie est ici inutile.
Quand je fais A truc = A::méthodeStatique();, ça utilise un constructeur d'affectation. Affectation inutile, car je n'ai pas besoin d'avoir deux instances de l'objet quelque part en mémoire au même moment.

Y a-t-il une façon de faire qui évite ces lourdeurs ?

Merci bien !

Avec un move constructor ? https://en.cppreference.com/w/cpp/language/move_constructor

Yay, j'avais vu ça passé, mais je m'était jamais penché dessus. C'est bien ce que je veux.
J'ai toujours été étonné que le compilateur ne sache pas mettre ça en place tout seul comme un grand.
Il doit y avoir un mécanisme qui m'échappe pour que le langage doive prévoir quelque chose d'explicite...

Merci !

normalement les constructeurs de déplacement sont autogénérés pour les types triviaux de mémoire, à revoir les règles exactes. Perso, j'écris toujours mes constructeurs de déplacement et de copie.

---

Folco (./4322) :
Question bonus, dans la déclaration d'un constructeur je veux faire ça : truc::truc() : a(new A), b(new B(a))C'est garanti que a soit alloué avant b ? J'ai besoin de a pour construire b...

Je sais pas si on t'a répondu, alors voici: l'ordre d'appel des instructions de ta liste d'initialisation est dépendant de l'ordre de déclaration des membres.

https://godbolt.org/z/DNNVg6

Clang remonte correctement l'info par défaut. la solution ici, c'est de ne pas stocker des pointeurs dans ta classe parente: références ou flat type (`public : a a;`)
ou alors tu fais comme 90% des engins de jeux, tu fais une méthode postinit et tu t'assures de l'appeler comme il faut avec ce qu'il faut

Ok merci !

sinon, t'utilises pas l'initializer-list, mais c'est un peu reculer pour mieux sauter ^^

https://thedailywtf.com/articles/accidental-toast-of-the-town
Mignon ^^