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

**rOut** · 24/12/2012, 19h30

J'ai rajouté des cout pour montrer un peu l'interieur de la bête.

---------- Post added at 19h26 ---------- Previous post was at 19h11 ----------

Envoyé par Tomaka17

Je crois que t'as pas encore compris qu'il y a maximum 2-3 % des programmeurs C++ dans le monde qui s'emmerdent avec du code pareil.

Ce code fait une centaine de lignes, plus une autre vingtaine de lignes à l'utilisation, il est super chiant à lire et à utiliser, le tout pour... générer un tableau !
À la place tu aurais pu écrire "pointeur* tableau[] = { element1, element2, element3, ... };"
Cay nul !

La métaprogrammation c'est des trucs de doctorant ou de développeur de librairie super compliquée. Ca ne te servira à rien dans un vrai boulot.
Par contre l'héritage, la polymorphie et tout ça, ça te servira.

C'est avant tout parce que la plupart des programmeurs C++ n'y comprennent rien que ça ne servira pas dans un vrai boulot. C'est pas non plus une fatalité, mais c'est surtout dommage parce qu'ils passent à coté de la plus grande puissance du langage.
Après c'est pas comme si Boost était batie à ~90% sur des techniques similaires... Tu trouveras aussi beaucoup de gens qui te diront "HAAA T4UTILISE BOOST §§§, han mais t'es fou, c'est immaintenable après, c'est de la merde Boost". C'est avant tout parce qu'ils n'ont pas l'habitude de la librairie, qu'ils prennent peur à la première erreur de compilation et qu'ils n'ont pas conscience de la puissance qu'elle peut leur apporter s'ils prenaient le temps de l'étudier un peu.
C'est le même genre de personnes qui vont te dire "Ha non, moi les smart pointer, j'utilise pas, parce que sinon je ne sais pas ou mes objets sont détruits". C'est partiellement vrai, et ce n'est pas parce que tu as des smart pointer que tu peux faire n'importe quoi, il faut rester rigoureux. Ces développeurs là se contentent de faire du C avec un peu d'OOP. Ce ne sont pas des développeurs C++ au final.

Pour avoir des chiffres plus honnêtes. Mon entête "générique" fait ~170 lignes, franchement je ne trouve pas ça démentiel, mais OK, c'est un overhead. Ensuite le cas d'utilisation réel se résume à ça, quel que soit le nombre d'enum ou de valeurs ajoutées et supportées :

Pour la déclaration de l'enum :

Code:

enum op_code
{
    DO_OPERATION_1 = 6,
    DO_OPERATION_2 = 12,
    DO_OPERATION_6 = 12,
    DO_OPERATION_BLA = 7,
    DO_OPERATION_UNBOUND = 8,
};

namespace enums
{
  // declaration of the enum values in an MPL vector
  template<> struct get_values< op_code > { typedef boost::mpl::vector_c< op_code, DO_OPERATION_1, DO_OPERATION_2, DO_OPERATION_BLA, DO_OPERATION_UNBOUND > type; };

  // declaration of the handlers signatures for our enum
  template<> struct get_signature< op_code > { typedef signature< void, std::string const&, std::string const& > type; };
}

C'est à dire ~5 lignes en plus de l'enum (grosso modo, hein). Sans parler que le tout peut être simplifié et écrit une seule fois via une simple macro C, un seul endroit ou maintenir la liste des enums.

Ensuite, le binding entre méthode et enum est très simple :

Code:

// declaration of the handlers and binding to the dispatcher
void do_opcode_1(std::string const& param1, std::string const& param2) { std::cout << "doing opcode 1" << std::endl; }
template<> enums::signature_of< op_code > const& enums::get_handler< op_code, DO_OPERATION_1 >::type::value = do_opcode_1;

C'est à dire, +1 ligne à rajouter après la déclaration de la fonction à binder, par enum et par valeur que l'on veut binder. Ce qui permet également de garder code-a-cote le binding et la fonction (avantage ou non suivant les gouts).

L'utilisation elle même peut se faire en une seule ligne, contrairement à mon exemple :

Code:

enums::dispatcher< op_code >()[DO_OPERATION_1]("foo", "bar");

A l'inverse, un code avec des switch à divers endroits, ou un tableau dont le contenu doit être maintenu en parallèle avec l'enum est à mon avis, à la fois plus chiant à maintenir, et aussi introduit plus d'overhead.

Les avantages que je vois, perso, c'est :
- Une seule liste de valeurs à maintenir, à la déclaration de l'enum. Pas de switch à maintenir, ou à recopier partout ou on veut l'utiliser.
- Pas besoin de créer le tableau d'accès inverse pour mapper l'enum à l'index du tableau de pointeur de fonction, ce qui permet d'avoir des enums qui ne commencent pas forcément à 0, et qui prennent n'importe quelle valeur.
- Si une valeur de l'enum est renommée, le binding problématique va générer une erreur de compilation, et il suffira de le corriger ou de l'enlever. Alors qu'avec un tableau de pointeurs accédé via la valeur entière de l'enum, un entier reste un entier.

---------- Post added at 19h30 ---------- Previous post was at 19h26 ----------

Mais bon, c'était avant tout pour la beauté du truc. J'aime surtout jouer avec la méta-programmation pour le coté artistique que ça a.

**Tomaka17** · 24/12/2012, 21h27

Méthode 1 :

Code:

enum op_code
{
    DO_OPERATION_1 = 6,
    DO_OPERATION_2 = 12,
    DO_OPERATION_6 = 12,
    DO_OPERATION_BLA = 7,
    DO_OPERATION_UNBOUND = 8,
};

namespace enums
{
  // declaration of the enum values in an MPL vector
  template<> struct get_values< op_code > { typedef boost::mpl::vector_c< op_code, DO_OPERATION_1, DO_OPERATION_2, DO_OPERATION_BLA, DO_OPERATION_UNBOUND > type; };

  // declaration of the handlers signatures for our enum
  template<> struct get_signature< op_code > { typedef signature< void, std::string const&, std::string const& > type; };
}

// declaration of the handlers and binding to the dispatcher
void do_opcode_1(std::string const& param1, std::string const& param2) { std::cout << "doing opcode 1" << std::endl; }
template<> enums::signature_of< op_code > const& enums::get_handler< op_code, DO_OPERATION_1 >::type::value = do_opcode_1;

void do_opcode_2(std::string const& param1, std::string const& param2) { std::cout << "doing opcode 2" << std::endl; }
template<> enums::signature_of< op_code > const& enums::get_handler< op_code, DO_OPERATION_2 >::type::value = do_opcode_2;

void do_opcode_bla(std::string const& param1, std::string const& param2) { std::cout << "doing opcode bla" << std::endl; }
template<> enums::signature_of< op_code > const& enums::get_handler< op_code, DO_OPERATION_BLA >::type::value = do_opcode_bla;

Méthode 2 :

Code:

std::unordered_map<op_code, void (*)(const std::string&, const std::string&)>
    tableau = {
       { DO_OPERATION_1, &do_opcode_1 },
       { DO_OPERATION_2, &do_opcode_2 },
       { DO_OPERATION_BLA, &do_opcode_bla }
    };

Donc d'après toi si les gens préfèrent la méthode 2 c'est parce qu'ils n'ont pas pris conscience de la puissance que pouvait leur apporter la métaprogrammation ?

Je troll un peu, mais 99.9 % des codes utilisant la métaprogrammation à outrance ont un équivalent infiniment plus simple et très légèrement plus lent.

Personnellement j'ai jamais utilisé boost.lambda bien que je connaissais son existance, tout simplement à cause de la syntaxe dégeulasse. Quand les lambdas sont arrivés en C++11 je les ai utilisés day1 sur la première version de gcc qui les supportait.
C'est pas une question de peur ou de méconnaissance, c'est juste que c'est mieux quand c'est plus simple et plus propre.

**rOut** · 25/12/2012, 02h29

Donc d'après toi si les gens préfèrent la méthode 2 c'est parce qu'ils n'ont pas pris conscience de la puissance que pouvait leur apporter la métaprogrammation ?

C'était d'une manière générale, pas sur ce cas particulier.

Je troll un peu, mais 99.9 % des codes utilisant la métaprogrammation à outrance ont un équivalent infiniment plus simple et très légèrement plus lent.

Remplacer un accès dans un tableau par une hashtable c'est quand même pas tout à fait du même calibre. Enfin en théorie...

Personnellement j'ai jamais utilisé boost.lambda bien que je connaissais son existance, tout simplement à cause de la syntaxe dégeulasse. Quand les lambdas sont arrivés en C++11 je les ai utilisés day1 sur la première version de gcc qui les supportait.
C'est pas une question de peur ou de méconnaissance, c'est juste que c'est mieux quand c'est plus simple et plus propre.

Tu remarqueras que je n'ai pas utilisé de syntaxe pourrie que l'on peut trouver dans certaines librairies boost, uniquement des templates. Les macros C j'évite aussi comme la peste, et les librairies comme Boost Parameter me donnent la nausée. Pour mon bout de code, comme je le disais, c'était avant tout pour le défi de faire ça avec des templates.

En plus, mon code gère les opcode inconnus, tandis qu'avec une hashtable faut faire un lookup pour rien, ou rajouter un if, ou se faire chier autrement.

**Tomaka17** · 25/12/2012, 07h08

Envoyé par rOut

Remplacer un accès dans un tableau par une hashtable c'est quand même pas tout à fait du même calibre. Enfin en théorie...

C'était pour montrer le truc. Tu peux très facilement coder une fonction avec cette initializer_list comme paramètre et qui remplit un vecteur.

De toutes manières aujourd'hui quand tu fais un switch c'est optimisé avec une dispatch table. Niveau vitesse c'est probablement lui qui gagne.

**Møgluglu** · 25/12/2012, 19h25

Envoyé par Tomaka17

La métaprogrammation c'est des trucs de doctorant ou de développeur de librairie super compliquée. Ca ne te servira à rien dans un vrai boulot.
Par contre l'héritage, la polymorphie et tout ça, ça te servira.

Non mais là vectra est juste en mode "c'est la crise y'a plus de sous y'a plus de poste c'est la fin du monde on va tous mourir ou pire finir en SSII", étape normale de la vie d'un thésard. Faut pas le prendre au pied de la lettre.

Je vois pas le problème d'aborder la métaprogrammation avant la POO. La métaprogrammation, c'est très utile lorsqu'on ne peut pas se permettre de générer du contrôle dynamique pour des raison de perf, de validation ou autres.
Par exemple, quand j'étais petit, CUDA ne supportait pas les fonctions virtuelles et les pointeurs de fonctions. Alors qu'avec un peu de métaprogrammation, on arrivait à générer à peu près le code machine qu'on voulait (bon, compter 10 lignes pleines de templates par instruction assembleur). Mais ça remplace avantageusement les macros C (voire les macro-assembleurs).

Et Noyeux Joël à tous.

**rOut** · 25/12/2012, 19h40

Tiens, question existentielle du jour :

Code:

void f(int const i)

vs

Code:

void f(int i)

?

**Tomaka17** · 25/12/2012, 19h59

Je pense que ça pourrait être pas mal si on pouvait écrire :

Code:

void f(int i);

void f(const int i) {
    ...
}

**rOut** · 25/12/2012, 20h02

Je crois que c'est possible, mais c'est quand même pas la solution la plus claire...

**Tomaka17** · 25/12/2012, 20h05

Ah ouai

révélation du jour

Ben le choix const-pasconst dépend de l'implémentation de ta fonction f. Du coup à toi de choisir.

**rOut** · 25/12/2012, 20h08

Bin c'est surtout que ça ne fait aucune différence vu de l'exterieur. Personellement je met const partout parce que je trouve que ça indique bien les input (tous les inputs sont const ou const&) tandis que les outputs sont les seuls à ne pas être marqués const (ils sont passés par reference).
Mais Herb dit que c'est "useless and at best misleading".

**deathdigger** · 26/12/2012, 11h14

Envoyé par vectra

Je vais tâcher de.

J'ai pas mal de lectures à faire avant de comprendre comment ca fonctionne, mais c'est précisément le but. Quand ma thèse sera finie, faudra bien que je me trouve un travail, et je me doute bien que ca va finir en analyste-programmeur. Donc, au boulot!

En attendant, merci encore, et surtout passez de bonnes fêtes :trucsdenoel:

T'inquiète pas, du boulot en dev, t'en trouveras à la pelle, par contre y'a de grandes chances que tu fasses autre chose que du C++

**war-p** · 26/12/2012, 12h44

De la bouche de mon patron (boîte d'éditeur de logiciel) "le c++, ça devient de plus en plus obsolète avec le java et le c#, par exemple..."

**rOut** · 26/12/2012, 12h56

lol.

---------- Post added at 12h56 ---------- Previous post was at 12h46 ----------

Tiens sinon pour rigoler.

**war-p** · 26/12/2012, 13h03

Hey, je dis pas que le c++ ne sert plus à rien, mais c'est vrai qu'à côté de la souplesse des langages plus récents...

**rOut** · 26/12/2012, 13h06

Ben tout dépend de ce que tu veux faire.

**Tomaka17** · 26/12/2012, 13h15

Personnellement, soit je code un truc dans un langage interprété, parce que c'est simple à écrire, c'est simple à débugger, c'est multiplateformes, etc.
Soit je code un truc qui doit être rapide et professionnel, et dans ce cas là c'est du C++.

Pour moi le C# et le Java combinent les défauts des langages interprétés (lenteur, on sait pas trop ce qu'il se passe) et les défauts des langages compilés (plus rigoureux à écrire et POO obligatoire).

**rOut** · 26/12/2012, 13h22

Python c'est le bien, et après je génère des templates C++ avec Cheetah. :meta-meta-programmation:

**vectra** · 26/12/2012, 13h27

Envoyé par deathdigger

T'inquiète pas, du boulot en dev, t'en trouveras à la pelle, par contre y'a de grandes chances que tu fasses autre chose que du C++

C'est bien ce qui me fait peur. J'aimerais vraiment pouvoir m'insérer chez quelqu'un qui fait du C++ dans l'embarqué ou le traitement de signal/image/vidéo et en particulier l'imagerie médicale. Mais pour ca, faut que j'aie déjà le niveau, et pas que je me pointe en disant "bonjour, je veux faire du C++ top moumoute mais en réalité j'en suis encore au message-passing lol".

J'ai encore un peu moins de 2 ans, je préfère m'y mettre de suite. Comme le dit très bien Mogluglu, j'en suis au point où je comprends que la recherche universitaire, c'est soit voué à disparaître dans toutes les petites et moyennes unités, soit bouché à 100% dans les autres. Et comme je ne veux pas faire prof de lycée, je serais déjà content de coder en évitant Java et C# que je connais à peine.

**deathdigger** · 26/12/2012, 14h09

Oui voilà, à moins de bosser dans des trucs hyper spécialisés (embarqué...), ça sera Java/C# et si t'es pas veinard Windev

Je vais parler du C# (et du .Net en général) vu que c'est ce que je connais de mieux :
Tu montes une appli très rapidement, la compatibilité avec Windows est assurée à 100%, tu peux filer la partie graphique à un graphiste (surtout pour le wpf), et le code est très facilement maintenable.
Et devine quoi, c'est exactement ce que cherche 99% des entreprises !

C'est un peu le même principe pour le web, y'a des technos 1000* plus poussées que le PHP ou le .net, mais le marché est à 99% sur ces 2 technos. Et pour l'intranet, t'as des millions de trucs open-source, mais tu auras 10 fois plus de boulots si tu maitrise SharePoint.

**Tomaka17** · 26/12/2012, 14h20

Dans la catégorie facepalm : PHP invente le générateur de nombre pseudo-aléatoire non-déterministe

Envoyé par http://php.net/manual/fr/function.mt-srand.php

5.2.1 L'implémentation Mersenne Twister en PHP utilise maintenant un nouvel algorithme d'initialisation, réalisé par Richard Wagner. Des initialisations identiques ne produisent plus la même séquence de valeurs, comme cela pouvait être le cas dans les versions antérieures. Ce comportement ne devrait plus changer.

**deathdigger** · 26/12/2012, 14h24

J'avais lu un truc (dans Misc je crois) qui disait que l'aléatoire réel en informatique n'existait pas.
La seule façon de faire un vrai hasard, c'est de passer par un truc extérieur, comme random.org qui utilise les parasites des ondes radio pour générer un chiffre au hasard.

**Charmide** · 26/12/2012, 14h36

Envoyé par Tomaka17

les défauts des langages compilés (plus rigoureux à écrire et POO obligatoire).

T'entends quoi par "plus rigoureux à écrire"? Et en quoi c'est un défaut? Ça peut même être une qualité, non?
Idem pour la POO, je vois pas en quoi c'est mal en soi?

**Tomaka17** · 26/12/2012, 14h56

Envoyé par deathdigger

J'avais lu un truc (dans Misc je crois) qui disait que l'aléatoire réel en informatique n'existait pas.
La seule façon de faire un vrai hasard, c'est de passer par un truc extérieur, comme random.org qui utilise les parasites des ondes radio pour générer un chiffre au hasard.

Justement, ce truc en PHP est trop aléatoire.
Les générateurs de nombres pseudo-aléatoires doivent être prévisibles. Celui-là ne l'est pas.

Envoyé par Charmide

T'entends quoi par "plus rigoureux à écrire"? Et en quoi c'est un défaut? Ça peut même être une qualité, non?
Idem pour la POO, je vois pas en quoi c'est mal en soi?

Ben si déjà un langage est interprété ou semi-compilé, avec du garbage collection, sans accès direct possible à la mémoire, etc., autant rajouter du typage faible et le rendre plus flexible.

**Møgluglu** · 26/12/2012, 15h04

Envoyé par deathdigger

J'avais lu un truc (dans Misc je crois) qui disait que l'aléatoire réel en informatique n'existait pas.
La seule façon de faire un vrai hasard, c'est de passer par un truc extérieur, comme random.org qui utilise les parasites des ondes radio pour générer un chiffre au hasard.

Les processeurs Intel depuis Sandy Bridge ont l'instruction RDRAND qui génère des nombres aléatoires à partir d'une source physique (bruit thermique). Les processeurs Via aussi, entre autres.

Tomaka : mais alors, comment faut faire pour avoir de l'aléatoire/pseudo-aléatoire imprévisible en PHP ?

**Tomaka17** · 26/12/2012, 15h10

Envoyé par Møgluglu

Tomaka : mais alors, comment faut faire pour avoir de l'aléatoire/pseudo-aléatoire imprévisible en PHP ?

Ben c'est tout simplement que les valeurs aléatoires ne dépendent pas de la seed avec mt_rand.

Dans n'importe quel langage, si tu écris :

Code:

srand(517);
for ($i = 0; $i < 1000; ++$i)
    echo rand();

Ce programme te sortira toujours les mêmes valeurs.
C'est pour ça qu'on met "time()" à l'intérieur de srand() en général, pour éviter d'avoir les mêmes valeurs.

Mais PHP a décidé que ce ne serait plus vrai, que même si tu donnais toujours la même seed, ben les valeurs seraient différentes.

Ca paraît con, mais par exemple dans minecraft tu peux donner une seed pour générer un monde. Si ensuite tu donnes la même seed à quelqu'un d'autre, ça va générer un monde identique. C'est tout simplement grâce au déterminisme de l'algo d'aléatoire.
Si minecraft était codé avec mt_srand et mt_rand, ça aurait pas été possible (ou alors il aurait dû écrire un algorithme d'aléatoire manuellement).

**Møgluglu** · 26/12/2012, 15h26

Oui, mais ma question, c'était : si je veux générer des clefs pour de la crypto, il y a une autre fonction PHP ? Ou dans l'autre sens, si tu veux juste du pseudo-aléatoire facile, pourquoi ne pas utiliser la fonction rand tout court ? Minecraft ne doit pas avoir besoin d'un Mersenne Twister non plus...
La bonne approche est d'avoir des fonctions différentes pour les différentes utilisations de l'aléatoire. Est-ce que par hasard c'est pas pour ça que PHP a à la fois une fonction rand et une fonction mt_rand ?

Initialiser le générateur avec srand(time), c'est particulièrement con si je puis me permettre. La valeur de l'horloge du serveur au moment où la page a été générée, c'est pas un truc trop difficile à deviner pour l'attaquant...

**Tomaka17** · 26/12/2012, 15h30

Ben justement :
- si tu veux générer un truc vraiment aléatoire, il faut utiliser openssl_random_pseudo_bytes
- et pour l'aléatoire à la cool t'as le choix entre mt_rand et rand, mais le second est quatre fois plus lent d'après la doc

mt_rand est tout simplement un remplacement plus rapide que rand. Le fait que ce soit une fonction différente c'est probablement pour la rétrocompatibilité.

Du coup l'objectif de mt_rand c'est justement pour les cas comme l'exemple de Minecraft.

**Møgluglu** · 26/12/2012, 15h38

Envoyé par Tomaka17

Ben justement :
- si tu veux générer un truc vraiment aléatoire, il faut utiliser openssl_random_pseudo_bytes

OK merci. Oui, du coup à quoi bon te demander un seed pour mt_srand si c'est pour initialiser le générateur avec des valeurs de l'extérieur...

**rOut** · 26/12/2012, 15h44

Si tu veux un truc reproductible et rapide, pas besoin de t'emmerder avec des vrais générateurs pseudo-aléatoires, utilises carrément un xorshift: https://en.wikipedia.org/wiki/Xorshift

Mersenne Twister c'est un peu la rolls royce du pseudo aléatoire, pour les gens pour qui l'aléatoire et la non-reproductibilité compte. Ca ne m'étonne pas trop qu'ils aient décidé de rendre la fonction rand non-reproductible. Ca comble sans doute un bon paquet de failles de sécurité chez les gens qui l'utilisaient avoir conscience que la seed était une faille.

Et pour ceux comme toi qui veulent juste un truc rapide et pseudo random, ce qui est sans doute plus rare, tu peux utiliser quelque chose de plus adapté.

---------- Post added at 15h44 ---------- Previous post was at 15h41 ----------

Envoyé par Tomaka17

Ben justement :
- si tu veux générer un truc vraiment aléatoire, il faut utiliser openssl_random_pseudo_bytes
- et pour l'aléatoire à la cool t'as le choix entre mt_rand et rand, mais le second est quatre fois plus lent d'après la doc

mt_rand est tout simplement un remplacement plus rapide que rand. Le fait que ce soit une fonction différente c'est probablement pour la rétrocompatibilité.

Du coup l'objectif de mt_rand c'est justement pour les cas comme l'exemple de Minecraft.

A mon avis niveau lenteur openssl_random_pseudo_bytes doit se poser bien comme il faut.

**trenks** · 26/12/2012, 19h07

J'ai installé MySQL pour bricoler des trucs avec Django, donc j'essaie de me connecter mais pas moyen, j'obtiens une erreur :

Code:

$ mysql -u root -p
Enter password: 
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

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

Outils de la discussion

Règles de messages