Re: [qub] Re: Awesome DTP counters

[stephan b. <st...@ei...>]

On Wednesday 30 July 2003 10:07, Rusty Ballinger wrote:
> - QStrings for keys.  Presumably string or char * could be dropped in
>   instead.

std::string :)

> - There's some support for serializing/deserializing QPtrLists of
>   Serializables, but I think that's a wrapper around std::vector
>   now.  (So it would be easy to #ifdef that out.)

i've also got a pointer-list class which i've modelled off of QPtrList, 
but which uses STL conventions. It's just a std::list<Foo *> wrapper, 
in any case.

> - Internally, in ClassLoader, QDict is used for hash tables, because
>   I *think* there's not a "standard" standard hash table class.  It
>   would be easy to conditionally use some other non-hashing STL
>   collection, but it might perform worse at runtime.  (Or, heck,
>   maybe better.)

There isn't a standard hashtable, amazingly enough. std::map does a good 
job for me but is certainly not ideal once you've got tens of thousands 
of entries, due to it's ordered nature. Then again, i've got some 
experimental code where i create tens of thousands of star systems and 
stick them in a std::map, and it is remarkably fast, so maybe it's not 
as bad as i would expect. Hell, maybe that's why there's no standard 
hashtable, because std::map performs so well ;).

> A slightly related question: usually when I sit down to write other
> stuff for fun, I wind up #including & linking with libfunUtil in QUB
> (almost always for serialization); what do you think about moving
> libfunUtil, or some subset of what's currently in it, into a separate
> sourceforge project?

i've also thought about that before, but i wasn't sure if it was worth 
the maintenance effort. i certainly think it makes sense from an 
organizational point of view.

> The benefits would be:
> - it would be easier to use in other projects.  (well... that's no
>   benefit to qub.)

i've certainly got code which would benefit from this, though. :)

> The reasons *not* to do that are:
> - it makes some things harder in qub:
>   - step 1 of building qub is "go download & build this other thing,"
>     which is not so good.

We could also include that as part of the build process, checking out 
using pserver (or your sf account, if you provide one to configure?). 
Alternately (for releases), we could host the matching tarball on the 
web site and download that as part of the build. Or... we could explain 
the interface to the user and ask them to code it themselves...


>   - in some cases you might have to edit code in two projects.  Bleh.

Admittedly not ideal, but probably not as horrible as my gut tells me it 
is. i've been doing this with the elib tree for a month or so, for some 
submissions i've made to miwm.sourceforge.net.

>   - to help people debug problems in qub, you have to start asking
>     what version of libfunUtil they have, etc.

Then again, how often have we had a bug in serialization? i /think/ i 
can remember maybe one or two minor ones, but those were always limited 
to the dev tree, AFAIR. i can't ever remember a significant libfun bug 
getting into a release (but i can't remember lots of significant gcom 
bugs which did).

> - it makes some things harder in libfunUtil:
>   - if you make changes, you have to make sure you haven't broken
>     binary compatibility.

Personally i'm not worried about bin compat, but if you want to then i 
certainly won't try to stop you ;).

>   - some time has to be spent packaging up releases instead of
>     writing code, boo.

i'll volunteer for that. Build processes have become a hobby of mine the 
past 2 years or so. However, i can't promise how portable i can make 
it.

> - you have to join more mailing lists, and remember which list some
>   bug in libfunUtil was discussed on, etc.

True enough - i hadn't considered that.
Maybe one alternative is creating lib/fun2 (or funstl, or whatever) in 
the qub tree, though i can immediately see potential problems with 
header file confusion (assuming the classnames are the same).

> Presumably it would be easy to make Qt an optional part of that
> libfunUtil build.  If I did that, I would probably make it use
> autoconf (not sure about automake), because it would need a working
> install target. :)  (Err, well, I get the heebie-jeebies just
> thinking about using autoconf again... I want the features, but
> without the pain!

Amen.
Actually, i have working install support, but it won't work exactly as 
we want because of our mix of qmake files and makefiles. (We would have 
to duplicate dist_file lists, which i would very much like to avoid.) 
Alternately, i could kludge up something similar to the 'make dist' 
support, which uses a single file containing the list of all files to 
dist. "Kludge" is the operative word, i think.

>  I guess I'd take a look at some other projects
> which don't use autoconf.  I definitely wouldn't use qmake, if one
> goal is to make Qt optional in that build.)

There's probably no danger of Qt going away in general any time before 
Burrito Boy hits high school, i think. i'm certainly a huge fan of Qt, 
i'd just love to have access to a no-3rd-party-code serialization 
layer. (i can dream, can't i?)

> If you think that's worth doing, let me know, & I'll set up the
> sourceforge project, & start fiddling with ./configure --without-qt
> ...  (Although, is that basically the same as elib?  Is that in
> sourceforge?  The last thing I remember about that is a couple of
> months ago, complaining that you'd stuck "public domain" headers on
> GPL code, but I don't remember your reply.)  (man!!  That seems like
> *years* ago!  I've gotta get a job...)

elib is essentially my C++ experimentation/playground, and i use it to 
develop toc (the other configure): http://stephan.rootonfire.org/elib/
The code /should/ be PD at this point, though i certainly had licenses 
all screwed up at some point. AFAIK the only GPL class in there (which 
i didn't write, i mean) was the KDE StringTokenizer class, but i've got 
permission from the authors to release it into the PD (well, i replaced 
it with an std::string-based impl, so that's moot, anyway).

i've considered sticking elib into the toc project, as a reference/test 
source tree, but i haven't gotten around to it and i'm not sure if it's 
"the right thing to do" or not.

> (but, going back to your original point, why do you want a libgcom
> without Qt?  It sounds like there are some basic Qt features which
> you use & like...)

Absolutely, it's only that i want the serialization layer because others 
i've used don't make as much sense as yours and aren't 
backwards-data-compatible when the serialized object changes. i don't 
even need the XML part - just the basic interface and (e.g.) the text 
or binary serializer would be /fantastic/. i've been idly working on a 
space trade/colonization/god-sim style game (as part of elib) and i 
keep realizing that i really can't do much more until i have the 
ability to de/ser data in between runs. (Why? Because i don't want to 
manually populate 10k star systems between runs!) To be clear, though, 
this is all idle fantasy - i've always assumed it would be quite 
difficult to do a non-Qt port so i've never done more than just pout 
about it. :/

In any case, i think it's entirely up to you. i don't think i have the 
know-how to sit and port the ser layer, primarily the classloader part 
(to which the serializer is intimately tied), as i know absolutely 
nothing about properly working with DLLs.


-- 
----- stephan
Generic, Technically-inclined Employee
st...@ei... - http://www.einsurance.de
"You cannot guaranty freedom of speech *and* enforce copyright law."
-- Ian Clarke