Problem with initialization of poiter to the file stream

[Anton Pervukhin]

Hi everybody!

I have a small problem regarding the initialization of pointer to the
file stream under some conditions.
Imagine a class which has a pointer to output file stream and some
additinional methods to deal with it, i.e. open/close/write:

classA {
private:
const std::auto_ptr<std:fstream> filePtr;
std::_Ios_Openmode mode;
public:
classA(const std::string& name, bool isAppended = true);
virtual ~ClassA{};
void setAppended(bool isAppended);
bool isAppended();
bool reopen();
void close();
}

The usage of std:fstream in my case is well suited to be defined as
auto_ptr.
There is also a variable "mode" which defines in which mode file should
be opened (i.e. appended, truncated etc)

Now I'm trying to write a constructor to set both private variables.
Clearly I would like to open "filePtr" with the mode given by
"isAppended" formal variable.

classA::ClassA(const std::string& fileName, bool isAppended) {
this->setAppended(isAppended); // to set
mode
*filePtr = *(new std:fstream(fileName.c_str(), mode)); //
Compile error
}

which leads to a compilation error that std::ios_base:perator= is
private.

I could set filePtr in initialization list like this:

ClassA::ClassA(const std::string& fileName, bool isAppended):
filePtr(new std:fstream(fileName.c_str())){
this->setAppended(isAppended);
}

but then at the moment of "filePtr" initialization its "mode" is not
known yet, meaning that "filePtr" should be reopened again later with
the right "mode".

Putting initialization of "mode" in a list before "filePtr" doesn't
guarantied that it will be initialized before.

There is a solution to make function "setAppended" returns bool and put
it this way:

ClassA::ClassA(const std::string& fileName, bool isAppended):
filePtr(new std:fstream(fileName.c_str(),
this->setAppended(isAppended))){
}

which looks rather ugly... Putting in the same place the code of
function "setAppended" instead of calling it, duplicates the code.

So all in all I'm wondering whether "filePtr" could be initialized
somehow but in the constructor body and not its initialization list.

the case with using reference like this...

///
std:fstream& fileRef;
....
std:fstream tempRef(fileName.c_str(), mode);
fileRef = tempRef;
///

...won't work because I cannot define reference for auto_ptr like this:
const std::auto_ptr<std:fstream&> filePtr


Any tips will be appreciated!

regards,
Anton

 

[Rolf Magnus]

Hi everybody!

I have a small problem regarding the initialization of pointer to the
file stream under some conditions.
Imagine a class which has a pointer to output file stream and some
additinional methods to deal with it, i.e. open/close/write:

#include <memory>
#include <string>
#include <ostream>

classA {

class classA

private:
const std::auto_ptr<std:fstream> filePtr;
std::_Ios_Openmode mode;
public:
classA(const std::string& name, bool isAppended = true);
virtual ~ClassA{};

virtual ~classA{}

void setAppended(bool isAppended);
bool isAppended();
bool reopen();
void close();
}
;

The usage of std:fstream in my case is well suited to be defined as
auto_ptr.

Your class doesn't correctly handle copying, which would be disaterous with
an auto_ptr as member.

There is also a variable "mode" which defines in which mode file should
be opened (i.e. appended, truncated etc)

Now I'm trying to write a constructor to set both private variables.
Clearly I would like to open "filePtr" with the mode given by
"isAppended" formal variable.

classA::ClassA(const std::string& fileName, bool isAppended) {
this->setAppended(isAppended); // to set
mode
*filePtr = *(new std:fstream(fileName.c_str(), mode)); //
Compile error

Why are you dereferencing?

Try:
filePtr = new std:fstream(fileName.c_str(), mode);

}

which leads to a compilation error that std::ios_base:perator= is
private.

I could set filePtr in initialization list like this:

ClassA::ClassA(const std::string& fileName, bool isAppended):
filePtr(new std:fstream(fileName.c_str())){

You're not dereferencing here.

this->setAppended(isAppended);
}

but then at the moment of "filePtr" initialization its "mode" is not
known yet, meaning that "filePtr" should be reopened again later with
the right "mode".

Putting initialization of "mode" in a list before "filePtr" doesn't
guarantied that it will be initialized before.

It's guaranteed that it won't. That's because you declared "mode" after
"filePtr". Members are always initialized in the order they are declared
in.

There is a solution to make function "setAppended" returns bool and put
it this way:

ClassA::ClassA(const std::string& fileName, bool isAppended):
filePtr(new std:fstream(fileName.c_str(),
this->setAppended(isAppended))){
}

which looks rather ugly... Putting in the same place the code of
function "setAppended" instead of calling it, duplicates the code.

So all in all I'm wondering whether "filePtr" could be initialized
somehow but in the constructor body and not its initialization list.

Initializations can only be done in the initializer list.

the case with using reference like this...

///
std:fstream& fileRef;
...
std:fstream tempRef(fileName.c_str(), mode);
fileRef = tempRef;
///

..won't work because I cannot define reference for auto_ptr like this:
const std::auto_ptr<std:fstream&> filePtr

I'm wondering why you don't just add an _instance_ of std:fstream as a
member.

 

[Anton Pervukhin]

Your class doesn't correctly handle copying, which would be disaterous with

an auto_ptr as member.

why it should be disasterous with an auto_ptr as member?
If I disable copy constructor and assignment operator, will it be still
dangerous to use auto_ptr?

Why are you dereferencing?

Try:
filePtr = new std:fstream(fileName.c_str(), mode);

In case with filePtr definition as auto_ptr this statement won't
compile.

I'm wondering why you don't just add an _instance_ of std:fstream as a
member.

Good question ;-) I just decided to give a try to use auto_ptr, since
the class is not going to be copied or assigned.

 

[Karl Heinz Buchegger]

why it should be disasterous with an auto_ptr as member?

because it has a wrong copy semantics. For the same reason auto_ptr
cannot be used in a container.

If I disable copy constructor and assignment operator, will it be still
dangerous to use auto_ptr?

Then you are fine. But you didn't

Good question ;-) I just decided to give a try to use auto_ptr, since
the class is not going to be copied or assigned.

Thats not a good reason. Your first question should be: Do I need to allocate
dynamically or not. Only then, after you decided that you need dynamic allocation
you can ask the question if some smart pointer is the way to go.
But in your case, I really see no reason why the stream object has to be allocated
with new. Especially because you say you don't want to copy or assign such an object.
Whats wrong with using an ordinary ofstream member and open the file with open()?

 

[Anton Pervukhin]

Thats not a good reason. Your first question should be: Do I need to allocate

dynamically or not. Only then, after you decided that you need dynamic allocation
you can ask the question if some smart pointer is the way to go.
But in your case, I really see no reason why the stream object has to be allocated
with new. Especially because you say you don't want to copy or assign such an object.
Whats wrong with using an ordinary ofstream member and open the file with open()?

I see your point and need to reconsider mine Thanks for
explanation.