probleme avec namespace(?) et visual studio .net 2003

Luc Hermitte

10/01/2004 à 04:07

Bonsoir,

"Flzw" wrote in
news:btndt2$dov$:

j'avais ce bout de code simple simple sur visual c++ 6 qui
fonctionnait parfaitement :

ifstream* replayfile = new ifstream;
replayfile->open( FileName, ios::in | ios::nocreate | ios::binary);

C'est pas std::ios_base maintenant ?

--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>

Thierry Miceli

10/01/2004 à 09:01

ifstream* replayfile = new ifstream;
replayfile->open( FileName, ios::in | ios::nocreate | ios::binary);

Remplace ios par std::ios_base. Et puis également "nocreate" n'existe plus.

Loïc Joly

10/01/2004 à 09:34

Flzw wrote:

error C2039: 'nocreate' : n'est pas membre de
'std::basic_ios<_Elem,_Traits>'
with
[
_Elem=char,
_Traits=std::char_traits<char>
]

Le nocreate n'existe pas avec les nouveaux streams. Quand tu essaye
d'ouvrir un fichier en lecture, si le fichier n'existe pas, ton ifstream
n'est pas dans un état valide, c'est tout. Si tu préfères, sur un
std::ifstream, il y a le nocreate par défaut.

--
Loïc

James Kanze

11/01/2004 à 22:04

Loïc Joly writes:

|> Flzw wrote:
|> > error C2039: 'nocreate' : n'est pas membre de
|> > 'std::basic_ios<_Elem,_Traits>'
|> > with
|> > [
|> > _Elem=char,
|> > _Traits=std::char_traits<char>
|> > ]

|> Le nocreate n'existe pas avec les nouveaux streams.

Il n'existait pas de façon générale avec les anciens non plus.
A priori, un vendeur qui le fournissait avec les anciens doit les
fournir avec les nouveaux, à titre d'extension. Au moins qu'il se
moque des ces clients complètement.

|> Quand tu essaye d'ouvrir un fichier en lecture, si le fichier
|> n'existe pas, ton ifstream n'est pas dans un état valide, c'est
|> tout. Si tu préfères, sur un std::ifstream, il y a le nocreate
|> par défaut.

En revanche, l'option peut être utile dans le cas des flux
bidirectionnels.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

James Kanze

11/01/2004 à 22:04

Luc Hermitte writes:

|> "Flzw" wrote in
|> news:btndt2$dov$:

|> > j'avais ce bout de code simple simple sur visual c++ 6 qui
|> > fonctionnait parfaitement :

|> > ifstream* replayfile = new ifstream;
|> > replayfile->open( FileName, ios::in | ios::nocreate | ios::binary);

|> C'est pas std::ios_base maintenant ?

Pour des masochistes. Mais std::ios marche toujours.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Loïc Joly

12/01/2004 à 21:45

James Kanze wrote:

Loïc Joly writes:

|> Flzw wrote:
|> > error C2039: 'nocreate' : n'est pas membre de
|> > 'std::basic_ios<_Elem,_Traits>'
|> > with
|> > [
|> > _Elem=char,
|> > _Traits=std::char_traits<char>
|> > ]

|> Le nocreate n'existe pas avec les nouveaux streams.

Il n'existait pas de façon générale avec les anciens non plus.
A priori, un vendeur qui le fournissait avec les anciens doit les
fournir avec les nouveaux, à titre d'extension. Au moins qu'il se
moque des ces clients complètement.

J'ai du mal à voir pourquoi.

Autant je suis d'accord pour dire qu'un compilateur qui avait les
anciens flux se doit de toujours les avoir, autant j'ai du mal à voir ce
que tripaouiller les nouveaux flux avec certains éléments des anciens
(et quels éléments, en particulier ?) peut servir.

Soit l'utilisateur veut continuer avec les anciens flux, c'est son
droit, soit il veux passer aux nouveaux et alors présenter des
extensions non portable n'est pas lui rendre service.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers les
nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate dans
les nouveaux flux), son programme aura changé silentieusement de
comportement. Si maintenant il entreprend la tâche de relire son code,
enlever quelques nocreate inutiles n'est pas la mort.

--
Loïc

kanze

13/01/2004 à 12:06

Loïc Joly wrote in message
news:<btv0uo$9rt$...

James Kanze wrote:

Loïc Joly writes:

|> Flzw wrote:
|> > error C2039: 'nocreate' : n'est pas membre de
|> > 'std::basic_ios<_Elem,_Traits>'
|> > with
|> > [
|> > _Elem=char,
|> > _Traits=std::char_traits<char>
|> > ]

|> Le nocreate n'existe pas avec les nouveaux streams.

Il n'existait pas de façon générale avec les anciens non plus. A
priori, un vendeur qui le fournissait avec les anciens doit les
fournir avec les nouveaux, à titre d'extension. Au moins qu'il se
moque des ces clients complètement.

J'ai du mal à voir pourquoi.

A priori, pour la même raison qu'il l'a ajouté aux anciens.

Autant je suis d'accord pour dire qu'un compilateur qui avait les
anciens flux se doit de toujours les avoir, autant j'ai du mal à voir
ce que tripaouiller les nouveaux flux avec certains éléments des
anciens (et quels éléments, en particulier ?) peut servir.

Deux raisons :

- D'abord, les deux flux ne sont pas radicalement différents, et dans
la mesure qu'on n'a fait que des choses simples, on peut remplacer
les anciens flux par les nouveaux sans trop de modification du code
utilisateur.

- Si on a ajouté une extension dans les anciens flux, c'était sans
doute parce qu'elle correspondait à un besoin. Qui existe
probablement encore. Donc, la même motivation existe pour de
nouveaux flux.

Soit l'utilisateur veut continuer avec les anciens flux, c'est son
droit, soit il veux passer aux nouveaux et alors présenter des
extensions non portable n'est pas lui rendre service.

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

Dans ce cas précis, en supposant que l'utilisateur a eu besoin de cette
extension, il y a trois possibilités en ce qui concerne un nouveau
compilateur :

- implémenter la même extension dans les nouveaux flux,

- exiger l'utilisateur à retourner à un niveau plus bas, et utiliser
l'API Posix directement, ou

- ne supporter aucune extension, et forcer l'utilisateur à passer à un
autre compilateur, voire un autre langage.

La dernière correspond à la philosophie de Java. La deuxième est
répandue en C++, mais je ne vois pas où est le problème avec la
première, dans la mesure qu'il est bien documenté qu'il s'agit d'une
extension.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique. Sans
l'extension, comment l'obtenir ? La seule solution que je vois d'office,
c'est d'écrire son propre streambuf, qui le supporte. Mais qui serait à
99% près identique à filebuf.

AMHA, chez un fournisseur responsable, la norme en soi n'est pas une
fin. C'est la plupart du temps, un moyen pour rendre ses utilisateurs
plus efficace (parce qu'ils savent à quoi s'attendre, etc.). Mais elle
ne doivent pas servir d'excuse d'ôter des fonctionnalités utiles qui
existaient déjà.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<btv0uo$9rt$1@news-reader1.wanadoo.fr>...

James Kanze wrote:

Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:

|> Flzw wrote:
|> > error C2039: 'nocreate' : n'est pas membre de
|> > 'std::basic_ios<_Elem,_Traits>'
|> > with
|> > [
|> > _Elem=char,
|> > _Traits=std::char_traits<char>
|> > ]

|> Le nocreate n'existe pas avec les nouveaux streams.

Il n'existait pas de façon générale avec les anciens non plus. A
priori, un vendeur qui le fournissait avec les anciens doit les
fournir avec les nouveaux, à titre d'extension. Au moins qu'il se
moque des ces clients complètement.

J'ai du mal à voir pourquoi.

A priori, pour la même raison qu'il l'a ajouté aux anciens.

Autant je suis d'accord pour dire qu'un compilateur qui avait les
anciens flux se doit de toujours les avoir, autant j'ai du mal à voir
ce que tripaouiller les nouveaux flux avec certains éléments des
anciens (et quels éléments, en particulier ?) peut servir.

Deux raisons :

- D'abord, les deux flux ne sont pas radicalement différents, et dans
la mesure qu'on n'a fait que des choses simples, on peut remplacer
les anciens flux par les nouveaux sans trop de modification du code
utilisateur.

- Si on a ajouté une extension dans les anciens flux, c'était sans
doute parce qu'elle correspondait à un besoin. Qui existe
probablement encore. Donc, la même motivation existe pour de
nouveaux flux.

Soit l'utilisateur veut continuer avec les anciens flux, c'est son
droit, soit il veux passer aux nouveaux et alors présenter des
extensions non portable n'est pas lui rendre service.

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

Dans ce cas précis, en supposant que l'utilisateur a eu besoin de cette
extension, il y a trois possibilités en ce qui concerne un nouveau
compilateur :

- implémenter la même extension dans les nouveaux flux,

- exiger l'utilisateur à retourner à un niveau plus bas, et utiliser
l'API Posix directement, ou

- ne supporter aucune extension, et forcer l'utilisateur à passer à un
autre compilateur, voire un autre langage.

La dernière correspond à la philosophie de Java. La deuxième est
répandue en C++, mais je ne vois pas où est le problème avec la
première, dans la mesure qu'il est bien documenté qu'il s'agit d'une
extension.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique. Sans
l'extension, comment l'obtenir ? La seule solution que je vois d'office,
c'est d'écrire son propre streambuf, qui le supporte. Mais qui serait à
99% près identique à filebuf.

AMHA, chez un fournisseur responsable, la norme en soi n'est pas une
fin. C'est la plupart du temps, un moyen pour rendre ses utilisateurs
plus efficace (parce qu'ils savent à quoi s'attendre, etc.). Mais elle
ne doivent pas servir d'excuse d'ôter des fonctionnalités utiles qui
existaient déjà.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

Loïc Joly wrote in message
news:<btv0uo$9rt$...

James Kanze wrote:

Loïc Joly writes:

|> Flzw wrote:
|> > error C2039: 'nocreate' : n'est pas membre de
|> > 'std::basic_ios<_Elem,_Traits>'
|> > with
|> > [
|> > _Elem=char,
|> > _Traits=std::char_traits<char>
|> > ]

|> Le nocreate n'existe pas avec les nouveaux streams.

Il n'existait pas de façon générale avec les anciens non plus. A
priori, un vendeur qui le fournissait avec les anciens doit les
fournir avec les nouveaux, à titre d'extension. Au moins qu'il se
moque des ces clients complètement.

J'ai du mal à voir pourquoi.

A priori, pour la même raison qu'il l'a ajouté aux anciens.

Autant je suis d'accord pour dire qu'un compilateur qui avait les
anciens flux se doit de toujours les avoir, autant j'ai du mal à voir
ce que tripaouiller les nouveaux flux avec certains éléments des
anciens (et quels éléments, en particulier ?) peut servir.

Deux raisons :

- D'abord, les deux flux ne sont pas radicalement différents, et dans
la mesure qu'on n'a fait que des choses simples, on peut remplacer
les anciens flux par les nouveaux sans trop de modification du code
utilisateur.

- Si on a ajouté une extension dans les anciens flux, c'était sans
doute parce qu'elle correspondait à un besoin. Qui existe
probablement encore. Donc, la même motivation existe pour de
nouveaux flux.

Soit l'utilisateur veut continuer avec les anciens flux, c'est son
droit, soit il veux passer aux nouveaux et alors présenter des
extensions non portable n'est pas lui rendre service.

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

Dans ce cas précis, en supposant que l'utilisateur a eu besoin de cette
extension, il y a trois possibilités en ce qui concerne un nouveau
compilateur :

- implémenter la même extension dans les nouveaux flux,

- exiger l'utilisateur à retourner à un niveau plus bas, et utiliser
l'API Posix directement, ou

- ne supporter aucune extension, et forcer l'utilisateur à passer à un
autre compilateur, voire un autre langage.

La dernière correspond à la philosophie de Java. La deuxième est
répandue en C++, mais je ne vois pas où est le problème avec la
première, dans la mesure qu'il est bien documenté qu'il s'agit d'une
extension.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique. Sans
l'extension, comment l'obtenir ? La seule solution que je vois d'office,
c'est d'écrire son propre streambuf, qui le supporte. Mais qui serait à
99% près identique à filebuf.

AMHA, chez un fournisseur responsable, la norme en soi n'est pas une
fin. C'est la plupart du temps, un moyen pour rendre ses utilisateurs
plus efficace (parce qu'ils savent à quoi s'attendre, etc.). Mais elle
ne doivent pas servir d'excuse d'ôter des fonctionnalités utiles qui
existaient déjà.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Loïc Joly

13/01/2004 à 23:59

wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas, mais
c'est ce que me confirme la doc dinkumware)
Maintenant, si on veut faire des nouveaux flux avec un nocreate, que faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

[...]

--
Loïc

kanze@gabi-soft.fr wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas, mais
c'est ce que me confirme la doc dinkumware)
Maintenant, si on veut faire des nouveaux flux avec un nocreate, que faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

[...]

--
Loïc

Vous avez filtré cet utilisateur ! Consultez son message

wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers allégrément.
Est-ce que tu es sûr que le compilateur C++ doit interdire des threads,
des link dynamiques et l'utilisation d'un GUI ? Ce ne sont, après tout,
que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement de
comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas, mais
c'est ce que me confirme la doc dinkumware)
Maintenant, si on veut faire des nouveaux flux avec un nocreate, que faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

[...]

--
Loïc

kanze

14/01/2004 à 09:25

Loïc Joly wrote in message
news:<bu1t8o$fei$...

wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers
allégrément. Est-ce que tu es sûr que le compilateur C++ doit
interdire des threads, des link dynamiques et l'utilisation d'un GUI
? Ce ne sont, après tout, que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le
premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement
de comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas,
mais c'est ce que me confirme la doc dinkumware)

Je ne sais pas ce que dit la documentation Dinkumware. La norme mappe
les modes d'ouverture en modes de fopen. En faisant l'abstraction du
binaire (qui ajoute chaque fois un 'b' dans le mode de fopen), on peut
obtenir des modes "w", "a", "r", "r+" et "w+". D'après ISO 9899:1990
(mais ça n'a pas changé depuis C90), §7.19.5.3/3 :

r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create file for update

Ce qui manque un peu de précison (peut-être exprès, pour permettre
l'implémentation à conformer aux possibilités de la plateforme).
Surtout, il n'est jamais *interdit* de créer un fichier (et il me semble
systèmatiquement, même avec "r"). Et il y a toujours la question :
comment ouvrir un ficher pour écriture et lecture sans le modifier, mais
en le créant s'il n'existe pas ? Est-ce que ce n'est pas la
fonctionnalité souhaitée par "r+" ?

En tout cas, la spécification de la norme ici correspond à peu près à ce
que faisait les flux classiques. Dans les deux cas, je m'attendrais à
une certaine variance entre les implémentations. Et que la nouvelle
implémentation ait le même fonctionnement ici que l'ancienne.

Mais j'avoue que le fait que la norme *est* la norme, et
qu'implicitement, je dirais que l'intention, sinon ce qu'elle exige
impérativement, semblerait être que "r+" ne crée pas de fichier. Je
pourrais donc concevoir qu'une implémentation choisit de respecter cette
intention dans les nouveaux flux, même si les anciens fonctionnaient
différemment. Dans ce cas-là, l'option nocreate devient supérflue. Mais
je ne vois toujours pas où sa présence poserait un problème avec du code
existant. C'est plutôt les opérations qui ne s'en servent pas qui
changeront de la sémantique.

Maintenant, si on veut faire des nouveaux flux avec un nocreate, que
faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Le vrai problème ici, c'est comment faire dans le cas où on voulait la
création. Qu'on définit nocreate comme un no-op, pour que les anciens
programmes puissent compiler avec moins de modification, ne me semble
pas forcement mauvais.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

Tout à fait. C'est probablement la sémantique la plus démandée, et on ne
le supporte pas. Au moins qu'en prend la liberté de créer un fichier qui
n'existte pas quand on ouvre avec "r+".

(Dans la pratique, je me démande si c'est important. J'avoue ne jamais
avoir ouvrert un fichier autrement qu'en "r" or "w", ou l'équivalent
avec filebuf. Et ne jamais avoir fait un seek sur un flux non plus. En
général, quand on se met à faire des choses compliquer avec les accès
aléatoire, il faut passer à la couche système.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bu1t8o$fei$1@news-reader2.wanadoo.fr>...

kanze@gabi-soft.fr wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers
allégrément. Est-ce que tu es sûr que le compilateur C++ doit
interdire des threads, des link dynamiques et l'utilisation d'un GUI
? Ce ne sont, après tout, que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le
premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement
de comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas,
mais c'est ce que me confirme la doc dinkumware)

Je ne sais pas ce que dit la documentation Dinkumware. La norme mappe
les modes d'ouverture en modes de fopen. En faisant l'abstraction du
binaire (qui ajoute chaque fois un 'b' dans le mode de fopen), on peut
obtenir des modes "w", "a", "r", "r+" et "w+". D'après ISO 9899:1990
(mais ça n'a pas changé depuis C90), §7.19.5.3/3 :

r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create file for update

Ce qui manque un peu de précison (peut-être exprès, pour permettre
l'implémentation à conformer aux possibilités de la plateforme).
Surtout, il n'est jamais *interdit* de créer un fichier (et il me semble
systèmatiquement, même avec "r"). Et il y a toujours la question :
comment ouvrir un ficher pour écriture et lecture sans le modifier, mais
en le créant s'il n'existe pas ? Est-ce que ce n'est pas la
fonctionnalité souhaitée par "r+" ?

En tout cas, la spécification de la norme ici correspond à peu près à ce
que faisait les flux classiques. Dans les deux cas, je m'attendrais à
une certaine variance entre les implémentations. Et que la nouvelle
implémentation ait le même fonctionnement ici que l'ancienne.

Mais j'avoue que le fait que la norme *est* la norme, et
qu'implicitement, je dirais que l'intention, sinon ce qu'elle exige
impérativement, semblerait être que "r+" ne crée pas de fichier. Je
pourrais donc concevoir qu'une implémentation choisit de respecter cette
intention dans les nouveaux flux, même si les anciens fonctionnaient
différemment. Dans ce cas-là, l'option nocreate devient supérflue. Mais
je ne vois toujours pas où sa présence poserait un problème avec du code
existant. C'est plutôt les opérations qui ne s'en servent pas qui
changeront de la sémantique.

Maintenant, si on veut faire des nouveaux flux avec un nocreate, que
faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Le vrai problème ici, c'est comment faire dans le cas où on voulait la
création. Qu'on définit nocreate comme un no-op, pour que les anciens
programmes puissent compiler avec moins de modification, ne me semble
pas forcement mauvais.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

Tout à fait. C'est probablement la sémantique la plus démandée, et on ne
le supporte pas. Au moins qu'en prend la liberté de créer un fichier qui
n'existte pas quand on ouvre avec "r+".

(Dans la pratique, je me démande si c'est important. J'avoue ne jamais
avoir ouvrert un fichier autrement qu'en "r" or "w", ou l'équivalent
avec filebuf. Et ne jamais avoir fait un seek sur un flux non plus. En
général, quand on se met à faire des choses compliquer avec les accès
aléatoire, il faut passer à la couche système.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

Loïc Joly wrote in message
news:<bu1t8o$fei$...

wrote:

En es tu sûr ? J'avoue que les compilateurs C++ dont je me sers me
présentent beaucoup d'extensions portables, dont je me sers
allégrément. Est-ce que tu es sûr que le compilateur C++ doit
interdire des threads, des link dynamiques et l'utilisation d'un GUI
? Ce ne sont, après tout, que des extensions.

J'avoue avoir moins de problème avec des extentions se présentant sous
forme de nouvelles fonctions/classes qu'avec des extensions se
présentant comme nouvelle valeur possible d'un paramètre de fonction.
J'ai un peu plus l'impression que le second cas peut arriver dans un
programme par étourderie et non par choix plus facilement que le
premier.

Par exemple si à un moment l'utilisateur ouvrait un fichier sans le
nocreate, il en créait un. Si maintenant il porte son programme vers
les nouveaux flux sans le relire (ce qu'incite l'ajout d'un nocreate
dans les nouveaux flux), son programme aura changé silentieusement
de comportement.

Comment ?

C'est ce que j'essaye d'expliquer dessus, mais j'ai du mal me faire
comprendre, je réessaye :
Anciens flux :
- Rien : On crée s'il n'existe pas
- nocreate : On ne crée pas s'il n'existe pas
Nouveaux flux sans nocreate :
- On ne crée pas s'il n'existe pas
(Je n'ai pas retrouvé de ref dans mon exemplaire de la norme,
puisqu'elle fait référence à la norme C que je ne possède pas,
mais c'est ce que me confirme la doc dinkumware)

Je ne sais pas ce que dit la documentation Dinkumware. La norme mappe
les modes d'ouverture en modes de fopen. En faisant l'abstraction du
binaire (qui ajoute chaque fois un 'b' dans le mode de fopen), on peut
obtenir des modes "w", "a", "r", "r+" et "w+". D'après ISO 9899:1990
(mais ça n'a pas changé depuis C90), §7.19.5.3/3 :

r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create file for update

Ce qui manque un peu de précison (peut-être exprès, pour permettre
l'implémentation à conformer aux possibilités de la plateforme).
Surtout, il n'est jamais *interdit* de créer un fichier (et il me semble
systèmatiquement, même avec "r"). Et il y a toujours la question :
comment ouvrir un ficher pour écriture et lecture sans le modifier, mais
en le créant s'il n'existe pas ? Est-ce que ce n'est pas la
fonctionnalité souhaitée par "r+" ?

En tout cas, la spécification de la norme ici correspond à peu près à ce
que faisait les flux classiques. Dans les deux cas, je m'attendrais à
une certaine variance entre les implémentations. Et que la nouvelle
implémentation ait le même fonctionnement ici que l'ancienne.

Mais j'avoue que le fait que la norme *est* la norme, et
qu'implicitement, je dirais que l'intention, sinon ce qu'elle exige
impérativement, semblerait être que "r+" ne crée pas de fichier. Je
pourrais donc concevoir qu'une implémentation choisit de respecter cette
intention dans les nouveaux flux, même si les anciens fonctionnaient
différemment. Dans ce cas-là, l'option nocreate devient supérflue. Mais
je ne vois toujours pas où sa présence poserait un problème avec du code
existant. C'est plutôt les opérations qui ne s'en servent pas qui
changeront de la sémantique.

Maintenant, si on veut faire des nouveaux flux avec un nocreate, que
faire :
- nocreate : On ne crée pas s'il n'existe pas
- rien : On est comme spécifié dans la norme : On ne crée pas s'il
n'existe pas

Donc l'existance d'un nocreate ne me semble pas très intéressante,
puisque le comportement des anciens flux (créer si le fichier n'existe
pas) ne sera de toute manière pas retrouvé.

Le vrai problème ici, c'est comment faire dans le cas où on voulait la
création. Qu'on définit nocreate comme un no-op, pour que les anciens
programmes puissent compiler avec moins de modification, ne me semble
pas forcement mauvais.

Si maintenant il entreprend la tâche de relire son code, enlever
quelques nocreate inutiles n'est pas la mort.

Sauf que s'il les a mis, c'est qu'il en a besoin de la sémantique.

Et il l'a sans rien faire. Ce serait en fait d'une semantique
create_if_not_found dont il aurait besoin.

Tout à fait. C'est probablement la sémantique la plus démandée, et on ne
le supporte pas. Au moins qu'en prend la liberté de créer un fichier qui
n'existte pas quand on ouvre avec "r+".

(Dans la pratique, je me démande si c'est important. J'avoue ne jamais
avoir ouvrert un fichier autrement qu'en "r" or "w", ou l'équivalent
avec filebuf. Et ne jamais avoir fait un seek sur un flux non plus. En
général, quand on se met à faire des choses compliquer avec les accès
aléatoire, il faut passer à la couche système.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Fabien LE LEZ

15/01/2004 à 02:55

On 14 Jan 2004 00:25:56 -0800, wrote:

w truncate to zero length or create text file for writing
w+ truncate to zero length or create file for update

J'ai bien du mal à saisir la différence entre ces deux-là...

--
;-)

http://www.gotw.ca/gotw/063.htm
http://www.gotw.ca/gotw/067.htm#2

probleme avec namespace(?) et visual studio .net 2003

10 réponses

Veuillez sélectionner un problème