créer bibliothèque de fonctions

Bonjour à tous!
:pastaper:J'ai des fonctions qui "calculent" du code.Je suis amené à les modifier/ajuster au fur et à mesure des mises au point et voudrait les rassembler dans une bibliothèque statique (ou un fichier d'entête) pour ne faire les modifications qu'une fois pour qu'elles soient valables partout.Dans ma compréhension une sorte de super-fonction.
Je ne trouve rien de compréhensible sur le net.Si vous avez un lien je serai content.:pastaper:
(je cherche à utiliser un vélo,voir à changer de chaîne,cadre,roue,selle mais pas à savoir comment on consruit une chaîne,un cadre,une roue,une selle..
:lol:)

A lire :

http://www.adp-gmbh.ch/cpp/gcc/create_lib.html
ou
http://msdn.microsoft.com/en-us/library/ms235627.aspx

merci...intéressant...en anglais...bien théorique...:oops:

Ca m'a pas l'air trop sorcier.

Les sites précédents (notamment le premier) ne sont pas compliqués. Faut prendre 2 min la peine de lire, c'est tout.

pas sorcier mais abscond.;)
Evidemment je suis sous Dev-cpp pas sous Blocks...
Le projet parle de dll.h:pour moi c'est n'est pas du statique mais pourquoi pas.
Ensuite il ya main.c,linker,etc,etc,..
J'avais déjà trouvé mais n'avais pas donné suite car trop éloigné de Dev-cpp et ne suis pas assez éduqué.
Merci quand même de t'être penché sur mon cas.:oops:

il m'est venu à l'idée soit d'utiliser code:blocks pour créer ma bib statique en espérant qu'elle soit utilisable sous dev-cpp,soit de la créer avec wxdev-cpp la dernière mouture de dev.
Quand pensez-vous?
----------------plus tard:
Finalement tous inbuvables pour moi.
Je rennonçe à créer un lib/bib statique perso.
Merci pour vos aides et conseils.Je vais continuer avec ma méthode artisanale.
:cry:

J'en pense que tu devrais abandonner devcpp qui n'est plus supporté, depuis au moins 7 ans.

Salut,

Il ne faut pas confondre : Code::blocks, Dev-Cpp, XDev-cpp ou même QtCreator ne sont que ce que l'on appelle des "EDI" (Environnement de Developpement Intégré).

Ce ne sont que des environnements qui permettent d'utiliser une série d'outils (compilateur, éditeur de liens, archiveur,...) dans un ordre bien précis pour permettre de transformer le code que tu as écrit en quelque chose d'utilisable (bibliothèque, statique ou dynamique, ou exécutable).

Si deux EDI utilisent le même compilateur (par exemple gcc), dans la même version, et les mêmes options de compilation, ce qui est généré avec l'un est parfaitement utilisable par l'autre.

Ceci dit, dev-cpp (et ses variations WxDev-cpp) est un projet qui n'est plus maintenu depuis maintenant déjà quelques années.

Il est donc largement préférable de choisir un EDI plus récent, comme Code::blocks ;)

Pour en revenir à ta question initiale :

Il existe deux types de bibliothèques : les bibliothèques statiques et les bibliothèques dynamiques ("dll" sous windows, "so" sous linux).

Les bibliothèques statiques ne sont, pour faire simple, que des archives qui contiennent des fichiers objets (*) dont le contenu utile sera rajouté à ton application au moment de l'édition de liens afin qu'il soit utilisé.

Si tu modifies une bibliothèque statique, les applications qui ont déjà été compilées avec les versions précédentes ne seront pas affectées par les modification, pour la simple et bonne raison que l'application finale est indépendante de la bibliothèque statique.

Si tu veux qu'une application puisse profiter des modifications que tu as apportées à une bibliothèque statique, il faut... recompiler l'application (ou au minimum refaire l'édition de liens) ;)

Le fonctionnement des bibliothèques dynamiques est un peu différent.

Elles contiennent toujours le code objet des fonctions qui en font partie, mais ce code n'est pas ajouté directement dans l'application qui utilise la bibliothèque:

L'application va appeler les fonctions directement dans la bibliothèque.

Comme le code de la bibliothèque n'est pas directement inclus dans l'application, mais que c'est l'application qui va le chercher en cas de besoin, si tu modifies une bibliothèque dynamique, et que tu t'arranges pour que la nouvelle version de cette bibliothèque dynamique se trouve à l'endroit où l'application s'attend à la trouver, toute application utilisant la bibliothèque dynamique sera directement impactée par la modification, y compris les applications les plus anciennes.

A lire ton premier message, j'ai l'impression que ce que tu cherches à faire ressemble beaucoup plus à une bibliothèque dynamique qu'à une bibliothèque statique ;)

(*) pour comprendre ce dont je parle, il faut connaitre, au moins dans les grandes lignes, la "chaine de compilation".

Le compilateur n'est qu'un des outils qui interviennent entre le code que tu écris (quel que soit le langage) et l'exécutable final.

En effet, pour passer du code que tu écris à l'exécutable final, il faut passer par plusieurs étapes :

1. La première étape est effectuée par ce que l'on appelle le "préprocesseur". C'est un outils qui se contente de modifier le code en fonction de certaines macros (par exemple #include a pour effet de copier le contenu du fichier indiqué)
2. La deuxième étape (maintenant facultative grace aux évolutions) était la génération de code assembleur: l'assembleur est un langage moins évolué que le C ou le C++, qui représente les instructions que le processeur devra effectuer
3. La troisième étape est la génération de code binaire : chaque instruction que le processeur doit effectuer est "traduite" au format binaire pour qu'elle soit compréhensible par le processeur. Le résultat de cette traduction fournit ce que l'on appelle un "fichier objet"
4. La quatrième étape dépend du résultat que tu veux obtenir : Pour la création d'applications, c'est l'édition de liens qui va remplacer l'appel aux différents symbole représentant les différentes fonction par l'appel aux adresses mémoire auxquelles les fonctions en question se trouvent effectivement. Pour la création de bibliothèques, ce sera plutot la création d'une archive

Bon, bien sur, il n'y a ici que les grandes lignes (on pourrait écrire un bouquin complet ) te j'ai même pris quelques raccourcis qui font que ce n'est "pas tout à fait juste"...

Mais cela te permettra malgré tout de comprendre un peu d'avantage de quoi l'on parle ;)

La génération de bibliothèques statiques est "relativement" simple :

En gros, une fois que l'ensemble des fichiers objets a été généré, il "suffit" de créer une archive qui les contient tous avec l'outil qui permettra au compilateur d'en récupérer le contenu (et en lui donnant un nom qui permettra au compilateur de se rendre compte qu'il s'agit bel et bien d'une bibliothèque ;) ).

Pour les bibliothèques dynamiques, c'est "un peu plus compliqué", car cela dépendra essentiellement du système cible.

Sous linux, il suffit généralement d'utiliser l'option de compilation -fPIC pour indiquer au compilateur qu'il doit générer du code indépendant de la position (Position Independant Code) avant de tout mettre dans une archive

Sous windows, il faut commencer par:
faire en sorte que les symboles utilisés par l'application soit "exportés" de la dll
faire en sorte que l'application sache qu'elle doit "importer" les symboles qui viennent de la dll.

Pour indiquer qu'un symbole doit etre exporté par une dll, il faut utiliser la déclaration de spécification __declspec(dllexport).

Cela donne, pour une déclaration de fonction, un code proche de

Code:

---

type_de_retour __declspec(dllexport) nom_de_la_fonction(/* liste de paramètres */ );

---

et, si tu veux exporter l'ensemble d'une classe, un code proche de

Code:

---

1 2 3 4

class __declspec(dllexport) NomDeLaClass { /* contenu de la classe */ };

---

Lorsque l'on veut utiliser dans une application quelque chose qui est fournit par une dll, il faut indiquer dans la déclaration de ce "quelque chose" que cela doit etre importé.

A cette fin, la déclaration d'une fonction devra ressembler à quelque chose proche de

Code:

---

type_de_retour __declspec(dllimport) nom_de_la_fonction(/* liste de paramètres */ );

---

et celle d'une classe à un code proche de

Code:

---

1 2 3 4

class __declspec(dllimport) NomDeLaClass { /* contenu de la classe */ };

---

La solution la plus simple (pour éviter d'avoir à gérer deux versions des fichiers d'en-tête : une pour la compilation et l'autre pour l'utilisation) est de recourir à des directives préprocesseurs proches de

Code:

---

1 2 3 4 5

#if defined(MYLIB_EXPORT) #define MYLIB_API __declspec( dllexport ) #else #define MYLIB_API __declspec( dllimport ) #endif

---

et d'ajouter la définition MYLIB_EXPORT à la ligne de commande de compilation ( ex avec g++ : gcc -DMYLIB_EXPORT -DSHARED -fmonFichier.cpp -o../build/monFichier.o )

Les codes correspondant aux déclarations de fonctions et de classes ressemblant alors à quelque chose proche de

Code:

---

type_de_retour MYLIB_API nom_de_la_fonction(/* liste de paramètres */ );

---

et celle d'une classe à un code proche de

Code:

---

1 2 3 4

class MYLIB_API NomDeLaClass { /* contenu de la classe */ };

---

Évidemment, les directives préprocesseurs peuvent devenir beaucoup plus complexes, si tu veux, par exemple, pouvoir aussi bien créer une bibliothèque statique qu'une bibliothèque dynamique ou si tu veux pouvoir créer une bibliothèque fonctionnant aussi bien sous linux que sous windows.

Tu pourrais ainsi très bien te trouver avec des directives préprocesseurs proches de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#if defined(__WIN32) // la partie utilisée sous windows #if defined(SHARED) // la version "dll" #if defined(MYLIB_EXPORT) // lors de la compilation #define MYLIB_API __declspec(dllexport) #else // lors de l'utilisation #define MYLIB_API __declspec(dllimport) #endif // MYLIB_EXPORT #else // la version statique (windows) #define MYLIB_API #endif // SHARED #else // sous linux #define MYLIB_API #endif // __WIN32

---

Hope it helps ;)

merci pour ceux qui ont tout compris..........
Question lib/bib j'ai bien compris à quoi çà servait et comment l'utiliser mais voila ma méthode artisanale:
--------------
#include x
#include y
#include z

fonction A
fonction B
fonction C

int (P)
{
appel de fonction A
appel de fonction B
appel de fonction C
}
----------
je compile mais prob avec B
j'extrait B dans un programme spécifique
---------------------
#include x +/ou y +/ou z selon nécessités
fonction B
int (Q)
{
appel B
}
je compile et vérifie prob
je modifie B qui devient Bprime
que j'intègre dans P à la place de B
P devient Q
je compile Q avec A,Bprime,C
çà marche ou pas
Si j'avais une lib/bib je modifierai et un seul endroit mes fonctions.
Si j'utilise Dev-cpp c'est que çà suffit à mes ambitions.
Salut à tous!:marteau:

Le fait est que si tu renomme B en Bprime, cela ne pourra jamais marcher sans commencer à remplacer tous les appels à B par des appels à Bprime.

Si ce que tu veux faire, c'est pouvoir corriger le comportement de B (tout en gardant comme nom de fonction B) et que toutes les applications qui utilisent B puissent profiter des corrections, alors, c'est très clairement vers une bibliothèque dynamique ( dll, sous windows) que tu dois te diriger.

Il faudra cependant prendre soin de bien veiller à ce que la nouvelle version de la dll se trouve exactement au même endroit que l'ancienne version une fois qu'elle est déployée.

Concernant Dev-Cpp, je comprend qu'il puisse "suffir à tes ambitions" comme tu dis si bien, mais il faut cependant bien comprendre que, son développement n'étant plus assuré, son évolution est, purement et simplement arrêtée.

Cela implique, par exemple, que Dev-Cpp travaille encore avec la version 3.4 de Gcc (de mémoire).

Or, la dernière release de gcc 3.4 de Gcc date de 2006, ce qui en fait une version particulièrement vieille et qui d'ailleurs, pour autant que je puisse m'en souvenir, souffrait encore de quelques problèmes quant au respect de certain points de la norme.

Il ne faut donc absolument pas croire que, lorsque l'on déconseille d'utiliser un outil, ce n'est que parce qu'il est vieux ;)

C'est parce que le support étant arrêté, son ancienneté le rend, purement et simplement, obsolète, et que son ancienneté fait que tu perds l'occasion de profiter d'un certain nombre de corrections en tous genres ;)


Peut etre as tu raison d'estimer qu'il ne t'est pas indispensable d'avoir la possibilité de compiler en 64bits ou celle de profiter de C++11 (je suis tout à fait disposé à prendre en compte tes raisons sur ces sujets ;)), mais il est par contre beaucoup plus problématique de se retrouver face à une situation où tu risques de ne pas pouvoir utiliser des fonctionnalités réputées fonctionnelles, "simplment" parce que tu as la flegme de mettre ton compilateur à jour et que la version que tu utilises n'avais pas encore réussi à les implémenter :aie:

Code::Blocks et QtCreator sont deux outils totalement gratuits et multi plateformes, qui utilisent par défaut les suites d'outils GNU (Gcc et binutils), mais qui peuvent également être configurés pour utiliser une série d'autres compilateurs, et qui ont au moins le bon gout d'encore proposer un support, et donc de proposer, au pire, une version "presque à jour" des outils par défaut.

A l'heure actuelle, il devient donc tout aussi aberrant de vouloir utiliser Dev-C++ que de vouloir utiliser VC6 (qui date d'avant la normalisation) pour un nouveau projet ou de vouloir absolument faire tourner win98 sur un pc que tu aurais acheté hier: Rien de tout cela n'est formellement impossible, mais tu te prépares des soucis sans noms en prenant ce genre de décision ;)

Amen!
---
J'aurais pas dû répondre çà!
J'ai peut-être mal expliqué ma technique mais elle fonctionne.Elle est seulement longue car si on a modifié une fonction il faut la retrouver partout inscrire la nouvelle mouture puis détruire la mouture obsolète.Je passe sur les détails pour opérer.
Avec une lib/bib je pense simplifier et sécuriser le processus car il n'y aurait QUE la lib/bib à modifier.
Merci pour le cours de technique utile à tous.
:hola: