Re: Bjam in C++?

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-26 09:32:48

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > Even gcc developers consider requiring C++. If they consider it, than
>> > surely every other project can just switch. Also, one of the primary
>> > goals of Boost.Build is to be build system for C++ Boost -- which is
>> > collection of C++ libraries. Surely user needs a C++ compiler anyway.
>> >
>> > Thoughts?
>
>> Aside from other concerns voiced here, I am not sure how extensive you
>> want to make these changes, but I think any major expenditure of
>> effort on the low-level build tool is a waste of time in the long run.
>
> I'm still undecided on this one, but surely hacking in C would be more waste 
> of time than in C++.

Agreed.

>> Fundamentally, the original product from Perforce is not very good
>> software, and it's unreasonably difficult to create good software in
>> the Jam language. We've corrected a lot of that, but I think we're
>> near the end of that road. I really think in the long run we ought to
>> be thinking in terms of preserving the architecture of Boost.Build,
>> but of dumping the Jam heritage.
>
> And here C++ might come handy. If say, I write "class Property_set", then
> it will speed up current Boost.Build, but this class will be also usable in 
> the long run. 

Point taken. But can you avoid building in dependencies on Jam's
dumb data structures?

> It's quite possible to use C++ class from Python, if we decide to use it.
>
>> FWIW, also, I think it would be fairly trivial to build a Jam ->
>> Python compiler :-).
>
> I think that strategically, we better implement core features in a
> language which is fast -- C++. I suspect that converting not very
> efficient code into yet another language might have dramatic effect
> on performance.

I don't know. Python's already pretty darned good at manipulating
lists of strings. Add to that the fact that it has real integers and
highly optimized mappings, and it starts to look pretty good to me.

> Really, it probably would be much better if we implemented more
> stuff in C++ from the start, rather then trying to put everything
> into jam language layer. After all, very few users, if any, will
> ever need to hack core modules like properties.jam. For tools/*
> interpreted language is fine, but for core parts it's probably not
> needed.

I can see both sides of this argument. On one hand, it's very nice to
have rapid development in a scripting language, and since the language
is implemented in 'C', we don't have to worry about portability. On
the other hand, the lack of type declarations and static type checking
make it hard to keep Jam code understandable and maintainable. I
don't see speed as a major argument for C++, at least not yet: Jam's
fundamental data structures and operations are so limited in power
that it's very hard to conclude that we're paying for time spent in
the interpreter (as opposed to just doing stuff inefficiently because
there's no other way).

Ultimately, I remain convinced that authors of Jamfiles need the power
of a scripting language at their disposal, and that it should be
possible to add support for a new toolset or operating system without
using a compiler. I don't know what to conclude about all of this,
though.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com