Re: [boost] The C++ Post-Processor

Subject: Re: [boost] The C++ Post-Processor
From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2009-10-19 09:27:42

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_at_[hidden]> wrote:
>
>   
>> On Sun, Oct 18, 2009 at 12:09 PM, Christopher Jefferson
>> <chris_at_[hidden]> 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.