Subject: Re: Abi string class
From: Mighty sorcerer Tim (troberts@du.edu)
Date: Thu Feb 01 2001 - 06:48:21 CST
Hi,
I lurk this list, which is why you've never heard of me. When I saw this
thread, though, you piqued my curiosity.
What I'm curious about, mainly, is what you're trying to acheive *instead*
of the new/exception behavior. Earlier, you said that preserving the
last stable state is only semi-safe--what is completely safe?
Contingent upon how you answer that question, why aren't you making use of
the new_handler functionality? 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, but I don't see what using malloc/free
gets you above that, anyway.
If you want to avoid the new() exceptions, you've either 1) got to NOT use
new/delete 2) use the nothrow version 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...
-tim
On Thu, 1 Feb 2001, Mike Nordell wrote:
> Coming to think of it, I have one question regarding this class.
>
> To be exception safe I need to use malloc, but then I need to use the
> in-plce placement new (to initialize the pimpl). An exmaple is perhaps
> better. The way I'd like to do it (and since we currently don't care about
> exceptions and still use "new" all over the place perhaps this is what I
> should do)
>
> UT_String::UT_String()
> : pimpl(new UT_StringImpl)
> {}
>
> but that's not exception safe. The only other way to accomplish this would
> be to write
> UT_String::UT_String()
> : pimpl(malloc(sizeof(*pimpl)))
> {
> new(pimpl) UT_StringImpl;
> }
>
> in every constructor. But this requires the C++ library to provide a
> (somewhat) conforwing header file <new> with this in-place placement
> operator new.
>
> I'm leaning against letting the exception safety (again) sacrifice in favor
> of the more readable versiion. That version also doesn't have the
problem
> that it depends on <new>. Comments please.
>
> Dom Lachowicz wrote:
> > 1) Could we also have a method called length() in addition to/instead of
> > size()?
>
> That would be in addition to. I tried to keep to the naming of C++, and
> size() is what std C++ lib uses. I could of course add a length() forwarder
> to size(), but I won't do it without a fight. :-)
> The only reasons worth mentioning are 1) std C++ use size(), 2) using two
> member functions for the same functionality is bloat and will only add to
> the confusion when trying to understand what the code does.
> Why? Does Java use length()?
>
> > 2) What might you suggest doing about handling UT_UCSChar * more sanely as
> > well?
>
> Wow. That's a big one. Actually, I'd really *really* like to do this. Now,
> correct me if I'm wrong, but UT_UTSChar is UTS-2, i.e. 16-bit Unicode. If
> that's the case, I'd propose I create the interface and write the windows
> implementation (since win32 *is* native Unicode (OK, the partial win-16
> shells win9x and fuck^H^H^H^Hwindows-me don't have complete Unicode
> support)) and thereby drop a *considerable* amount of redundant code in
> win32, and someone else fix the implementation for platforms that don't have
> this natively but depends upon external libraries (or perhaps even I could
> do this also, time permitting). How does that sound?
>
> There are however a few problems that I've tried to raise earlier, but it
> met so little resistance it wasn't even fun. :-)
> IIRC this datatype is used to express both "native" endian-ness (little
> endian on x86) _and_ persistent-endianness format (big endian). To me, this
> is clearly two different datatypes. Unfortunately that distinction hasn't
> been done in AW (yet?). I'm not sure if I remember it right, it could have
> been an of the XML char type that had these problems, but I am sure I came
> across it while debugging (possibly into one of our C libraries). Could
> anyone shed some light about what I'm talking about?
>
> > 3) Why the UT_STRING_FOR_ABIWORD approach to the UT_Bool? If your compiler
> > supports bool (which VC6 most definitely does), wouldn't it be better to:
> [...]
>
> What's worse, the plague or colera? This was actually an attempt at sparking
> the old bool vs. UT_Bool question again. You actually have to write
>
> foo != 0 ? UT_TRUE : UT_FALSE;
> or the shorter
> foo ? UT_TRUE : UT_FALSE;
>
> to get the UT_Bool datatype, while using a native bool you'd simply use
>
> foo != 0;
>
> to get a "bool". I was sick and tired of writing the ?: expression once
> again why I used the real bool type. Besides, any compiler supporting bool
> will anyhow use bool as it's internal type, even if we write code to not use
> it (logical expressions results in bool, not int) why it's impossible to not
> use bool in AW.
>
> Also, I hate to be forced to depend upon the ut_types.h header files in
> every header file just because I want to return a bool (decoupling and
> compile-time dependencies again). Since the UT_Bool is a typedef and not a
> class, you can't fwd. decl. it either.
> But, I can replace that "wierd" type with our UT_Bool (but I'd be darned if
> I replace the implementation with the ?: construction, I'll rely on integer
> promotion from false->int(0) and true->int(1)).
>
> Since I'm now getting up to revs. again, and its over three years since the
> C++ language standard was accepted (the macro __cplusplus expands to 199711L
> on a conforming implementation) would it be possible to reopen this
> discussion?
> Are we currently supporting any compiler without the bool keyword? If not,
> what would be the risk we would ever encounter such a beast in the future
> (when compilers hopefully have become even more, not less, conforming)?
>
> We require at least MSVC++ 5.0 for a win32 build, and that one supports bool
> why windows is in the clear. Gcc most certainly supports it why BeOS, AIX,
> HP/UX, Mac-X and QNX are OK. I don't know about SunOS, Solaris etc. using
> some of their native compilers, but if gcc is available it's not a problem.
> What compiler without bool support are we supporting, or waiting for?
>
> > 4) Is there a C++ operator that one could override, so that when an
> instance
> > of this class was passed to a method expecting a const char *, you could
> > return the result of c_str ()?
>
> Yes, that would be the "operator const char*()" :-) And I'm not gonna let
> you override it, but I can implement it.
>
> > I really like the pointer to the impl class approach to this. This is such
> a
> > better design than putting all of our info in a private or protected
> block.
> > It'd be like being caught with our pants down.
>
> Yes, the pimpl idiom is good when trying to keep the compile time
> dependencies to a minimum, or when hiding implementations details from
> clients. But, as everything it has a price. In this case the price wasn't
> high, and it was worth every byte I think. Sometimes it's even essential,
> like when implementing ref-counting pointers and such. But it still needs
> some careful judgement of when and how to use it. It doesn't fit everywhere,
> but I think we could easily cut down our compile times by half if we had
> applied it to carefully selected classes (without sacrificing measurable
> performance loss).
>
> /Mike
>
>
>
>
This archive was generated by hypermail 2b25 : Thu Feb 01 2001 - 06:48:23 CST