On Fri, 25 Jul 2003 15:30:11 +0200, "NonoSoft"
wrote:Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
Si tu espères avoir une réponse, fais un copier-coller de ton post ici
plutôt que de donner une URL que personne n'ira voir. En tant qu'à
faire, enlève les fautes d'orthographe.
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On Fri, 25 Jul 2003 15:30:11 +0200, "NonoSoft" <vincot@wanadoo.fr>
wrote:
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
Si tu espères avoir une réponse, fais un copier-coller de ton post ici
plutôt que de donner une URL que personne n'ira voir. En tant qu'à
faire, enlève les fautes d'orthographe.
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On Fri, 25 Jul 2003 15:30:11 +0200, "NonoSoft"
wrote:Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
Si tu espères avoir une réponse, fais un copier-coller de ton post ici
plutôt que de donner une URL que personne n'ira voir. En tant qu'à
faire, enlève les fautes d'orthographe.
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Le post est assez long c'est pourquoi je n'est pas fait de copier coller.
Le post est assez long c'est pourquoi je n'est pas fait de copier coller.
Le post est assez long c'est pourquoi je n'est pas fait de copier coller.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
Voila une methode de ma classe doit ecrire une chiane de caractére dans un
fichier texte.
Rien de plus simple :
Code:
#include <fstream.h>
void CCle::Ecrire()
{
ofstream monFichier;
monFichier.open("c:tmp");
monFichier << Cle;
monFichier.close();
}
Ce code fonctionne tres bien hors de ma classe mais la quand je compile j'ai
:
Code:
[Warning] In function `CCle::Ecrire(void)':
[Linker error] undefined reference to `ostream::operator<<(char const *)'
[Linker error] undefined reference to `fstreambase::close(void)'
Et quel est la différence entre fstream.h et fstream ?
Voila une methode de ma classe doit ecrire une chiane de caractére dans un
fichier texte.
Rien de plus simple :
Code:
#include <fstream.h>
void CCle::Ecrire()
{
ofstream monFichier;
monFichier.open("c:\tmp");
monFichier << Cle;
monFichier.close();
}
Ce code fonctionne tres bien hors de ma classe mais la quand je compile j'ai
:
Code:
[Warning] In function `CCle::Ecrire(void)':
[Linker error] undefined reference to `ostream::operator<<(char const *)'
[Linker error] undefined reference to `fstreambase::close(void)'
Et quel est la différence entre fstream.h et fstream ?
Voila une methode de ma classe doit ecrire une chiane de caractére dans un
fichier texte.
Rien de plus simple :
Code:
#include <fstream.h>
void CCle::Ecrire()
{
ofstream monFichier;
monFichier.open("c:tmp");
monFichier << Cle;
monFichier.close();
}
Ce code fonctionne tres bien hors de ma classe mais la quand je compile j'ai
:
Code:
[Warning] In function `CCle::Ecrire(void)':
[Linker error] undefined reference to `ostream::operator<<(char const *)'
[Linker error] undefined reference to `fstreambase::close(void)'
Et quel est la différence entre fstream.h et fstream ?
Non standard, préférer <fstream>
Non standard, préférer <fstream>
Non standard, préférer <fstream>
Jonathan Mcdougall writes:
|> >Et quel est la différence entre fstream.h et fstream ?
|> fstream.h est un header non standard, datant de l'avant
|> standardisation.
C-à-d il y a bien peu d'années. Toutes les dernières versions
des compilateurs que je connais le supportent, mais parfois, on est
obligé à supporter d'anciens compilateurs aussi. (G++ ne le
supporte correctement que depuis un an ou deux. L'implémentation
dans la dernière version de Sun CC dont je me suis servi est d'un
ordre de grandeur plus lente que <fstream.h>, etc.)
|> Les headers standards n'ont plus l'extension .h
|> (iostream.h est devenu iostream tout court..)
iostream.h n'est pas devenu iostream. C'est une des raisons pourquoi
on a changé les noms : le contenu n'est pas le même. Surtout,
<iostream> ne définit pas streambuf, istream, ostream ni les
opérateurs >> et << (au moins que ton implémentation d'iostream
inclut d'autres en-têtes, ce qui est permis).
Tu oublies le :
#include <ostream>
Sans ça, ton code n'est pas correct, et il existe des compilateurs
(d'après ce qu'on me dit) où il ne compile pas.
Jonathan Mcdougall <DELjonathanmcdougall@yahoo.ca> writes:
|> >Et quel est la différence entre fstream.h et fstream ?
|> fstream.h est un header non standard, datant de l'avant
|> standardisation.
C-à-d il y a bien peu d'années. Toutes les dernières versions
des compilateurs que je connais le supportent, mais parfois, on est
obligé à supporter d'anciens compilateurs aussi. (G++ ne le
supporte correctement que depuis un an ou deux. L'implémentation
dans la dernière version de Sun CC dont je me suis servi est d'un
ordre de grandeur plus lente que <fstream.h>, etc.)
|> Les headers standards n'ont plus l'extension .h
|> (iostream.h est devenu iostream tout court..)
iostream.h n'est pas devenu iostream. C'est une des raisons pourquoi
on a changé les noms : le contenu n'est pas le même. Surtout,
<iostream> ne définit pas streambuf, istream, ostream ni les
opérateurs >> et << (au moins que ton implémentation d'iostream
inclut d'autres en-têtes, ce qui est permis).
Tu oublies le :
#include <ostream>
Sans ça, ton code n'est pas correct, et il existe des compilateurs
(d'après ce qu'on me dit) où il ne compile pas.
Jonathan Mcdougall writes:
|> >Et quel est la différence entre fstream.h et fstream ?
|> fstream.h est un header non standard, datant de l'avant
|> standardisation.
C-à-d il y a bien peu d'années. Toutes les dernières versions
des compilateurs que je connais le supportent, mais parfois, on est
obligé à supporter d'anciens compilateurs aussi. (G++ ne le
supporte correctement que depuis un an ou deux. L'implémentation
dans la dernière version de Sun CC dont je me suis servi est d'un
ordre de grandeur plus lente que <fstream.h>, etc.)
|> Les headers standards n'ont plus l'extension .h
|> (iostream.h est devenu iostream tout court..)
iostream.h n'est pas devenu iostream. C'est une des raisons pourquoi
on a changé les noms : le contenu n'est pas le même. Surtout,
<iostream> ne définit pas streambuf, istream, ostream ni les
opérateurs >> et << (au moins que ton implémentation d'iostream
inclut d'autres en-têtes, ce qui est permis).
Tu oublies le :
#include <ostream>
Sans ça, ton code n'est pas correct, et il existe des compilateurs
(d'après ce qu'on me dit) où il ne compile pas.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
Voici mon post : http://www.developpez.net/forums/viewtopic.php?t3975
On m'a dis d'ecrire ici pour avoir peu etre une réponse.
writes:
| > >Tu oublies le :
| > > #include <ostream>
| > >Sans ça, ton code n'est pas correct, et il existe des
| > >compilateurs (d'après ce qu'on me dit) où il ne compile pas.
| > Théoriquement oui, mais pratiquement, pas à ma connaissance.
| On m'a parlé dans le temps d'un cas réel.
Il me semble qu'une version de la bibliothèque vendue par Dinkumware à
un moment donné avait un tel comportement. Je ne l'ai jamais essayé
moi-même.
| Le but de diviser les iostream en tant d'en-têtes différents,
| c'était bien pour qu'on n'inclut que ce dont on a besoin, sans
| s'encombrer du reste. Si <iostream> fait partie de cette
| philosophie, logiquement, c'est une mauvaise implémentation qui
| fournira tout.
C'est un point de vue. Un autre est de considérer que cela n'a aucune
utilité pratique de casser quelque chose comme
#include <iostream>
using namespace std;
int main() { cout << "Hello World" << endl; }
Oui, je sais ce que tu vas dire.
| Si le but d'<iostream>, c'était d'avoir une façon simple à avoir
| tout, je me pose deux questions : 1) pourquoi on n'a pas exigé alors
| qu'il inclut toute la reste, et 2) pourquoi est-ce qu'on n'a pas
| créé aussi un en-tête pour n'avoir que cin, cout, etc. (Après tout,
| c'est extrèmement rare d'utiliser cin, cout ou cerr dans le même
| fichier source que << ou >>.) En somme, je dirais que c'est un
| défaut (assez mineur, j'avoue) d'une bibliothèque que de définir
| tout istream, ostream et les opérateurs dans <iostream>.
Il avertir le monde, parce que de nos jours, je ne connais pas
d'implémentation moderne qui n'accepte pas le programme ci-dessous. Si
tu en connais, j'aimerais le savori afin de mettre ma base de données
à jour.
| En revanche, en ce qui concerne <fstream>, tu as probablement
| raison. L'en-tête <fstream> doit définir filebuf, ifstream et
| ofstream. Classes qui dérivent de streambuf, istream et d'ostream,
| respectivement. Alors, je vois mal comment il pourrait définir des
| classes qui en dérivent sans avoir les définitions des classes de
| base, donc, sans inclure <streambuf>, <istream> et <ostream>.
Un peu d'imagination, que diable. La définition de ces classes peut
très bien se trouver dans des endroits sépararés de <istream>,
<ostream> et le reste.
<xxx/istream-def>
// contient la définition de std::istream
// le contenu est différent de <istream>
<xxx/ostream-def>
// contient la définition de std::ostream
// le contenu est différent de <ostream>
<fstream>
#include <xxx/istream-def>
#include <xxx/ostream-def>
// ... ajoute la reste
Alors <fstream> peut, de manière interne, n'inclure que ces entêtes
(internes) avec le résultat qu'il n'a pas à inclure l'intégralité de
<istream> ou <ostream> dans <fstream>.
kanze@gabi-soft.fr writes:
| > >Tu oublies le :
| > > #include <ostream>
| > >Sans ça, ton code n'est pas correct, et il existe des
| > >compilateurs (d'après ce qu'on me dit) où il ne compile pas.
| > Théoriquement oui, mais pratiquement, pas à ma connaissance.
| On m'a parlé dans le temps d'un cas réel.
Il me semble qu'une version de la bibliothèque vendue par Dinkumware à
un moment donné avait un tel comportement. Je ne l'ai jamais essayé
moi-même.
| Le but de diviser les iostream en tant d'en-têtes différents,
| c'était bien pour qu'on n'inclut que ce dont on a besoin, sans
| s'encombrer du reste. Si <iostream> fait partie de cette
| philosophie, logiquement, c'est une mauvaise implémentation qui
| fournira tout.
C'est un point de vue. Un autre est de considérer que cela n'a aucune
utilité pratique de casser quelque chose comme
#include <iostream>
using namespace std;
int main() { cout << "Hello World" << endl; }
Oui, je sais ce que tu vas dire.
| Si le but d'<iostream>, c'était d'avoir une façon simple à avoir
| tout, je me pose deux questions : 1) pourquoi on n'a pas exigé alors
| qu'il inclut toute la reste, et 2) pourquoi est-ce qu'on n'a pas
| créé aussi un en-tête pour n'avoir que cin, cout, etc. (Après tout,
| c'est extrèmement rare d'utiliser cin, cout ou cerr dans le même
| fichier source que << ou >>.) En somme, je dirais que c'est un
| défaut (assez mineur, j'avoue) d'une bibliothèque que de définir
| tout istream, ostream et les opérateurs dans <iostream>.
Il avertir le monde, parce que de nos jours, je ne connais pas
d'implémentation moderne qui n'accepte pas le programme ci-dessous. Si
tu en connais, j'aimerais le savori afin de mettre ma base de données
à jour.
| En revanche, en ce qui concerne <fstream>, tu as probablement
| raison. L'en-tête <fstream> doit définir filebuf, ifstream et
| ofstream. Classes qui dérivent de streambuf, istream et d'ostream,
| respectivement. Alors, je vois mal comment il pourrait définir des
| classes qui en dérivent sans avoir les définitions des classes de
| base, donc, sans inclure <streambuf>, <istream> et <ostream>.
Un peu d'imagination, que diable. La définition de ces classes peut
très bien se trouver dans des endroits sépararés de <istream>,
<ostream> et le reste.
<xxx/istream-def>
// contient la définition de std::istream
// le contenu est différent de <istream>
<xxx/ostream-def>
// contient la définition de std::ostream
// le contenu est différent de <ostream>
<fstream>
#include <xxx/istream-def>
#include <xxx/ostream-def>
// ... ajoute la reste
Alors <fstream> peut, de manière interne, n'inclure que ces entêtes
(internes) avec le résultat qu'il n'a pas à inclure l'intégralité de
<istream> ou <ostream> dans <fstream>.
writes:
| > >Tu oublies le :
| > > #include <ostream>
| > >Sans ça, ton code n'est pas correct, et il existe des
| > >compilateurs (d'après ce qu'on me dit) où il ne compile pas.
| > Théoriquement oui, mais pratiquement, pas à ma connaissance.
| On m'a parlé dans le temps d'un cas réel.
Il me semble qu'une version de la bibliothèque vendue par Dinkumware à
un moment donné avait un tel comportement. Je ne l'ai jamais essayé
moi-même.
| Le but de diviser les iostream en tant d'en-têtes différents,
| c'était bien pour qu'on n'inclut que ce dont on a besoin, sans
| s'encombrer du reste. Si <iostream> fait partie de cette
| philosophie, logiquement, c'est une mauvaise implémentation qui
| fournira tout.
C'est un point de vue. Un autre est de considérer que cela n'a aucune
utilité pratique de casser quelque chose comme
#include <iostream>
using namespace std;
int main() { cout << "Hello World" << endl; }
Oui, je sais ce que tu vas dire.
| Si le but d'<iostream>, c'était d'avoir une façon simple à avoir
| tout, je me pose deux questions : 1) pourquoi on n'a pas exigé alors
| qu'il inclut toute la reste, et 2) pourquoi est-ce qu'on n'a pas
| créé aussi un en-tête pour n'avoir que cin, cout, etc. (Après tout,
| c'est extrèmement rare d'utiliser cin, cout ou cerr dans le même
| fichier source que << ou >>.) En somme, je dirais que c'est un
| défaut (assez mineur, j'avoue) d'une bibliothèque que de définir
| tout istream, ostream et les opérateurs dans <iostream>.
Il avertir le monde, parce que de nos jours, je ne connais pas
d'implémentation moderne qui n'accepte pas le programme ci-dessous. Si
tu en connais, j'aimerais le savori afin de mettre ma base de données
à jour.
| En revanche, en ce qui concerne <fstream>, tu as probablement
| raison. L'en-tête <fstream> doit définir filebuf, ifstream et
| ofstream. Classes qui dérivent de streambuf, istream et d'ostream,
| respectivement. Alors, je vois mal comment il pourrait définir des
| classes qui en dérivent sans avoir les définitions des classes de
| base, donc, sans inclure <streambuf>, <istream> et <ostream>.
Un peu d'imagination, que diable. La définition de ces classes peut
très bien se trouver dans des endroits sépararés de <istream>,
<ostream> et le reste.
<xxx/istream-def>
// contient la définition de std::istream
// le contenu est différent de <istream>
<xxx/ostream-def>
// contient la définition de std::ostream
// le contenu est différent de <ostream>
<fstream>
#include <xxx/istream-def>
#include <xxx/ostream-def>
// ... ajoute la reste
Alors <fstream> peut, de manière interne, n'inclure que ces entêtes
(internes) avec le résultat qu'il n'a pas à inclure l'intégralité de
<istream> ou <ostream> dans <fstream>.