fileBox

James Kanze

16/10/2004 à 13:54

3dsman writes:

|> >> Sauf erreur ou omission de ma part, la librairie standard du C++
|> >> n'offre pas ala possibilité de parcourir une rborescence. La
|> >> librairie C peut disposer ddes fonctions _findfirst et _findnext.
|> >> Ces fonctions sont en générales Uisponibles sous Windows, mais
|> >> n'étant pas normalisées, rien ne nous assure tqu'elles soient
|> >> disponibles sous NIX-Linux. Il faut donc envisager de parcourir
|> >> l'arborescence au moyen d'appels systèmes, avec la surcharge de
|> >> ravail et le risque d'erreur que cela implique.

C'est pas tout à fait vrai ce qui est écrit là. La bibliothèque C ne
dispose pas des fonctions _findfirst et _findnext. Ces fonctions font
partie de l'API Windows, et ne seront en général pas disponibles
ailleurs.

|> et je ne comprend pas l'histoire de disponibilité sous linux. Ca
|> veux dire que sous certain linux ca ne compilera pas? et si je
|> compile avec un linux ca fonctionnera sous les autres ou pas?

Si tu utilises _findfirst et _findnext, je doute que ça compile du tout
sous Linux.

Posix définit des fonctions opendir, readdir et closedir. Il y a des
fonctions du même nom disponible sous Linux ; je ne sais pas si la
version Linux est compatible Posix, mais a priori, je m'y attendrais.
(Les signatures s'y ressemblent comme deux gouttes d'eau.) Il est
probable que des fonctions semblables soient aussi disponible sous
Windows ; Windows essaie souvent d'offrir une couche à peu près
semblable à Unix.

|> Je suis toujours ouvert a toute bonne idée :-)

La solution que j'utilise : je définis une interface, c-à-d dans ce
cas-ci, un fichier .hh avec une définition d'une classe (dans mon cas,
qui s'appelle File, et qui s'inspire de la classe du même nom dans Java)
qui se sert de l'idiome du pare-feu de compilation (afin que la
définition visible aux utilisateurs n'ait besoin de rien qui dépend du
système). Ensuite, j'ai deux implémentations de la classe (dans deux .cc
différente, dans deux répertoires différents), une pour Windows, et une
pour Unix. Quand je compile pour Windows, je compile l'implémentation
dans le répertoire Windows ; quand je compile pour Unix, celle dans le
répertoire Unix. (En fait, l'implémentation Windows se fait attendre,
parce que je n'en ai pas besoin.)

--
James Kanze
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

3dsman <3dsman@free.fr> writes:

|> >> Sauf erreur ou omission de ma part, la librairie standard du C++
|> >> n'offre pas ala possibilité de parcourir une rborescence. La
|> >> librairie C peut disposer ddes fonctions _findfirst et _findnext.
|> >> Ces fonctions sont en générales Uisponibles sous Windows, mais
|> >> n'étant pas normalisées, rien ne nous assure tqu'elles soient
|> >> disponibles sous NIX-Linux. Il faut donc envisager de parcourir
|> >> l'arborescence au moyen d'appels systèmes, avec la surcharge de
|> >> ravail et le risque d'erreur que cela implique.

C'est pas tout à fait vrai ce qui est écrit là. La bibliothèque C ne
dispose pas des fonctions _findfirst et _findnext. Ces fonctions font
partie de l'API Windows, et ne seront en général pas disponibles
ailleurs.

|> et je ne comprend pas l'histoire de disponibilité sous linux. Ca
|> veux dire que sous certain linux ca ne compilera pas? et si je
|> compile avec un linux ca fonctionnera sous les autres ou pas?

Si tu utilises _findfirst et _findnext, je doute que ça compile du tout
sous Linux.

Posix définit des fonctions opendir, readdir et closedir. Il y a des
fonctions du même nom disponible sous Linux ; je ne sais pas si la
version Linux est compatible Posix, mais a priori, je m'y attendrais.
(Les signatures s'y ressemblent comme deux gouttes d'eau.) Il est
probable que des fonctions semblables soient aussi disponible sous
Windows ; Windows essaie souvent d'offrir une couche à peu près
semblable à Unix.

|> Je suis toujours ouvert a toute bonne idée :-)

La solution que j'utilise : je définis une interface, c-à-d dans ce
cas-ci, un fichier .hh avec une définition d'une classe (dans mon cas,
qui s'appelle File, et qui s'inspire de la classe du même nom dans Java)
qui se sert de l'idiome du pare-feu de compilation (afin que la
définition visible aux utilisateurs n'ait besoin de rien qui dépend du
système). Ensuite, j'ai deux implémentations de la classe (dans deux .cc
différente, dans deux répertoires différents), une pour Windows, et une
pour Unix. Quand je compile pour Windows, je compile l'implémentation
dans le répertoire Windows ; quand je compile pour Unix, celle dans le
répertoire Unix. (En fait, l'implémentation Windows se fait attendre,
parce que je n'en ai pas besoin.)

--
James Kanze
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

Vous avez filtré cet utilisateur ! Consultez son message

3dsman writes:

|> >> Sauf erreur ou omission de ma part, la librairie standard du C++
|> >> n'offre pas ala possibilité de parcourir une rborescence. La
|> >> librairie C peut disposer ddes fonctions _findfirst et _findnext.
|> >> Ces fonctions sont en générales Uisponibles sous Windows, mais
|> >> n'étant pas normalisées, rien ne nous assure tqu'elles soient
|> >> disponibles sous NIX-Linux. Il faut donc envisager de parcourir
|> >> l'arborescence au moyen d'appels systèmes, avec la surcharge de
|> >> ravail et le risque d'erreur que cela implique.

C'est pas tout à fait vrai ce qui est écrit là. La bibliothèque C ne
dispose pas des fonctions _findfirst et _findnext. Ces fonctions font
partie de l'API Windows, et ne seront en général pas disponibles
ailleurs.

|> et je ne comprend pas l'histoire de disponibilité sous linux. Ca
|> veux dire que sous certain linux ca ne compilera pas? et si je
|> compile avec un linux ca fonctionnera sous les autres ou pas?

Si tu utilises _findfirst et _findnext, je doute que ça compile du tout
sous Linux.

Posix définit des fonctions opendir, readdir et closedir. Il y a des
fonctions du même nom disponible sous Linux ; je ne sais pas si la
version Linux est compatible Posix, mais a priori, je m'y attendrais.
(Les signatures s'y ressemblent comme deux gouttes d'eau.) Il est
probable que des fonctions semblables soient aussi disponible sous
Windows ; Windows essaie souvent d'offrir une couche à peu près
semblable à Unix.

|> Je suis toujours ouvert a toute bonne idée :-)

La solution que j'utilise : je définis une interface, c-à-d dans ce
cas-ci, un fichier .hh avec une définition d'une classe (dans mon cas,
qui s'appelle File, et qui s'inspire de la classe du même nom dans Java)
qui se sert de l'idiome du pare-feu de compilation (afin que la
définition visible aux utilisateurs n'ait besoin de rien qui dépend du
système). Ensuite, j'ai deux implémentations de la classe (dans deux .cc
différente, dans deux répertoires différents), une pour Windows, et une
pour Unix. Quand je compile pour Windows, je compile l'implémentation
dans le répertoire Windows ; quand je compile pour Unix, celle dans le
répertoire Unix. (En fait, l'implémentation Windows se fait attendre,
parce que je n'en ai pas besoin.)

--
James Kanze
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

James Kanze

16/10/2004 à 14:01

3dsman writes:

|> heu g une question subsidiaire:

|> Tous les linux utilisent les memes fonctions pour parcourir
|> l'arboréscence?

|> et heu c quoi ces fonctions?

Autant que je sache, Linux essaie d'être Posix conforme ici. Selon
Posix, les fonctions s'appellent opendir, readdir, rewinddir et
closedir. Voir à http://www.unix.org/single_unix_specification/, ou
démander dans un groupe Unix pour plus de détails.

Il y a aussi une fonction ftw() (file tree walk), qui pourrait être
utile dans certains cas.

--
James Kanze
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

drkm

16/10/2004 à 21:02

James Kanze writes:

La solution que j'utilise : je définis une interface, c-à-d dans ce
cas-ci, un fichier .hh avec une définition d'une classe (dans mon cas,
qui s'appelle File, et qui s'inspire de la classe du même nom dans Java)

Tiens, je ne l'ai pas trouvée dans la gabi-lib. Est-elle sur ton
site ?

Ensuite, j'ai deux implémentations de la classe (dans deux .cc
différente

Tu veux dire deux .mcc, j'imagine ?-)

--drkm

Fabien LE LEZ

16/10/2004 à 21:05

On Sat, 16 Oct 2004 21:02:20 +0200, drkm :

Tu veux dire deux .mcc, j'imagine ?-)

Désolé d'arriver comme un épagneul breton dans un jeu de quilles s'il
s'agit d'une inside joke, mais... c'est quoi un .mcc ?

--
;-)

drkm

16/10/2004 à 22:09

Fabien LE LEZ writes:

On Sat, 16 Oct 2004 21:02:20 +0200, drkm :

Tu veux dire deux .mcc, j'imagine ?-)

Désolé d'arriver comme un épagneul breton dans un jeu de quilles s'il
s'agit d'une inside joke

En effet, un peu.

mais... c'est quoi un .mcc ?

James utilise une série d'extensions différentes dans la gabi-lib.
D'après ce que j'ai compris (James, j'aurais peut-être dû te laisser
répondre ; mais je te laisse corriger ...), et de mémoire, donc
peut-être pas exhaustif :

· .icc : implémentation des fonctions inlines ; ce fichier est
inclus à la fin de l'en-tête exportable .hh ;

· .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
rencontré dans la gabi-lib ;

· .k{cc,hh} : idem ;

· .l{cc,hh} : fichiers « locaux » ; on a par exemple Class.hh dans
le répertoire des en-têtes exportables, Class.cc dans le
répertoire des sources (implémentation de l'en-tête), Class.lhh
dans le même répertoire des sources, qui déclare des éléments de
support à l'implémentation dans Class.cc, et toujours dans le
même répertoire Class.lcc omplémentant Class.lhh ;

· .m{cc,hh} : fichiers dépendants de l'architecture (architecture
matérielle, OS, et/ou compilateur) ;

· .tcc : est aux templates ce que les .icc sont aux fonctions
inlines.

Sous réserves de corrections par James.

--drkm

James Kanze

17/10/2004 à 15:51

drkm writes:

|> James Kanze writes:

|> > La solution que j'utilise : je définis une interface, c-à-d dans
|> > ce cas-ci, un fichier .hh avec une définition d'une classe (dans
|> > mon cas, qui s'appelle File, et qui s'inspire de la classe du même
|> > nom dans Java)

|> Tiens, je ne l'ai pas trouvée dans la gabi-lib. Est-elle sur ton
|> site ?

Non. Elle ne date que depuis peu.

En fait, j'ai un certain nombre de classes de ce genre qui ne se trouve
pas sur ma site. Surtout parce que leur seul véritable intérêt, c'est de
résoudre un problème de portabilité, et donc, qu'elles n'ont d'intérêt
que si je les aie réelement porté, et à l'époque où j'ai installé ma
site, je n'avais pas accès à une machine non Unix.

Actuellement, j'ai bien accès à une machine Windows avec VC++ (6.0). À
l'occasion, je chercherai à les porter. Mais il faut dire que je ne
connais pas l'API de Windows particulièrement bien, ce qui rend le
portage parfois difficile.

|> > Ensuite, j'ai deux implémentations de la classe (dans
|> > deux .cc différente

|> Tu veux dire deux .mcc, j'imagine ?-)

En fait, où je suis maintenant, ça serait bien deux .cc. Mais il est
probable que s'il arrive à ma site, ça serait bien deux .mcc. D'une
côté, j'aimerais bien me libérer du .cc quasiment vide, mais de l'autre,
je n'ai pas encore trouvé de solution plus simple, et ça marche.

(Pour ceux qui ne suivent pas trop : drkm a manifestement régardé le
code à ma site. Et il a rémarqué que quand j'ai une implémentation qui
dépend du système, j'ai un .cc qui ne contient que #include
"whatever.mcc" -- .mcc signifiant, chez moi, le « machine cc ». Ce qui
permet la selection de l'implémentation au moyen d'une option -I.)

--
James Kanze
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

James Kanze

17/10/2004 à 16:17

drkm writes:

|> Fabien LE LEZ writes:

|> > On Sat, 16 Oct 2004 21:02:20 +0200, drkm
|> > :

|> >> Tu veux dire deux .mcc, j'imagine ?-)

|> > Désolé d'arriver comme un épagneul breton dans un jeu de quilles
|> > s'il s'agit d'une inside joke

|> En effet, un peu.

|> > mais... c'est quoi un .mcc ?

|> James utilise une série d'extensions différentes dans la gabi-lib.
|> D'après ce que j'ai compris (James, j'aurais peut-être dû te laisser
|> répondre ; mais je te laisse corriger ...),

Surtout, quand on régarde le code à mon site, il ne faut pas perdre de
vue que c'est un résultat historique. Il y a donc des réliquats qui
ne correspondent pas forcement à ce que je ferais aujourd'hui. Et en ce
qui concerne le .mcc, c'est une solution qui ne me satisfait pas
pleinement. (Mais pour l'instant, je n'ai pas trouvé mieux.)

|> et de mémoire, donc
|> peut-être pas exhaustif :

|> · .icc : implémentation des fonctions inlines ; ce fichier est
|> inclus à la fin de l'en-tête exportable .hh ;

C'est .icc ou .ihh, selon l'époque. Aujourd'hui, c'est plutôt .ihh.

|> · .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
|> rencontré dans la gabi-lib ;

|> · .k{cc,hh} : idem ;

C'était deux noms créés surtout sur le modèle de .ihh, parce qu'il m'en
fallait d'autres. D'après mes souvenirs, les .jhh était inclus avant la
définition de la classe, quand la définition de la classe avait besoin
des définitions globales qui ne concernait pas l'utilisateur -- le but,
c'était simplement de mettre ces définitions quelque part où il ne
genait pas. Le .khh, c'était dans les rares cas où j'avais besoin d'une
include quelque part au milieu. (Dans le temps, il m'était même arriver
de faire un #include au plein milieu d'une classe.)

Je ne crois que ni l'un ni l'autre apparaissent dans mon code récent.

|> · .l{cc,hh} : fichiers « locaux » ; on a par exemple Class.hh dans
|> le répertoire des en-têtes exportables, Class.cc dans le
|> répertoire des sources (implémentation de l'en-tête), Class.lhh
|> dans le même répertoire des sources, qui déclare des éléments de
|> support à l'implémentation dans Class.cc, et toujours dans le
|> même répertoire Class.lcc omplémentant Class.lhh ;

Tout à fait. Un .lhh ne serait jamais exporté. (Je ne crois pas qu'il y
a des .lcc.)

|> · .m{cc,hh} : fichiers dépendants de l'architecture (architecture
|> matérielle, OS, et/ou compilateur) ;

Au départ, le m signifiait « machine ». Aujourd'hui, il s'avère qu'il y
a surtout des dépendences du compilateur ou du système. Encore que des
choses comme StackTrace.mcc dépend plus du hardware que d'autres choses.

|> · .tcc : est aux templates ce que les .icc sont aux fonctions
|> inlines.

Exacte. C'est une innovation assez récente (par rapport aux autres) chez
moi, franchement copié de g++ (ou de Boost, je ne me rappelle jamais
lequel).

Dans mon code le plus récent, les .jhh et .khh sont plutôt remplacé par
l'idiome du pare-feu compilationnel -- non seulement j'isole pour
l'utilisateur, mais pour le compilateur aussi. Et les .ihh ont tendance
à diminuire dans la mésure où je me sers de moins en moins des fonctions
inline. En revanche, les .mhh/.mcc y sont toujours, et les .tcc ont
tendance à augmenter (en attendant export).

Donc, si on considère une classe un peu compliquée, GB_RegExpr :

- Au départ, il avait un .jhh (je crois, mais je ne me rappelle plus
pourquoi) et surtout, un .khh, inclue au plein milieu de la classe,
pour définir des classes imbriquées du genre ParseTree, NFA et DFA.
Et un .ihh avec beaucoup de fonctions inline.

- Aujourd'hui, elle se sert de l'idiome du pare-feu de compilation --
il y a donc surtout un .lhh qui définit GB_RegExpr::Impl. Et les
classes imbriquées sont imbriquées dans GB_RegExpr::Impl ; il n'y a
donc pas de problème pour les « cacher » de l'utilisateur, et donc,
pas de .jhh ni de .khh. Il y a eu aussi une version sans fonctions
inline, donc sans .ihh. En revanche, en essayant de m'adapter à la
STL, il est apparu une ou deux fonctions template -- et un .tcc.

- Entre les deux, il y a eu un certain nombre de variants.

--
James Kanze
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

drkm <usenet.fclcxx@fgeorges.org> writes:

|> Fabien LE LEZ <gramster@gramster.com> writes:

|> > On Sat, 16 Oct 2004 21:02:20 +0200, drkm
|> > <usenet.fclcxx@fgeorges.org>:

|> >> Tu veux dire deux .mcc, j'imagine ?-)

|> > Désolé d'arriver comme un épagneul breton dans un jeu de quilles
|> > s'il s'agit d'une inside joke

|> En effet, un peu.

|> > mais... c'est quoi un .mcc ?

|> James utilise une série d'extensions différentes dans la gabi-lib.
|> D'après ce que j'ai compris (James, j'aurais peut-être dû te laisser
|> répondre ; mais je te laisse corriger ...),

Surtout, quand on régarde le code à mon site, il ne faut pas perdre de
vue que c'est un résultat historique. Il y a donc des réliquats qui
ne correspondent pas forcement à ce que je ferais aujourd'hui. Et en ce
qui concerne le .mcc, c'est une solution qui ne me satisfait pas
pleinement. (Mais pour l'instant, je n'ai pas trouvé mieux.)

|> et de mémoire, donc
|> peut-être pas exhaustif :

|> · .icc : implémentation des fonctions inlines ; ce fichier est
|> inclus à la fin de l'en-tête exportable .hh ;

C'est .icc ou .ihh, selon l'époque. Aujourd'hui, c'est plutôt .ihh.

|> · .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
|> rencontré dans la gabi-lib ;

|> · .k{cc,hh} : idem ;

C'était deux noms créés surtout sur le modèle de .ihh, parce qu'il m'en
fallait d'autres. D'après mes souvenirs, les .jhh était inclus avant la
définition de la classe, quand la définition de la classe avait besoin
des définitions globales qui ne concernait pas l'utilisateur -- le but,
c'était simplement de mettre ces définitions quelque part où il ne
genait pas. Le .khh, c'était dans les rares cas où j'avais besoin d'une
include quelque part au milieu. (Dans le temps, il m'était même arriver
de faire un #include au plein milieu d'une classe.)

Je ne crois que ni l'un ni l'autre apparaissent dans mon code récent.

|> · .l{cc,hh} : fichiers « locaux » ; on a par exemple Class.hh dans
|> le répertoire des en-têtes exportables, Class.cc dans le
|> répertoire des sources (implémentation de l'en-tête), Class.lhh
|> dans le même répertoire des sources, qui déclare des éléments de
|> support à l'implémentation dans Class.cc, et toujours dans le
|> même répertoire Class.lcc omplémentant Class.lhh ;

Tout à fait. Un .lhh ne serait jamais exporté. (Je ne crois pas qu'il y
a des .lcc.)

|> · .m{cc,hh} : fichiers dépendants de l'architecture (architecture
|> matérielle, OS, et/ou compilateur) ;

Au départ, le m signifiait « machine ». Aujourd'hui, il s'avère qu'il y
a surtout des dépendences du compilateur ou du système. Encore que des
choses comme StackTrace.mcc dépend plus du hardware que d'autres choses.

|> · .tcc : est aux templates ce que les .icc sont aux fonctions
|> inlines.

Exacte. C'est une innovation assez récente (par rapport aux autres) chez
moi, franchement copié de g++ (ou de Boost, je ne me rappelle jamais
lequel).

Dans mon code le plus récent, les .jhh et .khh sont plutôt remplacé par
l'idiome du pare-feu compilationnel -- non seulement j'isole pour
l'utilisateur, mais pour le compilateur aussi. Et les .ihh ont tendance
à diminuire dans la mésure où je me sers de moins en moins des fonctions
inline. En revanche, les .mhh/.mcc y sont toujours, et les .tcc ont
tendance à augmenter (en attendant export).

Donc, si on considère une classe un peu compliquée, GB_RegExpr :

- Au départ, il avait un .jhh (je crois, mais je ne me rappelle plus
pourquoi) et surtout, un .khh, inclue au plein milieu de la classe,
pour définir des classes imbriquées du genre ParseTree, NFA et DFA.
Et un .ihh avec beaucoup de fonctions inline.

- Aujourd'hui, elle se sert de l'idiome du pare-feu de compilation --
il y a donc surtout un .lhh qui définit GB_RegExpr::Impl. Et les
classes imbriquées sont imbriquées dans GB_RegExpr::Impl ; il n'y a
donc pas de problème pour les « cacher » de l'utilisateur, et donc,
pas de .jhh ni de .khh. Il y a eu aussi une version sans fonctions
inline, donc sans .ihh. En revanche, en essayant de m'adapter à la
STL, il est apparu une ou deux fonctions template -- et un .tcc.

- Entre les deux, il y a eu un certain nombre de variants.

--
James Kanze
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

Vous avez filtré cet utilisateur ! Consultez son message

drkm writes:

|> Fabien LE LEZ writes:

|> > On Sat, 16 Oct 2004 21:02:20 +0200, drkm
|> > :

|> >> Tu veux dire deux .mcc, j'imagine ?-)

|> > Désolé d'arriver comme un épagneul breton dans un jeu de quilles
|> > s'il s'agit d'une inside joke

|> En effet, un peu.

|> > mais... c'est quoi un .mcc ?

|> James utilise une série d'extensions différentes dans la gabi-lib.
|> D'après ce que j'ai compris (James, j'aurais peut-être dû te laisser
|> répondre ; mais je te laisse corriger ...),

Surtout, quand on régarde le code à mon site, il ne faut pas perdre de
vue que c'est un résultat historique. Il y a donc des réliquats qui
ne correspondent pas forcement à ce que je ferais aujourd'hui. Et en ce
qui concerne le .mcc, c'est une solution qui ne me satisfait pas
pleinement. (Mais pour l'instant, je n'ai pas trouvé mieux.)

|> et de mémoire, donc
|> peut-être pas exhaustif :

|> · .icc : implémentation des fonctions inlines ; ce fichier est
|> inclus à la fin de l'en-tête exportable .hh ;

C'est .icc ou .ihh, selon l'époque. Aujourd'hui, c'est plutôt .ihh.

|> · .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
|> rencontré dans la gabi-lib ;

|> · .k{cc,hh} : idem ;

C'était deux noms créés surtout sur le modèle de .ihh, parce qu'il m'en
fallait d'autres. D'après mes souvenirs, les .jhh était inclus avant la
définition de la classe, quand la définition de la classe avait besoin
des définitions globales qui ne concernait pas l'utilisateur -- le but,
c'était simplement de mettre ces définitions quelque part où il ne
genait pas. Le .khh, c'était dans les rares cas où j'avais besoin d'une
include quelque part au milieu. (Dans le temps, il m'était même arriver
de faire un #include au plein milieu d'une classe.)

Je ne crois que ni l'un ni l'autre apparaissent dans mon code récent.

|> · .l{cc,hh} : fichiers « locaux » ; on a par exemple Class.hh dans
|> le répertoire des en-têtes exportables, Class.cc dans le
|> répertoire des sources (implémentation de l'en-tête), Class.lhh
|> dans le même répertoire des sources, qui déclare des éléments de
|> support à l'implémentation dans Class.cc, et toujours dans le
|> même répertoire Class.lcc omplémentant Class.lhh ;

Tout à fait. Un .lhh ne serait jamais exporté. (Je ne crois pas qu'il y
a des .lcc.)

|> · .m{cc,hh} : fichiers dépendants de l'architecture (architecture
|> matérielle, OS, et/ou compilateur) ;

Au départ, le m signifiait « machine ». Aujourd'hui, il s'avère qu'il y
a surtout des dépendences du compilateur ou du système. Encore que des
choses comme StackTrace.mcc dépend plus du hardware que d'autres choses.

|> · .tcc : est aux templates ce que les .icc sont aux fonctions
|> inlines.

Exacte. C'est une innovation assez récente (par rapport aux autres) chez
moi, franchement copié de g++ (ou de Boost, je ne me rappelle jamais
lequel).

Dans mon code le plus récent, les .jhh et .khh sont plutôt remplacé par
l'idiome du pare-feu compilationnel -- non seulement j'isole pour
l'utilisateur, mais pour le compilateur aussi. Et les .ihh ont tendance
à diminuire dans la mésure où je me sers de moins en moins des fonctions
inline. En revanche, les .mhh/.mcc y sont toujours, et les .tcc ont
tendance à augmenter (en attendant export).

Donc, si on considère une classe un peu compliquée, GB_RegExpr :

- Au départ, il avait un .jhh (je crois, mais je ne me rappelle plus
pourquoi) et surtout, un .khh, inclue au plein milieu de la classe,
pour définir des classes imbriquées du genre ParseTree, NFA et DFA.
Et un .ihh avec beaucoup de fonctions inline.

- Aujourd'hui, elle se sert de l'idiome du pare-feu de compilation --
il y a donc surtout un .lhh qui définit GB_RegExpr::Impl. Et les
classes imbriquées sont imbriquées dans GB_RegExpr::Impl ; il n'y a
donc pas de problème pour les « cacher » de l'utilisateur, et donc,
pas de .jhh ni de .khh. Il y a eu aussi une version sans fonctions
inline, donc sans .ihh. En revanche, en essayant de m'adapter à la
STL, il est apparu une ou deux fonctions template -- et un .tcc.

- Entre les deux, il y a eu un certain nombre de variants.

--
James Kanze
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

drkm

17/10/2004 à 19:42

James Kanze writes:

drkm writes:

|> · .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
|> rencontré dans la gabi-lib ;

|> · .k{cc,hh} : idem ;

C'était deux noms créés surtout sur le modèle de .ihh, parce qu'il m'en
fallait d'autres. D'après mes souvenirs, les .jhh était inclus avant la
définition de la classe, quand la définition de la classe avait besoin
des définitions globales qui ne concernait pas l'utilisateur -- le but,
c'était simplement de mettre ces définitions quelque part où il ne
genait pas. Le .khh, c'était dans les rares cas où j'avais besoin d'une
include quelque part au milieu. (Dans le temps, il m'était même arriver
de faire un #include au plein milieu d'une classe.)

Si je me souviens bien, StackTrace.hh incluait un fichier dans la
définition même de StackTrace (mais il me semble qu'il s'agissait d'un
.mhh). Cela ne m'avait pas choqué.

--drkm

3dsman

17/10/2004 à 19:59

3dsman writes:

heu g une question subsidiaire:

Tous les linux utilisent les memes fonctions pour parcourir
l'arboréscence?

et heu c quoi ces fonctions?

Autant que je sache, Linux essaie d'être Posix conforme ici. Selon
Posix, les fonctions s'appellent opendir, readdir, rewinddir et
closedir. Voir à http://www.unix.org/single_unix_specification/, ou
démander dans un groupe Unix pour plus de détails.

Il y a aussi une fonction ftw() (file tree walk), qui pourrait être
utile dans certains cas.

et pour macOSX ? c pareil non ?
Donc j'aurais que deux versions a faire?

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

James Kanze

17/10/2004 à 22:55

drkm writes:

|> James Kanze writes:

|> > drkm writes:

|> > |> · .j{cc,hh} : je ne me souviens plus, mais pense bien l'avoir
|> > |> rencontré dans la gabi-lib ;

|> > |> · .k{cc,hh} : idem ;

|> > C'était deux noms créés surtout sur le modèle de .ihh, parce qu'il
|> > m'en fallait d'autres. D'après mes souvenirs, les .jhh était
|> > inclus avant la définition de la classe, quand la définition de la
|> > classe avait besoin des définitions globales qui ne concernait pas
|> > l'utilisateur -- le but, c'était simplement de mettre ces
|> > définitions quelque part où il ne genait pas. Le .khh, c'était
|> > dans les rares cas où j'avais besoin d'une include quelque part au
|> > milieu. (Dans le temps, il m'était même arriver de faire un
|> > #include au plein milieu d'une classe.)

|> Si je me souviens bien, StackTrace.hh incluait un fichier dans la
|> définition même de StackTrace (mais il me semble qu'il s'agissait
|> d'un .mhh). Cela ne m'avait pas choqué.

C'est possible, au moins à un certain époque. StackTrace doit bien
savior le type d'une adresse de rétour, vue que c'est qu'il mémorise. Et
ce type dépend fortement de l'architecture du système.

La version la plus récente de StackTrace utilise un typedef global pour
ce type, et include ReturnAddress.hh avant de commencer la définition
de la classe, mais je ne crois pas qu'il a toujours été ainsi, et je ne
sais pas exactement quelle version est sur ma site actuellement.

--
James Kanze
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

fileBox

10 réponses

Veuillez sélectionner un problème