I really just wanted to add visibility to the C++ pre-processor. It is frowned upon in general, yet it solves many problems due to the fact that it is cross-cutting. I don't like reading code that uses it overly, much like you do not. However, C++ has the 'advantage' of the PP that other languages do not. Sure, they don't need one because they can morph types and instances at runtime. But we like our types and instances to be well behaved. So I have wondered out loud about developing the PP, rather than C++ itself, in order to further develop ideas about programming. I think that Boost.Wave is the obvious point of departure for this. Indeed, I wondered if extentions to the PP could result in more/better 'meta-programming' for C++. The PP is seen as a bastard child, but that doesn't have to be the case. I am inspired by ideas of symbiotic and recursive relationships in nature to propose that a way forward for C++ doesn't have to be via extensions to C++ itself. For instance, build systems. As a game developer with 20 years experience, I see build systems as a crucial issue for games. We have to gather art, code and scripts to produce an 'image' that can be deployed and run. The complexity of this production is such that itself requires a program - but this program has input that is the filesystem and produces an executable and belated linked assets as output. Running this executable results in building an image of the game. Forgive my foray, put please understand that much as with game development, other projects and ideas also require a process that must be run in order to produce a thing that is used to produce the final thing. We are familiar with this idea in general, and i think that we all acknowledge that boost itself has this problem. Jam isn't awesome for most people. Similarly, the PP isn't awesome and it's considered poor taste to use it. So, I say that we could spend some time on the PP and fix that, and move our mindsets a little to the left of immediate execution. I confused matters with ideas of a C++ interpreter, but I see that as part of the solution. Regards, Christian On Mon, Oct 19, 2009 at 10:35 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
On Sun, Oct 18, 2009 at 12:09 PM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 18 Oct 2009, at 18:56, Vladimir Prus wrote:
Christopher Jefferson wrote:
On 18 Oct 2009, at 18:14, Hartmut Kaiser wrote:
> I agree with everything except Sebastians notion the preprocessor > was not > Turing complete, because it is (this has been shown in the past). > But that's > just a minor detail.
Are you sure? I'm sure it's not. Template instansiation certainly is, but I'm sure the preprocessor isn't, due to the lack of recursion or backtracking.
See here: http://tinyurl.com/yj6crup
While that is a very impressive piece of coding, it doesn't show NP- completeness of the preprocessor,
Did you mean "Turing-complete"?
Yes, sorry. And also sorry how far we are drifting off topic.
One thing that lambda code does show to me is that there are some in principle fairly simple extensions which could be made to the C
preprocessor
which would make it much more useful, while keeping it's current approach of being unaware of the underlying language. Has anyone ever investigated how they might write a "better preprocessor", which mght simplify or remove much of the nastier parts of the preprocessor hacks in boost?
Hence why I mentioned D templates. You could probably hack something like that into Clang, along with D mixins (all compatible with C++ syntax), that gives you just about all the power anyone could ever want for C++, in a vastly easier to use way then is current. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost