From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-29 01:05:40
David Abrahams wrote:
> > I don't really know how optimized mappings in Python are compared with
> > Jam, and Python's list handling optimizations. Real integers are surely
> > good. So, maybe conversion to Python will increase performance, maybe
> > not. But C++ would still be faster.
> In most places, probably. When's the last time you successfully
> implemented fast general-purpose hashing in C++? Python dicts are
> remarkably efficient.
Ok, I trust you on this one.
> > Right. And since in C++ we're not limited in any way, we can do
> > things efficiently. The only necessary thing is that interface with
> > Jam be thin, so that we don't loose all performance gain on that
> > boundary.
> I don't think that's the only neccessary thing. If the interface is
> too thin, then you're stuck dealing with unexpressive Jam data
> structures in C++.
Why? If interface is thin you can convert Jam data structures into anything
> > I agree with the above. It's good to add toolset in a scripting
> > language -- and I don't ever intend to rewrite "tools" layer in C++
> > -- especially since it's not performance critical. I guess one day
> > we can allow writing tools in Python -- I don't see a problem with
> > that.
> Well, if we're going to consider a C++-based build system, I think we
> ought to consider the whole architecture, rather than allowing a 3rd
> language to creep into an already-messy system. Nasty "language
> creep" was one of the reasons I didn't want to go with autotools.
I don't think switch from C to C++ is really "allowing a 3rd language". We
need to improve performance, and doing this in C++ is way more convenient.
We can improve architecture at the same time, but I don't see those two things
as being inter-dependent in any way.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk