je cherche a savoir si les .so sont pour linux la meme chose que les
.dll sous windows?
quelles differences y a il?
quelles difference dans la gestion dans le programme?
y a il un autre moyen de faire des "plugins" qui soit multi-os?
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows?
Plus ou moins.
quelles differences y a il?
Il faudrait préciser. En capacité, je crois que la plus notable est que sous Unix il n'y a pas de ressources.
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne sont pas les mêmes.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser la question. Et il y a des contraintes qui font douter de l'utilité. L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
3dsman <3dsman@free.fr> writes:
je cherche a savoir si les .so sont pour linux la meme
chose que les .dll sous windows?
Plus ou moins.
quelles differences y a il?
Il faudrait préciser. En capacité, je crois que la plus
notable est que sous Unix il n'y a pas de ressources.
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne
sont pas les mêmes.
y a il un autre moyen de faire des "plugins" qui soit
multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser
la question. Et il y a des contraintes qui font douter de
l'utilité. L'alternative (trop souvent oubliée me
semble-t'il) est d'avoir un langage d'extension du genre TCL
ou Python.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows?
Plus ou moins.
quelles differences y a il?
Il faudrait préciser. En capacité, je crois que la plus notable est que sous Unix il n'y a pas de ressources.
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne sont pas les mêmes.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser la question. Et il y a des contraintes qui font douter de l'utilité. L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
3dsman
3dsman writes:
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows?
Plus ou moins.
quelles differences y a il?
Il faudrait préciser. En capacité, je crois que la plus notable est que sous Unix il n'y a pas de ressources.
ok ca ca me pose pas de probleme.
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne sont pas les mêmes.
ok et entre unix et macos c'est les meme?
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser la question.
peut etre mais c'est quoi? :-)
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
un langage de script quoi? c'est pas asse rapide pour ce que je veux en faire.
3dsman <3dsman@free.fr> writes:
je cherche a savoir si les .so sont pour linux la meme
chose que les .dll sous windows?
Plus ou moins.
quelles differences y a il?
Il faudrait préciser. En capacité, je crois que la plus
notable est que sous Unix il n'y a pas de ressources.
ok ca ca me pose pas de probleme.
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne
sont pas les mêmes.
ok et entre unix et macos c'est les meme?
y a il un autre moyen de faire des "plugins" qui soit
multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser
la question.
peut etre mais c'est quoi? :-)
Et il y a des contraintes qui font douter de
l'utilité.
lesquelles?
L'alternative (trop souvent oubliée me
semble-t'il) est d'avoir un langage d'extension du genre TCL
ou Python.
un langage de script quoi? c'est pas asse rapide pour ce que je veux en
faire.
L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
un langage de script quoi? c'est pas asse rapide pour ce que je veux en faire.
Il s'agit surtout d'un langage-glu, qui permet de "lier" des programmes ultra rapides entre-eux.
-- Richard
Richard Delorme
salut!
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows? quelles differences y a il? quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit sur les entrées standards (std::cin et std::cout), et l'application principale se lie au plugin par des tubes (pipes).
-- Richard
salut!
je cherche a savoir si les .so sont pour linux la meme chose que les
.dll sous windows?
quelles differences y a il?
quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est
différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit sur les
entrées standards (std::cin et std::cout), et l'application principale
se lie au plugin par des tubes (pipes).
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows? quelles differences y a il? quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit sur les entrées standards (std::cin et std::cout), et l'application principale se lie au plugin par des tubes (pipes).
-- Richard
Jean-Marc Bourguet
3dsman writes:
quelles difference dans la gestion dans le programme? Les fonctions à utiliser pour les charger manuellement ne
sont pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres Unix...
y a il un autre moyen de faire des "plugins" qui soit multi-os? Oui, mais c'est vraiment hors de ta portée si tu dois poser
la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même l'utilisation de la bibliothèque standard (en particulier les templates) pose un beau problème.
L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
un langage de script quoi?
Tout dépend de la définition que tu donnes à langage de script. Donner cette qualification à Python en particulier me semble étrange.
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
Qu'est-ce que tu veux faire?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
3dsman <3dsman@free.fr> writes:
quelles difference dans la gestion dans le programme?
Les fonctions à utiliser pour les charger manuellement ne
sont pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres
Unix...
y a il un autre moyen de faire des "plugins" qui soit
multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois poser
la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même
l'utilisation de la bibliothèque standard (en particulier
les templates) pose un beau problème.
L'alternative (trop souvent oubliée me semble-t'il) est
d'avoir un langage d'extension du genre TCL ou Python.
un langage de script quoi?
Tout dépend de la définition que tu donnes à langage de
script. Donner cette qualification à Python en particulier
me semble étrange.
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
Qu'est-ce que tu veux faire?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
quelles difference dans la gestion dans le programme? Les fonctions à utiliser pour les charger manuellement ne
sont pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres Unix...
y a il un autre moyen de faire des "plugins" qui soit multi-os? Oui, mais c'est vraiment hors de ta portée si tu dois poser
la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même l'utilisation de la bibliothèque standard (en particulier les templates) pose un beau problème.
L'alternative (trop souvent oubliée me semble-t'il) est d'avoir un langage d'extension du genre TCL ou Python.
un langage de script quoi?
Tout dépend de la définition que tu donnes à langage de script. Donner cette qualification à Python en particulier me semble étrange.
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
Qu'est-ce que tu veux faire?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
3dsman
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
pour le python je sais pas je n'ai encore jamais utilisé mais j'ai utilisé le language de script de maya par exemple ou de 3dsmax et en terme de vitesse ca a rien a voir avec du compilé!!!
Qu'est-ce que tu veux faire?
je cherche a faire un logiciel de compositing (il faut qu'il fasse de nombreux traitements sur des series d'images pouvant ateindre 4000x4000 pixels) donc j'ai besoin d'une vitesse d'execution assé importante.
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
pour le python je sais pas je n'ai encore jamais utilisé mais j'ai
utilisé le language de script de maya par exemple ou de 3dsmax et en
terme de vitesse ca a rien a voir avec du compilé!!!
Qu'est-ce que tu veux faire?
je cherche a faire un logiciel de compositing (il faut qu'il fasse de
nombreux traitements sur des series d'images pouvant ateindre 4000x4000
pixels) donc j'ai besoin d'une vitesse d'execution assé importante.
c'est pas asse rapide pour ce que je veux en faire.
Tu as mesuré? Sinon, sur quoi bases-tu ton affirmation?
pour le python je sais pas je n'ai encore jamais utilisé mais j'ai utilisé le language de script de maya par exemple ou de 3dsmax et en terme de vitesse ca a rien a voir avec du compilé!!!
Qu'est-ce que tu veux faire?
je cherche a faire un logiciel de compositing (il faut qu'il fasse de nombreux traitements sur des series d'images pouvant ateindre 4000x4000 pixels) donc j'ai besoin d'une vitesse d'execution assé importante.
Jean-Marc Bourguet
3dsman writes:
Qu'est-ce que tu veux faire?
je cherche a faire un logiciel de compositing (il faut qu'il fasse de nombreux traitements sur des series d'images pouvant ateindre 4000x4000 pixels) donc j'ai besoin d'une vitesse d'execution assé importante.
Je ne connais pas bien ce domaine mais j'imagine facilement que manipuler des pixels un par un n'est pas assez efficace. Mais est-ce que fournir des primitives supplementaires est une possibilite (c'est quand meme l'interet d'avoir un langage d'extension: on fournit les primitives et l'utilisateur les combine comme il veut) ?
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
3dsman <3dsman@free.fr> writes:
Qu'est-ce que tu veux faire?
je cherche a faire un logiciel de compositing (il faut qu'il fasse
de nombreux traitements sur des series d'images pouvant ateindre
4000x4000 pixels) donc j'ai besoin d'une vitesse d'execution assé
importante.
Je ne connais pas bien ce domaine mais j'imagine facilement que
manipuler des pixels un par un n'est pas assez efficace. Mais est-ce
que fournir des primitives supplementaires est une possibilite (c'est
quand meme l'interet d'avoir un langage d'extension: on fournit les
primitives et l'utilisateur les combine comme il veut) ?
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
je cherche a faire un logiciel de compositing (il faut qu'il fasse de nombreux traitements sur des series d'images pouvant ateindre 4000x4000 pixels) donc j'ai besoin d'une vitesse d'execution assé importante.
Je ne connais pas bien ce domaine mais j'imagine facilement que manipuler des pixels un par un n'est pas assez efficace. Mais est-ce que fournir des primitives supplementaires est une possibilite (c'est quand meme l'interet d'avoir un langage d'extension: on fournit les primitives et l'utilisateur les combine comme il veut) ?
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
Jean-Marc Bourguet wrote:
3dsman writes:
quelles difference dans la gestion dans le programme? Les fonctions à utiliser pour les charger manuellement ne sont
pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres Unix...
J'ai exactement le même code qui tourne sous Linux et sous Solaris.
C'est vrai que les dlopen et al. ne font pas partie de la norme Posix ; ils sont une extensions X/Open System. Je ne connais pas la politique de Mac vis-à-vis de Open System, ni même sur quel Unix il se base. Mais il n'est pas difficile d'écrire des plugin portable entre Unix et tous les Open System (Solaris, HP/UX, AIX...).
y a il un autre moyen de faire des "plugins" qui soit multi-os? Oui, mais c'est vraiment hors de ta portée si tu dois
poser la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Je ne comprends pas. Il faut bien tricher un peu avec la norme C/C++. (Mais c'est documenté dans la spécification de dlsym comment il faut faire.) Et il peu y avoir des histoires de l'ordre de construction/destruction -- sous Linux, au moins, j'ai bien eu des cas où des variables statiques dans le main ont été détruits avant des variables statiques dans l'objet dynamique, pourtant chargé bien plus tard. (Mais ça dépend des options lors de la compilation de g++.) Mais rien de très difficile à contourner.
Je dirais même que c'est plus facile que sous Windows. D'abord, parce que pour faire bien, il faut s'assurer que les bibliothèques de base (libc, etc. sous Unix) soient chargées dynamiquement ; c'est le défaut sous Unix, mais pas sous Windows. Ensuite, parce que sous Windows, il faut utiliser des extensions du langage pour rendre les symboles visibles ; sous Unix, tout est toujours visible avec dlsym, et on choisit lors du chargement si les symboles sont autrement visibles. (Pour un plugin, évidemment, on choisit que non. Ce qui n'est pas le défaut.)
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même l'utilisation de la bibliothèque standard (en particulier les templates) pose un beau problème.
Encore, je ne comprends pas. J'utilise assez régulièrement depuis peu des plugin dans mon propre code, sans le moindre problème (sauf l'histoire de l'ordre de destruction).
La seule contrainte que je connais, c'est que les bibliothèques « système » soient liées dynamiquement. Mais au moins chez Sun, c'est une contrainte générale depuis au moins Sun OS 4.x -- Sun ne garantit la compatibilité ascendante que pour les bibliothèques liées dynamiquement.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
3dsman <3dsman@free.fr> writes:
quelles difference dans la gestion dans le programme? Les
fonctions à utiliser pour les charger manuellement ne sont
pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres
Unix...
J'ai exactement le même code qui tourne sous Linux et sous
Solaris.
C'est vrai que les dlopen et al. ne font pas partie de la norme
Posix ; ils sont une extensions X/Open System. Je ne connais pas
la politique de Mac vis-à-vis de Open System, ni même sur quel
Unix il se base. Mais il n'est pas difficile d'écrire des plugin
portable entre Unix et tous les Open System (Solaris, HP/UX,
AIX...).
y a il un autre moyen de faire des "plugins" qui soit
multi-os?
Oui, mais c'est vraiment hors de ta portée si tu dois
poser la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Je ne comprends pas. Il faut bien tricher un peu avec la norme
C/C++. (Mais c'est documenté dans la spécification de dlsym
comment il faut faire.) Et il peu y avoir des histoires de
l'ordre de construction/destruction -- sous Linux, au moins,
j'ai bien eu des cas où des variables statiques dans le main ont
été détruits avant des variables statiques dans l'objet
dynamique, pourtant chargé bien plus tard. (Mais ça dépend des
options lors de la compilation de g++.) Mais rien de très
difficile à contourner.
Je dirais même que c'est plus facile que sous Windows. D'abord,
parce que pour faire bien, il faut s'assurer que les
bibliothèques de base (libc, etc. sous Unix) soient chargées
dynamiquement ; c'est le défaut sous Unix, mais pas sous
Windows. Ensuite, parce que sous Windows, il faut utiliser des
extensions du langage pour rendre les symboles visibles ; sous
Unix, tout est toujours visible avec dlsym, et on choisit lors
du chargement si les symboles sont autrement visibles. (Pour un
plugin, évidemment, on choisit que non. Ce qui n'est pas le
défaut.)
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même
l'utilisation de la bibliothèque standard (en particulier les
templates) pose un beau problème.
Encore, je ne comprends pas. J'utilise assez régulièrement
depuis peu des plugin dans mon propre code, sans le moindre
problème (sauf l'histoire de l'ordre de destruction).
La seule contrainte que je connais, c'est que les bibliothèques
« système » soient liées dynamiquement. Mais au moins chez Sun,
c'est une contrainte générale depuis au moins Sun OS 4.x -- Sun
ne garantit la compatibilité ascendante que pour les
bibliothèques liées dynamiquement.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
quelles difference dans la gestion dans le programme? Les fonctions à utiliser pour les charger manuellement ne sont
pas les mêmes.
ok et entre unix et macos c'est les meme?
Il n'y a déjà pas tellement d'homogénéité entre les autres Unix...
J'ai exactement le même code qui tourne sous Linux et sous Solaris.
C'est vrai que les dlopen et al. ne font pas partie de la norme Posix ; ils sont une extensions X/Open System. Je ne connais pas la politique de Mac vis-à-vis de Open System, ni même sur quel Unix il se base. Mais il n'est pas difficile d'écrire des plugin portable entre Unix et tous les Open System (Solaris, HP/UX, AIX...).
y a il un autre moyen de faire des "plugins" qui soit multi-os? Oui, mais c'est vraiment hors de ta portée si tu dois
poser la question.
peut etre mais c'est quoi? :-)
Implémenter toi même un chargeur/éditeur de liens.
Je ne comprends pas. Il faut bien tricher un peu avec la norme C/C++. (Mais c'est documenté dans la spécification de dlsym comment il faut faire.) Et il peu y avoir des histoires de l'ordre de construction/destruction -- sous Linux, au moins, j'ai bien eu des cas où des variables statiques dans le main ont été détruits avant des variables statiques dans l'objet dynamique, pourtant chargé bien plus tard. (Mais ça dépend des options lors de la compilation de g++.) Mais rien de très difficile à contourner.
Je dirais même que c'est plus facile que sous Windows. D'abord, parce que pour faire bien, il faut s'assurer que les bibliothèques de base (libc, etc. sous Unix) soient chargées dynamiquement ; c'est le défaut sous Unix, mais pas sous Windows. Ensuite, parce que sous Windows, il faut utiliser des extensions du langage pour rendre les symboles visibles ; sous Unix, tout est toujours visible avec dlsym, et on choisit lors du chargement si les symboles sont autrement visibles. (Pour un plugin, évidemment, on choisit que non. Ce qui n'est pas le défaut.)
Et il y a des contraintes qui font douter de l'utilité.
lesquelles?
La principale est l'absence d'appel direct à l'OS. Même l'utilisation de la bibliothèque standard (en particulier les templates) pose un beau problème.
Encore, je ne comprends pas. J'utilise assez régulièrement depuis peu des plugin dans mon propre code, sans le moindre problème (sauf l'histoire de l'ordre de destruction).
La seule contrainte que je connais, c'est que les bibliothèques « système » soient liées dynamiquement. Mais au moins chez Sun, c'est une contrainte générale depuis au moins Sun OS 4.x -- Sun ne garantit la compatibilité ascendante que pour les bibliothèques liées dynamiquement.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Richard Delorme wrote:
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows? quelles differences y a il? quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit sur les entrées standards (std::cin et std::cout), et l'application principale se lie au plugin par des tubes (pipes).
Je ne crois pas qu'on appelle ça un plugin ; si oui, je fais des plugin depuis vingt ans.
Mais tu as bien raison de rappeler qu'il y a des alternatifs autres que les objets liés dynamiquement. On pourrait bien imaginer un processus à part, qui travaille sur des données en mémoire partagée (ou un fichier mmappé). Ce qui a l'avantage d'être bien plus robuste qu'une module liées dynamiquement.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Richard Delorme wrote:
je cherche a savoir si les .so sont pour linux la meme chose
que les .dll sous windows? quelles differences y a il?
quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est
différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit
sur les entrées standards (std::cin et std::cout), et
l'application principale se lie au plugin par des tubes
(pipes).
Je ne crois pas qu'on appelle ça un plugin ; si oui, je fais des
plugin depuis vingt ans.
Mais tu as bien raison de rappeler qu'il y a des alternatifs
autres que les objets liés dynamiquement. On pourrait bien
imaginer un processus à part, qui travaille sur des données en
mémoire partagée (ou un fichier mmappé). Ce qui a l'avantage
d'être bien plus robuste qu'une module liées dynamiquement.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
je cherche a savoir si les .so sont pour linux la meme chose que les .dll sous windows? quelles differences y a il? quelles difference dans la gestion dans le programme?
Des principes sont similaires, mais le fonctionnement interne est différent.
y a il un autre moyen de faire des "plugins" qui soit multi-os?
Une manière simple consiste à faire un plugin qui lit et écrit sur les entrées standards (std::cin et std::cout), et l'application principale se lie au plugin par des tubes (pipes).
Je ne crois pas qu'on appelle ça un plugin ; si oui, je fais des plugin depuis vingt ans.
Mais tu as bien raison de rappeler qu'il y a des alternatifs autres que les objets liés dynamiquement. On pourrait bien imaginer un processus à part, qui travaille sur des données en mémoire partagée (ou un fichier mmappé). Ce qui a l'avantage d'être bien plus robuste qu'une module liées dynamiquement.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
