Re: Abi string class


Subject: Re: Abi string class
From: Mike Nordell (tamlin@algonet.se)
Date: Thu Feb 01 2001 - 07:37:12 CST


Mighty sorcerer Tim wrote:
> What I'm curious about, mainly, is what you're trying to acheive *instead*
> of the new/exception behavior.

I'm not sure I should say this, but perhaps I was (gasp) trying to start
some discussion regarding this also (it all comes together, memory
management, exceptions and mutable classes using dynamically allocated
memory). It's impossible in this case to both have nice semantics/syntax and
still not use exceptions. Since we want to use the nicer syntax and can't
use exeptions, we unfortunately currently have to live with the fact that
string operations can fail without being able to report it. We'll see how it
ends.

> Earlier, you said that preserving the
> last stable state is only semi-safe--what is completely safe?

Exceptions. If you try to modify an object and that can't be done (such as
out of mem) the object hasn't got the users intended state. Yet, with and
operation like

    string& operator+=(const string&)

The only way you could ever report failure is using exceptions. The return
value from the operator will still return a legal string, just not the
string you would expect. i.e.
  string s3 = string("foo") + string("bar");
might result in s3 == "foo", not "foobar" as you'd expect if it was correct.

The two possibilities are
1) allow exceptions to report out-of-mem conditions.
2) don't allow this syntax, require
   bool append(const string& rhs);
and report any error via the returned bool.

> Contingent upon how you answer that question, why aren't you making use of
> the new_handler functionality?

1. M$VC compiler *still* doesn't support it (it has its own implementations
starting with an underscore, but I don't suggest you try it. NT says "Out of
mem, extending swapfile" and by that point you better reboot :-( It's
basically useless)!
2. Compatibility/portability (where #1 is a big one).

> You could catch out of memory conditions
> before an exception is thrown, and cause some other behavior to take place
> instead. Granted, there isn't a whole lot you can do other than die or
> try to free up memory somewhere,

Right, "I" as a string class don't have a clue about what's going on around
me. The only thing I could reasonable do is to (or let the operator new)
throw bad_alloc and let someone up the call chain that knows how to deal
with out-of-memory conditions deal with it.

> but I don't see what using malloc/free
> gets you above that, anyway.

Since new_handler is out of the question, I can at least be sure to either
get memory or a NULL ptr.

> If you want to avoid the new() exceptions, you've either 1) got to NOT use
> new/delete
> 2) use the nothrow version

2 is unfortunately not an option at the moment because of support of non
conforming implementations (though I personally would like to use it).

> or 3) try to catch errors with
> new_handler and do something intelligent in response. Those are your
> options. Given your earlier posts, it sounds like (3) is best, but I
> don't know precisely what your criteria are...

I can't use 3, since we can't use any exception (or handling) in AbiWord for
portability reasons.

As you see, I'm stuck between a rock and a hard place. :-)

We'll see how the negotiations/discussions goes.

Thanks for your input. Please comment if you have any suggestions about the
implementations.

/Mike - please don't cc



This archive was generated by hypermail 2b25 : Thu Feb 01 2001 - 07:36:00 CST