«

Hi there,

Let say I am writing a word processor. It would be a bad design to
consider that a document is a std::vector of instances of a class
MyChar ? Where a MyChar would look like:

struct MyChar
{
char TheChar;
bool Bold;
bool Italic;
unsigned char Color[3];
};

This design is hardcoded (what if I need another attribute later on)
and it would be very difficult to look for a specify array of char. It
would also eat a lot of memory...
Is this something describe in the literature ? If yes, where can I
find documentation ?

Thanks,

* mathieu:
> Hi there,
>
> Let say I am writing a word processor. It would be a bad design to
> consider that a document is a std::vector of instances of a class
> MyChar ? Where a MyChar would look like:
>
> struct MyChar
> {
> char TheChar;
> bool Bold;
> bool Italic;
> unsigned char Color[3];
> };
>
> This design is hardcoded (what if I need another attribute later on)
> and it would be very difficult to look for a specify array of char. It
> would also eat a lot of memory...
> Is this something describe in the literature ? If yes, where can I
> find documentation ?

FlyWeight pattern.


Cheers & hth.,

- Alf

On Aug 10, 2:22*pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * mathieu:
>
>
>
> > Hi there,
>
> > * Let say I am writing a word processor. It would be a bad design to
> > consider that a document is a std::vector of instances of a class
> > MyChar ? Where a MyChar would look like:
>
> > struct MyChar
> > {
> > * char TheChar;
> > * bool Bold;
> > * bool Italic;
> > * unsigned char Color[3];
> > };
>
> > * This design is hardcoded (what if I need another attribute later on)
> > and it would be very difficult to look for a specify array of char. It
> > would also eat a lot of memory...
> > * Is this something describe in the literature ? If yes, where can I
> > find documentation ?
>
> FlyWeight pattern.

I cannot believe :

1. I got an answer in a couple of minutes,
2. You managed to decipher the description of my issue,
3. There is actually a pattern very well detailed, and with a very
intuitive name

Thanks Alf !

On 10 août, 14:13, mathieu <mathieu.malate...@gmail.com> wrote:
> * Let say I am writing a word processor. It would be a bad design to
> consider that a document is a std::vector of instances of a class
> MyChar ? Where a MyChar would look like:
>
> struct MyChar
> {
> * char TheChar;
> * bool Bold;
> * bool Italic;
> * unsigned char Color[3];
> };

Inserting and deleting in a vector<> for an editor is already a
problem.

>
> * This design is hardcoded (what if I need another attribute later on)
> and it would be very difficult to look for a specify array of char. It
> would also eat a lot of memory...
> * Is this something describe in the literature ? If yes, where can I
> find documentation ?

There are many ways to tackle this problem and they depend on your
needs.
You could have a look into some open source projects which do what you
want and see how they did it.

Googling for 'how to design a text editor' also gives interesting
results.

Please come back when you have a C++ language question.

--
Michael

In article <dd7c3f23-8c16-4cfa-b456-efc7d2f35a25
@r24g2000vbn.googlegroups.com>, says...
>
> Hi there,
>
> Let say I am writing a word processor. It would be a bad design to
> consider that a document is a std::vector of instances of a class
> MyChar ? Where a MyChar would look like:
>
> struct MyChar
> {
> char TheChar;
> bool Bold;
> bool Italic;
> unsigned char Color[3];
> };
>
> This design is hardcoded (what if I need another attribute later on)
> and it would be very difficult to look for a specify array of char. It
> would also eat a lot of memory...
> Is this something describe in the literature ? If yes, where can I
> find documentation ?

FlyWeight has already been mentioned, but it's really only part of
the answer.

IMO, you should take a look at the general design of CSS and/or ODF.
They're obviously not identical, but they have some characteristics
on common, and give an idea of how this general type of problem has
been solved (with a reasonable degree of success, I might add)
already.

The general idea can be described fairly simply though: a couple of
extra levels of indirection, at least one of them explicitly visible
to the user. Specifically, you want to allow the user to put together
a "style sheet" that describes characteristics of some text (font,
color, spacing, etc.) then you want to let them apply that style to
lots of different text. The user can then format most of his/her
document(s) based on a logical style rather than always separately
editing the individual attributes. For example, you could start by
stealing a few "styles" from HTML, and having H1, H2, H3 and H4.

Much like a browser, give each of these a default style -- but let
the user edit styles, so if the user wants H1 to be 32 point Bodoni
bold, and H2 to be 27.5 point Castellar MT black, s/he can do that.
Then when they change their mind and decide those should both be
Arial bold, in 30 and 20 points respectively, they can easily do that
-- and when they change the style, every instance of H1 or H2
throughout their document will automatically change together.

Likewise, of course, you want to let the user define new styles, so
the styles can and will reflect the logical structure of the document
they're creating, in the way they think about things. The style one
user calls "chemical formula" might happen to have identical
attributes to another user's "algorithm", but they're still separate
styles that happen (at least at some particular moment) to look the
same.

--
Later,
Jerry.

* Michael Doubez:
> On 10 août, 14:13, mathieu <mathieu.malate...@gmail.com> wrote:
>> Let say I am writing a word processor. It would be a bad design to
>> consider that a document is a std::vector of instances of a class
>> MyChar ? Where a MyChar would look like:
>>
>> struct MyChar
>> {
>> char TheChar;
>> bool Bold;
>> bool Italic;
>> unsigned char Color[3];
>> };
>
> Inserting and deleting in a vector<> for an editor is already a
> problem.

No, it's the preferred and fastestest for an editor. The idiomatic choice for
those who have made some editors from scratch (not just using an edit
control/widget). Look up "cursor gap" in Wikipedia or wherever.

For a word processor it's a different matter.


Cheers & hth.,

- Alf

Alf P. Steinbach a écrit :
> * Michael Doubez:
>> On 10 août, 14:13, mathieu <mathieu.malate...@gmail.com> wrote:
>>> Let say I am writing a word processor. It would be a bad design to
>>> consider that a document is a std::vector of instances of a class
>>> MyChar ? Where a MyChar would look like:
>>>
>>> struct MyChar
>>> {
>>> char TheChar;
>>> bool Bold;
>>> bool Italic;
>>> unsigned char Color[3];
>>> };
>>
>> Inserting and deleting in a vector<> for an editor is already a
>> problem.
>
> No, it's the preferred and fastestest for an editor.

I thought it was the scratch buffer (like in ed or vi).

> The idiomatic
> choice for those who have made some editors from scratch (not just using
> an edit control/widget).Look up "cursor gap" in Wikipedia or wherever.

I had a look on wikipedia ... as clear as the bottom of my socks. But it
looks interesting. Definitely will get a look at "The Craft of Text
Editing" (if I can find a working link).

--
Michael

In article <4a808b83$0$426$>,
says...

[ ... ]

> > The idiomatic
> > choice for those who have made some editors from scratch (not just using
> > an edit control/widget).Look up "cursor gap" in Wikipedia or wherever.
>
> I had a look on wikipedia ... as clear as the bottom of my socks.

The idea is pretty simple, really. When you're editing a text file,
you separate the file into two pieces: everything that's before the
cursor, and everything that's after the cursor.

Those two pieces are place into memory with the part that's before
the cursor at the very beginning of the buffer, and the part that's
after the cursor at the very end of the buffer. In between the two,
you have a "gap" of unused memory space. When/if the user enters new
text, you add the characters into that memory space (for overwrite
mode, you write at the end of the gap instead of the beginning).

When the user moves the cursor, you copy text from one side of the
gap to the other. Since the user usually only moves the cursor in
small increments (word, line, possibly page) it's pretty easy to copy
the text around quickly enough to keep up (with a little care, you
could keep up even on 8-bit processors). With this design, the single
most difficult situation to handle quickly is a goto line N, which
involves not only scanning through the data to find the Nth line, but
also copying data around to put the gap at the right place. Unless
files get really huge, though, it's still not much of a problem.

--
Later,
Jerry.

On 10 août, 23:52, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <4a808b83$0$426$426a7...@news.free.fr>,
> michael.dou...@free.fr says...
>
> [ ... ]
>
> > > The idiomatic
> > > choice for those who have made some editors from scratch (not just using
> > > an edit control/widget).Look up "cursor gap" in Wikipedia or wherever..
>
> > I had a look on wikipedia ... as clear as the bottom of my socks.
>
> The idea is pretty simple, really. When you're editing a text file,
> you separate the file into two pieces: everything that's before the
> cursor, and everything that's after the cursor.

That I understood but what do you gain except an amortized copy ?
I guess it is memory cost effective.

> Those two pieces are place into memory with the part that's before
> the cursor at the very beginning of the buffer, and the part that's
> after the cursor at the very end of the buffer. In between the two,
> you have a "gap" of unused memory space. When/if the user enters new
> text, you add the characters into that memory space (for overwrite
> mode, you write at the end of the gap instead of the beginning).

That has the sake of simplicity but if you maintain a list of
modification (like rope or another list structure with modifications
stored in a scratch buffer) until next write to file then insertion
and deletion seems cheap to me.

I have never tried to write a text editor but this approach appeals me
more than gap buffer.

> When the user moves the cursor, you copy text from one side of the
> gap to the other. Since the user usually only moves the cursor in
> small increments (word, line, possibly page)

I don't know what you call small increment but, on a daily basis, I
move between marks, end/beginning of line, next/previous char/word/
symbol ... I move much more than I write; I expect the gap is created
on the first modification.

Don't mistake me. I don't discuss the usefulness of the technique but
I try to understand the forces that apply to such a design.

--
Michael

* Michael Doubez:
> On 10 août, 23:52, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
>> In article <4a808b83$0$426$426a7...@news.free.fr>,
>> michael.dou...@free.fr says...
>>
>> [ ... ]
>>
>>>> The idiomatic
>>>> choice for those who have made some editors from scratch (not just using
>>>> an edit control/widget).Look up "cursor gap" in Wikipedia or wherever.
>>> I had a look on wikipedia ... as clear as the bottom of my socks.
>> The idea is pretty simple, really. When you're editing a text file,
>> you separate the file into two pieces: everything that's before the
>> cursor, and everything that's after the cursor.
>
> That I understood but what do you gain except an amortized copy ?
> I guess it is memory cost effective.

It's a *simple* structure that yields O(1) insertion and deletion at the cursor
position and O(1) random access read and write, where the former is the same as
with a linked list, and the latter is much better than a linked list.

The main cost is that, without reallocation and copying of all the data, the
maximum size of the buffer is determined up front, and it uses that much memory
regardless of the amount of data (for an editor, text), so no, it isn't
especially memory cost effective.

Of course, in C++ any complexity for a more complicated structure can be hidden
under a simpler programmatic interface. So I guess that my comment reflected
that since C++ displaced C for such tasks, implementing editors from scratch
hasn't been that much in vogue. And the only such editor I made that I still
have the source code for, on magnetic tape, an editor for the HP3000 from 198x!,
wasn't written in C but in Pascal, and it didn't use cursor gap but a more
sophisticated list of blocks, sort of like a C++ std::deque implementation.


Cheers,

- Alf