C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  i18n et fstream          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message Loïc Joly Guest Posted: Mon Mar 06, 2006 10:06 pm    Post subject: i18n et fstream Bonjour à tous, Je suis sur un OS (windows XP) dont le système de fichiers utilise une variante d'unicode (UCS2, si j'ai bien suivi) pour gérer les noms de fichier. Sur cette même plateforme, les chars font 8 bits, et donc ne peuvent coder UCS2. Or, le constructeur d'un fstream prend en paramètre un char const*, qui ne peut donc gérer tous les noms de fichier permis par l'OS. Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. Seconde question : J'ai fait une recherche dans les defect reports, et j'y ai trouvé le DR105 (émis par l'AFNOR en 9 classé comme évolution future. Est-ce que quelqu'un a repris le flambeau depuis ? Merci, -- Loïc Back to top Gabriel Dos Reis Guest Posted: Mon Mar 06, 2006 10:06 pm    Post subject: Re: i18n et fstream Loïc Joly <loic.actarus.joly (AT) numericable (DOT) fr> writes: [ je n'ai pas de réponses à tes autres question ] [...] | Seconde question : J'ai fait une recherche dans les defect reports, et | j'y ai trouvé le DR105 (émis par l'AFNOR en 9 classé comme évolution | future. Est-ce que quelqu'un a repris le flambeau depuis ? Je ne crois pas. Mais je pense que tu pourrais soulever le problème en relation avec ceci http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1955.html -- Gaby Back to top Loïc Joly Guest Posted: Tue Mar 07, 2006 1:06 am    Post subject: Re: i18n et fstream Gabriel Dos Reis a écrit : Quote: Loïc Joly <loic.actarus.joly (AT) numericable (DOT) fr> writes: [ je n'ai pas de réponses à tes autres question ] [...] | Seconde question : J'ai fait une recherche dans les defect reports, et | j'y ai trouvé le DR105 (émis par l'AFNOR en 9 classé comme évolution | future. Est-ce que quelqu'un a repris le flambeau depuis ? Je ne crois pas. Mais je pense que tu pourrais soulever le problème en relation avec ceci http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1955.html Je vais lire ça. Je viens de voir http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1934.html qui a l'air de faire ce que je souhaite aussi (contrairement à boost::filesystem, dont est tiré cette proposition, qui pour l'instant ne supporte pas de jeu de caractère étendu). Je vais lire aussi plus en détails. -- Loïc Back to top kanze Guest Posted: Tue Mar 07, 2006 11:06 am    Post subject: Re: i18n et fstream Loïc Joly wrote: Quote: Je suis sur un OS (windows XP) dont le système de fichiers utilise une variante d'unicode (UCS2, si j'ai bien suivi) pour gérer les noms de fichier. Sur cette même plateforme, les chars font 8 bits, et donc ne peuvent coder UCS2. Or, le constructeur d'un fstream prend en paramètre un char const*, qui ne peut donc gérer tous les noms de fichier permis par l'OS. Bien sûr que si. L'UTF-8 existe. Il n'y a pas de solution portable, mais ce n'est pas du nouveau. Ce que c'est qu'un nom de fichier légal, et comment il se mappe sur les noms qu'on voit avec d'autres outils, dépend de l'implémentation. Depuis le C du K&R. Mais j'imagine que ton problème, c'est que tu obtiens un nom de fichier (de l'utilisateur, par exemple) sur des wchar_t, et que tu veux pouvoir l'utiliser, étant donné que le système aussi accepte des noms de fichiers sur wchar_t. Quote: Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. La bibliothèque de VC++ les supporte directement. -- James Kanze GABI Software 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 Back to top Jean-Marc Desperrier Guest Posted: Tue Mar 07, 2006 3:06 pm    Post subject: Re: i18n et fstream kanze wrote: Quote: Mais j'imagine que ton problème, c'est que tu obtiens un nom de fichier (de l'utilisateur, par exemple) sur des wchar_t, et que tu veux pouvoir l'utiliser, étant donné que le système aussi accepte des noms de fichiers sur wchar_t. Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas wchar_t. Et je ne vois aucune méthode portable pour passer directement de l'un à l'autre. Quote: Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. La bibliothèque de VC++ les supporte directement. Les fonctions wchar_t de VC++ ? Effectivement, msvcrt.dll importe la fonction native de l'OS pour ouvrir les fichiers avec des noms UTF16-LE, soit CreateFileW dans kernel32.dll, donc a la possibilité d'implémenter la partie "magique" nécessaire pour faire fonctionner cela, mais ce qui n'est pas garanti avec tout autre compilateur. Et après vérification, VC++ propose pour l'ouverture un tout à fait non-standard _wfopen avec argument en wchar_t. Il y a aussi un "open(const wchar_t *_Filename ..." dans son basic_ifstream qui me semble n'être absolument pas plus standard. Back to top kanze Guest Posted: Tue Mar 07, 2006 4:06 pm    Post subject: Re: i18n et fstream Jean-Marc Desperrier wrote: Quote: kanze wrote: Mais j'imagine que ton problème, c'est que tu obtiens un nom de fichier (de l'utilisateur, par exemple) sur des wchar_t, et que tu veux pouvoir l'utiliser, étant donné que le système aussi accepte des noms de fichiers sur wchar_t. Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas wchar_t. Et je ne vois aucune méthode portable pour passer directement de l'un à l'autre. Et qu'est-ce que tu as dans les wchar_t ? Sous Windows, les sources principales des chaînes en wchar_t sont donnent bien du UTF16. (Et le LE ne s'applique qu'aux chaînes d'octets. Dans un wchar_t de 16 bits, comme sous Windows, c'est UTF16 tout court.) La question, c'est d'où provient le nom de fichier. S'il l'a lu d'une requête système qui lui a donné du wchar_t, c'est du UTF16. Quote: Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. La bibliothèque de VC++ les supporte directement. Les fonctions wchar_t de VC++ ? Effectivement, msvcrt.dll importe la fonction native de l'OS pour ouvrir les fichiers avec des noms UTF16-LE, soit CreateFileW dans kernel32.dll, donc a la possibilité d'implémenter la partie "magique" nécessaire pour faire fonctionner cela, mais ce qui n'est pas garanti avec tout autre compilateur. Sans cette fonction, j'imagine que la question ne se poserait pas. Quote: Et après vérification, VC++ propose pour l'ouverture un tout à fait non-standard _wfopen avec argument en wchar_t. Je ne sais pas ce que veut dire « non-standard » ici. En général, les fonctions de l'API du système ne sont pas standard C++. Si j'inclus <unistd.h>, par exemple, sur les systèmes dont je me sers le plus, ou <pthread.h>, j'ai bien des fonctions non-standard du point de vue strictement C++. Heureusement. Quote: Il y a aussi un "open(const wchar_t *_Filename ..." dans son basic_ifstream qui me semble n'être absolument pas plus standard. Ce n'est pas défini par la norme, mais la norme dit explicitement que « An implementation can declare additional non-virtual member function signatures within a class: [...] by adding a member function signature for a member function name. » C'est donc une extension prévue et permise par la norme. -- James Kanze GABI Software 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 Back to top Loïc Joly Guest Posted: Tue Mar 07, 2006 9:06 pm    Post subject: Re: i18n et fstream kanze a écrit : Quote: Loïc Joly wrote: Bien sûr que si. L'UTF-8 existe. A ma (très faible) connaisance sur le sujet, windows n'utilise pas l'UTF8, et n'a aucune API qui le comprenne, mais uniquement le MBCS, encodage basé sur le même principe, mais encodé autrement pour lequel j'ai du mal à trouver des fonctions de conversions. Quote: Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. La bibliothèque de VC++ les supporte directement. Effectivement, en regardant le .h, j'ai vu que c'était supporté. J'ai été trompé par la doc : même si j'ai réussi finalement à trouver une doc qui l'indiquait (en spécifiant comme de bien entendu qu'il s'agit d'une extention), il y a d'autres docs sur le sujet qui n'en parlent pas. Je vais faire des tests demain. -- Loïc Back to top kanze Guest Posted: Wed Mar 08, 2006 8:06 am    Post subject: Re: i18n et fstream Loïc Joly wrote: Quote: kanze a écrit : Loïc Joly wrote: Bien sûr que si. L'UTF-8 existe. A ma (très faible) connaisance sur le sujet, windows n'utilise pas l'UTF8, et n'a aucune API qui le comprenne, mais uniquement le MBCS, encodage basé sur le même principe, mais encodé autrement pour lequel j'ai du mal à trouver des fonctions de conversions. En effet, autant que je sache, Windows ne connaît pas l'UTF-8 (mais je ne suis pas spécialiste de cette plateforme). Je prenais seulement exception à ta déclaration que puisque les char's ne font que 8 bits, ils ne peuvent pas encoder Unicode. La possibilité existe, même si la bibliothèque Windows ne s'en sert pas. -- James Kanze GABI Software 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 Back to top Richard Gill Guest Posted: Thu Mar 09, 2006 4:06 pm    Post subject: Re: i18n et fstream Loïc Joly a écrit : Quote: Bonjour à tous, Bonjour à toi (je suis tout nouveau sur ce groupe, alors soyez indulgents :-) Quote: Je suis sur un OS (windows XP) dont le système de fichiers utilise une variante d'unicode (UCS2, si j'ai bien suivi) pour gérer les noms de fichier. Je me suis justement renseigné sur toutes ces histoires d'encodage et comment passer de l'un à l'autre, ma réponse ne donnera pas la solution, mais peut-être des pistes. Le système de fichiers NTFS, tout comme le système Windows entier, utilise l'UCS2 comme représentation interne des caractères, et propose donc une programmation en UTF16 via son API WIN32 (API qui permet de définir un nom de fichier, à un bas niveau par exemple). Quote: Sur cette même plateforme, les chars font 8 bits, et donc ne peuvent coder UCS2. Or, le constructeur d'un fstream prend en paramètre un char const*, qui ne peut donc gérer tous les noms de fichier permis par l'OS. normal Quote: Première question : Quelqu'un connait-il une astuce non portable pour pouvoir quand même ouvrir un fichier y compris avec des caractères étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de lecture/écriture de fichiers dans un format propriétaire. L'astuce est soit de passer ton code en Unicode (en utilisant les variantes *w* des fonctions et classes liées aux chaînes de caractères), soit de faire une conversion MBCS (UTF-8 en gros), mais dans ce cas, ton programme devra être capable de gérer les caractères mutli-octets. Voici les références qui devraient t'aider: http://www.cl.cam.ac.uk/~mgk25/unicode.html - très bonne FAQ sur Unicode (orienté Unix mais très instructive, quelques snipsets intéressants) http://www.czyborra.com/utf - explication des UTF et quelques pistes Back to top kanze Guest Posted: Fri Mar 10, 2006 9:06 am    Post subject: Re: i18n et fstream Richard Gill wrote: Quote: Loïc Joly a écrit : Je suis sur un OS (windows XP) dont le système de fichiers utilise une variante d'unicode (UCS2, si j'ai bien suivi) pour gérer les noms de fichier. Je me suis justement renseigné sur toutes ces histoires d'encodage et comment passer de l'un à l'autre, ma réponse ne donnera pas la solution, mais peut-être des pistes. Si c'est pour expliquer qu'il y a un problème, je crois que Loïc en est au courant:-). Quote: Le système de fichiers NTFS, tout comme le système Windows entier, utilise l'UCS2 comme représentation interne des caractères, et propose donc une programmation en UTF16 via son API WIN32 (API qui permet de définir un nom de fichier, à un bas niveau par exemple). En es-tu sur ? D'après ce qu'il me semble avoir entendu dire, Windows était à l'origine UCS2, mais a été modifier pour supporter UTF-16. En ce qui concerne les fonctions qui gèrent les fichiers et leurs noms, cette modification était évidemment triviale -- on accepte des codes 0xD800 à 0xDFFF, qui ne sont pas lègaux en UCS2. -- James Kanze GABI Software 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 Back to top kanze Guest Posted: Fri Mar 10, 2006 9:06 am    Post subject: Re: i18n et fstream Richard Gill wrote: Quote: L'astuce est soit de passer ton code en Unicode (en utilisant les variantes *w* des fonctions et classes liées aux chaînes de caractères), soit de faire une conversion MBCS (UTF-8 en gros), mais dans ce cas, ton programme devra être capable de gérer les caractères mutli-octets. Si je ne me trompe pas, les wchar_t sous Windows sont UTF-16. Ce qui veut dire qu'il faut être capable de gérer les caractères composés là aussi. Quote: Voici les références qui devraient t'aider: http://www.cl.cam.ac.uk/~mgk25/unicode.html - très bonne FAQ sur Unicode (orienté Unix mais très instructive, quelques snipsets intéressants) Tout à fait. Aussi, http://www.unicode.org, tout bêtement. À commencer par la glossaire, et les nombreux rapports techniques. Quote: http://www.czyborra.com/utf - explication des UTF et quelques pistes Surtout, http://www.czyborra.com pour tous les encodages huit bits. -- James Kanze GABI Software 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 Back to top Jean-Marc Desperrier Guest Posted: Fri Mar 10, 2006 11:06 pm    Post subject: Re: i18n et fstream kanze wrote: Quote: Loïc Joly wrote: A ma (très faible) connaisance sur le sujet, windows n'utilise pas l'UTF8, et n'a aucune API qui le comprenne, mais uniquement le MBCS [...] En effet, autant que je sache, Windows ne connaît pas l'UTF-8 (mais je ne suis pas spécialiste de cette plateforme). Il est possible d'utiliser UTF8 à partir de windows 98, et d'un windows 95 sur lequel on installe IE. Explication un peu plus détaillée bien qu'HS ici : Les Windows de la famille 9x utilisent pour les appels à l'OS un jeu de caractères variables suivant les versions localisée pour chaque pays et qui dans certains cas nécessite plusieurs octets pour représenter un caractère. Historiquement, on utilise parfois MBCS pour désigner ce cas là. La famille NT utilise en natif UTF16LE (UCS2LE dans les versions anciennes). Il faut utiliser le couple de fonction MultiByteToWideChar/WideCharToMultiByte pour convertir de l'un vers l'autre, en précisant avec une constante CP_XXX lequel des divers encodages locaux utiliser pour le coté MultiByte. Et à partir de Windows 98, la constante CP_UTF8 est supportée pour faire que l'encodage "local" soit en réalité UTF-8 et convertir d'UTF16LE vers UTF8. Par contre il n'existe absolument aucune version localisée de Windows 9x dans laquelle UTF-8 serait le codage natif. Pour l'anecdote et illustrer le support applicatif, Notepad et Wordpad supportent UTF8, depuis W2000 pour Notepad et XP pour Wordpad. Back to top Jean-Marc Desperrier Guest Posted: Sat Mar 11, 2006 7:06 am    Post subject: Re: i18n et fstream kanze wrote: Quote: Jean-Marc Desperrier wrote: kanze wrote: Bonsoir, Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point. Quote: Mais j'imagine que ton problème, c'est que tu obtiens un nom de fichier (de l'utilisateur, par exemple) sur des wchar_t, et que tu veux pouvoir l'utiliser, étant donné que le système aussi accepte des noms de fichiers sur wchar_t. Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas wchar_t. Et je ne vois aucune méthode portable pour passer directement de l'un à l'autre. Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème. Quote: Et qu'est-ce que tu as dans les wchar_t ? "Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ... En général, sous Un*x, wchar_t est sur 4 octets en UTF32. Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète). Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode. Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode). Quote: Sous Windows, les sources principales des chaînes en wchar_t sont donnent bien du UTF16. (Et le LE ne s'applique qu'aux chaînes d'octets. Dans un wchar_t de 16 bits, comme sous Windows, c'est UTF16 tout court.) C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC. Back to top kanze Guest Posted: Mon Mar 13, 2006 10:06 am    Post subject: Re: i18n et fstream Jean-Marc Desperrier wrote: Quote: kanze wrote: Jean-Marc Desperrier wrote: kanze wrote: Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point. Mais j'imagine que ton problème, c'est que tu obtiens un nom de fichier (de l'utilisateur, par exemple) sur des wchar_t, et que tu veux pouvoir l'utiliser, étant donné que le système aussi accepte des noms de fichiers sur wchar_t. Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas wchar_t. Et je ne vois aucune méthode portable pour passer directement de l'un à l'autre. Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème. C'est vrai que je les ai oublié. Reste que C90 n'impose pas d'encodage -- même si UTF-8 semble un choix logique. En fait, le problème est plus tordu qu'il n'en apparaît au premier abord. D'une part, je m'attendrais à ce que le système supporte plusieurs encodages composés, selon le locale. Il faudrait donc s'assurer que le locale global de C est celui pour UTF-8 si on veut se servir de ces fonctions (et tripoter avec le locale global, que ce soit du C ou du C++, a des répercutions non negligeable dans un programme multi-thread). Ensuite, il ne faut pas perdre de vue que sous certains systèmes (Windows, AIX, probablement d'autres), wchar_t utilise aussi des caractères composés. Quote: Et qu'est-ce que tu as dans les wchar_t ? "Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ... Et de comment on choisit de l'interpréter dans le code:-). Quote: En général, sous Un*x, wchar_t est sur 4 octets en UTF32. En général, ça varie d'un Unix à l'autre, et du locale dont on se servent. Parmi les Unix que je connais, Solaris, HP/UX et Linux utilisent les wchar_t de 32 bits, AIX de 16 bits. Quant à l'encodage utilisé, c'est difficile à dire. Sous Solaris, iswxxxx() renvoie faux pour tout caractère non-ASCII ; std::ctype<wchar_t> aussi, avec g++ (4.0.2). (Les locales de Sun CC ne sont pas tout à fait conforme ; ne n'ai donc pû tester qu'avec g++ -- version 4.0.2. Mais je suppose que g++ utilise le libc du système pour iswxxxx(), et s'y base aussi pour std::ctype<wchar_t>.) C-à-d que l'encodage du wchar_t (32 bits) est l'ASCII (7 bits) ! Quote: Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète). Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode. Tout à fait, sauf que ce n'est pas si particulier que ça. Le problème, c'est que jusqu'à une époque assez récente, Unicode disait que 16 bits suffissaient. Les systèmes qui se sont mis à l'internationalisation standardisée tôt se sont fait avoir. Quote: Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode). Sous Windows, les sources principales des chaînes en wchar_t sont donnent bien du UTF16. (Et le LE ne s'applique qu'aux chaînes d'octets. Dans un wchar_t de 16 bits, comme sous Windows, c'est UTF16 tout court.) C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC. Je crois que tu as mal compris la signification de mon propos. Ce n'est pas du tout théorique -- quand tu travailles sous Windows, ou sous AIX, tu travailles sur des wchar_t en UTF-16. Et il n'y a pas de boutienisme. Du tout : un wchar_t est 16 bits, avec les bits du poids forts de la valeur sur les bits du poids forts, et les bits du poids faibles sur les bits du poids faible. Il n'y a que quand tu sors les wchar_t vers un support orienté octets que le boutienisme entre en ligne de compte : si tu fais : dest.put( (ch >> & 0xFF ) ; dest.put( ch & 0xFF ) ; tu sort des données en UTF-16BE. Que le hardware que tu utilises soit grand-boutien ou petit-boutien. Si j'ai bien compris, Windows offre aussi une interface système permettant de traiter des fichiers comme un support orienté 16 bits. Si ensuite tu le lis avec l'interface octets, j'imagine que tu verras bien du UTF-16LE. Mais franchement, c'est une chose que j'éviterais -- si j'écris avec l'interface 16 bits, c'est purement un fichier interne, qui serait lu avec la même interface. Qu'on le veuille ou non, le monde est orienté 8 bits, et même Microsoft n'arrivera pas à le changer. -- James Kanze GABI Software 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 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.