Discussion :

[niconol]

Bonjour,

je travaille sur une appli qui inclut une ihm sous gtkmm3.
Je me suis inspiré d'un exemple simple (tout est contenu dans une fonction main qui affiche une simple fenêtre avec bouton exit)
Je veux éclater en plusieurs fonctions, voire plusieurs fichier ce qui concernait le contenu de cette fonction.

Dans cette fonction main() était déclaré refBuilder de la sorte:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto refBuilder = Gtk::Builder::create();

ce que je comprends de cela est que refBuilder est déclaré "autotypé" en fonction du retour de la fonction create(), et en même temps définit par la valeur de ce retour.
cela est-il exact?

Seule la fonction main() utilisais refBuilder (seule fonction du projet dans l'exemple)

Comment élargir la portée de refBuilder à d'autres fonctions du même cpp? à d'autres fonctions d'un autre cpp?
Pour des variables déclarées avec leur type connu, je m'en sort, car je les déclare hors des fonctions, et si il faut, en "externe" dans un .h
mais je ne vois pas comment déclarer une variable en auto hors d'une fonction (et pour l'instant je ne trouve pas le type retourné par la fonction create).

[niconol]

Bon j'ai aussi d'autres façons d'organiser mon code, mais peut-être que j'auri moins de souplesse au fur et à mesure qu'il s'étoffera,

et puis la question reste intéressante non?

[bacelar]

Je ne sais pas ce que vous entendez par "autotypé".
Concrètement, "auto" demande juste au compilateur de calculer à la compilation le type à droite de l'affectation et de faire en sorte que la variable ait le même type.
Ce n'est pas du typage dynamique mais de l'inférence de type.
Cela permet de plus facilement modifier le code, les signature en particulier, sans avoir à tout reprendre. Et aussi de ne pas utiliser explicitement les types avec des noms à coucher dehors que nous donne la STL, par exemple.

Mais quand on définit et on implémente une fonction, le type de la valeur de retour et les types des paramètres sont maitrisés.
Si la fonction marche avec n'importe quel type, ou avec plusieurs types, généralement, on passe par des fonctions Template qui ne demande pas à avoir la valeur explicite des types paramètres, l'inférence de type faisant aussi son travail.

EDIT :

Pour des variables déclarées avec leur type connu, je m'en sort, car je les déclare hors des fonctions, et si il faut, en "externe" dans un .h

Ça, c'est caca, c'est des variables globales, et c'est pas bien.
Forcez-vous à passer tout ce qu'utilise une fonction libre par ces paramètres.
Si c'est un méthode/fonction d'instance, l'utilisation des champs d'un objet permet d'y stocker un contexte.

[niconol]

par auto j'entends dont le type est automatiquement affecté après évaluation. Visiblement là dessus je ne me trompe pas, même si je n'utilise par forcément le bon langage ...

Je réduis au maximum (mon maximum, à ma portée) l'utilisation des variables globales, mais suis limité pour trouver, systématiquement, une alternative efficace, pas encore plus "caca", et que je comprends.

J'ai beau lire la multitudes de réflexions à ce sujet, et comprendre les problèmes de partages de variables (du moins suffisamment pour comprendre que ce n'est pas une bonne méthode que les définir globales), j'ai du mal à saisir les mécanismes pour y remédier, les explications ne sont pas tj faciles à suivre pour un non-expert, et pas tj accompagné de bons exemples pédago non plus.

J'essaie d'apprendre, alors si vous savez m'orienter vers un document fait pas des "experts", pour les novices, et donc accessible et accompagné d'exemples, je suis très très très preneur.

MERCI

[dalfab]

par auto j'entends dont le type est automatiquement affecté après évaluation. Visiblement là dessus je ne me trompe pas, même si je n'utilise par forcément le bon langage ...

Justement non. Aucun type n'est choisi après évaluation en C++.
Le C++ est un langage à typage strict tous les types sont définis au moment de la compilation. bacelar à clairement indiqué le rôle du mot auto dans ton cas; c'est celui retourné par la fonction et qui est complètement défini indépendamment de ce qui se passera quand le code s'exécutera.

[niconol]

c'est très frustrant, de vouloir dire la même chose mais de ne pas se comprendre.
J'ai bien lu et compris que c'est le compilo qui détermine le type.

Alors je ne dis pas évaluation, je dis déduction, détermination, .... calcul comme le dis bacelar?

Bon, en tout cas, merci pour ces précisions et cette leçon de vocabulaire.

[bacelar]

Bon, en tout cas, merci pour ces précisions et cette leçon de vocabulaire.

Tu peux nous prendre pour des relou avec ce "détail" mais ce n'est pas un détail.
C'est la différence FONDAMENTALE entre un langage fortement typé comme le C++ avec les langages à typage dynamique.
En C++, le "calcul" du type se fait sur les types, au moment de la compilation, et que sur les types, tandis que dans les langages type JavaScript, le "type" de la variable est déterminé au moment de l'évaluation au Runtime et sera fonction des valeurs passées.
C'est une manière totalement différente de "penser" (on parle de paradigme). Les mot-clés du langage sont imprégnés par cette manière de penser.

Le "var" du Javascript n'a rien à voir avec l'"auto" du C++.
Si c'est clair pour toi, c'est OK.

Les variables globales, c'est une très mauvaise solution à tout un tas de problème.
Chaque problème dispose d'une ou de plusieurs solutions correctes.
Il est donc impossible de dire simple "remplace les variables globales par X ou par Y", car le problème n'est pas les variables globales mais la chose qui a été "solutionné" avec ces cochonneries.
Il faut analyser "finement" le problème qui t'as conduit à utiliser une variable globale pour avoir une bonne solution au vrai problème initial.

Comment élargir la portée de refBuilder à d'autres fonctions du même cpp? à d'autres fonctions d'un autre cpp?

Pourquoi ne pas passer cette variable en paramètre de ces fonctions ?

(et pour l'instant je ne trouve pas le type retourné par la fonction create

RTFM
https://developer.gnome.org/gtkmm/st...4c2c16458403ce
Comme vous pouvez le voir, c'est un nom du type est à coucher dehors.
Après, il faut relativiser le machin. C'est un Design Pattern assez connu, "Builder", et la manière de l'utiliser est spécifique à ce Design Pattern.