default mode parameters for open member functions

On http://www.cplusplus.com/doc/tutorial/files/ it says:

-----------------------------
Each one of the open() member functions of the classes ofstream, ifstream and fstream has a default mode that is used if the file is opened without a second argument:

class default mode parameter
ofstream ios::out
ifstream ios::in
fstream ios::in | ios::out
-------------------------------

But I don't believe that is the case for fstream. I couldn't get it to work using CL.EXE VC++ -- I had to explicitly set the mode.

This appears to be confirmed by http://stdcxx.apache.org/doc/stdlibug/30-3.html which states:

----------------------------------
Bidirectional file streams, on the other hand, do not have the flag set implicitly. This is because a bidirectional stream does not have to be in both input and output mode in all cases. You might want to open a bidirectional stream for reading only or writing only. Bidirectional file streams therefore have no implicit input or output mode. You must always set a bidirectional file stream's open mode explicitly.
----------------------------------

Am I correct in concluding that fstream in fact does not have default modes?
Good question, I cannot get this example to run but the example sure seems to imply that the filestream can be opened and used with the defaults! On my system, it keeps failing to open the file even if I go and create the file first.
http://cplusplus.com/reference/iostream/fstream/is_open/

After specifying modes in the open call, I was able to confirm what you seem to be seeing. I do not know if that is a defect or if it was supposed to be wrong. Based on the documentation on this website it seems that our stdlib impls are defective. The documentation on cplusplus.com clearly shows that the interface should support default modes. Perhaps that documentation is wrong.
Last edited on
Okay, the documentation on this website seems to be reasonable but the std contains conflicting information which could be the source of why the code is not running the way you expect. I just looked in the ISO/IEC 14882:2003 std which shows the following declarations for basic_ifstream::open. The ifstream and ofstream contain consistent descriptions of the open function in the class decl as well as the member function decl section.
void open(const char* s, ios_base::openmode mode = ios_base::in);

However, for the basic_fstream::open function the std is inconsistent. section 27.8.1.11 shows this decl
void open(const char* s, ios_base::openmode mode = ios_base::out);

section 27.8.1.13 shows this decl but without the default modes. (note that in section 27.8.1.5 and 27.8.1.7 show the same decl for the ifstream).
void open(const char* s, ios_base::openmode mode);

Perhaps that discrepancy led to some stdlib impls to be coded incorrectly. Does anyone else see this differently?
According to the ISO/IEC 14882:2003 std I found at:

http://www.google.com/url?sa=t&source=web&ct=res&cd=3&url=http%3A%2F%2Fopenassist.googlecode.com%2Ffiles%2FC%252B%252B%2520Standard%2520-%2520ANSI%2520ISO%2520IEC%252014882%25202003.pdf&ei=n7RwSpfiJp6-tAOs2rHODw&usg=AFQjCNG4-cbawIu_O0_KwFqjXU6VG1cZDA&sig2=TOT807oKeDhC7P41v1lD5A

section 27.8.1.11 shows this for fstream's constructor:

1
2
3
explicit basic_fstream(
    const char* s,
    ios_base::openmode mode = ios_base::in|ios_base::out);


and this for its open member:

1
2
3
void open(
     const char* s,
     ios_base::openmode mode = ios_base::in|ios_base::out);


So clearly the standard calls for defaults. (27.8.1.13's declaration is for is_open and is unrelated)

Just as clearly, the VC++, Apache C++ and IBM's XL C/C++ V8.0 for AIX are not compliant with this standard.

So, a couple of (possibly naive) newbie questions:

1. Which C++ compiler does cplusplus.com represent?

2. How do I keep track of which standards a particular compiler doesn't comply to?

3. Is VC++ known for its lack of compliance? I like its IDE for its debugger but should I be using another compiler that is known more for its compliance?
I take it back, in fact as kempofighter pointed out, the standard does appear to contradict itself.

Contrary to 27.8.1.11's contructor above, 27.8.1.12 "basic_fstream constructors" has

explicit basic_fstream(const char* s, ios_base::openmode mode);

and contrary to 27.8.1.11's open member above, 27.8.1.13 "Member functions" has

void open(const char* s, ios_base::openmode mode);

neither of which have defaults for mode.

So does this explain the inconsistencies in compiler implementation?
The MSDN link was for Visual Studio 6 and I'm using VC++ 2008 and according to the documentation:

[url]http://msdn.microsoft.com/en-us/library/4dx08bh4.aspx[/url]

1
2
3
4
5
6
7
8
9
void open(
    const char *_Filename,
    ios_base::openmode _Mode = ios_base::in | ios_base::out,
    int _Prot = (int)ios_base::_Openprot
);
void open(
    const char *_Filename,
    ios_base::openmode _Mode
);


it should default the modes per the standard.

But this fails:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <fstream>
#include <iostream>

using std::fstream; using std::cout;

int main()
{
	fstream File;

	File.open("test.txt");                       // should default to ios_base::in & out

	if (File.fail()) cout<<"open failure";  // but it triggers the fail bit.

        return 0;
}


whereas this works AOK:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <fstream>
#include <iostream>

using std::fstream; using std::cout; using std::ios_base;

int main()
{
	fstream File;

	File.open("test.txt",std::ios_base:out);   // explicit out

	if (File.fail()) cout<<"open failure";           // and no trigger

        return 0;
}


Why doesn't the first code work since it should default ios_base:: out?
I wonder how the compiler could recognize the two overloads when passing a value to _Filename and _Mode
1
2
3
4
5
void open(
    const char *_Filename,
    ios_base::openmode _Mode = ios_base::in | ios_base::out,
    int _Prot = (int)ios_base::_Openprot
);
1
2
3
4
void open(
    const char *_Filename,
    ios_base::openmode _Mode
);

Microsoft's version has clearly something odd
Last edited on
Topic archived. No new replies allowed.