Bonjour, je suis en train de concevoir un projet .LIB je souhaite exporter certaine fonction mais rendre privé les autres ; comment on fait ??
Je ne sais pas trop ce que tu entends par privé, mais peut-être qu'un namespace anonyme est ce que tu souhaites :
namespace { int f() {...} }
-- Loïc
James Kanze
On Nov 29, 8:25 am, Loïc Joly wrote:
je suis en train de concevoir un projet .LIB je souhaite exporter certaine fonction mais rendre privé les autres ; comment on fait ??
Je ne sais pas trop ce que tu entends par privé, mais peut-être qu'un namespace anonyme est ce que tu souhaites :
namespace { int f() {...}
}
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
Dans certains cas, on pourrait simuler cette fonctionalité en mettant toute la bibliothèque dans une seule classe, avec public et private. Mais en général, c'est lourd.
Dans la pratique, je me contente d'un espace référentiel avec un nom particulier, non documenter. (J'utilise en général quelque chose du genre <library>Private.) Les déclarations globales dans cet espace référentiel sont déclarées dans un en-tête non exporté, auquel l'utilisateur n'a pas accès. Les symboles qui s'y trouvent sont bien visibles à l'éditeur de liens, mais l'utilisateur n'a aucun moyen de savoir d'avance ce qui est disponible.
-- James Kanze (GABI Software) email: 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
On Nov 29, 8:25 am, Loïc Joly <loic.actarus.j...@numericable.fr>
wrote:
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Je ne sais pas trop ce que tu entends par privé, mais peut-être qu'un
namespace anonyme est ce que tu souhaites :
namespace {
int f() {...}
}
Ou éventuellement static (mais le namespace anonyme est mieux).
Les deux ne marche qu'à l'intérieur d'une seule unité de
traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose
(mais même ça n'est pas certain) que par << projet .LIB >>, il
entend un composant qui comporte des entêtes et une bibliothèque
(linkée statiquement ?). Dans ce cas, la question a un sens,
mais la réponse, au moins avec des éditeurs de liens classiques,
c'est que ce n'est pas possible. L'édition de liens entre les
fichiers objets d'une bibliothèque ne se fait que lors de
l'édition de liens finale, qui lie la bibliothèque à la reste de
l'application. Et je ne connais pas d'éditeur de liens qui a une
fonctionalité permettant un symbole à être visible dans d'autres
objets de la même bibliothèque, mais pas ailleurs.
Dans certains cas, on pourrait simuler cette fonctionalité en
mettant toute la bibliothèque dans une seule classe, avec public
et private. Mais en général, c'est lourd.
Dans la pratique, je me contente d'un espace référentiel avec un
nom particulier, non documenter. (J'utilise en général quelque
chose du genre <library>Private.) Les déclarations globales dans
cet espace référentiel sont déclarées dans un en-tête non
exporté, auquel l'utilisateur n'a pas accès. Les symboles qui
s'y trouvent sont bien visibles à l'éditeur de liens, mais
l'utilisateur n'a aucun moyen de savoir d'avance ce qui est
disponible.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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 suis en train de concevoir un projet .LIB je souhaite exporter certaine fonction mais rendre privé les autres ; comment on fait ??
Je ne sais pas trop ce que tu entends par privé, mais peut-être qu'un namespace anonyme est ce que tu souhaites :
namespace { int f() {...}
}
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
Dans certains cas, on pourrait simuler cette fonctionalité en mettant toute la bibliothèque dans une seule classe, avec public et private. Mais en général, c'est lourd.
Dans la pratique, je me contente d'un espace référentiel avec un nom particulier, non documenter. (J'utilise en général quelque chose du genre <library>Private.) Les déclarations globales dans cet espace référentiel sont déclarées dans un en-tête non exporté, auquel l'utilisateur n'a pas accès. Les symboles qui s'y trouvent sont bien visibles à l'éditeur de liens, mais l'utilisateur n'a aucun moyen de savoir d'avance ce qui est disponible.
-- James Kanze (GABI Software) email: 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
Bertrand Motuelle
On Nov 29, 9:36 am, James Kanze wrote:
On Nov 29, 8:25 am, Loïc Joly wrote:
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble que les outils GNU et SUN (sun studio version >= 8) permettent de réaliser ce genre de choses (visibilité 'hidden'): http://gcc.gnu.org/wiki/Visibility http://developers.sun.com/solaris/articles/symbol_scope.html
A+, Bertrand.
On Nov 29, 9:36 am, James Kanze <james.ka...@gmail.com> wrote:
On Nov 29, 8:25 am, Loïc Joly <loic.actarus.j...@numericable.fr>
wrote:
Ou éventuellement static (mais le namespace anonyme est mieux).
Les deux ne marche qu'à l'intérieur d'une seule unité de
traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose
(mais même ça n'est pas certain) que par << projet .LIB >>, il
entend un composant qui comporte des entêtes et une bibliothèque
(linkée statiquement ?). Dans ce cas, la question a un sens,
mais la réponse, au moins avec des éditeurs de liens classiques,
c'est que ce n'est pas possible. L'édition de liens entre les
fichiers objets d'une bibliothèque ne se fait que lors de
l'édition de liens finale, qui lie la bibliothèque à la reste de
l'application. Et je ne connais pas d'éditeur de liens qui a une
fonctionalité permettant un symbole à être visible dans d'autres
objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble que les
outils GNU et SUN (sun studio version >= 8) permettent de réaliser ce
genre de choses (visibilité 'hidden'):
http://gcc.gnu.org/wiki/Visibility
http://developers.sun.com/solaris/articles/symbol_scope.html
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble que les outils GNU et SUN (sun studio version >= 8) permettent de réaliser ce genre de choses (visibilité 'hidden'): http://gcc.gnu.org/wiki/Visibility http://developers.sun.com/solaris/articles/symbol_scope.html
A+, Bertrand.
James Kanze
On Dec 6, 10:00 am, Bertrand Motuelle wrote:
On Nov 29, 9:36 am, James Kanze wrote:
On Nov 29, 8:25 am, Loïc Joly wrote:
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble que les outils GNU et SUN (sun studio version >= 8) permettent de réaliser ce genre de choses (visibilité 'hidden'):http://gcc.gnu.org/wiki/Visibilityhttp://developers.sun.com/sola ris/articles/symbol_scope.html
Je n'ai pas lu les articles en détail, mais d'après le peu que j'ai vu, ces limitations de visibilité ne concerne que des objets dynamiques (les .so sous Unix). Dans ce cas-là, ce n'est vraiment pas quelque chose de nouveau : l'éditeur de liens de Sun supporte des mapfiles depuis longtemps (et il ne sont pas si difficile à utiliser en C++ que l'article que tu cites fait croire), et VC++ a toujours insisté que les symboles visible dans une DLL soit marqués explicitement. Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
-- James Kanze (GABI Software) email: 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
On Dec 6, 10:00 am, Bertrand Motuelle
<bertrand.motue...@googlemail.com> wrote:
On Nov 29, 9:36 am, James Kanze <james.ka...@gmail.com> wrote:
On Nov 29, 8:25 am, Loïc Joly <loic.actarus.j...@numericable.fr>
wrote:
Ou éventuellement static (mais le namespace anonyme est mieux).
Les deux ne marche qu'à l'intérieur d'une seule unité de
traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose
(mais même ça n'est pas certain) que par << projet .LIB >>, il
entend un composant qui comporte des entêtes et une bibliothèque
(linkée statiquement ?). Dans ce cas, la question a un sens,
mais la réponse, au moins avec des éditeurs de liens classiques,
c'est que ce n'est pas possible. L'édition de liens entre les
fichiers objets d'une bibliothèque ne se fait que lors de
l'édition de liens finale, qui lie la bibliothèque à la reste de
l'application. Et je ne connais pas d'éditeur de liens qui a une
fonctionalité permettant un symbole à être visible dans d'autres
objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble
que les outils GNU et SUN (sun studio version >= 8) permettent
de réaliser ce genre de choses (visibilité
'hidden'):http://gcc.gnu.org/wiki/Visibilityhttp://developers.sun.com/sola ris/articles/symbol_scope.html
Je n'ai pas lu les articles en détail, mais d'après le peu que
j'ai vu, ces limitations de visibilité ne concerne que des
objets dynamiques (les .so sous Unix). Dans ce cas-là, ce n'est
vraiment pas quelque chose de nouveau : l'éditeur de liens de
Sun supporte des mapfiles depuis longtemps (et il ne sont pas si
difficile à utiliser en C++ que l'article que tu cites fait
croire), et VC++ a toujours insisté que les symboles visible
dans une DLL soit marqués explicitement. Mais en général, on
évite les éditions de liens quand elles ne sont pas nécessaire,
et sauf certains cas spéciaux et bien précis (les bases de
données, par exemple), utiliser le chargement dynamique pour les
bibliothèques tièrces, c'est chercher des problèmes.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
Ou éventuellement static (mais le namespace anonyme est mieux). Les deux ne marche qu'à l'intérieur d'une seule unité de traduction, en revanche.
C'est n'est pas trop clair ce qu'il veut exactement. Je suppose (mais même ça n'est pas certain) que par << projet .LIB >>, il entend un composant qui comporte des entêtes et une bibliothèque (linkée statiquement ?). Dans ce cas, la question a un sens, mais la réponse, au moins avec des éditeurs de liens classiques, c'est que ce n'est pas possible. L'édition de liens entre les fichiers objets d'une bibliothèque ne se fait que lors de l'édition de liens finale, qui lie la bibliothèque à la reste de l'application. Et je ne connais pas d'éditeur de liens qui a une fonctionalité permettant un symbole à être visible dans d'autres objets de la même bibliothèque, mais pas ailleurs.
A moins que je n'ai pas bien compris ton propos, il me semble que les outils GNU et SUN (sun studio version >= 8) permettent de réaliser ce genre de choses (visibilité 'hidden'):http://gcc.gnu.org/wiki/Visibilityhttp://developers.sun.com/sola ris/articles/symbol_scope.html
Je n'ai pas lu les articles en détail, mais d'après le peu que j'ai vu, ces limitations de visibilité ne concerne que des objets dynamiques (les .so sous Unix). Dans ce cas-là, ce n'est vraiment pas quelque chose de nouveau : l'éditeur de liens de Sun supporte des mapfiles depuis longtemps (et il ne sont pas si difficile à utiliser en C++ que l'article que tu cites fait croire), et VC++ a toujours insisté que les symboles visible dans une DLL soit marqués explicitement. Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
-- James Kanze (GABI Software) email: 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
Sylvain
James Kanze wrote on 07/12/2007 12:12:
[...] Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ... tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur, l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a les mêmes exigences - et justement le lien à des libs tierces, parfois non redistribuables, parfois souvent patchées, gagne à être dynamique.
Sylvain.
James Kanze wrote on 07/12/2007 12:12:
[...] Mais en général, on
évite les éditions de liens quand elles ne sont pas nécessaire,
et sauf certains cas spéciaux et bien précis (les bases de
données, par exemple), utiliser le chargement dynamique pour les
bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ...
tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur,
l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a les
mêmes exigences - et justement le lien à des libs tierces, parfois non
redistribuables, parfois souvent patchées, gagne à être dynamique.
[...] Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ... tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur, l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a les mêmes exigences - et justement le lien à des libs tierces, parfois non redistribuables, parfois souvent patchées, gagne à être dynamique.
Sylvain.
James Kanze
On Dec 7, 7:46 pm, Sylvain wrote:
James Kanze wrote on 07/12/2007 12:12:
[...] Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ... tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur, l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a l es mêmes exigences - et justement le lien à des libs tierces, parfois non redistribuables, parfois souvent patchées, gagne à être dynamique.
C'est en effet une bonne façon de l'expliquer. À vrai dire, je n'étais pas encore arrivé à définir les critères si bien. C'était plutôt des considérations pragmatiques qui me pousser. Dans le cas des bases de données, la plus grande partie de la fonctionnalité se trouve dans des programmes à part, qui ne sont pas linkés avec l'application (dynamiquement ou d'autre), et qui servent à beaucoup d'applications. Si on linke statiquement, une mise à jour de la base de données implique une mise à jour de toutes ses applications, simultanément. Ce qui pose un problème logistique énorme.
Dans le cas des bibliothèques système, c'est en quelque sort l'inverse : ton programme doit fonctionner sur plusieurs machines, avec éventuellement de différentes versions de l'OS, etc.
Dans les deux cas, les fournisseurs (de la base de données, de l'OS) font des garanties en ce qui concerne la compatibilité, mais uniquement si tu utilises la bibliothèque dynamique. (Évidemment, ces garanties valent ce qu'elles valent, et on connaît des cas dans la passée... L'emmigration de Sun OS 4 à Solaris n'a pas toujours été facile.)
-- James Kanze (GABI Software) email: 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
On Dec 7, 7:46 pm, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 07/12/2007 12:12:
[...] Mais en général, on
évite les éditions de liens quand elles ne sont pas nécessaire,
et sauf certains cas spéciaux et bien précis (les bases de
données, par exemple), utiliser le chargement dynamique pour les
bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ...
tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur,
l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a l es
mêmes exigences - et justement le lien à des libs tierces, parfois non
redistribuables, parfois souvent patchées, gagne à être dynamique.
C'est en effet une bonne façon de l'expliquer. À vrai dire, je
n'étais pas encore arrivé à définir les critères si bien.
C'était plutôt des considérations pragmatiques qui me pousser.
Dans le cas des bases de données, la plus grande partie de la
fonctionnalité se trouve dans des programmes à part, qui ne sont
pas linkés avec l'application (dynamiquement ou d'autre), et qui
servent à beaucoup d'applications. Si on linke statiquement, une
mise à jour de la base de données implique une mise à jour de
toutes ses applications, simultanément. Ce qui pose un problème
logistique énorme.
Dans le cas des bibliothèques système, c'est en quelque sort
l'inverse : ton programme doit fonctionner sur plusieurs
machines, avec éventuellement de différentes versions de l'OS,
etc.
Dans les deux cas, les fournisseurs (de la base de données, de
l'OS) font des garanties en ce qui concerne la compatibilité,
mais uniquement si tu utilises la bibliothèque dynamique.
(Évidemment, ces garanties valent ce qu'elles valent, et on
connaît des cas dans la passée... L'emmigration de Sun OS 4 à
Solaris n'a pas toujours été facile.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
[...] Mais en général, on évite les éditions de liens quand elles ne sont pas nécessaire, et sauf certains cas spéciaux et bien précis (les bases de données, par exemple), utiliser le chargement dynamique pour les bibliothèques tièrces, c'est chercher des problèmes.
c'est bien vrai ça ;)
enfin, il y a quand même des cas où cela sert ... tu cites les BdB j'imagine pour ""virtualiser"" l'accès au moteur, l'accès ""virtuel"" à du hard (eg périphériques d'acquisition) a l es mêmes exigences - et justement le lien à des libs tierces, parfois non redistribuables, parfois souvent patchées, gagne à être dynamique.
C'est en effet une bonne façon de l'expliquer. À vrai dire, je n'étais pas encore arrivé à définir les critères si bien. C'était plutôt des considérations pragmatiques qui me pousser. Dans le cas des bases de données, la plus grande partie de la fonctionnalité se trouve dans des programmes à part, qui ne sont pas linkés avec l'application (dynamiquement ou d'autre), et qui servent à beaucoup d'applications. Si on linke statiquement, une mise à jour de la base de données implique une mise à jour de toutes ses applications, simultanément. Ce qui pose un problème logistique énorme.
Dans le cas des bibliothèques système, c'est en quelque sort l'inverse : ton programme doit fonctionner sur plusieurs machines, avec éventuellement de différentes versions de l'OS, etc.
Dans les deux cas, les fournisseurs (de la base de données, de l'OS) font des garanties en ce qui concerne la compatibilité, mais uniquement si tu utilises la bibliothèque dynamique. (Évidemment, ces garanties valent ce qu'elles valent, et on connaît des cas dans la passée... L'emmigration de Sun OS 4 à Solaris n'a pas toujours été facile.)
-- James Kanze (GABI Software) email: 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
