C++/ D C struct2 D inner classes, C++ templates/D templates

[Bill Baxter]

BLS wrote:
> Bill Baxter schrieb:
>> BLS wrote:
>>> Hi Chris,
>>> MANY THANKS.
>>> Your help is kicking me into the right direction.
>>>
>>
>>> In case that you have time enough:  Here the /templated/ B+Tree Cpp 
>>> implementation. 
>>> http://idlebox.net/2007/stx-btree/stx-btree-0.8/include/stx/btree.h.html
>>>
>>> Read it ? Do you see something not doable in D ?
>>> again, thanks for beeing so gentle and patient
>>> Bjoern
>>
>>
>> The tricky thing, as with all STL-type C++, is translating the 
>> iterators.  The STL standard technique for iterators is to overload 
>> operator* and operator->, which you can't do in D.  So you need to use 
>> methods or something for those instead.  Something like iter.value or 
>> iter.deref or iter.data, etc.  Also there's a lot of passing of 
>> references here and there in STL code like that.  That's always kinda 
>> tricky to figure out what to do with.  Are you doing this with D2 or D 
>> classic?
> 
> 
> D classic because TANGO.
> 
> 
>>
>> One issue I ran into trying to translate std::map was the use of the 
>> idiom   T(val) or T x(val)  to construct objects.  In C++ that works 
>> fine whether T is an 'int', a class, or a struct.  But in D (AFAIK) 
>> there's no single expression that can be used to construct either a 
>> plain value type or a class type with the given initializer.  I didn't 
>> really think about it too hard though.  I decided it was easier to 
>> grab ArcLib's RedBlackTree implementation and use that.
>>
>> --bb
> 
> Hi Bill, thanks for taking the time to answere.
> first - OFF Topic
> interesting that you name ArcLibs RB Tree. My Interest in B+Trees are, 
> beside learning,  piece tables ... a (unknown?) data-structure which 
> uses trees to hold text information often used in 
> Text-processors/Management-Tools. /The workhorse in ABIWORD/. The funny 
> part is that people behind ABI WORD  are switching from RB Trees to 
> guess what : B+Trees, because of speed.  Further ArcLib has builtin 
> support for FreeType .... So I wonder why not build something better 
> than Scintilla using ArcLib ? [my never ending IDE proj.]
> 
> Some piece table info :
> 
> Both *NOT that good* :
> http://www.cs.unm.edu/~crowley/papers/sds/node15.html#SECTION00064000000000000000 
> 
> http://e98cuenc.free.fr/wordprocessor/piecetable.html

Well that's interesting, but if I were really worried about performance 
that much I'd probably be using Intel's C++ compiler and not D.  I don't 
expect I'll really be pushing up against any asymptotic ceilings with my 
current work.

> next :
> perheps it is not nessesary to use std::map; 2 weeks ago I read in 
> Dr.Dobs about Lisp like lists in C.
> Hmmm difficult to say "Okay thats it" : because it is more a feeling but 
> LISP Lists (implemented in C)  do not use _classic_ nodes just void* 
> probabely this is a workaround. As said, more a feeling;
> 
> And prob. using D AAs as key/value pairs (thanks to Chris) like :
> class X(_Key, _Val)
> {
> bla, bla
> 
>     _Key[_Val[]] key_val_pair;
> 
> is a workaround??? It is late now, I am afraid I produce too much 
> bullshi* Next try tommorow

If I follow you, yes, using AA's is a workaround if you want a Set type 
and you don't frequently need to access the elements in sorted order. 
But what I was actually after was a multiset, which isn't as trivial to 
implement with AA's, and is pretty easy to implement with an RBtree -- 
just make insert() unconditional pretty much.

But in the end actually I realized that the code I was porting was using 
a multiset for a very silly reason rather than the really slick reason I 
thought.  And it turned out just replacing the multiset with AA's was 
better.

(Incidentally, this is the code I was porting -- a triangle mesh 
datastructure in this library: 
http://www.multires.caltech.edu/software/CircleParam/html/index.html#download)

Sadly, in the end I've decided just to give up and use an existing C++ 
library instead.  Just can't justify spending all my time re-inventing 
wheels.  Sad but true fact of life in research. :-(

--bb