The C++ Post-Processor

[Christian Schladetsch]

Hello,

This is a general post about C++.

Why is it that the pre-processor (PP) is the source of so much disdain, and
yet it is the first resource exploited to 'fix' problems with C++?

Why has the PP received so little attention over the years, from its early
use as M4?

This is a message to the powers that be: the PP is a powerful tool. It
provides a 'context-cutting' mechanism for creating and extending solutions.
It is a true "meta-programming" system built right into C++. No other
language I can think of has a PP. This is often viewed as being a good
thing, but I wonder more and more as I get older that a good PP is in fact
needed to span some otherwise very difficult boundaries.

Other languages are "dynamic" inasmuch as they reflect classes and allow for
runtime changes to types and instances. I think we all here agree that this
ability is counter to building firm, safe and efficient software.

But the PP is similar to that, allowing a degree of dynamicy not otherwise
available. Specifically, by exposing concepts to the PP we can leverage
reflection and synthesis while building on inheritance and conglomeration.

I don't have a point as such; I just wanted to raise the idea of developing
M4 and the PP past where it is. There is a lot of low-hanging fruit there.
This is evidenced by the fact that a lot of other languages are or can be
transliterated to C++. Rather than thinking of C++ as the output, we could
be thinking of C++ as the input.

Perhaps a way forward for C++ is a good PP and a standards-based
implementation of C++ in C++ so it can embed itself.

I've written a number of languages, and in each I've had to address the
issue of pre-processing. The latest attempts have resulted in a system where
it parses and executes via AST input to produce an output that is then
parsed by the same system to produce an AST that is then walked to
eventually produce machine code. I think this model is best, and would be
delighted to see some similar movements in the PP/C++.

We have Boost.Wave to start with... Why not give it real Expressions? Loops?
Scopes? Classes? Templates? memory management? IO?

Is there any interest in a Boost.C++ ?

Regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sun, Oct 18, 2009 at 4:49 AM, Christian Schladetsch
<christian.schladetsch@...> wrote:

> Hello,
>
> This is a general post about C++.
>
> Why is it that the pre-processor (PP) is the source of so much disdain, and
> yet it is the first resource exploited to 'fix' problems with C++?
>
> Why has the PP received so little attention over the years, from its early
> use as M4?
>
> This is a message to the powers that be: the PP is a powerful tool. It
> provides a 'context-cutting' mechanism for creating and extending solutions.
> It is a true "meta-programming" system built right into C++. No other
> language I can think of has a PP. This is often viewed as being a good
> thing, but I wonder more and more as I get older that a good PP is in fact
> needed to span some otherwise very difficult boundaries.
>
> Other languages are "dynamic" inasmuch as they reflect classes and allow for
> runtime changes to types and instances. I think we all here agree that this
> ability is counter to building firm, safe and efficient software.
>
> But the PP is similar to that, allowing a degree of dynamicy not otherwise
> available. Specifically, by exposing concepts to the PP we can leverage
> reflection and synthesis while building on inheritance and conglomeration.
>
> I don't have a point as such; I just wanted to raise the idea of developing
> M4 and the PP past where it is. There is a lot of low-hanging fruit there.
> This is evidenced by the fact that a lot of other languages are or can be
> transliterated to C++. Rather than thinking of C++ as the output, we could
> be thinking of C++ as the input.
>
> Perhaps a way forward for C++ is a good PP and a standards-based
> implementation of C++ in C++ so it can embed itself.
>
> I've written a number of languages, and in each I've had to address the
> issue of pre-processing. The latest attempts have resulted in a system where
> it parses and executes via AST input to produce an output that is then
> parsed by the same system to produce an AST that is then walked to
> eventually produce machine code. I think this model is best, and would be
> delighted to see some similar movements in the PP/C++.
>
> We have Boost.Wave to start with... Why not give it real Expressions? Loops?
> Scopes? Classes? Templates? memory management? IO?
>
> Is there any interest in a Boost.C++ ?

Have you looked at the D language, it did away with the C/C++ style
pp, but buffed up the template capabilities to let it do just about
anything the C/C++ PP can.

Lisp/Scheme is also the perfect example of the language running
itself, no PP needed.

I wish C++ templates were like D templates...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Schladetsch]

On Mon, Oct 19, 2009 at 12:49 AM, OvermindDL1 <overminddl1@...> wrote:

> On Sun, Oct 18, 2009 at 4:49 AM, Christian Schladetsch
> <christian.schladetsch@...> wrote:
> > Hello,
> >
> > This is a general post about C++.
> >
> > Why is it that the pre-processor (PP) is the source of so much disdain,
> and
> > yet it is the first resource exploited to 'fix' problems with C++?
> [...]
>
> Have you looked at the D language, it did away with the C/C++ style
> pp, but buffed up the template capabilities to let it do just about
> anything the C/C++ PP can.
>
> Lisp/Scheme is also the perfect example of the language running
> itself, no PP needed.
>

Yes I am familiar with these excursions. However, my message was directed
entirely towards the C++ community and C++ itself. Other languages have
their own uses and excuses. Boost has Wave and I think it is under-used.
This is my point.

D is indeed interesting. But I wonder how far C++ can be taken with M4/C++
before it breaks.


> I wish C++ templates were like D templates..


I think we all wish C++ was something other than it is. Some more than
others.

But what can be done with Boost.Wave to make a C+++?

And, is there any serious effort to make a formal and correct C++
interpreter? It can of course be done. I will argue that it has to be done
sooner than later if C++ is to remain relevant as an actively used (as
opposed to necessarily maintained) language going forward.

Regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Klimpel]

Christian Schladetsch wrote:
> And, is there any serious effort to make a formal and correct C++
> interpreter? It can of course be done. I will argue that it has to be done
> sooner than later if C++ is to remain relevant as an actively used (as
> opposed to necessarily maintained) language going forward.

There is a famous company:
http://www.edg.com/

Using their products, you would probably be able to get your interpreter, but because it won't be open source, you probably won't be happy. But before you claim that they should open source it, consider that their offering can be used as an important building block of products that really make money.

Regards,
Thomas
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Schladetsch]

On Mon, Oct 19, 2009 at 1:48 AM, Thomas Klimpel <Thomas.Klimpel@...
> wrote:

> Christian Schladetsch wrote:
> > And, is there any serious effort to make a formal and correct C++
> > interpreter? It can of course be done. I will argue that it has to be
> done
> > sooner than later if C++ is to remain relevant as an actively used (as
> > opposed to necessarily maintained) language going forward.
>
> There is a famous company:
> http://www.edg.com/
>

This company is well known, as are their products. But they can't be used as
C++ or Boost can be used. I am not clear about what standard of C++ Edison
Design use. From their dox it seems quite dated. Personally, I haven't
followed them due to the name (Edison) and their tasteless choice of icon (a
light globe). Teslsa would turn.


> Using their products, you would probably be able to get your interpreter,
> but because it won't be open source, you probably won't be happy. But before
> you claim that they should open source it, consider that their offering can
> be used as an important building block of products that really make money.
>

Sure, but I am wondering openly about an effort based on Boost.Wave that can
provide a C++ environment created from a C++ environment. Such an effort
could be used to test ideas far better than the current 'standard' 5-20 year
turn-around could. And we shouldn't need to rely on a closed company.

C++ could make C++ quite easily, especially if using a tool like ANTLR. But
whatever the means, it is a sad state that C++ doesn't have a C++
interpreter or a C++ runtime. Perhaps the work done on Boost.Wave could be
used to make it.

Currently, the best way is either with Spirit or ANTLR. I don't care which,
but I do care that C++ is reflected soon. The fear is that C++ will become
the assembler of the future. Let's face it; it has old ideas and old
practices. No amount of cleverness can make it relevant in a cloud
environment, where everything is virtualised.

If it can be isolated via virtualisation, and standardised, then it could
remain, with some pre-processor magic, a common denominator language of good
reknown.

Regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

On 18 Oct 2009, at 14:42, Christian Schladetsch wrote:
>
>
> C++ could make C++ quite easily, especially if using a tool like  
> ANTLR. But
> whatever the means, it is a sad state that C++ doesn't have a C++
> interpreter or a C++ runtime. Perhaps the work done on Boost.Wave  
> could be
> used to make it.


I think you MASSIVELY underestimate the complexity of implementing C++.

The best current attempt I'm aware of is the clang project ( http://clang.llvm.org/ 
  ) which is aiming to produce a BSD-licensed C++ front-end of the  
LLVM project. They are making very good progress through a very  
difficult piece of work, and I'm sure would be happy with any help  
anyone might offer.

Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Klimpel]

Christian Schladetsch wrote:
> Sure, but I am wondering openly about an effort based on Boost.Wave that can
> provide a C++ environment created from a C++ environment. Such an effort
> could be used to test ideas far better than the current 'standard' 5-20 year
> turn-around could. And we shouldn't need to rely on a closed company.
>
> C++ could make C++ quite easily, especially if using a tool like ANTLR. But
> whatever the means, it is a sad state that C++ doesn't have a C++
> interpreter or a C++ runtime. Perhaps the work done on Boost.Wave could be
> used to make it.

I actually mentioned edg, because they emphasize that parsing C++ is really nontrivial. So I thought that reading your answer to this suggestion might be fun. If I had to think about a realistic option to make your wish come true, I should probably more go into the direction of LLVM and its clang front-end.

Regards,
Thomas
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Schladetsch]

Hi Chris,

I am a member of the Clang team, and also LLVM. It is hard and slow work.

I merely wished to try to spread out this work, and also raise the
importance of the C++ pre-processor.

At the end, I just wanted to raise the idea to boost because it seems like a
rarified area here. The idea of making a C++ interpreter that can parse and
use new modules dynamically, including pre-processing is important to the
future of the language, and is also a study paid for by Apple.

There are efforts, but I am not aware of any within boost. I specifically
was interested in developments of Boost.Wave to make a C++ backend. I think
such would be a good thing for C++. Clang and LLVM are great, and I will
continue my support for them, but they don't have C++ at heart.

Regards,
Christian.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sebastian Redl]

Christian Schladetsch wrote:
> There are efforts, but I am not aware of any within boost. I specifically
> was interested in developments of Boost.Wave to make a C++ backend. I think
> such would be a good thing for C++. Clang and LLVM are great, and I will
> continue my support for them, but they don't have C++ at heart.
>  
The open-source community has produced four significant C++ parsers that
I'm aware of: the highly standards-compliant but hard-to-reuse G++, the
easy-to-reuse but outdated and unmaintained Elsa, a similar project that
is scarcely more maintained, and Clang, which is worked on and has
recently reached the state where it can compile a iostreams-using Hello
World program.

I sincerely doubt that the community would be able to sustain yet
another C++ parser. What is it about Clang that is insufficient to your
(nebulous) purposes?
You hardly need to tell the Boost community about the importance of the
preprocessor. This is, after all, the library collection that hosts
Boost.PP.

The problem is that it's really hard to understand what your point is.
It seems that you want to improve the C++ preprocessor to the point
where it is effectively an embedded C++ implementation, so that you can
do full LISP-style metaprogramming. It's a nice idea, but somewhat
misguided. The preprocessor is a text replacement tool and not
turing-complete. Enhancing it to the point of being able to process
reflection information - where's the point? Can you think of a way to do
this that wouldn't be better done by instead changing C++ so that you
can do metaprogramming in C++ itself?


As for a C++ interpreter, I believe there is some work underway to make
a C interpreter based on Clang/LLVM. If that project gets off, it would
be a small step to a C++ interpreter. Not that templates lend themselves
very well to interpretation.
I also believe that CERN has a limited C++ interpreter.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> Christian Schladetsch wrote:
> > There are efforts, but I am not aware of any within boost. I
> specifically
> > was interested in developments of Boost.Wave to make a C++ backend. I
> think
> > such would be a good thing for C++. Clang and LLVM are great, and I
> will
> > continue my support for them, but they don't have C++ at heart.
> >
> The open-source community has produced four significant C++ parsers
> that
> I'm aware of: the highly standards-compliant but hard-to-reuse G++, the
> easy-to-reuse but outdated and unmaintained Elsa, a similar project
> that
> is scarcely more maintained, and Clang, which is worked on and has
> recently reached the state where it can compile a iostreams-using Hello
> World program.
>
> I sincerely doubt that the community would be able to sustain yet
> another C++ parser. What is it about Clang that is insufficient to your
> (nebulous) purposes?
> You hardly need to tell the Boost community about the importance of the
> preprocessor. This is, after all, the library collection that hosts
> Boost.PP.
>
> The problem is that it's really hard to understand what your point is.
> It seems that you want to improve the C++ preprocessor to the point
> where it is effectively an embedded C++ implementation, so that you can
> do full LISP-style metaprogramming. It's a nice idea, but somewhat
> misguided. The preprocessor is a text replacement tool and not
> turing-complete. Enhancing it to the point of being able to process
> reflection information - where's the point? Can you think of a way to
> do
> this that wouldn't be better done by instead changing C++ so that you
> can do metaprogramming in C++ itself?
>
> As for a C++ interpreter, I believe there is some work underway to make
> a C interpreter based on Clang/LLVM. If that project gets off, it would
> be a small step to a C++ interpreter. Not that templates lend
> themselves very well to interpretation.
> I also believe that CERN has a limited C++ interpreter.

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.

Wave is a nice tool (hey, remember, I'm biased), and it has its usage as a
first tool in a language analysis tool-chain, but in order to sustain more
complex use cases it needs more love. So, Christian, feel free to
contribute!

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

On 18 Oct 2009, at 16:54, 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.

Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> > 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

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

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, as the code is hardwired to at most  
2^30-1 reductions.

Chis
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus-3]

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"?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Jefferson]

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?

Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sun, Oct 18, 2009 at 12:09 PM, Christopher Jefferson
<chris@...> 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

[Christian Schladetsch]

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@...> wrote:

> On Sun, Oct 18, 2009 at 12:09 PM, Christopher Jefferson
> <chris@...> 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

[Jarrad Waterloo]

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@...> wrote:
>
>  
>> On Sun, Oct 18, 2009 at 12:09 PM, Christopher Jefferson
>> <chris@...> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ruediger Berlich-2]

Hi there,

> And, is there any serious effort to make a formal and correct C++
> interpreter?

Have a look at http://root.cern.ch/drupal/content/cint . Cint has been in
production use at CERN as part of the ROOT analysis toolkit for a number of
years. I doubt that it will fulfill all of your wishes -- e.g. it'll be
able to cope with some, but certainly not all of Boost's libraries. But it
is the best starting point I can think of.

Best Regards,
Ruediger


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Schladetsch]

> > And, is there any serious effort to make a formal and correct C++
> > interpreter?
>
> Have a look at http://root.cern.ch/drupal/content/cint . Cint has been in
> production use at CERN as part of the ROOT analysis toolkit for a number of
> years. I doubt that it will fulfill all of your wishes -- e.g. it'll be
> able to cope with some, but certainly not all of Boost's libraries. But it
> is the best starting point I can think of.
>

I have looked at Cint, and have been impressed. Using it was a little less
terrible than using, say, LUA or Boost.Python.

It is good, but it is not a C++ interpreter as I imagine: with clean and
easy bindings, and full language support.

Some will argue that I am too high-minded and should just settle for a
C++-ish system embedded in C++. Perhaps that is true.

But I really do think that C++ needs %100 reflection, and that it needs a
better pre-processor. It would be awesome if we could kill three birds with
one stone and produced a C++ that produced C++ which was interpreted by C++
and created C++.

Cheers,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost