je suis en train de concevoir un projet .LIB
je suis en train de concevoir un projet .LIB
je suis en train de concevoir un projet .LIB
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
Bonjour,
je suis en train de concevoir un projet .LIB
je souhaite exporter certaine fonction mais rendre privé les autres ;
comment on fait ??
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() {...}
}
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() {...}
}
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() {...}
}
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.
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.
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.
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
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
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
[...] 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.
[...] 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.
[...] 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 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.
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.
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.