In article <[EMAIL PROTECTED]>,
Patrick Beard <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> (Matthew Tuck) wrote:
>
> > Patrick Beard wrote:
> >
> > > Now that this has been fixed, the correct Close() method will get called
> > > upon destruction, so we don't absolutely require explicit calls to
> > > Close(), but I would agree with others that it is good programming
> > > practice to use explicit Close() calls, as it leads to fewer surprises.
> >
> > I agree, and in line with that, it would be nice if closes within a
> > destructor caused an warning, so the client code could be fixed.
> >
> > However, from what I understand of what I've read, it appears there is
> > no method for determining whether a stream is already closed, so it
> > seems this is probably not possible.
>
> I just realized that we have TWO implementations of file streams, one in
> XPCOM (nsFileStream.cpp) and one in Necko (nsFileStreams.cpp), and the
> bug I mentioned was in the Necko version (same author?). The changes
> recently made in the XPCOM version look wrong to me, we should
> definitely do the close in the destructor if it hasn't been done already.
>
> As far as knowing whether a file has been closed, it should be safe to
> call Close() multiple times, that is to say, the method should be
> "idempotent."
The real bug here is that our stream implementations don't have
copy constructors or assignment operators defined, allowing the
compiler to generate default dones that just do memberwise copies.
I think we should define (but not implement) private copy ctors
and assignment operators for all of our stream classes.
I just filed a bug on this:
<http://bugzilla.mozilla.org/show_bug.cgi?id=71064>
Simon
--
Simon Fraser Entomologist
[EMAIL PROTECTED] http://people.netscape.com/sfraser/
