Le topic de la programmation, string, chaînes, cuir et compagnie

[deathdigger]

Je tiens tout de même à préciser, au cas où, que WinDev c'est quand même ultra franco-français comme truc.
En Belgique personne n'en entend parler (sauf quand tu parcours les forums français).

Ben notre ancien 'développeur' Windev m'a assuré le contraire, que la Belgique était à fond sur cette techno ( et aussi la Russie et la Chine) . Pour du prototypage, vu la simplicité du C# ou du VB.Net, je ne vois pas pourquoi ne pas utiliser ces langages. Pour l'Hyperfile, je trouve ça par contre pas trop mal foutu, c'est beaucoup moins contraignant que les bases access ou Compact SQL, et niveau perfs, pas sûr que ce soit plus lent que du SQLite.

[Tomaka17]

Et puis ça a l'avantage que t'as pas de risque de voir ta variable optimisée parce que tu l'as pas mise volatile.

Sinon j'ai trouvé aussi son talk très intéressant... en théorie. En pratique, j'ai aussi un peu peur mais pas vraiment pour des raisons de clarté (encore que l'abus de lambda donne mal à la tête). C'est plutôt que je me dis que tout ça c'est bien beau, tu fais tout en asynchrone... sauf qu'à un moment donné, il faut bien que le boulot soit exécuté tout de même. Et dans son monde, j'ai un peu l'impression que tu n'as plus aucun contrôle sur qu'est ce qui est executé et quand c'est executé. Tu vas vite avoir une tâche qui monopolise tous les workers (ou toutes les ressources) alors que d'autres sont en famine. J'ai un peu l'impression que ca va être un gigantesque bordel de task switch en arrière plan...

Aussi, en terme de life-time des objets, j'ai un peu de mal à voir comment il gère ça, à part en faisant des copies de partout, ce qui n'est pas forcément viable. Autrement, t'as vite fait d'avoir les objets sur lesquels la tâche doit s'executer devenir hors-scope. Typiquement le async cout, si tu loggues la valeur de variables locales... à part en les copiant dans le worker thread, ou d'attendre que le cout soit effecitvement fait... je ne vois pas comment ça peut être utilisable. La copie est peut être acceptable dans la plupart des cas, mais pas toujours je suppose...

Et puis on dirait un peu un truc event-based mais sans la clarté qui devrait aller avec. Les évènements et les tâches correspondantes sont mélangées au milieu du reste du code.

Je viens de regarder en entier et je suis également assez réservé.
En fait le problème c'est pas tellement de savoir quand ça va être exécuté. Si tu veux être sûr que ce soit exécuté immédiatement tu fais du blocking. Si tu veux être sûr que ce soit exécuté avant tel autre truc, tu fais future.wait().

Mais pour le lifetime des objets, je pense qu'à un moment donné t'es obligé d'utiliser du shared_ptr.

C'est sympa de dire "cette fonction renvoie un future et prend comme paramètre un objet Foo qui doit être détruit après le future", mais c'est juste super chiant à gérer.

Et le problème de shared_ptr, comme j'ai déjà dit, c'est que si tu commences à en mettre dans les interfaces, tu vas en mettre partout partout.
shared_ptr c'est un peu tout ou rien : soit tu l'utilises uniquement dans l'implémentation (recommendé), soit tu en mets dans toutes les interfaces. Et dans ce dernier cas tu tombes rapidement sur des problèmes, tu écris des wrapper pour les classes standard, tu mets des enable_shared_from_this partout, etc.

---------- Post added at 12h01 ---------- Previous post was at 11h37 ----------

Voilà une illustration ce que je veux dire :
https://gist.github.com/4492298

Soit on utilise shared_ptr, soit on met des conditions lourdingues du genre "le future doit être getté avant que tel objet soit détruit"

---------- Post added at 12h08 ---------- Previous post was at 12h01 ----------

En fait je pense que le plus simple est encore de ne jamais renvoyer de std::future.
La partie asynchrone se faisant uniquement à l'intérieur des implémentations, et de s'assurer du vérouillage et du lifetime des objets à l'intérieur de chaque implémentation.

[Tomaka17]

Tiens j'ai commencé à bosser là dessus hier : https://github.com/Tomaka17/mason

C'est un peu ambitieux mais la façon dont je conçois le truc me paraît faisable.

---------- Post added at 13h40 ---------- Previous post was at 13h28 ----------

Pour détailler, parce que j'ai pas tout mis dans le readme :

Mon programme agit comme un ./configure, tu l'invoques en faisant "mason configure ../code_source"
Il analyse le code source (il cherche un CMakeLists.txt ou un fichier "configure" par exemple) et génère alors un fichier "mason.lock" dans le répertoire en build, en s'aidant d'un éventuel mason.json qui serait présent dans le code source (mais optionnel).

Ce fichier "mason.lock" contient toutes les infos sur la façon de faire le configure normal, ainsi que l'emplacement des dépendances à télécharger sur le net.
Il essaye alors de télécharger toutes les dépendances. Si c'est du debian, il appelle aptitude par exemple.
En dernier recours, il télécharge le code source de la lib et réitère la même opération sur ce code source-là.

Enfin il invoque le programme de configuration normal.


Pour savoir où télécharger la lib, il cherche soit dans le fichier mason.json (tu peux y mettre une liste d'emplacements), soit avec aptitude, soit avec une base de données qui contient les libs les plus utilisées, mais je sais pas encore quelle forme aura cette base de données.

[rOut]

C'est intéressant et ambitieux. J'imaginais démarrer sur un truc similaire mais j'essaie de ne pas m'éparpiller dans douze mille projets.

Sous Debian OK, c'est facile les paquets sont déjà là, mais comment faire pour récupérer une version spécifique qui n'est pas celle packagée ?
Sous les autres OS, comment faire ? Recompiler depuis les sources mais comment comptes tu supporter les whatmille build system des différents projets ?

Je pensais qu'il serait intéressant de fournir des genres de paquets debian pour différents OS, avec un ensemble d'outils genre apt pour les installer. Je me disais qu'il faudrait tenter de porter dpkg/apt sur windows et/ou mac mais ça n'a pas l'air évident.

[Tomaka17]

Ben je suis pas fan du système de dpkg/aptitude.

Par exemple je voudrais bien pouvoir créer une petit lib C++ semi-confidentielle, la foutre quelque part sur le net, puis l'utiliser dans d'autres projets perso. Je vais pas submit un packet debian pour ça. Et même si ça valait le coup, faut attendre 6 mois qu'ils le valident.

Là ce serait possible : je rajoute simplement l'emplacement de la lib dans le fichier mason.json de mes autres projets, ou bien dans la base de données de mason.

[rOut]

T'es pas obligé d'avoir un paquet officiel. Tu peux te faire ton repo perso et y uploader tes paquets. Et ensuite l'enregistrer dans apt. Tu peux faire ça avec un soft comme reprepro pour gérer ton repo APT, et le rendre disponible sur un serveur web quelconque, ou bien même comme un repo github en mettant tes fichiers dans une branche gh-pages.

[Tomaka17]

Par contre, j'ai essayé d'utiliser boost.program_options

Je sais que ça peut me faciliter la vie pour certains trucs (par exemple parser les nombres), mais y a rien à faire c'est trop lourdingue à utiliser.

J'ai la sensation que tous les bons côtés de la lib vont être contrebalancés par cette lourdeur et cette "non-intuitivité".

[rOut]

Qu'est ce que tu trouves lourd ?

[Tomaka17]

Ben rien que leur syntaxe de départ.

options_machin x;
x()("option1", "description")("option2", "description")("option3", "description")

C'est typiquement boost ça : on te propose une syntaxe totalement à l'opposé des bonnes pratiques du langage, juste parce qu'elle est plus courte à écrire.
Au bout d'une heure d'utilisation dans un truc comme ça et t'es totalement perdu, tu sais plus quand mettre des templates, quand c'est un appel fonction, quand c'est une structure template.

Et puis pour mettre une valeur par défaut :

x()("option1", value<int>(&variable)->defaultvalue(10), "description");

Seriously?


Ce serait mille fois plus clair d'avoir un truc comme ça :

options_machin x;
x.add<std::string>("option1", "description");
x.add<int>("option2", "description", 10);    // 10 étant la valeur par défaut

De toutes façons je voudrais une syntaxe du genre "mason commande paramètres", et j'ai pas trouvé comment faire pour que les paramètres dépendent de la commande.
C'est sûrement possible, mais pas sans aspirine.

[rOut]

bpo::options_description general_options("General Options");
auto add_general_option = general_options.add_options();
add_general_option("version,v", "print version string")
add_general_option("help", "produce help message")
add_general_option("config,c", bpo::value<int>(&config_file)->default_value("config.cfg"), "configuration file");

Y'a pire hein niveau manque d'ergonomie. Dans ton exemple par exemple, on ne sait pas ce que signifie 10. Est-ce une valeur par défaut ? Un nombre maximum d'occurence ? Et comment indiques-tu qu'une option peut apparaitre plusieurs fois, ou prendre n valeurs, ou être juste un switch true/false mais ne prendre aucune valeur etc... Tout ça est supporté par bpo::value avec des fonctions à appeler dessus lors de la déclaration de l'option.

En plus, tu peux même lui fournir une lambda à appeler lorsque l'option est trouvée dans la ligne de commande, avec le nom de l'option et les valeurs trouvées, au lieu par exemple de remplir des variables locales, ça permet de remplir un arbre de config avec des valeurs provenant de la ligne de commande par exemple, surchargeant des valeurs récupérées auparavant d'un fichier de config.

Pour mason command paramètres, tu fais comme git. Ton programme mason est un simple proxy qui va appeler ensuite des binaires nommés mason-<command> et en leur repassant les paramètres, chaque binaire parsant différentes choses. Ou alors program_options te permet aussi de parser en ignorant les options inconnues. Tu fais un premier parsing avec juste tes commandes, et ensuite pour chaque commande tu fais des option_descriptions différentes et tu reparse la ligne de commande.

---------- Post added at 14h33 ---------- Previous post was at 14h25 ----------

Sinon au niveau de la config, perso je partirais sur du yaml, c'est bien plus joli à lire.

[Tomaka17]

GRAAAAAAAA

Génial, je viens encore de passer 30mn à essayer de comprendre pourquoi ma regex ne marchait pas.

Jusqu'à ce que je vois ça dans le header <regex> :

  // [7.11.3] Function template regex_search
  /**
   * Searches for a regular expression within a range.
   * @param __first [IN]  The start of the string to search.
   * @param __last  [IN]  One-past-the-end of the string to search.
   * @param __m     [OUT] The match results.
   * @param __re    [IN]  The regular expression to search for.
   * @param __flags [IN]  Search policy flags.
   * @retval true  A match was found within the string.
   * @retval false No match was found within the string, the content of %m is
   *               undefined.
   *
   * @throws an exception of type regex_error.
   *
   * @todo Implement this function.
   */
  template<typename _Bi_iter, typename _Allocator,
	   typename _Ch_type, typename _Rx_traits>
    inline bool
    regex_search(_Bi_iter __first, _Bi_iter __last,
		 match_results<_Bi_iter, _Allocator>& __m,
		 const basic_regex<_Ch_type, _Rx_traits>& __re,
		 regex_constants::match_flag_type __flags
		 = regex_constants::match_default)
    { return false; }

Ca les ferait chier de mettre "throw not_yet_implemented()" ou "assert(false)" ou un header guard bidon pour que la fonction ne soit pas définie.
Il faut qu'ils mettent un "return false" totalement silencieux.

Et le pire c'est que je me souviens qu'il y a 6 mois/1 an j'avais aussi passé des heures à débugger ma regex.

[Møgluglu]

Au moins, ils ont mis un commentaire et le résultat est manifestement faux. C'est pas comme le code qui vient tout juste d'être commité en 1997 dans la gnu libm.

[Tomaka17]

Bon, finalement j'avance relativement vite.

Pour l'instant quand j'appelle "mason configure", ça lit le fichier mason.json, ça convertit toutes les dépendances en URLs (pour l'instant j'ai juste hardcodé l'url de CURL), ça télécharge les paquets depuis le web, et ça appelle le logiciel de configuration natif qui a été détecté automatiquement.

La prochaine étape ce sera de décompresser le .tar.gz que je télécharge et d'appeller la configuration dans ce répertoire.

Après il me reste un petit problème, c'est de passer les include_path et les chemins vers les libs à cmake/configure/etc.

[Sahnvour]

Dites les guru ès C++ et compagnie, je me demandais si y'avait un moyen de mimer les decorator comme on les trouve en python, j'ai cherché un peu sur google mais pas trouvé grand chose.

A base de macro ou de templates doit y avoir des trucs faisables non ? Ça pourrait présenter un intérêt ?

[rOut]

Je ne sais pas trop ce que fait un décorateur en python, mais si c'est du code executé avant/après l'appel de fonction, ça rejoint la programmation par aspect. Je n'ai jamais joué avec, mais je suppose que http://www.aspectc.org/ se pose en référence.

[Tomaka17]

En C++11 un décorateur de fonction est assez facile à faire sans macro et sans template.

J'ai repris l'exemple de stackoverflow tout en haut quand google quand on tape "python decorator"

std::function<std::string ()>
  gras(std::function<std::string ()> base)
{
    return [=]() {
        return "<b>" + base() + "</b>"
    };
}


std::function<std::string ()>
  italique(std::function<std::string ()> base)
{
    return [=]() {
        return "<i>" + base() + "</i>"
    };
}


std::string
  get_text()
{
    return "bonjour";
}


auto fonctionTexteFormatte = gras(italique(get_text));
fonctionTexteFormatte();   // renvoie "<b><i>bonjour</i></b>"

// on peut aussi écrire :
gras(italique(get_text))();

// ou bien :
auto f = italique(get_text);
gras(f)();

Par contre pour l'intérêt, c'est plutôt moyen car on passe rarement des fonctions à d'autres fonctions.
En général en C++ quand tu appelles une fonction c'est toujours directement, t'as pas des fonctions qui renvoient des fonctions ou autres joyeusetées.

Du coup autant faire directement "<b><i>" + get_text() + "</i></b>" plutôt que de s'emmerder.

[Tomaka17]

terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::remove: LÆopÚration a rÚussi

Bon, après avoir passé 2 heures à télécharger manuellement toutes les dépendances (hin hin) j'ai enfin un libarchive qui marche.

By the way, pour une raison que je ne m'explique pas, quand je fais "exception.what()" il me sort toujours "std::exception", alors que normalement il est censé te filer un message d'erreur.
Du coup pour le moment je me fais pas chier à faire un joli message d'erreur et je throw juste, comme ça au moins c'est lisible.

[Nacodaco]

Bon, j'ai un truc tout bête, enfin je croyais, mais même ça j'y arrive pas

J'ai un tableau de pixel à une dimension, disons pour l'exemple de taille 6 (2x3).

Je veux agrandir mon image, et donc chaque pixel deviendra un carré de 9 pixels.
J'ai donc un nouveau tableau de taille 54 (6*9).

Seulement les indices des 9 pixels en question ne sont pas à la suite dans le tableau.

Donc normalement je trouve cette correspondance pour le premier pixel (je peux ensuite déduire les 8 autres de celui-ci :
1er tableau - 2nd tableau
0 -> 0
1 -> 3
2 -> 18
3 -> 21
4 -> 36
etc

Comment je retrouve la seconde valeur à partir de la première ?

C'est moi ou je fait n'importe quoi ?

[rOut]

1. Si ton tableau d'origine était de taille (w, h).
2. Que ton pixel d'origine était à (x, y), c'est à dire à l'indice i = y * w + x.
3. Que ton nouveau tableau est de taille (W, H), alors :
4. En prenant (X, Y) les nouvelles coordonnées de ton pixel, et I son indice :
X = x * W / w
Y = y * H / h
I = Y * W + X
I = y * H / h * W + x * W / w

D'où
I = ( i div w ) * H / h * W + ( i mod w ) * W / w

Dans ton cas :
- i = 0, x = i mod 2 = 0, y = i div 2 = 0 ⇒ I = 0
- i = 1, x = i mod 2 = 1, y = i div 2 = 0 ⇒ I = 0 + 1 * 6 / 2 = 3
- i = 2, x = i mod 2 = 0, y = i div 2 = 1 ⇒ I = 1 * 9 / 3 * 6 + 0 = 18
- i = 3, x = i mod 2 = 1, y = i div 2 = 1 ⇒ I = 1 * 9 / 3 * 6 + 1 * 6 / 2 = 21
...

[Tomaka17]

En général on calcule l'emplacement pixel source en fonction du pixel de destination (l'inverse de ce que tu as fait).

C'est plus facile à calculer et c'est plus utile.

[Nacodaco]

1. Si ton tableau d'origine était de taille (w, h).
2. Que ton pixel d'origine était à (x, y), c'est à dire à l'indice i = y * w + x.
3. Que ton nouveau tableau est de taille (W, H), alors :
4. En prenant (X, Y) les nouvelles coordonnées de ton pixel, et I son indice :
X = x * W / w
Y = y * H / h
I = Y * W + X
I = y * H / h * W + x * W / w

D'où
I = ( i div w ) * H / h * W + ( i mod w ) * W / w

Dans ton cas :
- i = 0, x = i mod 2 = 0, y = i div 2 = 0 ⇒ I = 0
- i = 1, x = i mod 2 = 1, y = i div 2 = 0 ⇒ I = 0 + 1 * 6 / 2 = 3
- i = 2, x = i mod 2 = 0, y = i div 2 = 1 ⇒ I = 1 * 9 / 3 * 6 + 0 = 18
- i = 3, x = i mod 2 = 1, y = i div 2 = 1 ⇒ I = 1 * 9 / 3 * 6 + 1 * 6 / 2 = 21
...

Merci

En général on calcule l'emplacement pixel source en fonction du pixel de destination (l'inverse de ce que tu as fait).

C'est plus facile à calculer et c'est plus utile.

Ça je le savais, mais je suis partit sur l'inverse à un moment où ça m'a paru logique (je dis pas que j'avais raison ^^).

En fait, le pixel devient un pixel de 3x3 puis ce carré est traité avec un autre masque de 3x3.
Si je partais de la destination, je dois retrouvé le pixel d'origine, et la position du pixel de destination dans le calque.
Si je partais de l'origine, j'avais le pixel haut-gauche et je parcourais simplement mon masque.

[vectra]

Pour ce genre d'opérations, il est aussi possible de passer par OpenCV ou autre bibliothèque (VTK), qui va gérer proprement l'interpolation par exemple.
C'est pas si simple à coder, mais c'est tellement classique à première vue que ca n'a pas grand intérêt de le refaire.

[deathdigger]

Je suis en train de me faire chier à mort en C# avec les threads :
J'utilise un FileSystemWatcher sur une appli en WPF pour vérifier si un fichier a été modifié, le cas échéant, je change ma vue.
Vu que ça plantait au début, j'ai pigé que c'était un problème d'accès au thread (sinon effectivement l'appli serait bloquée tout le temps).
Donc :
- J'ai crée un délégué, mais ça ne change rien
- Si je fais un Dispatcher.Invoke(new Action(() => Print_Infos())); ça marche la première fois mais pas la deuxième
- Même résultat avec _syncContext.Post(o => Print_Infos(), null); où _syncContext est un SynchronizationContext
Je pense que je dois clore mon invoke, mais je ne sais comment faire, quelqu'un pourrait m'aider là-dessus ?

EDIT : C'est une autre méthode qui foutait le bordel
Suffit que je poste ici pour comprendre ce qui se passe 2 secondes après ²

[Robix66]

Je suis en train de me faire chier à mort en C# avec les threads :
J'utilise un FileSystemWatcher sur une appli en WPF pour vérifier si un fichier a été modifié, le cas échéant, je change ma vue.
Vu que ça plantait au début, j'ai pigé que c'était un problème d'accès au thread (sinon effectivement l'appli serait bloquée tout le temps).
Donc :
- J'ai crée un délégué, mais ça ne change rien
- Si je fais un Dispatcher.Invoke(new Action(() => Print_Infos())); ça marche la première fois mais pas la deuxième
- Même résultat avec _syncContext.Post(o => Print_Infos(), null); où _syncContext est un SynchronizationContext
Je pense que je dois clore mon invoke, mais je ne sais comment faire, quelqu'un pourrait m'aider là-dessus ?

EDIT : C'est une autre méthode qui foutait le bordel
Suffit que je poste ici pour comprendre ce qui se passe 2 secondes après ²

Tiens, en parlant de ça, si quelqu'un a quelque chose d'intelligible pour la gestion du multi-tâches en C#, ça m’intéresse. Parce que j'ai toujours un mal fou à faire passer les infos entre les threads.

[deathdigger]

Le backgroundWorker marche plutôt bien

Sinon,
J'avais un deuxième problème, malgré un (using Filestream...), le fait de lire le fichier avec des threads différents, ça me mettait une erreur de fichier déjà ouvert.
J'ai foutu un try/catch sans sortir d'erreur, et là ça marche

[Robix66]

Le backgroundWorker marche plutôt bien

C'est ce que j'utilise, mais j'ai un peu de mal par moments (genre j'ai un gros WriteableBitmap que j'ai jamais réussi à faire passer, du coup je l'enregistre puis lève un évènement pour dire qu'il est dispo (bon, de toutes façons j'ai besoin de l'enregistrer, mais j'aurais bien voulu faire ça proprement)). J'ai eu beau essayer de le freezer ou quoi, pas moyen.

Sinon,
J'avais un deuxième problème, malgré un (using Filestream...), le fait de lire le fichier avec des threads différents, ça me mettait une erreur de fichier déjà ouvert.
J'ai foutu un try/catch sans sortir d'erreur, et là ça marche

Normalement, si tu l'ouvre plusieurs fois en readonly ça marche.

[deathdigger]

Oui mais non, là ça ne voulait pas (readonly + fileaccess share pourtant), tu bloques sur quoi au niveau du BgW ? Tu utililses bien le ReportChange ?

[war-p]

Le clé est très tatillon sur la gestion de la mémoire, il faut se dire que de manière générale, il ne faut ouvrir un fichier qu'une seule fois, sinon il pense directe qu'il y a accès concurrentiel et ça fout la merde ( tiens d'ailleurs j'avais fait un algo avec un méthode asynchrone qui gérait ça avec des conditions, faudra que je le retrouve.)

[Tomaka17]

:musique-apple:

- Bonjour, je suis un programme en C#
- Et moi un programme écrit dans un vrai langage de programmation
- Woaw, je vois que tu as beaucoup de ressources ouvertes
- Oui, j'ai 5 threads différents qui ont chacun ouvert le même fichier et qui l'utilisent comme un lock

[deathdigger]

Disons que le fait de le faire à l'arrache, j'ai l'impression que le thread n'indique pas qu'il a fini sa tâche (malgré l'utilisation de using Filestream fs... et d'un fs.dispose() à la fin). C'est pas trop grave puisque ça marche si on empêche l'exception de se lever, maintenant, va falloir que je vérifie si niveau consommation mémoire ça fout pas le bordel.
En sachant que mon truc lit un fichier texte à chaque modification (toutes les demi-secondes) et qu'il met à jour ma vue en direct.
C'est plutôt puissant, reste à voir si en jeu (c'est sur Evochron Mercenary) avec beaucoup de changement en même temps ça va pas foutre la merde.

Pareil, des méthodes il y'en a beaucoup :
- délégué
- Dispatcher.Invoke(new Action(() => Print_Infos()));
- _syncContext.Post(o => Print_Infos(), null); où _syncContext est un SynchronizationContext

Mais est-ce la meilleur ?
Perso je suis passé par Action (que je ne connaissais pas), parce que c'est clairement la moins chiante à écrire