Indigo is a project to provide general containers for D that look & feel like the Qt 4.0 container classes, and additionally harmonize very well with D specialities. This is version 0.6, containing Vector, List, LinkedList, Map, and String. This release completes the String class, though i could not implement every feature of QString (especially RegExps and complex localization functionality). As this is all i wanted to accomplish, this project is somehow finished now (though i will implement bugfixes and requested features, of course).

String contains a some borrowed code from Mango again: the UTF16 to UTF8 decoder, mostly copied and a bit improved (about 30% faster). Thanks a lot for that, too.

You reach the docs under:
  http://www.uwesalomon.de/code/indigo/index.html
And the source under:
  http://www.uwesalomon.de/code/indigo/indigo.tar.gz

In the docs there are also some results of tests i made that show the very high performance of the containers.

This is not my first programming project, but my first open source project, thus i will be very grateful for advices from you all.

Thanks & ciao
uwe

Uwe Salomon wrote:
> Indigo is a project to provide general containers for D that look & feel  like the Qt 4.0 container classes, and additionally harmonize very well  with D specialities. This is version 0.6, containing Vector, List,  LinkedList, Map, and String. This release completes the String class,  though i could not implement every feature of QString (especially RegExps  and complex localization functionality). As this is all i wanted to  accomplish, this project is somehow finished now (though i will implement  bugfixes and requested features, of course).
> 
> String contains a some borrowed code from Mango again: the UTF16 to UTF8  decoder, mostly copied and a bit improved (about 30% faster). Thanks a lot  for that, too.
> 
> You reach the docs under:
>   http://www.uwesalomon.de/code/indigo/index.html
> And the source under:
>   http://www.uwesalomon.de/code/indigo/indigo.tar.gz
> 
> In the docs there are also some results of tests i made that show the very  high performance of the containers.
> 
> This is not my first programming project, but my first open source  project, thus i will be very grateful for advices from you all.
> 
> Thanks & ciao
> uwe

Great library. Too few algorithms yet :), but already implemented classes are very useful anyway. I'ld be very happy if Indigo will become part of standart D library in someway. Keep good work ;)

> Great library.

Thanks :)

> Too few algorithms yet :)

Yes, i totally forgot about them. :)  What algorithms would you want to see implemented at first? Binary search comes to my mind. Sorting is already implemented in the containers themselves, is it needed as an algorithm anyways?

Ciao
uwe

Uwe Salomon wrote:
> Yes, i totally forgot about them. :)  What algorithms would you want to  see implemented at first? Binary search comes to my mind. Sorting is  already implemented in the containers themselves, is it needed as an  algorithm anyways?

I find most useful algorithms those that perform "boolean" operations. E.g. return elements that are in both containers, that in first but not in second, that just only in one not in both, etc, etc. This was my IMHO.

Also I find container "Set" very useful in many cases, so it would be very nice to see it in further library versions.

By the way, Natural Doc is really cool, thanks for the idea.

"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.sqtug0y46yjbe6@sandmann.maerchenwald.net...
> String contains a some borrowed code from Mango again: the UTF16 to UTF8 decoder, mostly copied and a bit improved (about 30% faster). Thanks a lot for that, too.

You're welcome!

But you did fail to note that those functions of yours insist on allocating memory, making them 300% slower in a brief test against the current mango.io.Utf   ;-)

These routines are quite efficient though, especially where one can avoid heap-allocation (e.g. conversion of fragments).

>> String contains a some borrowed code from Mango again: the UTF16 to UTF8
>> decoder, mostly copied and a bit improved (about 30% faster). Thanks a lot for that, too.
>
> You're welcome!
>
> But you did fail to note that those functions of yours insist on allocating
> memory, making them 300% slower in a brief test against the current
> mango.io.Utf   ;-)

No, they don't insist. Use setUtf8() repeatedly on the same string. Providing the buffer would make no sense for this algorithm (its purpose is to fill the string's internal buffer). But it is easy to write it stand-alone, with an optional second buffer argument.

> These routines are quite efficient though, especially where one can avoid
> heap-allocation (e.g. conversion of fragments).

Perhaps you want to look at the conversion strategy: It is a bit different from yours, saving a variable and some code size. That makes up the 30% (Tested on a random german email i took from my girlfriend). Should work with your algorithm, too...

Ciao
uwe

> I find most useful algorithms those that perform "boolean" operations. E.g. return elements that are in both containers, that in first but not in second, that just only in one not in both, etc, etc. This was my IMHO.
>
> Also I find container "Set" very useful in many cases, so it would be very nice to see it in further library versions.

Ok, i will work on that for 0.8. Note that boolean algorithms are very slow in containers like List or Vector, thus i will implement them for Set, perhaps for Hash/Map.

Thanks for the feedback
uwe