Discussion :

[azeglaoui]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Mac LAK]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include <fstream>

[azeglaoui]

Je l'ai ajouté mais ça ne change rien. Il reconnait pas ofstream

[Goten]

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

[JulienDuSud]

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

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

D'ailleurs oui, pourquoi ?

[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 ??

[Goten]

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

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.

[Mac LAK]

@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 :

Sélectionner tout - Visualiser dans une fenêtre à part

class IStreamBuffer : public ofstream

[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.

[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...

[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).

[JulienDuSud]

wtf? heap == tas...

Euh...

Attends, 2sec.

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

Mes excuses, problèmes de traduction inside

[JolyLoic]

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).

[Goten]

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)

[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.

[Goten]

J'ai peut être mal vu (j'ai regardé vite fait) mais ofstream/ifstream n'ont pas de dtor virtuel si?

[JolyLoic]

Vu qu'ils dérivent de [i/o]stream qui ont un destructeur virtuel...

[Goten]

oh gash, dikumware m'a eu :p. Donc je retire mes précédentes affirmations, mea culpa

[Jean-Marc.Bourguet]

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.