Re: Writing to ostreams from operator new.

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Hi Carlo,

I am sorry for the delay in reviewing this straightforward submission.

>> If you write a patch that improves the quality of the implementation
>> without hurting anything else, then I would tend to believe that your
>> patch would be acceptable.

> I made a patch that addresses to first of the mentioned problems.
> The patch is relative to a recent version of the 3.1 CVS source tree.

First observation, your patch neither improves nor decreases QoI of
libstdc++-v3 if adding a non-standard entry point (i.e. an extension
known to users) is considered completely neutral.  It is my
observation that adding such extensions are rarely neutral.  However,
your request to add a properly-named method to merely report
initialization status would appear on the face to be a minor issue for
the library either way we slice it.  On that analysis, I would have no
problem with your patch being applied to mainline.  The long-term
effort to maintain this new non-standard entry point should be zero.

The long-term C++ library maintainers would have to review it as well
(since I have only ever considered patches that improve portability or
internal implementation).  I have included the part of your patch that
adds the entry point and would ask them to provide the final
approval/rejection.

I would still question how you intend to intermingle implementation of
the libraries (I seem to recall a thread where we discussed whether it
was even legal for your library to override libstdc++-v3's operator
new).  But it is unclear that this patch should be judged by how you
might use it as long as your new library is taking the burden of
future support of the entanglement (which you are).  You have your
reasons and prospective users of your library will have to judge
whether they accept a non-strict layering as I would advocate against.

> [...] That means that instead of creating an ios_base::Init::Init
> object inside operator new (in order to use std streams), the
> operator new should test whether or not the std streams are already
> initialized and not use them until they are.

Index: include/bits/ios_base.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/ios_base.h,v
retrieving revision 1.13
diff -u -d -p -r1.13 ios_base.h
--- ios_base.h	2001/09/25 23:51:17	1.13
+++ ios_base.h	2001/10/17 14:10:37
@@ -301,6 +301,13 @@ namespace std
       static void
       _S_ios_destroy();
 
+      // _S_initialized() is an extension to allow debugger applications
+      // to use the standard streams from operator new.  _S_ios_base_init
+      // must be incremented in _S_ios_create _after_ initialization is
+      // completed.
+      static bool
+      _S_initialized() { return _S_ios_base_init; }
+
     private:
       static int 	_S_ios_base_init;
       static bool	_S_synced_with_stdio;

Index: testsuite/27_io/ios_init_initialized.cc

[New test removed since no comment needed.  Looks like you followed
 all library conventions for a new test.]

If this patch is installed, you should consider adding documentation
to libstdc++-v3/docs/html/ext/howto.html (or is there somewhere
better?).

Thank you for being patient while I thought about this.

Regards,
Loren