Subject: Re: Abi string class
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Thu Feb 01 2001 - 01:03:45 CST
Hi Mike,
A few small questions and suggestions (on this otherwise great class)
1) Could we also have a method called length() in addition to/instead of
size()?
2) What might you suggest doing about handling UT_UCSChar * more sanely as
well?
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:
#define UT_Bool bool
#define UT_TRUE true
#define UT_FALSE false
in ut_types.h? Or is there something that I'm overlooking?
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 ()?
Dom
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.
Dom
>From: "Mike Nordell" <tamlin@algonet.se>
>To: "AbiWord-dev" <abiword-dev@abisource.com>
>Subject: Abi string class
>Date: Thu, 1 Feb 2001 07:50:44 +0100
>
>Well, I've now taken the few hours it took to assemble something that at
>least resembles a string class to use in AbiWord.
>
>Why?
>
>None of the existing string classes I've seen are fit for use in AW.
>std::string is a no-no since it's using templates, exceptions and the world
>is still full of bad implementations. For us to have a string class it need
>to match at least the following criteria:
>
>- Be completely portable. That means only ANSI C and a small subset of
>C++.
>- Not use new/delete since we don't allow exceptions.
>- Not use new(std::nothrow) since ancient libraries don't support it.
>- Not use the bool type, portability.
>
>and some others that get lost with these major design restrictions.
>
>This class is currently a very light wrapper around a plain char*, but I
>have tried to make it as efficient and exception safe as possible.
>Unfortunately there's a tradeof between semantics/syntax of its use, and a
>completely "safe" implementation. We want to be able to write
>
> UT_String s1("foo");
>or
> s1 = "bar";
>
>but to do this we would have to use exceptions to be "safe". Since we can't
>use exceptions this implementation is "somewhat" unsafe (it keeps a safe
>internal state, but in case of out-of-memory conditions it keeps its old
>value). To fix this we would have to forbid anything but the default
>constructor, and we would have to write assignment as
>
> if (!s1.assign("bar"))
>
>I traded safety for readability. If this turns out to be an issue of
>controversy I'll do it the "safe" way, but it would hurt readability much
>IMO.
>
>I also have some ideas of an XML_Char class if this one turns out to be
>useful. Such a class could replace more than a few wasteful static buffers
>we currently have that most of the time aren't even half-full.
>
>I've written test cases, and it passes all of'em. But, I'd like your input
>on the interface.
>
>
>class UT_String
>{
>public:
>#ifdef UT_STRING_FOR_ABIWORD
> typedef UT_Bool UT_Str_Bool;
>#else
> typedef bool UT_Str_Bool;
>#endif
>
> UT_String();
> UT_String(const char* sz);
> UT_String(const UT_String& rhs);
> ~UT_String();
> UT_String& operator=(const UT_String& rhs);
> UT_String& operator=(const char* rhs);
> UT_String& operator+=(const UT_String& rhs);
> UT_String& operator+=(const char* rhs);
>
> size_t size() const;
> UT_Str_Bool empty() const;
>
> UT_Str_Bool operator==(const UT_String& rhs) const;
> UT_Str_Bool operator==(const char* rhs) const;
>
> // The returned pointer is only valid until the
> // next UT_String non-const operation.
> const char* c_str() const;
>
>private:
> class UT_StringImpl* pimpl;
>};
>
>
>Comments, ideas or criticism?
>
>/Mike
>P.S.
>Wether accepted as-is or with changes, I plan to post the class with its
>test cases for other platforms to rey before committing anything.
>
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Thu Feb 01 2001 - 01:03:47 CST