Thread: Simple file close & clear question

What's important is if the Re_InvestCalc() actually touches the same file. You can use two different file objects to manipulate the same file, it just gets slightly confusing. If you want to mix reads and writes, a read following a write needs to be preceded by a ostream::flush(). (IOW, the writing file handle needs to flush its output or close before you read from the same file.) Also, take care not to overwrite your file at all. As long as you do that, you should be able to do what you want and let RAII take over closing files for you in the file objects' destructor.

Originally Posted by Guest

It's still open, nothing has changed. The object is local and the function isn't able to touch it unless you explicitly pass its memory location (which you don't).

Look at the following code:

Code:

void fn() { // doing some stuff }

int main()
{
    int obj = 5;
    fn();
    cout << obj << endl;
}

You wouldn't expect obj to change state after fn() has been called, right? What makes you doubt this behavior when the object in question is a std:fstream instead?

Uh well that makes perfect sense now that you put it like that. As a novice learner I was apprehensive since I read that ofstream object (ptr or container or whatever it actually is) automatically closes as it goes out of scope.

If speaking totally in terms of stack memory being released walking back up each call, then obviously a sub-function down further on stack memory would not put a calling function out of current (rather it's own) stack frame scope.

But honestly I did not know "where" the compiler creates the function nor am I yet totally under each aspect of "scope" be it class, stack or otherwise. And therein my own testing of the matter might depict inconclusive results. So I wanted the voice of experience to comment. And I thank you much for that Adrian.

Originally Posted by whiteflags

What's important is if the Re_InvestCalc() actually touches the same file. You can use two different file objects to manipulate the same file, it just gets slightly confusing. If you want to mix reads and writes, a read following a write needs to be preceded by a ostream::flush(). (IOW, the writing file handle needs to flush its output or close before you read from the same file.) Also, take care not to overwrite your file at all. As long as you do that, you should be able to do what you want and let RAII take over closing files for you in the file objects' destructor.

Thanks whiteflags, I am more aware of those aspects than I currently am all the "scope" aspects. But I thank you for all and any clarification at this point in my journey.

The calling function maintains the state prior to entering the stack frame of the sub-function and – after returning from that – is reinstated to continue the computation. I cannot imagine how hard programming would be, if every function call killed all other objects

One thing that might help you get a better sense of scope is using a class that notifies you of its own creation and destruction. Instantiating such an object at different places in your code gives you feedback on its lifetime (and that of others in its place).

Code:

struct X
{
    X(const string& n = "X") : name(n) { cout << name << " lives!" << endl; }
    ~X() { cout << name << " dies." << endl; }
    string name;
};

int main()
{
    X x1("foo");
    cout << "---------" << endl;
    { // you can create plain blocks such as this to test scope behavior
        X x2("bar");
        cout << "---------" << endl;
    }
    cout << "---------" << endl;
}

Output:

Code:

foo lives!
---------
bar lives!
---------
bar dies.
---------
foo dies.

Well, technically speaking, all state lives on the stack, regardless of how many functions are called. Just think of it as a stack of boxes. Every time a function gets called, it puts a new box on the top of the stack. When the function ends, it removes the box (i.e. clean up everything it put on the stack). All other boxes on the stack are not affected.

Classes are no exception to this. It lives when it is first created and dies when the function (or the local scope) it is declared in ends.

There would be "exceptions" to these rules when you start talking about statics, globals and the heap. But otherwise these rules are absolute.

>>sName(ssName.str());
Should be
sName = ssName.str();

You can't "call" a string; it makes no sense. You really wanted to assign the generated string from the stringstream to the string, but that's really not necessary either, which brings me to the next point:

>> string sName(ssName.str());
>> const char* ccpFilename = sName.c_str();
>> ofstream ofstr_ReVest(ccpFilename); // Open new ReVest file
This can be simplified to just:
ofstream ofstr_ReVest(ssName.str()); // Open new ReVest file

I'm assuming you're using gcc.
By default, gcc doesn't compile with respect to the newest standard (it still compiles with respect to the 98/03 standard, which in my opinion, is a mistake since it's been 5 years since C++11 came out).
Try including in your command line or your IDE -std=c++17/1z/14/1y/11/0x. That means you should try -std=c++17 first, then if that doesn't work, -std=c++1z, and so on. The compiler switches change depending on the version you have. Optimally, you should have the latest version, though.

Due to an oversight, the C++98/03 standard did not have overloads for streams that took an std::string. That was fixed in C++11, so what I originally wrote is correct, adhering to the C++11 standard.

It's OK to do it the longer way if you're uncertain. The basic principle to understand here is that std::stringstream.str() returns a temporary string. Then you call c_str() on that temporary object, giving you a const char* pointer. But when that temporary string goes out of scope, that pointer becomes invalid. What you can generally consider is that temporaries live at least for the duration of the line it was created on. So the example in your link you see someCStyleFunction( myStringStream.str().c_str() ), and this is correct since the temporary string created by str() outlives the function call.

Now, there is a caveat. The pointer will only live for the function call, or in your code, the constructor call. If the constructor stores away the pointer for later use, it's going to become a problem. However, fstream only needs the pointer to open the file. After that, it doesn't need the pointer any more*, so we're all good.

*) This is not guaranteed by the standard as far as I know, but I know no sane implementation that would store the pointer because pretty much any OS will give you back a file handle to use to identify the file you've opened.

Originally Posted by Elysia

*) This is not guaranteed by the standard as far as I know, but I know no sane implementation that would store the pointer because pretty much any OS will give you back a file handle to use to identify the file you've opened.

OS considerations aside, a more general implementation issue is that the stream has no guarantees about the lifetime of what the pointer points to either, so if it wants to keep the string, it has to make a copy.