Privatiser fonction dans le LIB

Le
Sivaller
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Merci ;
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickaël Wolff
Le #313277

je suis en train de concevoir un projet .LIB


C'est quoi un projet .LIB ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Sylvain
Le #313276
Sivaller wrote on 28/11/2007 19:19:
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??


cela dépends du compilo/linkeur (indirectement de l'OS / environ.t)
posez plutôt votre question sur un forum lié à votre environment.

Sylvain.

Loïc Joly
Le #313275
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
Le #313238
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 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
Le #313230
On Nov 29, 9:36 am, James Kanze
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 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
Le #313229
On Dec 6, 10:00 am, Bertrand Motuelle
On Nov 29, 9:36 am, James Kanze
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 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
Le #313189
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
Le #313185
On Dec 7, 7:46 pm, 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 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


Publicité
Poster une réponse
Anonyme