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
On Sun, Oct 18, 2009 at 4:49 AM, Christian Schladetsch <christian.schladetsch@gmail.com> 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...
On Mon, Oct 19, 2009 at 12:49 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
On Sun, Oct 18, 2009 at 4:49 AM, Christian Schladetsch <christian.schladetsch@gmail.com> 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
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
On Mon, Oct 19, 2009 at 1:48 AM, Thomas Klimpel <Thomas.Klimpel@synopsys.com
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
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
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.
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
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
Christian Schladetsch wrote: 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
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
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
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
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
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
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.
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
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.
Christopher Jefferson wrote:
While that is a very impressive piece of coding, it doesn't show [Turing]-completeness of the preprocessor, as the code is hardwired to at most 2^30-1 reductions.
How is that significantly different from the recursion limit in template meta-programming?
Mathias Gaunard wrote:
Christopher Jefferson wrote:
While that is a very impressive piece of coding, it doesn't show [Turing]-completeness of the preprocessor, as the code is hardwired to at most 2^30-1 reductions.
How is that significantly different from the recursion limit in template meta-programming?
Or the stack and heap limits, for that matter. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
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
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
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
On 10/18/2009 08:06 AM, Christian Schladetsch wrote:
D is indeed interesting. But I wonder how far C++ can be taken with M4/C++ before it breaks.
...which seems to imply it isn't already broken. (Sorry, couldn't resist. ;-) )
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+++?
C++++ ?? Now that sounds like a scary idea.
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.
I fully disagree. C++, as every language, serves particular domains. There are other domains, much better served by other languages. Cramming more programming paradigms into C++ doesn't (necessarily) make it a better language. I'm a big fan of multi-paradigm design (in C++). But I also recognize the limits of C++ (and all other languages I speak / use, for that matter), and thus I also like hybrid programming (e.g. http://www.boostpro.com/writing/bpl.html). Instead of attempting to put more features into C++, let's try to fix the existing ones. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Sun, Nov 1, 2009 at 12:57 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 10/18/2009 08:06 AM, Christian Schladetsch wrote:
D is indeed interesting. But I wonder how far C++ can be taken with M4/C++ before it breaks.
...which seems to imply it isn't already broken. (Sorry, couldn't resist. ;-) )
Heh, I have actually been playing with the idea of porting some D concepts into C++ in the Clang compiler when C++ in it is more mature, call it CD or something. Not everything from D, but D's templates and mixins are a *must*, as well as a lot of the static compilation abilities. Would be fully backwards compatible (something nice about the D syntax is it is designed to fit into C++, not replace, its templates use the !() syntax instead of <> for example) while bringing in the power that D is better at. Would be nice to bring in the new array handling functionality, but not sure that would fit in as well without breaking old code. Hmm, looks like D can link in to C++ code too now, was not able to before; considering that, I may have to take another look at it...
When I think of a "post-processor", I think of something like the Java annotation processing mechanism. In Java, you can annotate classes, interfaces or methods with user-defined attributes (with names like @Test or @Entity). javac then invokes annotation processors (Java programs) that can process a read-only tree of declarations and read their annotations. While annotation processors are not allowed to modify the original source files, they are allowed to generate new files that get passed to the compiler, potentially triggering further annotation processing. While limited by only being able to generate new files, this is essentially a type- and syntax-aware post-processor. To be honest, I haven't seen it be used for very much outside of persistence frameworks and service registration (e.g., @ServiceProvider in NetBeans), but it seems very powerful. I'm not sure how it would be implemented for C++ (a g++ plugin?), but it would seem to be less work than a C++ interpreter and would allow more powerful/easier computation at compile-time. Annotations could perhaps be implemented using the C++0x attribute syntax. --Jeffrey Bosboom
From : Jeffrey Bosboom While annotation processors are not allowed to modify the original source files, they are allowed to generate new files that get passed to the compiler
Well, I suppose something like the C++ Qt post-processor could do the trick in that case. By the way I am not sure about the thread: is it about the preprocessor or about a possible post processor? From my point of view, the thread opening talks only of preprocessor, while the title is postprocessor. Concerning automatic reflection system, I know 2 possibilities to access the name of some classes and methods and their quality (without doing a C++ parser). The first one is to use doxygen directly to generate xml to parse. It produces lots of errors but may be enough for simple uses. There is also visual studio which can ouput xml (it's huge!). I never used the visual studio system though (I mean for reflection). But in both case it's possible to use it (to generate new C++ files, or to feed the program directly). I just say that because it may help. Concerning C++ parsing, I suppose that it is a beautiful wish, but as long as nobody propose a good interface to extract the data out of a bunch of C++ files + configuration generation (including classes, typedef, templates, but also commentaries, pragma, spaces, etc... for code refactoring), then it won't be possible to propose any good implementation. First it needs a tremendous work for specifying a complete convincing C++ interface, then only the implementation might be done. Concerning the whole topic, I think that reasearching is not something bad, as long as you don't lose too much in the process :-). It is sometimes very hard to tell what will be found in the end, and it might be rewarding as well. Best Regards, Pierre Morcello
On 10/19/09 15:54, Pierre Morcello wrote:
From : Jeffrey Bosboom While annotation processors are not allowed to modify the original source files, they are allowed to generate new files that get passed to the compiler
[snip]
Concerning automatic reflection system, I know 2 possibilities to access the name of some classes and methods and their quality (without doing a C++ parser). The first one is to use doxygen directly to generate xml to parse. It produces lots of errors but may be enough for simple uses. There is also visual studio which can ouput xml (it's huge!). I never used the visual studio system though (I mean for reflection). But in both case it's possible to use it (to generate new C++ files, or to feed the program directly). I just say that because it may help.
Concerning C++ parsing, I suppose that it is a beautiful wish, but as long as nobody propose a good interface to extract the data out of a bunch of C++ files + configuration generation (including classes, typedef, templates, but also commentaries, pragma, spaces, etc... for code refactoring), then it won't be possible to propose any good implementation. First it needs a tremendous work for specifying a complete convincing C++ interface, then only the implementation might be done. [snip]
The Texas A&M Profit project *may* be relevant. I've just looked at: http://parasol.tamu.edu/pivot/index.html and it seems to be somewhat related. -regards, Larry
Christian Schladetsch wrote:
Why has the PP received so little attention over the years, from its early use as M4?
There is a library around the C preprocessor in Boost, Boost.Preprocessor (or Boost.PP, depending on how you want to call it). It allows to do very powerful things and it is the most advanced usage of the C preprocessor I've seen. It is widely used by most Boost libraries.
We have Boost.Wave to start with... Why not give it real Expressions? Loops? Scopes? Classes? Templates? memory management? IO?
Expressions, loops, scopes can already be done. For classes, just use tuples. Templates and memory management don't make much sense; IO can be done in terms of #warning or something like that.
Is there any interest in a Boost.C++ ?
You mean an implementation of C++, implemented as a post-processor over another compiler, that would add new features? I believe this could be interesting, but mainly to fix deficiencies or to add future standard features not available in compilers yet.
On 20 Oct 2009, at 10:59, Mathias Gaunard wrote:
Christian Schladetsch wrote:
Why has the PP received so little attention over the years, from its early use as M4?
There is a library around the C preprocessor in Boost, Boost.Preprocessor (or Boost.PP, depending on how you want to call it).
It allows to do very powerful things and it is the most advanced usage of the C preprocessor I've seen.
It is widely used by most Boost libraries.
However, it is, and I say this in the best possible way, in many places really really horrible and inefficent. These problems are caused entirely by a large number of very clever ways of getting around some crippling limitations of the preprocessor, which is being pushed far beyond it's original intention. What kind of things would make using the preprocessor easier, while keeping all remaining programs valid? Here's something I've been playing with (on paper) during this conversation, I'd be interested in what people think. At first I thought about trying to add extra things fairly directly, perhaps by adding some special macros which are compiler-defined. I think now I prefer the idea of adding new types of expressions, because it's easier to show that these won't interfere with the existing rules. As an example: #function defines a simple arithmetic language, for example: #function f(x,y) x + y + 1 The intention is that such expressions will be evaluated by first extending any #function or #define macros, and then evaluating the resulting expression. This would simplify much of the current preprocessor. Of course, using such a thing would require changing your preprocessor to be Boost.wave, instead of your compiler's built-in preprocessor. I've tried doing this in the past as an experiment and it works fine, but I didn't previously find it a particularly useful thing to do. Chris
We have Boost.Wave to start with... Why not give it real Expressions? Loops? Scopes? Classes? Templates? memory management? IO?
Expressions, loops, scopes can already be done. For classes, just use tuples.
Templates and memory management don't make much sense; IO can be done in terms of #warning or something like that.
Is there any interest in a Boost.C++ ?
You mean an implementation of C++, implemented as a post-processor over another compiler, that would add new features?
I believe this could be interesting, but mainly to fix deficiencies or to add future standard features not available in compilers yet.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
First, thanks for all your thoughts and effort in the responses. Your kind and valued attention has helped me to better formalise my original thoughts, and I am grateful. [snip] #function f(x,y) x + y + 1
The intention is that such expressions will be evaluated by first extending any #function or #define macros, and then evaluating the resulting expression. This would simplify much of the current preprocessor.
This is along the lines of the intention of my original post; to come up with constructive ideas on how to extend the PP to service our needs. To address a previous query, yes I am aware of and use Boost.PP (mostly to deal with tedious issues arising from arity), however it is awkward and hard for others in my team to use, and breaks the debugger. So I'll add that to my wishlist: any extensions to the PP should also assist with debugging which is currently pathological in some cases. Others have wondered aloud about my intent or purpose with this thread. I wished to start a wider discussion about how the PP is currently used and why, and how it can be enhanced. Specifically, how we can use Boost.Wave (or ANTLR!) to enhance the PP and avoid some of the extremely clever yet excruciating tricks and hacks it uses. Seriously - if the author of Boost.PP could just remake the PP I'd be happy. He knows it better than most of us. So, ideas like #function are very welcome. I'll add one: #{ #local ident = <expr> #} I don't mean this as a literal and serious proposition; but really, we need scopes in the PP. And/or namespaces. The other half of my original motivation for this thread is to make C++ more elastic in general; not only in terms of constructing the tokens required, but also in interpreting those tokens. This to me is a mirror of the first issue. Even as I wonder about how to improve the PP (which generates code), I also wonder about how to fold that with a P (which interprets it), and wonder about the commonality between those processes. I am pleased that a previous reply questioned my use of "Post-Processor" in the subject, given that the body was about the PP. I carefully intended to introduce that ambiguity. My intent was to get some energy behind the idea of using C++ source code as an output, and treating C++ as a target platform That is, you do some thinking and work in C+++, which outputs C++ (including the PP), which then goes through the common C++ build. P3 is a good name for this; P2 is the current PP++ and P1 is the current runtime++. And P3 is better than C+++. I wonder what the result would be if the great minds that input to boost could instead turn their fantastic faculties to resolving the inherit problems in C++, rather than constantly working around them. I wonder what P2 would look like if the author of Boost.PP was given free license (and support). I wonder what a dynamic C++ runtime, P1, would look like if Joel was given free license to create one (and support). And I wonder what P3 would look like if we could make it. I wonder what could be created if we just shifted a little to the left. A key motivation for the existence of boost is the improvement of C++ - not just as a space for clever and esoteric ways to work around known faults. C++ won't be changed quickly and for good reason. But I am not alone in my impatience. Rather than simply moving my team wholly to the .NET framework, I want to give C++ another chance. It is not unnoticed to me that obvious efforts like #local and #function above to introduce scope to the PP look a lot like COBOL. And this is almost 2010. My heart sinks. D is an effort to address some of these issues, but it doesn't go far enough in some respects and too far in others. I think D is worthy, but I don't think D is the next C++. The next C++ has to be able to compile and link with C++. So, my question is, is C++ the next C++? Can C++ be used to create C++? How? After some thought, I realised that the low-hanging fruit here is in the PP, which is ancient and needs a LOT more love. Some key ideas have come out of this discussion to me already; such as how to deal with compile-time constants in different compilation units (in response to my rant about game build systems) - but that is also an underlying problem with current C++. Rather than proclaiming "Oh, It's too hard, what about project settings" - we need to be thinking about "how do we make the project settings part of the substance of the thing that is used to build the project". Rather than fly off into complete hyperspace, I'll stop now. But please, hear the cry of many C++ developers: we envy some features and are getting tired of being defensive. .NET is awesome; it's cross-platform, performant, and reflected. Better we address that now, if we can, or just confine ourselves to the COBOL of the future. Regards, Christian
Oops, D can compile and link C++, of course. On Thu, Oct 22, 2009 at 12:47 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
First, thanks for all your thoughts and effort in the responses. Your kind and valued attention has helped me to better formalise my original thoughts, and I am grateful.
[snip]
#function f(x,y) x + y + 1
The intention is that such expressions will be evaluated by first extending any #function or #define macros, and then evaluating the resulting expression. This would simplify much of the current preprocessor.
This is along the lines of the intention of my original post; to come up with constructive ideas on how to extend the PP to service our needs.
To address a previous query, yes I am aware of and use Boost.PP (mostly to deal with tedious issues arising from arity), however it is awkward and hard for others in my team to use, and breaks the debugger.
So I'll add that to my wishlist: any extensions to the PP should also assist with debugging which is currently pathological in some cases.
Others have wondered aloud about my intent or purpose with this thread. I wished to start a wider discussion about how the PP is currently used and why, and how it can be enhanced. Specifically, how we can use Boost.Wave (or ANTLR!) to enhance the PP and avoid some of the extremely clever yet excruciating tricks and hacks it uses.
Seriously - if the author of Boost.PP could just remake the PP I'd be happy. He knows it better than most of us.
So, ideas like #function are very welcome. I'll add one:
#{ #local ident = <expr> #}
I don't mean this as a literal and serious proposition; but really, we need scopes in the PP. And/or namespaces.
The other half of my original motivation for this thread is to make C++ more elastic in general; not only in terms of constructing the tokens required, but also in interpreting those tokens. This to me is a mirror of the first issue. Even as I wonder about how to improve the PP (which generates code), I also wonder about how to fold that with a P (which interprets it), and wonder about the commonality between those processes.
I am pleased that a previous reply questioned my use of "Post-Processor" in the subject, given that the body was about the PP. I carefully intended to introduce that ambiguity. My intent was to get some energy behind the idea of using C++ source code as an output, and treating C++ as a target platform That is, you do some thinking and work in C+++, which outputs C++ (including the PP), which then goes through the common C++ build.
P3 is a good name for this; P2 is the current PP++ and P1 is the current runtime++. And P3 is better than C+++.
I wonder what the result would be if the great minds that input to boost could instead turn their fantastic faculties to resolving the inherit problems in C++, rather than constantly working around them.
I wonder what P2 would look like if the author of Boost.PP was given free license (and support). I wonder what a dynamic C++ runtime, P1, would look like if Joel was given free license to create one (and support). And I wonder what P3 would look like if we could make it.
I wonder what could be created if we just shifted a little to the left. A key motivation for the existence of boost is the improvement of C++ - not just as a space for clever and esoteric ways to work around known faults.
C++ won't be changed quickly and for good reason. But I am not alone in my impatience. Rather than simply moving my team wholly to the .NET framework, I want to give C++ another chance.
It is not unnoticed to me that obvious efforts like #local and #function above to introduce scope to the PP look a lot like COBOL. And this is almost 2010. My heart sinks.
D is an effort to address some of these issues, but it doesn't go far enough in some respects and too far in others. I think D is worthy, but I don't think D is the next C++. The next C++ has to be able to compile and link with C++.
So, my question is, is C++ the next C++? Can C++ be used to create C++? How? After some thought, I realised that the low-hanging fruit here is in the PP, which is ancient and needs a LOT more love.
Some key ideas have come out of this discussion to me already; such as how to deal with compile-time constants in different compilation units (in response to my rant about game build systems) - but that is also an underlying problem with current C++. Rather than proclaiming "Oh, It's too hard, what about project settings" - we need to be thinking about "how do we make the project settings part of the substance of the thing that is used to build the project".
Rather than fly off into complete hyperspace, I'll stop now. But please, hear the cry of many C++ developers: we envy some features and are getting tired of being defensive. .NET is awesome; it's cross-platform, performant, and reflected. Better we address that now, if we can, or just confine ourselves to the COBOL of the future.
Regards, Christian
participants (15)
-
Christian Schladetsch -
Christopher Jefferson -
Hartmut Kaiser -
Jarrad Waterloo -
Jeffrey Bosboom -
Joel de Guzman -
Larry Evans -
Mathias Gaunard -
OvermindDL1 -
Pierre Morcello -
Ruediger Berlich -
Sebastian Redl -
Stefan Seefeld -
Thomas Klimpel -
Vladimir Prus