Mail Archives: djgpp/1997/11/04/11:41:30
On 11/4/97 1:27:57 PM Eli Zaretskii wrote:
>On Mon, 3 Nov 1997, Nate Eldredge wrote:
>
>> I found the cause, but I still don't know if it's a bug. In
>> src/libc/ansi/stdlib/exit.c, __stdio_cleanup_hook is called before the
>> destructors. You guessed it, __stdio_cleanup_hook flushes all streams,
and
>> closes all except stdin, stdout, and stderr (cin, cout, cerr for C++).
If
>> this is not what's Supposed To Happen, it should be easy to change, just
>> move two lines of code. *Are* files Supposed to work in destructors?
>
>IMHO, people who use C++ extensively should answer this. There might
>be conflicts with objects that use I/O streams and are destructed by
>global destructors. DJ?
>
>Is it at all safe to assume that file handles beyond the 3 standard
>streams are available in the global destructor? After all, they *are*
>run after `main' returned, so at least in principle, this is a
>never-never land for the application, no?
>
This is from the latest CD2 (december 96). [ CD2 == Commity Draft ]
[start quote:
3.6.3 Termination [basic.start.term]
1 Destructors (_class.dtor_) for initialized objects of static storage
duration (declared at block scope or at namespace scope) are called as
a result of returning from main and as a result of calling exit
(_lib.support.start.term_). These objects are destroyed in the
reverse order of the completion of their constructor or of the comple-
tion of their dynamic initialization. If an object is initialized
statically, the object is destroyed in the same order as if the object
was dynamically initialized. For an object of array or class type,
all subobjects of that object are destroyed before any local object
with static storage duration initialized during the construction of
the subobjects is destroyed.
end quote]
Note the line "reverse order of the completion of their constructor ..."
since the constructor of the static global object in the sample is
completed AFTER the completion of the stream constructor, its destructor
should be called first. This assures that the file stream (and the file
handle)
is valid inside the destructor of the static global object.
I tested the sample also with Borland C++ 5.02 and it did write to the file
inside the destructor
I think that this sample should be checked with g++ on unix, to see if it
is DJGPP specific problem.
Eyal
- Raw text -