Problème avec Ofstream

Version imprimable

Bonjour,

J'essaie dans mon programme de créer un fichier où je vais écrire le résultat qui est une matrice. Pour cela j'ai écrit un header Streambuffer:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#ifndef __STREAMBUFFER__
#define __STREAMBUFFER__
 
 
#include <iostream>
#include <ostream>
 
class IStreamBuffer : public ofstream
{
private:
	ofstream*  m_streamfile ;
public:
            // ****************************
            IStreamBuffer(const char* _filename)
            {
                  m_streamfile = new ofstream(_filename, ios::out);
            }
            void WriteStrToBuffer(char* _str)
            {
                  *m_streamfile << _str << endl;           
            }
 
            void WriteDblToBuffer(double _amount)
            {
                  *m_streamfile << _amount << endl;
            }
            void WriteFloatToBuffer(float _value)
            {
                  *m_streamfile << _value << endl;
            }
            void Close()
            {
                  m_streamfile->close();
            }         
 
};
#endif

mais j'ai une erreur que j'arrive pas à résoudre: "error C2504: 'ofstream'*: classe de base non définie"
Avez vous une idée sur que ça peut être(Je suis sur Visual express 2005)

Merci

12/10/2009, 17h11
Mac LAK

Code:

#include <fstream>
12/10/2009, 17h45
azeglaoui

Je l'ai ajouté mais ça ne change rien. Il reconnait pas ofstream
12/10/2009, 17h46
Goten

std::ofstream... et pourquoi l'alloué sur le tas?
12/10/2009, 17h50
JulienDuSud

Citation:

Envoyé par Goten

std::ofstream... et pourquoi l'alloué sur le tas?

Justement, il ne l'alloue pas sur le tas, il l'alloue sur le heap :P

D'ailleurs oui, pourquoi ?
12/10/2009, 17h56
Mac LAK

Heu... Au fait, ce n'est pas à la base une très mauvaise idée de dériver une classe de la STL ??
12/10/2009, 18h00
Goten

Citation:

Envoyé par JulienDuSud

Justement, il ne l'alloue pas sur le tas, il l'alloue sur le heap :P

D'ailleurs oui, pourquoi ?

wtf? heap == tas...

@Mac_lak : je sais pas si c'était rhétorique, mais dans tout les cas oui c'est pas une bonne idée, c'est pas prévu pour.
12/10/2009, 18h02
Mac LAK

Citation:

Envoyé par Goten

@Mac_lak : je sais pas si c'était rhétorique, mais dans tout les cas oui c'est pas une bonne idée, c'est pas prévu pour.

Ben regardes la déclaration de la classe...

Code:

class IStreamBuffer : public ofstream
12/10/2009, 18h04
Goten

Non non je sais qu'il la fait. Rhétorique dans le sens où pour toi c'était évident que oui c'est mal. Pas évident qu'il l'ai fait :p.
12/10/2009, 18h08
Mac LAK
Non, c'était bien pour me confirmer que même sur les flux, c'était pas spécialement une bonne idée... Et comme c'est le cas (il tente de dériver de ofstream), je me dis qu'il y a peut-être la cause à cet endroit :
- Dériver d'une classe STL,
- Ne pas préfixer par "std::" les références à ofstream.
Les deux combinés, ça ne doit pas aider... ;)
12/10/2009, 18h09
Goten

Ne pas préfixer ostream se suffit à lui même pour sortir ce message d'erreur. C'est plus vicieux les soucis quand on dérive d'une classe de la STL (flux compris).
12/10/2009, 18h09
JulienDuSud

Citation:

Envoyé par Goten

wtf? heap == tas...

Euh...

Attends, 2sec.

Stack. Stack... Pile !
Heap ne peut être que tas, en effet :calim2:

Mes excuses, problèmes de traduction inside :P
12/10/2009, 19h22
JolyLoic

Citation:

Envoyé par Mac LAK

Heu... Au fait, ce n'est pas à la base une très mauvaise idée de dériver une classe de la STL ??

De la STL, oui, par contre de la SL, ça dépend. En particulier, il y a des classes de la SL qui sont prévues pour être dérivées : Les *streambuf me viennent en tête, et les *stream aussi (même si souvent pour elles l'intérêt est juste d'utiliser un autre *streambuf au niveau de leur constructeur).

En fait, comme toujours, si la classe a des fonctions virtuelles, un destructeur virtuel, il doit y avoir une bonne raison, sinon, il vaut généralement mieux s'abstenir de dériver (sauf encore une fois de quelques classes de trait).
12/10/2009, 19h52
Goten

Citation:

Envoyé par JolyLoic

De la STL, oui, par contre de la SL, ça dépend. En particulier, il y a des classes de la SL qui sont prévues pour être dérivées : Les *streambuf me viennent en tête, et les *stream aussi (même si souvent pour elles l'intérêt est juste d'utiliser un autre *streambuf au niveau de leur constructeur).

En fait, comme toujours, si la classe a des fonctions virtuelles, un destructeur virtuel, il doit y avoir une bonne raison, sinon, il vaut généralement mieux s'abstenir de dériver (sauf encore une fois de quelques classes de trait).

par *stream t'entends bien : istream / ostream? (pas fstream quoi)
12/10/2009, 20h31
JolyLoic

Je ne vois pas trop quel problème il pourrait y avoir à dériver d'un fstream, même si jusqu'à présent, j'ai toujours dérivé mes flux de istream et ostream.
12/10/2009, 20h54
Goten

J'ai peut être mal vu (j'ai regardé vite fait) mais ofstream/ifstream n'ont pas de dtor virtuel si?
12/10/2009, 21h05
JolyLoic

Vu qu'ils dérivent de [i/o]stream qui ont un destructeur virtuel...
12/10/2009, 21h13
Goten

oh gash, dikumware m'a eu :p. Donc je retire mes précédentes affirmations, mea culpa
12/10/2009, 21h17
Jean-Marc.Bourguet

Citation:

Envoyé par JolyLoic

De la STL, oui, par contre de la SL, ça dépend. En particulier, il y a des classes de la SL qui sont prévues pour être dérivées : Les *streambuf me viennent en tête, et les *stream aussi (même si souvent pour elles l'intérêt est juste d'utiliser un autre *streambuf au niveau de leur constructeur).

Plus exception et la plupart de ses descendants, unary_function, binary_function, iterator, locale::facet et je dois en oublier.