Le topic de la programmation: Et envoyez des sioux!

**vectra** · 29/06/2018, 15h47

Bah non, c'est intéressant après tout.
Et c'est pas non plus comme si c'était le rush le reste du temps hein. Ca nous fait du traffic.

**FB74** · 02/07/2018, 20h17

VR & Programmation, série d'ebooks:
https://www.humblebundle.com/books/v...-reality-books

**vectra** · 04/07/2018, 16h19

Coincoin les coucous.

Petite question sur CMake: je vois bien comment importer un package cherché, et même à peu près comment générer les miens.
Par contre, j'aurais bien aimé savoir s'il y avait une variable qui me permettait de savoir dans quel répertoire se trouvent les bibliothèques .so effectivement linkées.

Code:

message("GDCM found")
message("includes: ${GDCM_INCLUDE_DIRS}")
message("libs: ${GDCM_LIBRARIES}")

Y'a ce qui faut pour les include, et effectivement ça marche bien, mais pour les libs, y'a que le nom des libs et pas leur repertoire

**FB74** · 04/07/2018, 17h03

Envoyé par vectra

Coincoin les couscous.

Boeuf ou légumes ?

**rOut** · 04/07/2018, 20h26

Envoyé par vectra

Coincoin les coucous.

Petite question sur CMake: je vois bien comment importer un package cherché, et même à peu près comment générer les miens.
Par contre, j'aurais bien aimé savoir s'il y avait une variable qui me permettait de savoir dans quel répertoire se trouvent les bibliothèques .so effectivement linkées.

Code:

message("GDCM found")
message("includes: ${GDCM_INCLUDE_DIRS}")
message("libs: ${GDCM_LIBRARIES}")

Y'a ce qui faut pour les include, et effectivement ça marche bien, mais pour les libs, y'a que le nom des libs et pas leur repertoire

<package>_INCLUDE_DIRS et <package>_LIBRARIES c'est la vieille manière de faire. Tout package qui se respecte se doit maintenant de déclarer des targets "IMPORTED", dont tu peux récupérer la propriété "IMPORTED_LOCATION" pour savoir de quel fichier il s'agit au juste (en plus des propriétés transitives pour donner automatiquement les bons include paths aux clients).

**FB74** · 04/07/2018, 22h49

**vectra** · 05/07/2018, 11h53

Merki rOut pour l'info, je pense qu'il va falloir que je m'achète le bouquin CMake de Kitware pour me refaire un peu, en espérant qu'il soit à jour des bonnes pratiques.

Sinon, dans la série "Vectra fait des conneries", aujourd'hui je martyrise le préprocesseur

Voici mon problème. J'ai mon code cripplé de saloperies du genre:

Code:

void myfun()
{
   vtkPolyDataMapper *cubeMapper = vtkPolyDataMapper::New();

// toujours indenté en c#0
#if (VTK_MAJOR_VERSION >= 6)
  cubeMapper->SetInputData( inData );
#else
  cubeMapper->SetInput( inData );
#endif

}

En gros, l'évolution de VTK entre la V5 et la V6 s'est faite dans la douleur, et y'a une série d'appels qui ont complètement changé.
Sous cette forme, c'est imbitable au possible, ça casse l'indentation, la lisibilité et ça m'exaspère au point que j'ai envie de dégager tout le code legacy, et je souhaite l'éviter.

Je veux arriver à:

Code:

void myfun()
{
   // indenté là où le code courant l'est 
   VTKLEGACY(  cubeMapper->SetInputData( inData ), 
               cubeMapper->SetInput( inData )      );
}

, et donc avec l'appel de macro indenté correctement.
Alors j'y suis arrivé, mais faut voir le brodel. Je vous montre, en espérant que vous me suggériez moins pire:

vtkmacros.h:

Code:

#include <boost/preprocessor/control/if.hpp>

#ifndef VTK_MAJOR_VERSION
MSG_ASSERT(false, "VTK version must be declared, eg. by CMake");
#else
#if (VTK_MAJOR_VERSION >= 6 )
#define VTK_MODERN 1
#else
#define VTK_MODERN 0
#endif 
#endif

#define VTKLEGACY( _MODERN, _ANCIENT ) \
  BOOST_PP_IF( VTK_MODERN , \
	       _MODERN,	    \
	       _ANCIENT );  \

Je masterise pas trop tellement le BOOST_PP, mais en gros, il n'aime pas true, false, ni des conditions genre (VTK_MAJOR_VERSION >= 6)
Mais sinon voilà, ça a l'air de passer comme ça. Notez bien que la clause "ancient" ne peut simplement pas compiler sur les versions récentes de VTK, et réciproquement: il s'agit d'expander uniquement une partie de code ou une autre selon une valeur connue à la compilation (en l'occurence, définie par CMake).

**Cwningen** · 05/07/2018, 12h19

Code:

#ifndef VTK_MAJOR_VERSION
MSG_ASSERT(false, "VTK version must be declared, eg. by CMake");
#else
#  if (VTK_MAJOR_VERSION >= 6 )
#    define VTKLEGACY( _MODERN, _ANCIENT ) _MODERN
#  else
#    define VTKLEGACY( _MODERN, _ANCIENT ) _ANCIENT 
#  endif 
#endif

Ça suffit, ou j'ai loupé une subtilité ?

**vectra** · 05/07/2018, 14h53

Si si, c'est limpide en plus!

En fait, j'ai cherché désespérément tout coder directement dans la macro VTKLEGACY, avant de me rendre compte qu'on peut pas expander une macro avec des directives #if..., ces dernières devant nécéssairement être en colonne 0.
J'en suis venu à extraire des trucs de VTKLEGACY avant qu'on en arrive à ta solution, qui va jusqu'au bout de la logique.

Ca laisse de côté la macro BOOST (dommage, j'aurais bien voulu en apprendre d'avantage là-dessus) mais il n'y a plus de définition qui traine et ça illustre bien que le préprocesseur effectue autant de passes que nécessaire, ce dont j'avais douté au début.

**Tramb** · 07/07/2018, 05h13

Par contre t'as pas besoin du préprocesseur dans chacun de tes clients.
Crée juste une fonction inline setMapperInputData(vtkPolyDataMapper*, data) et fous le #if *dedans*. Hop, tu as encapsulé la saleté à un seul endroit et gardé une sémantique d'appel de fonction.

**vectra** · 10/07/2018, 16h25

Ah, en fait, le problème est que *toutes* les classes ont certaines de leurs méthodes légèrement modifiées (très souvent, le même groupe de méthode pour toutes les classes).
C'est pourquoi, dans les codes-exemple de VTK, tu as un système de directive de compilation qui va utiliser l'ancienne ou la nouvelle syntaxe. C'est généralement pas énorme comme différence, mais voilà quoi.
Je ne pense pas pouvoir me permettre de créer une fonction à chaque fois que je dois appeler une des méthodes modifiée, c'est pourquoi je me contentais juste de travestir les directives...

**Raplonu** · 10/07/2018, 16h40

Vu au taf aujourd'hui :

Code:

std::map<float, Data*> ma_map;

**Patate** · 10/07/2018, 17h12

Touches pas c'est la sienne !

**vectra** · 10/07/2018, 17h46

Oui voilà, et puis c'est bien nommé: comme ça, tout le monde sait à qui elle est, cette map...

**vectra** · 11/07/2018, 18h51

Yop les gens,

J'aimerais beaucoup avoir un client stand-alone assez propre pour dépatouiller les commits et les branches de chez git.
Quand je ramène des dépôts de gros projets, c'est pas facile à suivre sur la console, et c'est à la rigueur mieux mais pas forcément top avec Bitbucket (j'arrive à voir les branches, mais pas facilement leurs noms), qui d'ailleurs n'est pas le genre de stand-alone que je recherche.

On m'a parlé de sourceTree et de gitKraken. Le second ne m'a pas beaucoup plu quand je l'avais essayé, et donc j'aimerais me tourner vers le premier.
Or, ce petit bâtard n'existe pas en version Linux

Je voulais savoir si vous aviez eu l'occasion de le faire tourner en émulation avec wine ou autre.
Apparemment, il faut installer plusieurs runtimes avant de pouvoir le lancer sous windows, ce qui veut dire que je ne sais pas faire un truc comme ça sous Wine sans utiliser Crossover (qui est payant).
Si vous avez des conseils ou remarques, n'hésitez pas!

**gros_bidule** · 11/07/2018, 19h21

GitKraken : au bureau, tous les collègues qui l'ont utilisé ont un jour ou l'autre eu des problèmes avec (lors d'un rebase interactif par exemple). Mon gros reproche à ce logiciel, c'est qu'il ne se base pas sur l'exécutale git standard, mais il fait sa propre tambouille. Sinon il est très beau, mais vala...

SourceTree : très bien fichu, fonctionnel et stable, mais trop lent à mon goût. Ca s'est peut être arrangé avec le temps, à voir.

Toutefois, je te conseille vivement SmartGit (https://www.syntevo.com/smartgit/). C'est une appli Java, compatible Windows Linux MacOS. Autant (sinon davantage) de fonctionnalités que SourceTree, stable, bien fichu, c'est ma GUI Git depuis plusieurs années et toujours pas déçu.
Je l'utilise pour m'y retrouver dans les branches et commits, et faire les squash (j'aime pas le faire à la main, et SmartGit permet de sélectionner les commits, Ctrl + J, et hop ça fait un squash). Et il a un thème dark qui n'est pas trop mal.
Pour tout le reste : IntelliJ !

**Orhin** · 11/07/2018, 20h12

SmartGit est cool en effet, mais pour 99% de l'usage quotidien la GUI intégrée des IDE Jetbrains me suffit perso.

**Nattefrost** · 11/07/2018, 20h42

Perso si j'ai besoin de GUI j'utilise gitcola, c'est compatible windows (avec de la motivation) linux et mac, ça fait visualisation, merge visuel de conflits, l'interface est customisable et ça reste super léger.
Autrement, soit 80% du temps, la CLI pour les actions simples.

**Tramb** · 11/07/2018, 22h13

Envoyé par vectra

Je ne pense pas pouvoir me permettre de créer une fonction à chaque fois que je dois appeler une des méthodes modifiée, c'est pourquoi je me contentais juste de travestir les directives...

Niveau perf ou niveau temps de dev ?
Dans les deux cas, tu as intérêt à utiliser des fonctions, potentiellement inline, tu ne perdras pas ta type-safety, ton IDE et ton debugger seront plus contents, et tu ne perdras pas un iota de perf.

**vectra** · 12/07/2018, 10h07

C'est surtout qu'on peut en écrire des centaines, entre le nombre de classes d'où la méthode est appellée et le nombre de classes qui peuvent servir d'arguments.

Sinon: BMDJ: J'ai retrouvé le plugin Bitbucket qui était utilisé à mon ancien boulot. Il s'agit de:
https://marketplace.atlassian.com/ap...r&tab=overview

Et il vient tout juste de voir une version free sortir

Cette qualitance de karma

**Tramb** · 12/07/2018, 12h03

Envoyé par vectra

C'est surtout qu'on peut en écrire des centaines, entre le nombre de classes d'où la méthode est appellée et le nombre de classes qui peuvent servir d'arguments.

Bon faudrait voir le code.
Déjà au niveau des appelants c'est la même quantité de macros ou de fonctions, donc t'élimines les ifdef.
Après pour la variabilité, j'imagine qu'il y a du polymorphisme à exploiter.

**vectra** · 12/07/2018, 14h28

Ben, il s'agit du code de VTK, donc déjà, toutes les méthodes SetInput de chaque classe sont affectées. C'est qu'une partie du problème, parce que bien d'autres méthodes sont concernées, et là, la variabilité du code va bien au-delà.
Je ne comprends pas très bien (*) ce que tu suggères, donc si ça se trouve, c'est bien. Mais si les gens de Kitware ont utilisé des directives de compilation pour leur propre code, c'est peut-être qu'ils n'avaient rien de mieux sous la main.

(*): c'est ça? :

inline void
vtk_troubleshoot_vectra::LinkEntries(vtkPolyDataMa pper *A, typeEntréeAcceptéPar_vtkPolyDataMapper *B)
{
#if (VTK_MAJOR_VERSION >= 6)
A->SetInputData( B );
#else
A->SetInput( B );
#endif
}

using namespace vtk_troubleshoot_vectra;

void myfun()
{
vtkPolyDataMapper *cubeMapper = vtkPolyDataMapper::New();
LinkEntries(cubeMapper, inData);
}

Et c'est la surcharge qui permet de faire cohabiter autant de fonctions LinkEntries que nécessaire, qui n'ont pas besoin d'être membre de quoi que ce soit.

**Tramb** · 12/07/2018, 14h53

C'est exactement ça !

**vectra** · 12/07/2018, 14h59

C'est vrai que c'est beaucoup, beaucoup mieux comme ça, au moins pour cette méthode.
J'avais oublié qu'il n'y avait qu'une paire de types possible par méthode SetInput(Data).

**Tramb** · 12/07/2018, 15h02

En gros si ça te baisse le nombre de #if, ça vaut le coup. Si tu dois le faire une fois pour économiser un #if, non.
Et tu peux peut-être générer des variantes en template si tu vois des généralisations, mais moi je le ferais pas, je préfère cherry-picker les overloads.

**vectra** · 12/07/2018, 17h12

Il y a un cours Udemy relativement complet sur le moteur Unreal Engine, pour 19 euroboules:

https://www.udemy.com/unrealcourse/

Bon plan ou dépense inutile?
A noter que ça m'intéresse d'être capable de faire des trucs sur le moteur, sans forcément trop masteriser un vrai workflow de JV.

**vectra** · 13/07/2018, 17h13

Je l'ai pris: pour 20 euros, je risque pas grand-chose.
Par contre, pour ceux et ceusses potentiellement intéressés, la "promo" finit dans quelques jours (200 € au prix nominal).

**yanad** · 16/07/2018, 09h19

Vectra je crois que tu utilises emacs non ? Dans ce cas Magit ne te vas pas ?

**vectra** · 16/07/2018, 10h06

J'ai pas réussi à bien le configurer, je crois.
Je crois surtout que j'ai besoin de quelque chose de plus graphique pour comprendre avec les mains comment ça fonctionne, git.
J'ai déjà beaucoup progressé depuis le début de quand je m'y suis mis, mais y'a vraiment beaucoup de chemin à faire, encore.

**vectra** · 16/07/2018, 16h46

Tiens, à propos d'emacs, je viens tout juste d'arriver à faire fonctionner correctement la completion de code

C'est pas tout à fait simple à mettre en place en fait: ça utilise clang et CMake, et j'avais notamment pas compris pour CMake qu'il fallait lancer cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON à la main dans chaque racine de projet

Le paquet emacs irony permet de lancer la base de la base du mode de completion, et je m'étais un peu trop perdu dans les très nombreux enrobages d'irony (e.g company-irony) qui ont été conçus pour faciliter l'usage d'irony et qui a priori fonctionnent bien... quand irony fonctionne.

Bon, au moins, ça roule maintenant

J'admets être à moitié teubé, mais question doc et tutos, c'est plus centré sur les enrobages que sur le fonctionnement de base. Les infos qui me manquaient n'étaient simplement pas dans le projet GitHub...

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages