Hi,
Kevin Jacobs (jacobs@darwin.EPBI.CWRU.Edu) wrote:
:  27.1.2.1  Imbue Limitations                [lib.iostream.limits.imbue]
:   No   function   described  in  clause  _lib.input.output_  except  for
:   ios_base::imbue   causes   any   instance   of   basic_ios::imbue   or
:   basic_streambuf::imbue to be called.  If any user function called from
:   a function declared in clause _lib.input.output_ or as  an  overriding
:   virtual  function  of  any class declared in clause _lib.input.output_
:   calls imbue the behavior is undefined.

: Does this mean that I cannot call imbue in the constructor of a derived
: class from, say, basic_ostream?

I think it is legal to call 'imbue()' from a constructor of a derived
class (except, of course, those defined by the standard):  This is not
a function defined in clause 27 and I think a constructor of a derived
class calls the ones of the base class, not vice versa. However, I
would not call 'imbue()' from such a constructor anyway...

: I think this implies that its not ok to
: call imbue from an io-manipulator called by operator<< or operator>>.

This is correct. However, you can easily implement your own manipulator
function for which it would be legal (eg. by making your manipulator a
static object of a class with an overloaded shift operator).

: ie:  For binary streams implemented via the locale system I would like to do
:      something like:

: cout << binary << 0
:      << ascii  << 1 << endl;

: would result in "\000\000\000\0001\n"

: where "binary" would alter the locale facets for num_put and possibly codecvt
: and "ascii" would restore the originals facets.

Clever idea but I don't think it is reasonable to mix binary IO and
formatted IO in such a way, especially as this will result in weird
behavior for third party inserters/extractors: The output would be a
mix of formatted IO and binary IO. For example, when writing a complex
number, it may appear as '(1.0,0.0)' in formatted mode and some binary
stuff with parenthesis and a comma in binary mode. It becomes really
interesting if the extractor does some minimal parsing like scanning
for a specific set of characters. This is the reason why I decided for
me that this is definitely not the correct approach to binary IO...
Instead, I use a completely different class hierarchy for binary IO.
--
<mailto:dietmar.kuehl@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ 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              ]

I hate to post twice in one day on related subjects before getting an
answer, but I have a question on how to interpret 27.1.2.1 of CD2 (and
FDIS) that is nagging at me.

 27.1.2.1  Imbue Limitations                [lib.iostream.limits.imbue]
  No   function   described  in  clause  _lib.input.output_  except  for
  ios_base::imbue   causes   any   instance   of   basic_ios::imbue   or
  basic_streambuf::imbue to be called.  If any user function called from
  a function declared in clause _lib.input.output_ or as  an  overriding
  virtual  function  of  any class declared in clause _lib.input.output_
  calls imbue the behavior is undefined.

Does this mean that I cannot call imbue in the constructor of a derived
class from, say, basic_ostream?  I think this implies that its not ok to
call imbue from an io-manipulator called by operator<< or operator>>.
Assuming my understanding is correct, what then would be the sanctioned
way(s) of getting around this limitation?

ie:  For binary streams implemented via the locale system I would like to do
     something like:

cout << binary << 0
     << ascii  << 1 << endl;

would result in "\000\000\000\0001\n"

where "binary" would alter the locale facets for num_put and possibly codecvt
and "ascii" would restore the originals facets.

Thanks,
Kevin Jacobs

--
----------->  Kevin Jacobs  <-----------|------->  (216) 778-8487  <--------
S.A.G.E. Project Technical Coordinator  | Department of Epidemiology
  & System Administrator                |   & Biostatistics
Internet E-mail: jacobs@darwin.cwru.edu | Case Western Reserve University
----------------------------------------------------------------------------
---
[ 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              ]