[patch] PR 8761 and 7076, take 4

[Nathan Myers]

On Fri, Jan 24, 2003 at 12:45:11AM -0500, Jerry Quinn wrote:
> I've placed the format cache constructor in an auto_ptr.  This protects 
> against leaking the cache.  The next call, to _Format_cache::_M_init(), 
> calls has_facet<T> under the covers.  This function has an exception 
> specification of throw(), but doesn't seem to have code that will 
> actually throw an exception.  Other than this, the function appears 
> safe to me.
> 
> I'm not incredibly exception-savvy, so if this isn't acceptable, can someone
> offer me a bit more idea of what should I do here?
> [...]
> +      if (!_M_format_cache)
> +	{
> +	  auto_ptr<_Format_cache<_CharT> > __fc(new _Format_cache<_CharT>());
> +	  // This will call has_facet, which has a throw() declaration, but I
> +	  // don't see how it could actually throw an exception.
> +	  __fc->_M_init(*this);
> +	  this->_M_format_cache = __fc.release();
> +	}

Am I mistaken in thinking that _M_init() calls _M_populate (when _CharT
is not in {char,wchar_t}), which calls various facet members, which 
might throw?  Maybe _M_format_cache should itself be an auto_ptr<>.  
That sort of thing is what auto_ptr<> is for.  That would also simplify
~ios_base().

> +    // Basic_ios stores the format cache, but sometimes, all we have is the
> +    // ios_base.  This provides access and casting.  A little bit ugly as you
> +    // must assign this to a _Format_cache<_CharT> for the cast to happen
> +    // cleanly.  Not safe to call until basic_ios::_M_init() has happened.
> +    _Format_cache_base& _M_cache() { return *_M_format_cache; }

I think this comment is mostly wrong now, except for the last sentence.

> +  // NB: Of the two parameters, _CharT can be deduced from the
> +  // function arguments. The other (_Traits) has to be explicitly specified.

Let's replace this comment with:

  // NB: __pad is meant to be partially-specialized, for optimization.

Apologies for being such a pest.

Nathan Myers
ncm-nospam@cantrip.org