In article <6rl06m$d79$1@engnews1.eng.sun.com>,
  stephen.clamage@sun.com (Steve Clamage) wrote:
>
> AllanW@my-dejanews.com writes:
>
> >The spec says that malloc cannot be implemented in terms of operator
> >new; I believe that the reason for this is to allow programmers to
> >write operator new in terms of malloc.
>
> That's right. You are allowed to write your own operator new
> that replaces one in the standard library. The various forms
> of operator new and delete are the ONLY members of the standard
> library you are allowed to replace without risking undefined
> behavior. (An implementation might allow you replace other
> functions, but you can't depend on it.)

The only ones? How about unexpected(), uncaught_exception(),
terminate(), etc.?

Is there any (non-normative?) place in the spec with a complete
list of all "replaceable" functions?

> The malloc constraint is on C++ implementors. C++ users who write
> their own operator new are thus allowed to use malloc without the
> fear that malloc might in turn call the operator new.

Right. That's important in portable code. If I had that problem on
my local platform, I would know it very quickly; the question is,
just because my code works here, does the standard guarantee that
it will work elsewhere? For the case of implementing operator new
in terms of malloc(), the answer is yes.

> >Does [the standard] say that printf, et. al., cannot be
> >implemented in terms of streams? If it doesn't, it should.
>
> Users of an implementation are not allowed to replace any of those
> functions, and cannot write any valid code that can tell how they
> are implemented. It cannot matter (from the viewpoint of standards
> conformance or portable programs) whether or not printf is written
> in terms of iostream functions. It is up to the implementor to
> make everything work somehow.

I was thinking about what happens if we extend the streams, but as
I think about it, I realize that this doesn't matter. Conceivably
my extension could call printf() or sprintf, which in turn would
call the standard iostreams; but this would not cause the infinite
recursion problem I was thinking about.

So I guess you're right; it doesn't matter if either one of those
two was specified in the other.

Except, perhaps, for space optimization; on any given platform, if
I knew that iostreams were written in terms of printf(), then my
program would get a smaller footprint if I used printf() directly,
but if printf() were written in terms of iostreams, then the
smaller footprint would come from using iostreams directly. This
probably isn't very important, because if I don't know how the
implementation works, or if I do know that neither one uses the
other, then I still have a fallback position: try it both ways
(perhaps with conditional compilation), and use whichever seems to
work better.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:


>In article <6rl06m$d79$1@engnews1.eng.sun.com>,
>  stephen.clamage@sun.com (Steve Clamage) wrote:
>>
>> AllanW@my-dejanews.com writes:
>>
>> >The spec says that malloc cannot be implemented in terms of operator
>> >new; I believe that the reason for this is to allow programmers to
>> >write operator new in terms of malloc.
>>
>> That's right. You are allowed to write your own operator new
>> that replaces one in the standard library. The various forms
>> of operator new and delete are the ONLY members of the standard
>> library you are allowed to replace without risking undefined
>> behavior. (An implementation might allow you replace other
>> functions, but you can't depend on it.)

>The only ones? How about unexpected(), uncaught_exception(),
>terminate(), etc.?

I wouldn't put those in the same category. You don't replace
those functions, you provide parallel versions which might
be called depending on the last call to set_unexpected,
set_terminate, etc. You can still call the default version if
you don't discard the value returned by the "set" function.

In the case of new and delete, the default versions are either
entirely replaced or not replaced at all. Throughout the entire
program, a call to "::operator new(size_t)" refers exclusively to
the default version unless it was replaced during program generation,
in which case it refers exclusively to one and only one replacement
version. (I'm excluding from consideration things like dynamic
libraries that can be linked and unlinked during program execution
-- the C++ standard does not address such a possibility.)

>Is there any (non-normative?) place in the spec with a complete
>list of all "replaceable" functions?

Just the various forms of operator new and operator delete. :-)

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <6rl06m$d79$1@engnews1.eng.sun.com>,
>   stephen.clamage@sun.com (Steve Clamage) wrote:
> >
> > AllanW@my-dejanews.com writes:
> >
> > >The spec says that malloc cannot be implemented in terms of operator
> > >new; I believe that the reason for this is to allow programmers to
> > >write operator new in terms of malloc.
> >
> > That's right. You are allowed to write your own operator new
> > that replaces one in the standard library. The various forms
> > of operator new and delete are the ONLY members of the standard
> > library you are allowed to replace without risking undefined
> > behavior. (An implementation might allow you replace other
> > functions, but you can't depend on it.)
>
> The only ones? How about unexpected(), uncaught_exception(),
> terminate(), etc.?

Those functions cannot be replaced by the user. Those functions call
user-defined handler functions, but are themselves defined only by the
standard library. It's pretty much the same thing that happens when you
define a signal handler.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dietmar_Kuehl@my-dejanews.com wrote:
>
> 'nocreate' is not a compiler specific issue but rather an operating
> system issue: there may be systems where it cannot be tested whether
> the file existed.

<bitch>
This is another case where I think the C++ standards folks were waaay
too solicitous of the limitations of archaic systems. Sure, there may
exist some arcane OS in which it is not possible to see if a file exists
without creating it, but is anyone really trying to write
standard-conforming C++ compilers for such systems? If so, how much of a
tragedy would it be if it were impossible for such systems to live up to
the standard in this minute detail? Compare that to the tragedy of the
remaining 99.44% of all programmers being denied the ability to use this
useful function portably on systems where it is perfectly feasible.
</bitch>

--

Ciao,
Paul


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 17 Aug 1998 16:50:10 GMT, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>Dietmar_Kuehl@my-dejanews.com wrote:

>> 'nocreate' is not a compiler specific issue but rather an operating
>> system issue: there may be systems where it cannot be tested whether
>> the file existed.

><bitch>
>This is another case where I think the C++ standards folks were waaay
>too solicitous of the limitations of archaic systems. Sure, there may
>exist some arcane OS in which it is not possible to see if a file exists
>without creating it, but is anyone really trying to write
>standard-conforming C++ compilers for such systems? If so, how much of a
>tragedy would it be if it were impossible for such systems to live up to
>the standard in this minute detail? Compare that to the tragedy of the
>remaining 99.44% of all programmers being denied the ability to use this
>useful function portably on systems where it is perfectly feasible.
></bitch>

The problem with ios::noreplace and ios::nocreate is that they don't test
for permissions.  Perhaps the file exists, but we don't have permission
to read from it.  So if ifstream("file",ios::in|ios::nocreate) fails, is
it because the file does not exist, or because the file exists but we
don't have read permission for it?  The way to specify permissions depends
on the OS.  Some don't have permissions, some have user/group/everyone,
others have list<user>.  Furthermore, user U1 may want to open a file for
reading -- and the file must exist and be readable by users U1, U2, and U3.
How to specify this within the ios::nocreate framework?



--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
> Paul D. DeRocco (pderocco@ix.netcom.com) wrote:
> This is another case where I think the C++ standards folks were waaay
> too solicitous of the limitations of archaic systems. Sure, there may
> exist some arcane OS in which it is not possible to see if a file exists
> without creating it, but is anyone really trying to write
> standard-conforming C++ compilers for such systems?

Why not? If they have gcc they will have C++ for this system which will
be conforming at some point in the (hopefully near) future. One attempt
made with C++ was to define the standard such that you can have a
conforming implementation where you can have a conforming C implementation.
In C, there are the same restriction with respect to file handling as there
are in C++. Actually, a large portion of C++ I/O is defined in terms of C
I/O and it is possible to implement C++ I/O on top of C I/O (this is eg.
what is done by Dinkumware to implement IOStreams).

> If so, how much of a
> tragedy would it be if it were impossible for such systems to live up to
> the standard in this minute detail?

What do you mean? If I understand you correctly, you want the standard to
define the 'nocreate' flag with some appropriate semantics and you want to
allow that an implementation does not meet the corresponding requirements
(eg. because the underlying system does not provide a way to guarantee the
correct behavior). This is basically what you have! A guarantee which is
not given by all conforming implementation does not buy you anything
because it is, well, no guarantee.

> Compare that to the tragedy of the
> remaining 99.44% of all programmers being denied the ability to use this
> useful function portably on systems where it is perfectly feasible.

There can be additional standard libraries. Although there is currently
no activity I know of, there may be POSIX or X/Open standards for C++
libraries which include additional features. This is what happened with C:
There is a standard library and there are POSIX and X/Open libraries for
C, too. These define additional functionality which can be provided eg.
on all POSIX systems. I can imagine that there will be corresponding C++
standard libraries in the future, too. Also, you have to remember that
many people in the C++ standardization committee want to sell their own
libraries: Putting everything into the standard means to share the
market with others...

Note, BTW, that there were even people opposed to a standard library
at all! It turned out that some very basic parts have to go into a
standard library (the language support stuff like the standard new and
delete operators, the rtti classes, and the exception classes thrown by
the standard). Fortunately, there was a majority for a basic standard
library...
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6rbtjs$ui1$1@nnrp1.dejanews.com>,
  dietmar.kuehl@claas-solutions.de wrote:
>
> Hi,
> > Paul D. DeRocco (pderocco@ix.netcom.com) wrote:
> > This is another case where I think the C++ standards folks were waaay
> > too solicitous of the limitations of archaic systems. Sure, there may
> > exist some arcane OS in which it is not possible to see if a file exists
> > without creating it, but is anyone really trying to write
> > standard-conforming C++ compilers for such systems?
>
> Why not? If they have gcc they will have C++ for this system which will
> be conforming at some point in the (hopefully near) future. One attempt
> made with C++ was to define the standard such that you can have a
> conforming implementation where you can have a conforming C implementation.
> In C, there are the same restriction with respect to file handling as there
> are in C++. Actually, a large portion of C++ I/O is defined in terms of C
> I/O and it is possible to implement C++ I/O on top of C I/O (this is eg.
> what is done by Dinkumware to implement IOStreams).

Not really.  It uses fread and fwrite to read the buffers, but (unlike
some very early implementations) it doesn't use the printf family for
formatting.

(It really shouldn't be necessary to say this, but when Dietmar says that
most of the C++ I/O is defined in terms of C, he isn't kidding.  The meaning
of the various flag bits are mapped to printf/scanf formatting specifiers,
so a statement that an implementation of iostream is based on the C IO
could easily be misunderstood.)

> > If so, how much of a
> > tragedy would it be if it were impossible for such systems to live up to
> > the standard in this minute detail?
>
> What do you mean? If I understand you correctly, you want the standard to
> define the 'nocreate' flag with some appropriate semantics and you want to
> allow that an implementation does not meet the corresponding requirements
> (eg. because the underlying system does not provide a way to guarantee the
> correct behavior). This is basically what you have! A guarantee which is
> not given by all conforming implementation does not buy you anything
> because it is, well, no guarantee.

Well, there's certainly a precedent.  Read the spec of time, for example
(returns the system time if available, or (time_t)(-1) if not).

> > Compare that to the tragedy of the
> > remaining 99.44% of all programmers being denied the ability to use this
> > useful function portably on systems where it is perfectly feasible.
>
> There can be additional standard libraries. Although there is currently
> no activity I know of, there may be POSIX or X/Open standards for C++
> libraries which include additional features. This is what happened with C:
> There is a standard library and there are POSIX and X/Open libraries for
> C, too. These define additional functionality which can be provided eg.
> on all POSIX systems. I can imagine that there will be corresponding C++
> standard libraries in the future, too. Also, you have to remember that
> many people in the C++ standardization committee want to sell their own
> libraries: Putting everything into the standard means to share the
> market with others...
>
> Note, BTW, that there were even people opposed to a standard library
> at all! It turned out that some very basic parts have to go into a
> standard library (the language support stuff like the standard new and
> delete operators, the rtti classes, and the exception classes thrown by
> the standard). Fortunately, there was a majority for a basic standard
> library...

I don't think that anyone was opposed to having a standard library.  After
all, what use would a language be without IO.  I think that the problem
was more the opposite; for a very long time, that (and string) were all
there was in the proposed standard library.

Of course, not everyone is totally convinced that the STL provided the
best possible basis for a standard library.  I can even imagine some
people preferring no standard library to the one we got, and I personally
would have preferred that they simplified a bit more, and maybe had made
it a bit safer.  (Two obvious IMHO improvements: drop the Allocator stuff
completely, and make the operator[] the safe one, and at -- which should
be renamed to unsafe_at -- the unsafe one.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote in article <6rhlc9$ll4$1@nnrp1.dejanews.com>...
> In article <6rbtjs$ui1$1@nnrp1.dejanews.com>,
>   dietmar.kuehl@claas-solutions.de wrote:
> >              Actually, a large portion of C++ I/O is defined in terms of C
> > I/O and it is possible to implement C++ I/O on top of C I/O (this is eg.
> > what is done by Dinkumware to implement IOStreams).
>
> Not really.  It uses fread and fwrite to read the buffers, but (unlike
> some very early implementations) it doesn't use the printf family for
> formatting.

Not really. The Dinkum C++ Library performs the vast majority of file I/O
by direct transmission to/from the buffers associated with C FILE objects.
The fread/fwrite calls you see at the top of <fstream> are exercised only
in the rarest of circumstances. OTOH, several locale facets call sprintf to
do the actual formatting.

> (It really shouldn't be necessary to say this, but when Dietmar says that
> most of the C++ I/O is defined in terms of C, he isn't kidding.  The meaning
> of the various flag bits are mapped to printf/scanf formatting specifiers,
> so a statement that an implementation of iostream is based on the C IO
> could easily be misunderstood.)

Yes. I argued strongly (and successfully on this rare occasion) to *define*
formatted I/O in terms of scanf/printf calls, because the C committee had
already argued out the corner cases at length and produced a reasonably
precise spec. Nowhere does the C++ Standard *require* the use of scanf
or printf, however.

> > Note, BTW, that there were even people opposed to a standard library
> > at all! It turned out that some very basic parts have to go into a
> > standard library (the language support stuff like the standard new and
> > delete operators, the rtti classes, and the exception classes thrown by
> > the standard). Fortunately, there was a majority for a basic standard
> > library...
>
> I don't think that anyone was opposed to having a standard library.  After
> all, what use would a language be without IO.  I think that the problem
> was more the opposite; for a very long time, that (and string) were all
> there was in the proposed standard library.

There was indeed some sentiment to advance the C++ Standard to completion
without waiting for a library specification. But that was way back about 1993.

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



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> jkanze@otelo.ibmmail.com wrote in article <6rhlc9$ll4$1@nnrp1.dejanews.com>...
> > (It really shouldn't be necessary to say this, but when Dietmar says that
> > most of the C++ I/O is defined in terms of C, he isn't kidding.  The meaning
> > of the various flag bits are mapped to printf/scanf formatting specifiers,
> > so a statement that an implementation of iostream is based on the C IO
> > could easily be misunderstood.)

In article <01bdcc74$36605f00$8a1ec2d0@porky>,
  "P.J. Plauger" <pjp@dinkumware.com> wrote:
> Yes. I argued strongly (and successfully on this rare occasion) to *define*
> formatted I/O in terms of scanf/printf calls, because the C committee had
> already argued out the corner cases at length and produced a reasonably
> precise spec. Nowhere does the C++ Standard *require* the use of scanf
> or printf, however.

The spec says that malloc cannot be implemented in terms of operator
new; I believe that the reason for this is to allow programmers to
write operator new in terms of malloc.

Does it say that printf, et. al., cannot be implemented in terms
of streams? If it doesn't, it should.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

>The spec says that malloc cannot be implemented in terms of operator
>new; I believe that the reason for this is to allow programmers to
>write operator new in terms of malloc.

That's right. You are allowed to write your own operator new
that replaces one in the standard library. The various forms
of operator new and delete are the ONLY members of the standard
library you are allowed to replace without risking undefined
behavior. (An implementation might allow you replace other
functions, but you can't depend on it.)

The malloc constraint is on C++ implementors. C++ users who write
their own operator new are thus allowed to use malloc without the
fear that malloc might in turn call the operator new.

>Does it say that printf, et. al., cannot be implemented in terms
>of streams? If it doesn't, it should.

Users of an implementation are not allowed to replace any of those
functions, and cannot write any valid code that can tell how they
are implemented. It cannot matter (from the viewpoint of standards
conformance or portable programs) whether or not printf is written
in terms of iostream functions. It is up to the implementor to
make everything work somehow.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Brian lLuethke" <Luethke@worldnet.att.net> writes:
>> is there a way the standard defines that is similar to nocreate? I
>> cannot see having to open a file read ony, check for a fail, close
>> it, the open the file for writing. Or am i ignorant of something else
>> in the standard?( i've never used any compilers besides Borland and
>> GNU c++ wich had ios::nocreate. )

Steve Clamage wrote:
> No. The iostream functionality is exactly the same as fopen in
> C stdio. The only fully portable way in iostreams or stdio
> to open a file for writing only if it already exists is to
> attempt to open for reading first.

Does this include (or imply) using 'fopen(file, "r+")' ?  If so,
what are the equivalent fstream::open() mode settings (I think
they are 'ios::in|ios::out')?

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

>Steve Clamage wrote:
>> No. The iostream functionality is exactly the same as fopen in
>> C stdio. The only fully portable way in iostreams or stdio
>> to open a file for writing only if it already exists is to
>> attempt to open for reading first.

>Does this include (or imply) using 'fopen(file, "r+")' ?  If so,
>what are the equivalent fstream::open() mode settings (I think
>they are 'ios::in|ios::out')?

Section 27.8.1.3 defines the equivalence of file open modes
between iostreams and stdio, and says that ios::in|ios::out
is equivalent to "r+".

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <6qpn46$b77$1@nnrp1.dejanews.com>,
  saroj@bear.com wrote:
> I have to use ios::nocreate flag in the ifstream constructor in VC++
> to be able to check for non-existance of the file. In other compilers
> (like Sun C++), I do not need this. So my question is what does the
> standard say about this? Whether it is standard compliant or not, it
> seems to be a pain to specify nocreate flag in VC++. I think it should
> be the default.

According to the standard, nocreate is the default when opening a file not for
writing (read only). When opening a file for writing it is created if it does
not exist. The standard does not define a flag named nocreate.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dietmar_Kuehl@my-dejanews.com wrote in message
<6qrod1$fcl$1@nnrp1.dejanews.com>...
>
>Hi,
>In article <6qpn46$b77$1@nnrp1.dejanews.com>,
>  saroj@bear.com wrote:
>> I have to use ios::nocreate flag in the ifstream constructor in VC++
>> to be able to check for non-existance of the file. In other compilers
>> (like Sun C++), I do not need this. So my question is what does the
>> standard say about this? Whether it is standard compliant or not, it
>> seems to be a pain to specify nocreate flag in VC++. I think it should
>> be the default.
>
>According to the standard, nocreate is the default when opening a file not
for
>writing (read only). When opening a file for writing it is created if it
does
>not exist. The standard does not define a flag named nocreate.
>--

><mailto:dietmar.kuehl@claas-solutions.de>
>homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
>


is there a way the standard defines that is similar to nocreate? I cannot
see having to open a file read ony, check for a fail, close it, the open the
file for writing. Or am i ignorant of something else in the standard?( i've
never used any compilers besides Borland and GNU c++ wich had
ios::nocreate. )

luethke@worldnet.att.net




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Brian lLuethke" <Luethke@worldnet.att.net> writes:

>is there a way the standard defines that is similar to nocreate? I cannot
>see having to open a file read ony, check for a fail, close it, the open the
>file for writing. Or am i ignorant of something else in the standard?( i've
>never used any compilers besides Borland and GNU c++ wich had
>ios::nocreate. )

No. The iostream functionality is exactly the same as fopen in
C stdio. The only fully portable way in iostreams or stdio
to open a file for writing only if it already exists is to
attempt to open for reading first.

If you are less concerned with complete portability, C libraries
typically support the "stat" function which will tell you
whether a file exists.

The "nocreate" flag was judged to be a Unix-ism. Since it
wasn't present in standard C, it was not included in standard
iostreams.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <6qt598$9pi@bgtnsc02.worldnet.att.net>,
  "Brian lLuethke" <Luethke@worldnet.att.net> wrote:
> is there a way the standard defines that is similar to nocreate?

Question: What effect does 'nocreate' have exactly? I suppose, opening a file
with the 'nocreate' flag fails if the file exists. The only way you can test
this is to open a file for reading only. If you know that an existing file
contains at least one byte (ie. is not empty), you can use the following
approach: Open the file with the 'ios_base::ate' flag set and test whether the
result of 'tellp()' is equal to 'traits::pos_type(0)' (using the corresponding
traits class). If it is not, the file contains at least one character which is
only possible if it existed before.

> I cannot
> see having to open a file read ony, check for a fail, close it, the open the
> file for writing. Or am i ignorant of something else in the standard?( i've
> never used any compilers besides Borland and GNU c++ wich had
> ios::nocreate. )

'nocreate' is not a compiler specific issue but rather an operating system
issue: there may be systems where it cannot be tested whether the file
existed. I was used to test whether a file has group read access or execute
rights. No point in doing this when using a Windoze system, independent from
the compiler... -- <mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

I have to use ios::nocreate flag in the ifstream constructor in VC++
to be able to check for non-existance of the file. In other compilers
(like Sun C++), I do not need this. So my question is what does the
standard say about this? Whether it is standard compliant or not, it
seems to be a pain to specify nocreate flag in VC++. I think it should
be the default.

Thank you,
Saroj Mahapatra


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

saroj@bear.com wrote in message <6qpn46$b77$1@nnrp1.dejanews.com>...
>I have to use ios::nocreate flag in the ifstream constructor in VC++
>to be able to check for non-existance of the file. In other compilers
>(like Sun C++), I do not need this. So my question is what does the
>standard say about this? Whether it is standard compliant or not, it
>seems to be a pain to specify nocreate flag in VC++. I think it should
>be the default.

You are using the wrong include files! Never include <fstream.h> but rather
<fstream>. The <fstream.h> (and <iostream.h> etc) are old files provided for
compatibility, you should use the ones without extension which refers to the
ANSI standard library. And the ios::nocreate flag is _not_ part of the ANSI
standard, so there no point in using it.

Hope this helps.

--
Alberto Barbati
albbarb@tin.it





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]