> We already have the string implementation, LString in 1.1 is a
> standard string (infunctionality not in implementation), I only know
> of two major missing things: some funcs returning iterators return
> wrong value, and reverse iterators is missing.
Great. We don't need reverse iterators, IMO.
> To make it work for char_traits too involves a lot of more work (to
> get wchar working.)
We don't need char_traits, IMO.
If LString is complete as a standard string, except for the char_traits and the
reverse iterators, I think we should do our own string and wstring based on it.
Then, we should declare LString from one of these.
After that, we should hack configure to make sure that we have a proper string,
and if not, use our own.
Any takers for parts of these jobs?
> Personally I don't think we should put too much
> effort into making this. (imo wasted effort)
It's not a lot of work, at least not mentally. It's just a question of
search&replace...
> Of course it is a problem
> that only some compiles have woring standard libraries. However this
> is likely to be a temporary problem only, at lot of c++ compiles has
> been updated to near standard conforming. and they continue to get
> closer. IMHO we should use gcc until impossible to use it anymore and
> then require a compiler that is as standard compilant as egcs.
I agree with you on this, but it's too early to require standard C++: Not even
egcs 1.1 has it (judging from what Allan wrote: He had an error with the
"using std::wstring;" statement.)
So, for now, if we want to use wstring, we have to provide our own.
And I really want to use wstring.
--
I have thought a bit about how our basic, fundamental document text
representation data structure should look like. My best bet so far is this:
A document is a list of paragraphs.
A paragraph is a list of insets!
In order for this to work, we would declare a basic InsetString. This inset
would be able to hold nothing but an LString and a character level properties
reference. In reality this inset owuld would be the bulk of the InsetText.
At first, it would look like I have dropped the idea of having a tree as the
documentation representation, but I haven't. The reason is simple: An inset
can be a footnote, and a footnote itself contains a list of paragraphs.
Now, the good question is whether a paragraph should be an inset in itself. I
don't know.
Similar for the document: Should a document be an inset in itself? Again, I
don't know.
They probably should, but this makes designing the Inset base class more
complex.
Greets,
Asger
