Christian Schladetsch wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sorry, I am coming into this conversation late so I have several responses. /["Perhaps a way forward for C++ is a good PP and a standards-based implementation of C++ in C++ so it can embed itself."]/ C++ compiler as a library usable from C++ code would be a great addition as a way to generate code when templates and the pre-processor is not up to the challenge. /["I think you MASSIVELY underestimate the complexity of implementing C++."]/ You are correct it is massive and greatly underestimated. Isn't part of this a requirement to parse C++ code if that requirement was removed than things would be much simpler. Consider for a moment another language, the dreaded C# or any of the .NET languages. I am not coveting any language feature here except reflection. Besides having generics, their dumbed down version of templates and a dumbed down version of concepts (which C++ won't get for a long while), they also have 2 API's, Reflection Emit and Code DOM. C++ don't have a virtual machine yet so lets focus in on Code DOM. Its a library where you instantiate a graph in memory that represents the code to be generated then assemblies or code can be generated directly from it. No need for code parsing. Leave that for the full compilers. Its only lack is that its graph can't be easily serialized into a format that is easily parsed such as XML.Similarly, their are open source Java projects out there though none of those has been made a standard part of Java. Applications include dynamic proxy and stub generation for remote method invocation, container managed functionality used in their enterprise servers such as J2EE or WCF though for us it could aid in creating a CORBA Component Model for Boost/C++, code injection for use in serializing plain objects to a object or relational database such as JDO, Hibernate or the myriad of other database technologies. / "For instance, build systems. .... 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. ... 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."/ Here's a thought. How about C++? I would like for my build scripts to be written in C++. All I need is some base libraries. We have filesystem but what is the progress on that run process library has been in the boost vault for years. Could C++ users please have a library to call a compiler directly instead of writing files and fooling with the console, cin, cout and cerror? There are a lot of libraries in the vault and from the Boost summer of code that if ompleted would make things easier.