Forum Linux.debian/ubuntu Une calculatrice multibases écrit en C avec GTK+3.

• # HTTP 403

  Posté par Slauncha (site web personnel) le 17 décembre 2014 à 08:15. Évalué à 3.

  

  Les liens retournent à l'heure actuelle une erreur HTTP 403.

• # précision des flottants

  Posté par freem le 17 décembre 2014 à 16:20. Évalué à 8.

  

  Si vous doutez de l'exactitude des calcules j'avoue que le plus gros problèmes a été les chiffres a virgules et la précision d'affichage car un:

  1.0002 + 2

  peut facilement se transformer en:

  3.00019999999999

  suivant la précision choisis dans un appel a sprintf().

  C'est normal, de ne pas avoir de résultats précis quand tu utilises des nombres flottants.
  C'est un sujet que je ne maîtrise personnellement pas, donc je vais éviter de risquer de dire des conneries: wikipedia sera plus instructif que moi.
  Toujours est-il que si tu veux manipuler des nombres à virgule en C, tu es probablement mieux à te trouver ou te faire une lib de manipulation de nombres qui ne se base pas sur float et double.

  Pour ce qui est d'avoir un avis sur ton code, voici le mien, que je vais diviser en 2 parties: objective (défauts du code), subjectifs (conventions, habitudes, etc):

  Objectivement, ton code:

  • est en franglais. Soit tu codes en français, soit tu codes en anglais, mais évites les mélanges, ça ne fait qu'ajouter à la confusion.
  • est monolithique. J'ai l'impression que toute la logique se situe uniquement dans le fichier contenant la fonction main. Tu devrais séparer ton code en unités logiques.
  • se répète trop. J'ai l'impression que tu répètes les mêmes blocs de code pour chaque instantiation de structure (ou est-ce un tableau?) de type, par exemple, "Operation": operande_1, operande_2, result.
  • tes fonctions ne sont pas assez spécialisées. Elles manipulent des données provenant de nombreuses sources, généralement des variables globales.
  • abuse des variables globales. Ces variables sont à éviter: elles rendent le code très difficile à maintenir, car on ne sait jamais quelle fonction à, ou non, des effets de bord et où s'arrêtent ces effets de bord.
  • ne vérifie pas que les appels aux fonctions se sont bien passés, alors qu'il utilise ensuite des structures allouées de cette manière. Attention aux crashs!
  • n'est pas documenté.

  Pour corriger ces problèmes, en gros, il te faut fracturer ton code.
  Pour chaque structure, tu dois implémenter un jeu de fonctions qui seront les seules à manipuler la structure. Ça peut sembler contraignant, mais c'est la seule façon de garder ton code maintenable.
  Ces fonctions ne doivent faire qu'une et une seule chose. Soit elles libèrent des ressources (mémoire, accès fichier, contrôle graphique, je sais pas), soit elles les allouent, soit elles manipulent les membres de la structure. J'ai pour standard personnel de ne jamais dépasser les 50 lignes par fonction. Quand je les dépasse, je réfléchis: ais-je mis un commentaire pour expliquer un bout de code (qui devrais donc être dans une fonction séparée, probablement)? Est-ce que je manipule des données de plus d'une structure au sein de la même fonction? Ais-je des pattern de code qui se ressemblent? Si je peux répondre oui à l'une de ces questions, alors c'est que ma fonction est mauvaise et je la refond. Si je répond oui à toutes, alors je vire directement le code et je recommence. Je n'ai pas peur d'avoir des fonctions qui ne contiennent que 3 lignes.

  Côté subjectif:

  • pas de versionning? Tu devrais t'y mettre, ça fait gagner un temps fou… à condition de garder à l'esprit de faire des commit minimaux et très fréquemment.
  • des majuscules dans les noms de fichier/dossier. Ça peut poser des problèmes, parce que tous les systèmes de fichier ne sont pas sensibles à la case.
  • aucune instruction pour compiler, un script d'install qui utilise sudo, aucune liste de dépendances. On ne peux pas tester sans devoir lutter pour comprendre ce que tu utilises? Désolé, j'ai la flemme. Si les Makefiles te soulent, ce que je comprend, il reste quand même de nombreuses alternatives: cmake, scons, et plein d'autres.
  • d'habitude, on utilise src pour Source, entres autres.
  • tu as une image au milieu de ton code source.

  Je pense avoir fait un tour rapide. Ce n'est pas exhaustif, mais travaille déjà sur les points objectifs.

  • [^] # Re: précision des flottants

    Posté par _kaos_ le 18 décembre 2014 à 01:52. Évalué à 1.

    

    Hello,

    C'est normal, de ne pas avoir de résultats précis quand tu utilises des nombres flottants.

    En fait non, mais c'est fait exprès. Et wikipédia n'aidera pas trop pour cela rapidement. Ici le résultat n'est pas imprécis, il est juste faussement affiché.

    Je n'ai pas spécialement la RFC exacte à jour sous la main, mais en gros : dans certains langages (mais pas tous !), les nombres flottants ont quelques bits de plus dans leur représentation interne. Et ils jouent beaucoup avec, dans les opérations mêmes les plus élémentaires.

    C'est lié à des travaux sur les itérations de calcul, pour apporter plus de précision et moins d'erreurs. Ce n'est pas sensé être présenté à l'utilisateur final.

    Une simple addition peut alors les exposer, si on ne fait pas attention. Notre cas ici.

    Matricule 23415

    • [^] # Re: précision des flottants

      Posté par freem le 18 décembre 2014 à 02:17. Évalué à 2.

      

      Ma foi…

      Je te crois sur parole, mais, aurais-tu à tout hasard un document qui présente de façon compréhensible à non mathématicien comment sont gérés les nombres à virgule flottante?
      Parce que personnellement, je les comprend si peu que je préfère ne pas les utiliser, ils me semblent encore plus dangereux qu'un pointeur non initialisé, pour dire!

      À noter: je suis également un auto-didacte. Je manque sûrement de nombre de savoirs.

      • [^] # Re: précision des flottants

        Posté par _kaos_ le 18 décembre 2014 à 07:03. Évalué à 2.

        

        Hello,

        Ma mémoire doit être légèrement incorrecte quant à l'explication précédente proposée.

        En tout cas, des choses sur la représentation des flottants peuvent se trouver par exemple ici.

        Matricule 23415

      • [^] # Re: précision des flottants

        Posté par Linuxator (site web personnel) le 19 décembre 2014 à 07:43. Évalué à 1.

        

        Il faut savoir que:

        type float précision 6 maximale codé sur 4 bytes.
        type double précision 15 maximale codé sur 8 bytes.
        type long double précision 19 maximale codé sur 10 bytes.

        Je pense que le l'inexactitude vient du codage interne des float, double, long double sous forme de:
        mantisse, exposant, signe.

        Si tu te demande ce qu'est une mantisse, un exposant: utilise le formateur %e.
        Par exemple: 1.234568e+08
        mantisse: 1.234568
        exposant: 08
        signe: +

        Le nombre de bits attribuer a la mantisse et a l'exposant dépendent du type et un bit pour le signe (d'ailleurs je crois que le 10 ième byte du long double ne sert que a stocker le signe).
        L'ordinateur ne peut pas stocker les valeurs exactes selon ce système de codage, mais des valeurs très proches.

        La FPU (Floating-Point Unit) qui sert (servait) a stocker les nombre a virgule est composé de 8 registre de de 80 bits (10 bytes) sur un ordinateur 32 bits.

        Mais actuellement ont joue avec des registres XMM (128 bits) ou YMM (256 bits) sur les machines 64 bits.

        Ont peut stocker plusieurs nombres a virgules a la fois dans un registre:

        -) 4 floats (simple précision.) XMM.
        -) 2 double (double précision.) XMM.

        Et effectuer des opérations simultanément sur plusieurs nombres (Simple Instruction Multiple Data) dans ces registres, en assembleur.

        En espérant ne pas trop avoir dit de bêtises.

        • [^] # Re: précision des flottants

          Posté par freem le 19 décembre 2014 à 12:12. Évalué à 2.

          

          Je pense que le l'inexactitude vient du codage interne des float, double, long double sous forme de:
          mantisse, exposant, signe.

          C'est ce que j'avais à l'esprit quand j'ai fait mon 1er post ici, mais je n'ai pas osé le formuler parce que je n'ai pas mis mon nez dans ces choses depuis plusieurs années, et que je n'utilise que très très peu les flottants à cause de ce genre de problèmes (genre le fait qu'un == ne soit pas fiable, c'est bloquant pour moi) et aussi pour le fait que je n'ai quasiment aucun usage des flottants au quotidien.

  • [^] # Re: précision des flottants

    Posté par Linuxator (site web personnel) le 19 décembre 2014 à 07:29. Évalué à -2.

    

    Merci pour ces critiques,
    une réponse rapide par citations:

    Objectivement, ton code:

    est en franglais. Soit tu codes en français, soit tu codes en anglais, mais évites les mélanges, ça ne fait qu'ajouter à la confusion.

    Je ne comprend pas j'ai coder exclusivement en anglais, ou est-ce mon anglais qui est franglais (c.a.d que je traduit du français littéralement en anglais ce qui ne donne pas un anglais correct) ?

    est monolithique. J'ai l'impression que toute la logique se situe uniquement dans le fichier contenant la fonction main. Tu devrais séparer ton code en unités logiques.

    La fonction main n'appelle pratiquement que la fonction de génération de la GUI et c'est dans les callback de celle-ci que j'appelle les fonctions du programme. Qu'appelle tu unité logique ?

    se répète trop. J'ai l'impression que tu répètes les mêmes blocs de code pour chaque instantiation de structure (ou est-ce un tableau?) de type, par exemple, "Operation": operande_1, operande_2, result.

    C'est normale il y a une structure Operande qui contient les membres dont a besoin une opérande:

    -) Une valeur booléen indiquant si l'opérande est un nombre a virgule ou un entier.
    -) La valeur en décimale (soit en de type long double soit de type long long en fonction que l'opérande est un entier ou un chiffre a virgule.)
    -) La valeur représenter sous forme de string en base 2, 8 et 16 (un membre par base).
    -) Un uint8_t représentant la base qui a été utiliser pour en coder l'opérande.
    -) Un string contenant le string de la valeur qui a été utiliser pour coder l'opérande.

    Cela me permet de pas faire de dégénération lors des conversion entre base avec des appels a des fonctions de conversions de base successifs.

    Après la structure Operation contient entre autre 3 membres de type struct Operande:
    -) Une pour la première opérande.
    -) Une pour la seconde opérande.
    -) Une pour le résultat.
    Et la structure Operation est remis a zéro après chaque opération et n'est instancier qu'au démarrage du programme statiquement.
    Et il existe une fonction pour chaque manipulation de ses membres:
    -) Remise a zéro.
    -) Filling d'une opérande.
    etc…
    C'est la structure principale du programme, GUI hormis.

    tes fonctions ne sont pas assez spécialisées. Elles manipulent des données provenant de nombreuses sources, généralement des variables globales.

    J'en prend bien note. Je pense que mon organisation est trop bordélique pour voir la logique des fonctions et donc leurs spécialisations.

    abuse des variables globales. Ces variables sont à éviter: elles rendent le code très difficile à maintenir, car on ne sait jamais quelle fonction à, ou non, des effets de bord et où s'arrêtent ces effets de bord.

    Je sais qu'il faut éviter les variables globales, j'en ai utiliser le moins possible (c.a.d encore beaucoup trop).

    n'est pas documenté.

    Entièrement d'accord je voulais en finir a la fin et j'ai oublier de faire des sessions de commentaires du code pendant le développement, comme je fait d'habitude, ce qui fait que le code n'est pas très documenter.

    Je ne contredit en rien ce qui été dit mais bon la vision de celui qui code et de celui qui relit n'est jamais la même. J'admets même que ce n'est pas du code C propre, trop noyer par GTK+3.

    PS: Est a cause de l'erreur d'orthographe du mot opérande en anglais que tu dit que mon code est du franglais…???
    Je ne comprend toujours pas cette critique.

    Merci d'avoir pris le temps de lire mon code, c'est vraiment gentil d'avoir fait l'effort je t'en remercie encore une fois.

    • [^] # Re: précision des flottants

      Posté par freem le 19 décembre 2014 à 12:47. Évalué à 3.

      

      Sommaire

      • • • conseils si tu veux refacto

      Je ne comprend pas j'ai coder exclusivement en anglais, ou est-ce mon anglais qui est franglais (c.a.d que je traduit du français littéralement en anglais ce qui ne donne pas un anglais correct) ?

      J'ai l'impression que tes noms (variables, fonctions) mélangent les 2 langues allègrement, même au sein d'un même nom. Peut-être que le problème viens de fautes, après tout beaucoup de mots anglais sont en fait issus du vieux français.

      La fonction main n'appelle pratiquement que la fonction de génération de la GUI et c'est dans les callback de celle-ci que j'appelle les fonctions du programme. Qu'appelle tu unité logique ?

      J'appelle unité logique des blocs de code type:

      struct foo { bla bla };
      
      foo* alloc_foo( bla bla );
      void do_something_with_foo_only( foo* bar );

      La définition est floue je te l'accorde, mais en gros, j'essaie de séparer de manière claire les portions de code qui manipulent les structures.

      J'en prend bien note. Je pense que mon organisation est trop bordélique pour voir la logique des fonctions et donc leurs spécialisations.

      J'ai appris à organiser mon code grâce au C++, je ne te le cache pas: en C++, on à généralement 2 fichiers par classe (une classe --sans méthodes virtuelles ni héritage--, ce n'est rien d'autre qu'une structure et un jeu de fonctions qui manipulent cette structure, après tout): un hpp et un cpp.
      On peut appliquer la même chose au C: la structure et les prototypes de fonction qui manipulent cette structure (et uniquement elle) dans le .h, l'implémentation des fonctions dans le .c.
      Après, comme je t'ai dis, je me suis fixé des objectifs quantitatifs pour le nombre de lignes de code, de fonctions manipulant une seule et unique structure, etc.
      Un outil très intéressant pour ça: cccc qui scanne tes sources et indique un certain nombre de métriques, notamment concernant la complexité cyclomatique.
      Cet outil à été un très bon prof pour m'apprendre à faire du code plus simple à maintenir.

      Entièrement d'accord je voulais en finir a la fin et j'ai oublier de faire des sessions de commentaires du code pendant le développement, comme je fait d'habitude, ce qui fait que le code n'est pas très documenter.

      J'ai dit documenté, pas commenté :)
      La différence entre les deux, pour moi, c'est qu'il n'y à pas besoin de commentaire dans le code pour documenter. Pour moi, des fonctions courtes dont le nom indique ce qu'elles font, et un ou deux diagrammes (dia est pas trop mal pour faire des diagrammes avec une GUI, mais je pense sérieusement commencer à utiliser dot à la place: plus léger, utilisable sans souris, versionable, bref, que du bonheur) qui représentent les principaux flux d'appels et c'est réglé.

      Je ne contredit en rien ce qui été dit mais bon la vision de celui qui code et de celui qui relit n'est jamais la même.

      C'est clair, d'autant que jusqu'à preuve du contraire, personne n'est capable de se mettre d'accord sur le code idéal :)
      Et puis comme on dit: les conseilleurs ne sont pas les payeurs.

      J'admets même que ce n'est pas du code C propre, trop noyer par GTK+3.

      Je ne connais pas GTK, et quand je vois la direction ou ça va, je n'ai pas envie d'apprendre. Pour le moment, je suis très heureux avec mes scanf/printf en fait. Si je dois utiliser des GUI, j'aurai plus tendance à partir sur wxWidgets, voire Qt.
      Il y à d'autres libs aussi, genre fltk qui passeront avant GTK.

      PS: Est a cause de l'erreur d'orthographe du mot opérande en anglais que tu dit que mon code est du franglais…???

      C'est possible, comme je t'ai dit, je n'ai lu que le fichier contenant la fonction main, et encore, très vite. C'était une impression à chaud, jamais 100% pertinent.

      Merci d'avoir pris le temps de lire mon code, c'est vraiment gentil d'avoir fait l'effort je t'en remercie encore une fois.

      C'est normal. Si un jour j'utilise ton soft, et que j'ai un truc à corriger, je préfèrerai autant que le code soit propre, et n'en déplaise aux fanatiques du libre, c'est rarement le cas. Ce n'est pas parce que le source est ouvert qu'on peut modifier un programme, certains sources sont dans un tel état qu'il est plus simple de modifier le binaire que le source! J'exagère un peu, mais pas tant que ça…
      D'ailleurs, pour choisir entre 2 softs, depuis quelques temps j'essaie de lire le code, histoire d'être capable de hacker les outils que j'utilise.
      Et puis, je t'avoue, galculator commence à me lasser sérieusement, changer de calculatrice est un truc auquel je pense de plus en plus fortement. Je me suis donc dit: pourquoi pas (mais j'ai pas compilé, flemme d'installer les libs de dev gtk).

      conseils si tu veux refacto

      Si tu veux refacto ton code pour le rendre plus lisible, à mon avis il faudrait que tu fasses ça:

      • déplacement de chaque structure dans un header dédié à la structure.
      • déplacement des blocs de code qui ne manipulent qu'une structure dans un .c dédié à la structure, sous forme de fonctions minimales (même si elles ne font que 3-5 lignes, peu importe) avec un prototype dans le header contenant la structure
      • suppression des notions d'indices dans les variables ( operand_1, operand_2, par exemple ça devrait aller dans un tableau )

      Déjà, ça devrait te rendre le code moins violant: si ton code t'a gavé c'est à cause du manque de structuration. Je ne sais pas quel outil tu utilises pour coder, mais perso, je me contente d'un bête éditeur de texte avec coloration syntaxique et d'un terminal. Séparer le code en pleins de fichiers me permets de savoir très rapidement ou se trouve le code lié à telle ou telle fonction, en fonction de la structure manipulée.

      Le problème, c'est que pour la compilation c'est moins simple, du coup il faut utiliser un système de build: j'ai adopté cmake, mais il y en a d'autres genre scons (que je n'ai même pas vraiment testé en plus).

      Ces 3 étapes vont probablement péter la compilation, c'est pour ça qu'il vaudrait mieux le faire structure par structure, avec un outil de versionning correct (git, mercurial, bazaar ou fossil entrent dans cette catégorie. Il y en à sûrement d'autres aussi, mais évites CVS ou SVN) ce qui te forcera à réfléchir à ton organisation.
      Normalement, en, disons, 2 ou 3 heures (ton code est assez petit après tout), tu devrais te retrouver avec un code qui te motivera plus à le maintenir sur la durée, plutôt qu'un "code jetable".

      • [^] # Re: précision des flottants

        Posté par Linuxator (site web personnel) le 20 décembre 2014 à 16:06. Évalué à -3.

        

        Merci pour ces précisions,
        petite note: le mot opérande en anglais ne prends pas de 'e' à la fin: d'ou la confusion.

        Concernant les fichiers d'en tête (*.h): ce sont souvent les seules fichiers que l'on retrouve dans le dossier /usr/include et ils ne contiennent que les déclaration des fonctions:

        void ma_func(int mon_int, char *mon_string) ;  
        

        Le corps des fonctions étant contenus dans des fichiers compilés qui sont des library partager ou shared object d'extension .so dont ont doit donner le lien au compilateur avec l'option -l de gcc.

        Je parle en connaissance de cause car je suis en train de travailler sur une library partagée, qui justement sera la library hobdcalc.
        C'est pour bientôt car j'ai terminer les fonctions et il me reste a écrire une partie des manpages, un readme et éventuellement générer une documentation.

        Je ferai un nouveau poste car il reste quelques points a éclaircir:
        -Le chemin ou sont situer les library partagées ne sont pas les mêmes sur les différentes distribution ? Sous Ubuntu elles sont situer dans /usr/lib.
        - Et j'ai le même problème avec les manpages /usr/share/man/ sous Ubuntu.
        Faire un script d'installation propre: ton conseil d'utilisé make me tente de plus en plus.

        Concernant les conseils données je m'en souviendrai pour la prochaine fois, car je ne retouche rarement a un code que je vient de publier (sauf bug fonctionnel), sinon pour faire un Ghobdcalc version 2. Car après un mois de codage acharné l'on a pas forcément envie de retoucher le code.

        Je retiens les conseils données et je les appliquerai car la dernière fois que j'ai publier un programme C ont m'a conseiller d'inclure des fichiers d'extension *.c et non *.h ce que j'ai fait ce coup ci et j'ai compris la différence entre les deux.

        J'ai fracturer le code selon le type de fonctions: fonction touchant aux strings, aux opération etc..
        Je penserai a le fracturer encore plus en fonction des structures manipulées.

        Je ne connais pas GTK, et quand je vois la direction ou ça va, je n'ai pas envie d'apprendre. Pour le moment, je suis très heureux avec mes scanf/printf en fait. Si je dois utiliser des GUI, j'aurai plus tendance à partir sur wxWidgets, voire Qt.
        Il y à d'autres libs aussi, genre fltk qui passeront avant GTK.

        Personnellement j'ai mis un an et demie avant d'envisager d'apprendre une GUI en C. Pas de regrets car cela permet de créer une GUI et donc de rendre accessible des programmes fonctionnant en ligne de commande a un publique qui n'est pas adepte de la ligne de commande, comme dans le cas d'une simple calculatrice.

        Une réflexion que j'ai appris dans un livre consiste a réfléchir sur le type de publique visé par son programme et donc le choix d'utiliser une GUI.

        Sinon j'utilise également un simple éditeur et le terminal comme toi. Pas de IDE comme code::block ou autres anjuta…

        Encore merci d'avoir prêter attention a mon code, car l'on a trop souvent ignoré mes créations sur les forums Linux (pas de réponses a la présentation d'un programme).

        • [^] # Re: précision des flottants

          Posté par Linuxator (site web personnel) le 20 décembre 2014 à 16:36. Évalué à -3.

          

          Et puis, je t'avoue, galculator commence à me lasser sérieusement, changer de calculatrice est un truc auquel je pense de plus en plus fortement. Je me suis donc dit: pourquoi pas (mais j'ai pas compilé, flemme d'installer les libs de dev gtk).

          Prend simplement le fichier de format *.deb:
          A condition d'avoir une connexion internet, et d'avoir un OS de la famille debian, ça installe le programme que les dépendances soit installées ou pas. C'est un format de fichier difficile a construire, car il existe un programme se nommant lintian qui vérifie que le fichier *.deb est au normes et qui t'avertis avant d'installer quoi que ça soit si le fichier n'est pas conformes, mais c'est aussi pratique qu'un *.exe (avec installeur) sous Windows.
          Et si tu a le moindre doute en terme de confiance par rapport aux opérations effectuer sur ton OS.
          Tu peut simplement décompresser le fichier *.deb et vérifier les 2 scripts et les sources compilés.

          • [^] # Re: précision des flottants

            Posté par freem le 02 janvier 2015 à 12:07. Évalué à 2.

            

            Moui, mais je trouve les fichiers source (le .deb source, je parle) assez, disons, étranges à manipuler.
            En même temps, Debian n'est pas faite pour être ultra customisée. Vais sûrement aller voir du côté d'une distro source quelconque un de ces 4…

        • [^] # Re: précision des flottants

          Posté par freem le 02 janvier 2015 à 12:05. Évalué à 2.

          

          Je ferai un nouveau poste car il reste quelques points a éclaircir:
          -Le chemin ou sont situer les library partagées ne sont pas les mêmes sur les différentes distribution ? Sous Ubuntu elles sont situer dans /usr/lib.
          - Et j'ai le même problème avec les manpages /usr/share/man/ sous Ubuntu.
          Faire un script d'installation propre: ton conseil d'utilisé make me tente de plus en plus.

          D'autant qu'en plus cmake… enfin, cpack, une sorte d'extension à cmake, intégrée par défaut, te permettras de générer des paquets/installateurs.

          Je retiens les conseils données et je les appliquerai car la dernière fois que j'ai publier un programme C ont m'a conseiller d'inclure des fichiers d'extension *.c et non *.h ce que j'ai fait ce coup ci et j'ai compris la différence entre les deux.

          Je serais curieux de voir l'argument employé. Ok, les .h peuvent servir pour les libs (que ce soit pour les dynamiques ou pour les statiques) mais personnellement, j'ai tendance à m'en servir pour savoir l'API du fichier d'implémentation correspondant. J'y mets aussi les trucs genre "commentaires doxygen", qui expliquent ce que la fonction prend en entrée et génère en sortie (en fait: préconditions, postconditions et invariants, même si le C++ permets déjà de bien l'expliquer via le langage).

          Personnellement j'ai mis un an et demie avant d'envisager d'apprendre une GUI en C.

          Bof, j'ai appris à utiliser Qt (v3 de mémoire), MFC, wxWidgets par le passé. M'adapter à une nouvelle API ne me prendrais pas longtemps, mais… j'avoue, me fader des IHM c'est ce qui m'emmerde le plus. Je trouve les toolkits assez mal conçus en général, et plus je peux éviter, mieux je me porte. Coup de bol: dans mon taf on me demande quasi pas d'IHM :p

          Sinon j'utilise également un simple éditeur et le terminal comme toi. Pas de IDE comme code::block ou autres anjuta…

          J'ai utilisé ce genre de trucs, par le passé. J'ai toujours trouvé ça stupide d'avoir, dans un même OS, une palanquée de logiciels implémentant la même fonctionnalité: la gestion de fenêtres. Un jour, j'ai découvert que des WM existaient qui permettent de faire du "docking" avec n'importe quelle application (TWM, dans mon cas i3). Ce jour la, j'ai pris la pente qui à aboutit à la suppression des IDE de ma trousse à outils ;)

• # La library hobdcalc disponible come shared library.

  Posté par Linuxator (site web personnel) le 21 décembre 2014 à 16:39. Évalué à -3.

  

  Pour finir,
  J'ai finit la shared library annoncée, avec une Makefile comme script d'installation.
  la présentation sur ce forum de
  hodbcalc une shared library for multibases conversions and calculation.

  Merci pour vos réponses éclairées qui m'ont bien aider.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.