Subject: Re: Abi string class
From: Mike Nordell (tamlin@algonet.se)
Date: Thu Feb 01 2001 - 03:25:19 CST
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 version. 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 - 03:24:58 CST