j'ai un vieux code qui contient un fstream file suivi d'un tres joli
file.rdbuf()->fd() permettant de recuperer le file descriptor sur d
anciens compilo. Le tout est suivi d'un lockf(descripteur, ...) qui est
le but de l' operation :)
probleme, cela n est faisable que parceque les fstream etaient bases sur
les FILE, ce qui est un peu hors norme...
quelle est la meilleur solution de remplacement ?
la plus evidente et la moins c++ serait amha de rfemplacer les fstream
par des FILE* fichier et hop j'ai mon file descripteur
Et mes commentaires s'adressaient non seulement à ton problème précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de chose. Rien ne l'aurait empéché d'ajouter un tyepdef system_specific_low_level_file_handle_t, et quelques fonctions pour le connecter à un filebuf ou en recupérer celui dont se sert le filebuf. Ensuite, évidemment, tout ce que je fais avec ce type dépend de l'implémentation, mais c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont éloignées des extentions standard « de facto » de ces systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
Et mes commentaires s'adressaient non seulement à ton problème
précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de
chose. Rien ne l'aurait empéché d'ajouter un tyepdef
system_specific_low_level_file_handle_t, et quelques
fonctions pour le connecter à un filebuf ou en recupérer
celui dont se sert le filebuf. Ensuite, évidemment, tout ce
que je fais avec ce type dépend de l'implémentation, mais
c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont
éloignées des extentions standard « de facto » de ces
systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles
j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose
filebuf::fd()
Et mes commentaires s'adressaient non seulement à ton problème précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de chose. Rien ne l'aurait empéché d'ajouter un tyepdef system_specific_low_level_file_handle_t, et quelques fonctions pour le connecter à un filebuf ou en recupérer celui dont se sert le filebuf. Ensuite, évidemment, tout ce que je fais avec ce type dépend de l'implémentation, mais c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont éloignées des extentions standard « de facto » de ces systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
James Kanze
On Feb 7, 12:39 pm, Michel Decima wrote:
Et mes commentaires s'adressaient non seulement à ton problème précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de chose. Rien ne l'aurait empéché d'ajouter un tyepdef system_specific_low_level_file_handle_t, et quelques fonctions pour le connecter à un filebuf ou en recupérer celui dont se sert le filebuf. Ensuite, évidemment, tout ce que je fais avec ce type dépend de l'implémentation, mais c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont éloignées des extentions standard « de facto » de ces systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
Ce qui n'en fait que deux:-). G++, c'est celui que je connaissais. xlC, c'est sans doute à cause de la même raison : ils ont remplacé leur implémentation traditionnelle avec une complètement nouvelle, que quelqu'un a implémenté selon la norme, sans tenir compte de l'environement où il allait servir, ni de l'historique, ni des utilisateurs. (Quand je me servais d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a prèsque dix ans, et l'implémentation des iostream à l'époque était encore celui de USL.)
-- 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 Feb 7, 12:39 pm, Michel Decima <michel.dec...@orange-ft.com> wrote:
Et mes commentaires s'adressaient non seulement à ton problème
précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de
chose. Rien ne l'aurait empéché d'ajouter un tyepdef
system_specific_low_level_file_handle_t, et quelques
fonctions pour le connecter à un filebuf ou en recupérer
celui dont se sert le filebuf. Ensuite, évidemment, tout ce
que je fais avec ce type dépend de l'implémentation, mais
c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont
éloignées des extentions standard « de facto » de ces
systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles
j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose
filebuf::fd()
Ce qui n'en fait que deux:-). G++, c'est celui que je
connaissais. xlC, c'est sans doute à cause de la même raison :
ils ont remplacé leur implémentation traditionnelle avec une
complètement nouvelle, que quelqu'un a implémenté selon la
norme, sans tenir compte de l'environement où il allait servir,
ni de l'historique, ni des utilisateurs. (Quand je me servais
d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a
prèsque dix ans, et l'implémentation des iostream à l'époque
était encore celui de USL.)
--
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
Et mes commentaires s'adressaient non seulement à ton problème précis, mais aussi aux certains regrets généraux que j'ai :
-- Que la norme n'a pas fourni un « hook » pour ce genre de chose. Rien ne l'aurait empéché d'ajouter un tyepdef system_specific_low_level_file_handle_t, et quelques fonctions pour le connecter à un filebuf ou en recupérer celui dont se sert le filebuf. Ensuite, évidemment, tout ce que je fais avec ce type dépend de l'implémentation, mais c'est à moi de décider si c'est un problème ou non.
Effectivement, c'est un peu dommage.
-- Que des implémentations sous Unix (une, au moins) se sont éloignées des extentions standard « de facto » de ces systèmes, et ont ôté la fonction filebuf::fd().
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
Ce qui n'en fait que deux:-). G++, c'est celui que je connaissais. xlC, c'est sans doute à cause de la même raison : ils ont remplacé leur implémentation traditionnelle avec une complètement nouvelle, que quelqu'un a implémenté selon la norme, sans tenir compte de l'environement où il allait servir, ni de l'historique, ni des utilisateurs. (Quand je me servais d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a prèsque dix ans, et l'implémentation des iostream à l'époque était encore celui de USL.)
-- 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
Michel Decima
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
Ce qui n'en fait que deux:-).
Ca depend comment on compte. J'ai fait le test g++ sur les deux plateformes, parce qu'il y aurait pu avoir un comportement provenant par exemple d'une consanguinité avec la glibc sous linux. Mais ce n'est pas le cas, donc tu compte juste ;)
G++, c'est celui que je connaissais. xlC, c'est sans doute à cause de la même raison : ils ont remplacé leur implémentation traditionnelle avec une complètement nouvelle, que quelqu'un a implémenté selon la norme, sans tenir compte de l'environement où il allait servir, ni de l'historique, ni des utilisateurs. (Quand je me servais d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a prèsque dix ans, et l'implémentation des iostream à l'époque était encore celui de USL.)
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998. Licensed to IBM Corp. and its suppliers. Copyright (c) 1994-1999 by P.J. Plauger.
Cette version date un peu, il doit y avoir des versions plus recentes avec l'ajout de filebuf::fd(). Bizaremment, je n'arrive pas a acceder au site dinkumware.com, donc je ne peux pas verifier dans la doc). M'enfin bon, s'il y avait quelque-chose a modifier dans cette bibliotheque, c'est pas le fd() qui me vient a l'esprit, mais plutot les performances (std::map en particulier).
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles
j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose
filebuf::fd()
Ce qui n'en fait que deux:-).
Ca depend comment on compte. J'ai fait le test g++ sur les deux
plateformes, parce qu'il y aurait pu avoir un comportement provenant
par exemple d'une consanguinité avec la glibc sous linux. Mais ce n'est
pas le cas, donc tu compte juste ;)
G++, c'est celui que je
connaissais. xlC, c'est sans doute à cause de la même raison :
ils ont remplacé leur implémentation traditionnelle avec une
complètement nouvelle, que quelqu'un a implémenté selon la
norme, sans tenir compte de l'environement où il allait servir,
ni de l'historique, ni des utilisateurs. (Quand je me servais
d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a
prèsque dix ans, et l'implémentation des iostream à l'époque
était encore celui de USL.)
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998.
Licensed to IBM Corp. and its suppliers.
Copyright (c) 1994-1999 by P.J. Plauger.
Cette version date un peu, il doit y avoir des versions plus
recentes avec l'ajout de filebuf::fd(). Bizaremment, je n'arrive pas a
acceder au site dinkumware.com, donc je ne peux pas verifier dans la
doc). M'enfin bon, s'il y avait quelque-chose a modifier dans cette
bibliotheque, c'est pas le fd() qui me vient a l'esprit, mais plutot
les performances (std::map en particulier).
Il y en a plus d'une, et a vrai dire aucune de celles auxquelles j'ai acces ici (xlC-6/AIX, g++-4.1/AIX, g++-4.1/Linux) ne propose filebuf::fd()
Ce qui n'en fait que deux:-).
Ca depend comment on compte. J'ai fait le test g++ sur les deux plateformes, parce qu'il y aurait pu avoir un comportement provenant par exemple d'une consanguinité avec la glibc sous linux. Mais ce n'est pas le cas, donc tu compte juste ;)
G++, c'est celui que je connaissais. xlC, c'est sans doute à cause de la même raison : ils ont remplacé leur implémentation traditionnelle avec une complètement nouvelle, que quelqu'un a implémenté selon la norme, sans tenir compte de l'environement où il allait servir, ni de l'historique, ni des utilisateurs. (Quand je me servais d'xlC, il supportait bien filebuf::fd(). Mais c'était il y a prèsque dix ans, et l'implémentation des iostream à l'époque était encore celui de USL.)
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998. Licensed to IBM Corp. and its suppliers. Copyright (c) 1994-1999 by P.J. Plauger.
Cette version date un peu, il doit y avoir des versions plus recentes avec l'ajout de filebuf::fd(). Bizaremment, je n'arrive pas a acceder au site dinkumware.com, donc je ne peux pas verifier dans la doc). M'enfin bon, s'il y avait quelque-chose a modifier dans cette bibliotheque, c'est pas le fd() qui me vient a l'esprit, mais plutot les performances (std::map en particulier).
James Kanze
Michel Decima wrote:
[...]
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998. Licensed to IBM Corp. and its suppliers. Copyright (c) 1994-1999 by P.J. Plauger.
Il me semble l'avoir entendu, oui.
Cette version date un peu, il doit y avoir des versions plus recentes avec l'ajout de filebuf::fd().
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware sert bien aussi en dehors des Unix. Je doute donc que cette fonction apparaisse dans sa branche principale. J'imagine, en revanche, que si IBM le démandait, Plauger l'ajouterait pour eux.
-- 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
Michel Decima wrote:
[...]
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998.
Licensed to IBM Corp. and its suppliers.
Copyright (c) 1994-1999 by P.J. Plauger.
Il me semble l'avoir entendu, oui.
Cette version date un peu, il doit y avoir des versions plus
recentes avec l'ajout de filebuf::fd().
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware
sert bien aussi en dehors des Unix. Je doute donc que cette
fonction apparaisse dans sa branche principale. J'imagine, en
revanche, que si IBM le démandait, Plauger l'ajouterait pour
eux.
--
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
La bibliothèque standard C++ de xlC-6 est celle de Plauger:
Dinkum C++ Library - Copyright (c) 1998. Licensed to IBM Corp. and its suppliers. Copyright (c) 1994-1999 by P.J. Plauger.
Il me semble l'avoir entendu, oui.
Cette version date un peu, il doit y avoir des versions plus recentes avec l'ajout de filebuf::fd().
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware sert bien aussi en dehors des Unix. Je doute donc que cette fonction apparaisse dans sa branche principale. J'imagine, en revanche, que si IBM le démandait, Plauger l'ajouterait pour eux.
-- 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
Michel Decima
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware sert bien aussi en dehors des Unix. Je doute donc que cette fonction apparaisse dans sa branche principale. J'imagine, en revanche, que si IBM le démandait, Plauger l'ajouterait pour eux.
Oui, je sais qu'elle est utilisee ailleurs (VC++ je crois). Quand je disais que des versions plus recentes pouvaient proposer filebuf::fd(), je faisait bien reference a la version IBM (ou les versions POSIX en general). Et effectivement, ce n'est absolument pas obligatoire.
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware
sert bien aussi en dehors des Unix. Je doute donc que cette
fonction apparaisse dans sa branche principale. J'imagine, en
revanche, que si IBM le démandait, Plauger l'ajouterait pour
eux.
Oui, je sais qu'elle est utilisee ailleurs (VC++ je crois). Quand
je disais que des versions plus recentes pouvaient proposer
filebuf::fd(), je faisait bien reference a la version IBM (ou les
versions POSIX en general). Et effectivement, ce n'est absolument
pas obligatoire.
Ce n'est pas dit. N'oublie pas que la bibliothèque Dinkumware sert bien aussi en dehors des Unix. Je doute donc que cette fonction apparaisse dans sa branche principale. J'imagine, en revanche, que si IBM le démandait, Plauger l'ajouterait pour eux.
Oui, je sais qu'elle est utilisee ailleurs (VC++ je crois). Quand je disais que des versions plus recentes pouvaient proposer filebuf::fd(), je faisait bien reference a la version IBM (ou les versions POSIX en general). Et effectivement, ce n'est absolument pas obligatoire.
