I want create an object using the fstream constructor,

fstream file("afile", ios_base::in|ios_base::out);

Does the file "afile" have to exist, as in an ifstream instantiation, or
will the file be created?  I have tried this on different compilers with
different results.

MS Visual C++ and gnu 3.22b (for DOS) does not create a new file, but
Borland's 5.5.1 command-line compiler does create the file.  I cannot find
reference to this in the C++ standard.  What is the answer and where can I
find a reference?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Joe Bentley" <bart@gotnet.net> wrote in message news:Ripma.2$qW2.1672@news-west.eli.net...

> I want create an object using the fstream constructor,
>
> fstream file("afile", ios_base::in|ios_base::out);
>
> Does the file "afile" have to exist, as in an ifstream instantiation, or
> will the file be created?  I have tried this on different compilers with
> different results.

The file must exist.

> MS Visual C++ and gnu 3.22b (for DOS) does not create a new file, but
> Borland's 5.5.1 command-line compiler does create the file.  I cannot find
> reference to this in the C++ standard.  What is the answer and where can I
> find a reference?

See 27.8.1.3. Table 92 there shows that in|out is equivalent to a C fopen
call with mode "r+". The C Standard says this mode does not create the
file.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Ripma.2$qW2.1672@news-west.eli.net>, Joe Bentley wrote:
> I want create an object using the fstream constructor,
>
> fstream file("afile", ios_base::in|ios_base::out);
>
> Does the file "afile" have to exist, as in an ifstream instantiation, or
> will the file be created?  I have tried this on different compilers with
> different results.
>
> MS Visual C++ and gnu 3.22b (for DOS) does not create a new file, but
> Borland's 5.5.1 command-line compiler does create the file.  I cannot find
> reference to this in the C++ standard.  What is the answer and where can I
> find a reference?

The fstream() constructor passes the mode to the open() function of its
filebuf.  The specification for this (section 27.8.1.3) says in|out
corresponds to stdio file mode "r+".  According to C99 (though C90 is
the authority here), "Opening a file with read mode ('r' as the first
character in the mode argument) fails if the file does not exist or
cannot be read."  So the Borland behaviour is wrong.

If you want to create a new file in the case that the named file does
not exist, use in|out|trunc.  (Don't ask me why trunc implies create.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

bart@gotnet.net (Joe Bentley) wrote

> I want create an object using the fstream constructor,
>
> fstream file("afile", ios_base::in|ios_base::out);
>
> Does the file "afile" have to exist, as in an ifstream instantiation, or
> will the file be created?  I have tried this on different compilers with
> different results.
>
> MS Visual C++ and gnu 3.22b (for DOS) does not create a new file, but
> Borland's 5.5.1 command-line compiler does create the file.  I cannot find
> reference to this in the C++ standard.  What is the answer and where can I
> find a reference?

The standard (27.8.1.3/2) specifies that this is equivalent to calling

  std::fopen("afile", "r+");

which is defined (by the C standard) as opening an existing file for
reading and writing.  So, if the file does not exist, I believe the
correct behavior is for this to fail.

Hope this helps!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message
news:<3e9a97ab$0$28118$4c41069e@reader0.ash.ops.us.uu.net>...
> "Joe Bentley" <bart@gotnet.net> wrote in message
> news:Ripma.2$qW2.1672@news-west.eli.net...

> > I want create an object using the fstream constructor,

> > fstream file("afile", ios_base::in|ios_base::out);

> > Does the file "afile" have to exist, as in an ifstream
> > instantiation, or will the file be created?  I have tried this on
> > different compilers with different results.

> The file must exist.

> > MS Visual C++ and gnu 3.22b (for DOS) does not create a new file,
> > but Borland's 5.5.1 command-line compiler does create the file.  I
> > cannot find reference to this in the C++ standard.  What is the
> > answer and where can I find a reference?

> See 27.8.1.3. Table 92 there shows that in|out is equivalent to a C
> fopen call with mode "r+". The C Standard says this mode does not
> create the file.

Is there some real reason for this, or is this just another case of
gratuous incompatibility with the pre-standard libraries?  Did the C++
standards committee realize that there were people writing code for the
iostreams before they even thought of standardizing it?

I used the following program to test:

    #ifdef OLD
    #include <iostream.h>
    #include <fstream.h>
    #define std
    #else
    #include <iostream>
    #include <ostream>
    #include <fstream>
    #endif
    #include <stdio.h>

    int
    main()
    {
        std::remove( "afile" ) ;
        std::fstream        file( "afile", std::ios::in | std::ios::out ) ;
        if ( file ) {
            std::cout << "Open succeeded, file created\n" ;
        } else {
            std::cout << "Open failed\n" ;
        }
        return 0 ;
    }

With g++ 2.95.2 or Sun CC 5.1 mode compat=4 (compatible with version
4.2), compiled with the option -DOLD, the open succeeds and the file is
created.  With g++ 3.2.2 or Sun CC 5.1 normal, the open fails and the
file is not created.

Logically, I would expect that even with a new compiler, using -DOLD
would suffice for the code to work.  At least if the compiler vendor had
any consideration for its users.  Regretfully, this is not the case with
either g++ 3.2.2 nor Sun CC 5.1.  Frankly, I can't understand it.  Both
compilers obviously had access to the old code, and could have done
things correctly.  In the case of Sun CC 5.1, the old code is even
delivered with the compiler, since if I specify -compat=4, I get it;
what stopped them from compiling for the new compiler as well?

(If I remember right, VC++ 5.0 and 6.0 got this right.  It's sort of
painful for an old Unix user like me to have to say that Microsoft has
more respect for its users than the Unix suppliers.  Especially when
they did so almost five years earlier.)

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0304150116.1e5b93f5@posting.google.com...

> pjp@dinkumware.com ("P.J. Plauger") wrote in message
> news:<3e9a97ab$0$28118$4c41069e@reader0.ash.ops.us.uu.net>...
> > "Joe Bentley" <bart@gotnet.net> wrote in message
> > news:Ripma.2$qW2.1672@news-west.eli.net...
>
> > > I want create an object using the fstream constructor,
>
> > > fstream file("afile", ios_base::in|ios_base::out);
>
> > > Does the file "afile" have to exist, as in an ifstream
> > > instantiation, or will the file be created?  I have tried this on
> > > different compilers with different results.
>
> > The file must exist.
>
> > > MS Visual C++ and gnu 3.22b (for DOS) does not create a new file,
> > > but Borland's 5.5.1 command-line compiler does create the file.  I
> > > cannot find reference to this in the C++ standard.  What is the
> > > answer and where can I find a reference?
>
> > See 27.8.1.3. Table 92 there shows that in|out is equivalent to a C
> > fopen call with mode "r+". The C Standard says this mode does not
> > create the file.
>
> Is there some real reason for this, or is this just another case of
> gratuous incompatibility with the pre-standard libraries?  Did the C++
> standards committee realize that there were people writing code for the
> iostreams before they even thought of standardizing it?

Yes, and as you can see here was an area where existing practice was
far from consistent. One of the roles of standardization is to choose
one form of behavior that's defensible. In this case, we chose to
reconcile the C++ Standard with the C Standard.

> .....
> With g++ 2.95.2 or Sun CC 5.1 mode compat=4 (compatible with version
> 4.2), compiled with the option -DOLD, the open succeeds and the file is
> created.  With g++ 3.2.2 or Sun CC 5.1 normal, the open fails and the
> file is not created.
>
> Logically, I would expect that even with a new compiler, using -DOLD
> would suffice for the code to work.  At least if the compiler vendor had
> any consideration for its users.  Regretfully, this is not the case with
> either g++ 3.2.2 nor Sun CC 5.1.  Frankly, I can't understand it.  Both
> compilers obviously had access to the old code, and could have done
> things correctly.  In the case of Sun CC 5.1, the old code is even
> delivered with the compiler, since if I specify -compat=4, I get it;
> what stopped them from compiling for the new compiler as well?

I agree that a stated attempt to conform to old conventions should get
the old behavior.

> (If I remember right, VC++ 5.0 and 6.0 got this right.  It's sort of
> painful for an old Unix user like me to have to say that Microsoft has
> more respect for its users than the Unix suppliers.  Especially when
> they did so almost five years earlier.)

You can probably blame me for how the C++ Standard reads in this area,
and how VC++ has worked since V4.2.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message
news:<3e9d5060$0$11182$4c41069e@reader1.ash.ops.us.uu.net>...
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0304150116.1e5b93f5@posting.google.com...

> > pjp@dinkumware.com ("P.J. Plauger") wrote in message
> > news:<3e9a97ab$0$28118$4c41069e@reader0.ash.ops.us.uu.net>...
> > > "Joe Bentley" <bart@gotnet.net> wrote in message
> > > news:Ripma.2$qW2.1672@news-west.eli.net...

> > > > I want create an object using the fstream constructor,

> > > > fstream file("afile", ios_base::in|ios_base::out);

> > > > Does the file "afile" have to exist, as in an ifstream
> > > > instantiation, or will the file be created?  I have tried this
> > > > on different compilers with different results.

> > > The file must exist.

> > > > MS Visual C++ and gnu 3.22b (for DOS) does not create a new
> > > > file, but Borland's 5.5.1 command-line compiler does create the
> > > > file.  I cannot find reference to this in the C++ standard.
> > > > What is the answer and where can I find a reference?

> > > See 27.8.1.3. Table 92 there shows that in|out is equivalent to a
> > > C fopen call with mode "r+". The C Standard says this mode does
> > > not create the file.

> > Is there some real reason for this, or is this just another case of
> > gratuous incompatibility with the pre-standard libraries?  Did the
> > C++ standards committee realize that there were people writing code
> > for the iostreams before they even thought of standardizing it?

> Yes, and as you can see here was an area where existing practice was
> far from consistent. One of the roles of standardization is to choose
> one form of behavior that's defensible.

Did pre-standards behavior differ here?  I've never encounter anything
other than what the USL library did (which is NOT what the standard
does).

And what implementation used templates in iostream, or did code
translation in filebuf?  Are you trying to tell me that iostream is just
a synthesis of previous existing practices?  How did I manage never to
have seen any of them (despite having used CFront, G++, Zortech, and two
or three other compilers)?

> In this case, we chose to reconcile the C++ Standard with the C
> Standard.

Rather than with the most widespread existing practice?

> > .....
> > With g++ 2.95.2 or Sun CC 5.1 mode compat=4 (compatible with version
> > 4.2), compiled with the option -DOLD, the open succeeds and the file
> > is created.  With g++ 3.2.2 or Sun CC 5.1 normal, the open fails and
> > the file is not created.

> > Logically, I would expect that even with a new compiler, using -DOLD
> > would suffice for the code to work.  At least if the compiler vendor
> > had any consideration for its users.  Regretfully, this is not the
> > case with either g++ 3.2.2 nor Sun CC 5.1.  Frankly, I can't
> > understand it.  Both compilers obviously had access to the old code,
> > and could have done things correctly.  In the case of Sun CC 5.1,
> > the old code is even delivered with the compiler, since if I specify
> > -compat=4, I get it; what stopped them from compiling for the new
> > compiler as well?

> I agree that a stated attempt to conform to old conventions should get
> the old behavior.

> > (If I remember right, VC++ 5.0 and 6.0 got this right.  It's sort of
> > painful for an old Unix user like me to have to say that Microsoft
> > has more respect for its users than the Unix suppliers.  Especially
> > when they did so almost five years earlier.)

> You can probably blame me for how the C++ Standard reads in this area,
> and how VC++ has worked since V4.2.

With regards to VC++, as I said, it is one thing I think they got
right.  Unlike many others:-(.

With regards to how the standard reads, I'll admit that I'm kind of
sensitive on this issue.  I wrote a lot of code before there was a
standard, and I tend to make fairly sophisticated use of the iostream
library.  As you can imagine, I'm not particularly happy that all of my
previous code got broken.  If it were just this one issue, I could
probably live with it, but when you add it to all of the rest...

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]