Persistent AST and google sparsehash

[Adam Treat]

On Saturday 05 August 2006 2:57 pm, David Nolden wrote:
> Am Samstag, 5. August 2006 18:22 schrieb Adam Treat:
> > Yah, I discovered Boost too, but I'm leaning towards just serializing the
> > AST ourselves.  Like Jakob said, we already have a visitor and everything
> >
> > :)
> >
> > But that leads me to a question...  why are you using Boost for the
> > teamwork plugin?  It seems you've also created your own networking lib
> > instead of using Qt's.  Is this because you wanted the teamwork layer (or
> > perhaps the server) not to have a dependency on Qt?
>
> As far as I can see Qt's networking-lib only consists of some
> socket-classes etc. Instead of that I use common-c++ which provides the
> same. The reason is that I wanted to create a standalone-server which is
> independent of Qt, exactly as you said. :) But I didn't rewrite anything
> that is in Qt.
>
> My metworking-lib has a powerful messaging- and message-dispatching-system
> for which I use boost-serialization. That allows very easy sending of very
> complex custom messages, and it is much more powerful than a QDataStream.

Alrighty :)  I was just wondering.

> > If it is not a technical reason, I'd really rather use Qt instead of
> > Boost. All of KDevelop is going to already depend upon Qt and any server
> > you have for KDevelop will probably require KDevelop installed on the
> > machine.  It also seems like a lot to redo the networking layer instead
> > of using Qt's networking classes.
>
> As I said.. nothing is redone. It's just based on different
> socket-classes(which are replaceable). And the server will be able to run
> on any machine, with or without Qt.
>
> > I've also had a look at your branch code.  Can you define a style that it
> > is in?  I had a brief try and merging it with trunk, but I couldn't make
> > heads or tails of it.
>
> Well.. what do you mean by "Style"? ;). It needs some cleaning again but I
> don't think it looks very bad. :)
>
> Currenty I still develop with an older version of kdelibs(I still use
> kdelibs4_snapshot), so merging it into trunk would not be of much use
> because of some incompatibilities. I've already spent hours by hours(if not
> days) trying to update which was very frustrating(there's many problems).
> Today I'll try it again. :)

I can try and help with the library API changes.  When I did it we didn't get 
any conflicts in the merge, but it sure wouldn't build.