La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!
Je pense que ce qui n'est pas clair, le fond du truc, c'est le type doit être déclaré et défini dans la library et non dans l'application.
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
Hello,
alors oui mon post plus haut est pas bon mais comme j'ai trouvé la solution je viens la poster ici.
Donc je suis bien parti sur une solution à base de #ifdef (merci Mr Slurp).
J'ai donc encadré mes typedef communs par une directive #ifdef LIB_ONLY dans les sources de ma librairie. Ensuite dans le makefile de la librairie, dans les options de compil j'ai déclaré un -DLIB_ONLY, ce qui fait que l'option est active lorsque je compile la librairie.
Et donc quand je compile l'application avec ce fichier .h en source (via la librairie), la directive n'étant pas active, les types utilisés sont bien ceux déclarés dans l'appli et non dans la librairie.
Et voilà ! ça fonctionne très bien.
Merci à tous pour votre aide
Alors de rien, mais normalement avec les header guard, pas besoin de spécifier quoi que ce soit à la compile pour que ça marche, exemple concret sur cette page
https://www.learncpp.com/cpp-tutorial/header-guards/
La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!
C'est 2 unités de compilations séparées, c'est normal qu'un header guard ne suffise pas.
Il dit qu'il voit pas le rapport, ou alors on parle d'erreur de linkage avec des fonctions compilées plusieurs fois dans plusieurs projets mais linké ensemble à la fin.
3 "binaire" : 2 exe, 1 lib
lib_a est une shared lib
bin_b include lib_a.h, et link avec son .so
bin_a include lib_a.h ET bin_b.h mais ne link pas avec le .so car il n'utilise pas la fonction small_func, mais seulement la définition de structure qui est dans lib_a.h
J'ai donc 3 unité de compilation distinctes et des inclusions multiple (bin_a include lib_a.h, puis bin_b.h qui lui même include lib_a.h
Le tout compile sans la moindre directive de compilation. Juste des header guard.
bin_a.h
bin_a.cCode:#include <stdio.h> #include "lib_a.h" #include "bin_b.h" #ifndef BINA_H #define BINA_H struct in_header_bin_a { int i; struct in_header_lib_a a; struct in_header_bin_b b; }; #endif
bin_a MakefileCode:#include "bin_a.h" #include "bin_b.h" #include "lib_a.h" void main(void) { struct in_header_bin_a ba; struct in_header_bin_b bb; struct in_header_lib_a la; printf("%d", ba.i); printf("%f %f", ba.a.f, ba.b.s.f); }
--------------------------------------------Code:default: bin_a bin_a.o: bin_a.c bin_a.h gcc -c bin_a.c -o bin_a.o -I../lib_a/ -I../bin_b/ bin_a: bin_a.o gcc bin_a.o -o bin_a clean: -rm -f bin_a.o -rm -f bin_a
bin_b.c
Code:#include "bin_b.h" #include "lib_a.h" void main(void) { struct in_header_bin_b b; struct in_header_lib_a a; printf("%f", a.f); printf("%d %f", b.i, b.s.f); small_func(b.s); }
bin_b.h
Code:#include <stdio.h> #include "lib_a.h" #ifndef BINB_H #define BINB_H struct in_header_bin_b { int i; struct in_header_lib_a s; }; #endif
bin_b Makefile
--------------------------------------------Code:default: bin_b bin_b.o: bin_b.c bin_b.h gcc -c bin_b.c -o bin_b.o -I../lib_a/ bin_b: bin_b.o gcc bin_b.o -o bin_b -L../lib_a -l:lib_a.so clean: -rm -f bin_b.o -rm -f bin_b
lib_a.c
lib_a.hCode:#include <stdio.h> #include "lib_a.h" void small_func(struct in_header_lib_a a) { printf("%f", a.f); }
Code:#ifndef LIBA_H #define LIBA_H struct in_header_lib_a { float f; }; void small_func(struct in_header_lib_a a); #endif
lib_a Makefile
Code:default: lib_a.so lib_a.o: lib_a.c lib_a.h gcc -c lib_a.c -o lib_a.o lib_a.so: lib_a.o gcc -shared lib_a.o -o lib_a.so clean: -rm -f lib_a.o -rm -f lib_a.so
Dernière modification par Mr Slurp ; 29/03/2024 à 16h02.
La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!
Salut les canards,
Besoin d'un petit conseil "langage de programmation".
Ma copine aurait besoin d'un outil pour lui simplifier la vie: son salaire varie en fonction des jours de congés, des maladies et des RTT pris sur l'année glissante, avec d'autres paramètres pris en compte... etc C'est un beau merdier au point que même ses RH s'y perdent. Elle souhaiterait un outil qui lui permetterais de calculer ses fluctuations de salaires et de "prédire" les futures fluctuations en fonction d'absences prévues.
Je voudrais lui faire une petite App pour ca. Je sais que ca bénéficierais aussi à ses collègues donc j'aimerais un truc compilé, facilement distribuable avec un GUI (2 registres, un tableau, un graph et 3 boutons; rien de bien fifou=.
Vers quel langage me tourner?
C#, que je connais le mieux, me semble être un overkill.
Rust, qui m'interresse, semble a chier pour les UI.
Python est au cauchemar a distribuer.
Je prend volontier des conseils.
Je vais ptêtre dire une connerie mais... pourquoi ne pas faire une app web ? Comme ça ça tourne n'importe où, sur mobile, pc, mac ..
Parce qu'il faut l’héberger ?
"Tout est vrai, tout existe, il suffit d'y croire."
Dieu. (enfin… je crois)
Si t'es confortable avec ça me paraît pas une si mauvaise idée. XAML est verbeux mais avec le designer intégré aux IDE t'as vite fait de bricoler une interface.
Rust est jouable (iced est assez correct, ou egui si tu veux t'essayer aux joies de l'immediate mode) mais ce sera certainement un poil plus prise de tête vu ses spécificités.
Sinon ouais du web (ou du C++ ).
Ça ressemble quand même à un truc qui pourrait être fait dans et avec un tableur.
Pas si tout tourne en javascript sur le client, il suffit de distribuer le HTML et les bricoles qui vont autour.
Sinon Purebasic ?
Google appscript avec du google sheet, c'est du js avec une page html et voilà.
On appelle ça du DHTML.
https://fr.wikipedia.org/wiki/HTML_dynamique
Et pour le distribuer, tu peux envoyer un zip par mél aussi.
Excel wai.
Sinon si tu veux t’entraîner, C# + WPF, vu que tu connais le premier. Mais faire une app dédié (quelque soit la techno) me semble un peu overkill en effet.
Comme certains l'ont dit : Excel est, à mon sens, ton meilleur ami pour ça.
Excel a pas mal de fonction avancé et si besoin tu peux le renforcer par de la programmation avec visual basic.
Je ne vois pas de langage et de processus plus adapté et plus simple personnellement.
J'ai fait pas mal de Excel+VBA dernièrement pour faire ce genre d'outils pour des collègues pour ce type de merdouille, c'est très puissant (et encore plus avec Power Query ).
Le problème de Excel, c'est que ca me rappelle trop le travail... '^^
Je vais essayer de faire ca en js. Une fois que j'aurais saisi les "subtilités" des event listeners en js de ma page html, le reste devrait dérouler (parser un csv et en trier / grouper les données c'est relativement simple).
Tableur, pas Excel.
Après le Marteau de Maslow du développement web client/serveur en ligne pour une petite calculette, celui de la suite Microsoft sans laquelle rien ne serait possible.
Il y a assez d'alternatives gratuites pour s'en passer, ce qui permettra à tout le public concerné de profiter de l'outil sans devoir débourser quoique ce soit pour le faire tourner.
Autre avantage du tableur : si des constantes ou les règles métier changent, l'utilisateur non informaticien peut se débrouiller seul pour les modifier au lieu de devoir faire appel au dev (ou signer un avenant au contrat).
Si besoin, on peut aussi simuler des appels AJAX sans avoir besoin que la ressource soit distante : https://github.com/jakerella/jquery-mockjax
Ça dépend que tu fais et ce que tu as à déployer
Sinon, je reste sur mon point que google sheet + appscript (js dans l'environnement google quoi) c'est une solution tout à fait valable sans compter qu'elle est portable par nature et tout le monde peut y avoir accès sans rien avoir à installer.
Hello,
Je cherche un GUI GIT pour windows, actuellement j'utilise github desktop mais récemment j'ai un peu plus investi GIT et je test les worktree pour avoir une version prod & dev en même temps. Sauf que github desktop ne les gère pas. Cela affiche bien une "branch" du nom du worktree, mais je ne peux pas interagir avec, ni push mon worktree.
Si quelqu'un en a un à me conseiller ?
(j'ai créé mon worktree via la console, mais sous windows je trouve que c'est l'enfer sur terre)
(c'est fort possible que je repasse au final à une version plus standard de git, à savoir un répertoire unique pour la branche "main" et la branche "dev". Si je modifie dans dev, que je commit/push/merge sur main, la version dev prend la version de main ?)
Merki !
---------
Je rajoute un autre truc, si je veux faire un truc genre dev -> testing -> main avec des merges de dev dans testing, puis testing dans main, est-ce qu'il y a un GUI qui peut également le faire ? :D
Dernière modification par Papeyo ; 25/04/2024 à 13h34.
Je n'utilise pas ces fonctions avancées, donc les intégrations des IDE m'ont toujours suffi (avec un peu de ligne de commande de temps en temps).
Mais j'avais entendu du bien de Fork à un moment, visiblement ils ont ajouté le support des worktree dans la dernière version (cf blog). Mais y'a probablement des alternatives gratuites qui sont tout aussi bien.
Je viens de remarquer qu'il ne conserve pas les junction sous windows :/
Merci du lien, c'est effectivement trop cher pour me faire changer
Alors t'as git kraken qui semble être la référence, mais, worktree est une fonction assez avancée et pas sûr qu'il y ait beaucoup de gui qui sachent s'en sortir avec. Sinon, pour git en ligne de commande sous windows, je te conseille d'utiliser powershell, sinon le must ça reste wsl (avec la distribution de ton choix).
Enfin, mon dernier point, worktree, à part cas très particulier, t'en a pas vraiment besoin, surtout si c'est pour comparer une branche prod et une branche dev. Diff fait déjà bien le travail (après c'est comme tu le sens, en général il y a toujours plusieurs méthodes pour se servir de git )