I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices.
The GCC frontend hasn't been integrated into mainline GCC, the LLVM frontend is beta and similarly lives out of tree. A substantial, incompatible, rewrite of the language is currently in progress.
The same can be said for C++0x. And LLVM is not in beta w.r.t Apple.
I've used D for some fun side projects, it is a nicer language than C++. However, would I suggest using it at work, and risking a major, long-living software project on it? Unfortunatly not yet, and most people I've personally spoken to agree.
I am speaking out of my backside when I say anything on this matter, as I have not written anything substantial in D. But my original point remains: why not? There are no tablets written in stone stating Thou Shalt Write In C++. Sure, there are many people that are "language lawyers" and understand the finer intricacies of ADL and that is their livelihood. Great for them. Most of us understand (or could understand) most of boost. It isn't that hard - most of the "chicanery" is to do with xplat systems creating code-paths that even the original authors don't understand. The rest of the magic is in Spirit and similar expression-template-based systems that are only hard to understand because of their working domain. If they were written procedurally, they would be fine, or if they were written in ML they would be fine but because they are written in a strange mixture of bastardised C++ they are esoteric and deemed to be "excellent C++". I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++ and I think that it represents a disservice to the C++ community. Further, I think it has singularly set back language development by years. The damage is untold - if only there was active C++ support for a system like ANTLR for the past few years rather than Spirit then maybe we wouldn't be in the mess we are in now. To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base per se. I just don't think that the C++ compiler was ever meant to be a language tool. I personally have witnessed at least two groups of coders reject a DSL-based solution because they thought that to do so "correctly" would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has no C++ support. It's a crying shame. Why is there no Boost.ANTLR? The question then stands: why stick with C++ for everything? What can D do in similar circumstances? (I know the immediate answer is "we don't use D" but can we please put that aside for a year). I don't know. I haven't used it. I have nothing to do with Digital Mars or Alex. I care only about writing effective code. I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code? Because I can agree with you, when you think that you are writing a lot of boilerplate nonsense to get basic things done. Move semantics and the problems that Ion is having is a case in point. I don't mean to be a misery-guts, but after having looking deeply at the issues I really don't see a way that it can be done without a language change. C++ is a fine language, but seriously, the authors didn't have any idea on how we'd use it and the differences are compounding exponentially. When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later? Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*? Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions? Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles. Say you want to write a geometry library. Ok, stop right there.... Is Boost.Graph the best way to make a basic DAG? I've tried all these systems. They work, there is no doubt. Do they work well, in practice? Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community? I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it. What do you use? Which parts of boost are good to use with least impact? This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm. I am in the position now to decide what will be the language for the next game made in company A. I am strongly tempted to make the core in C# with callouts to C++ libs for physics and render. Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs. Regards, Christian.
On 10 Sep 2009, at 14:25, Christian Schladetsch wrote:
I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices.
The GCC frontend hasn't been integrated into mainline GCC, the LLVM frontend is beta and similarly lives out of tree. A substantial, incompatible, rewrite of the language is currently in progress.
The same can be said for C++0x. And LLVM is not in beta w.r.t Apple.
C++0x isn't finished, but there is already good evidence there will be at least 3 independent implementations, each of which would stand alone if the other two failed, and an official ISO standard of the language. Can you same the same if Digital Mars disappeared tomorrow? LLVM is not in beta, but the D front-end of it is. Not sure what that has to do with Apple. Just a couple of points:
Move semantics and the problems that Ion is having is a case in point.
Of course writing move semantics as a library is horrible, that is why it is being added as a new language feature. It works well, and I am already using it in code. Is C++ the best language ever? Certainly not. But D version 2 is in beta, and is not backwardly compatible with D version 1. Further, there are two completely independent standard libraries for D. Certainly I don't question you, or anyone else, wanting to work with D. I would love nothing more than for it to get to a stable, respectable point where I could move my current C++ code, which runs on computers from massively parallel machines to iPhones, to D. In fact, we've just been looking at the language we should use for a major new system we will be designing over the next 4 years, and took a serious look at D. It's lovely, but in practice D isn't there. Yet.
What do you use? Which parts of boost are good to use with least impact?
Out of interest, I'm not totally sure what that has to do with D. I bet you could write libraries just as complex and pushing language corners in D as you can in C++, without much difficulty. Chris
An interesting statement. Three points: 1/About "Spirit-like C++". You're saying that it's not doing C++ "the way it was intended". Fortunately there are people who go beyond and just "don't use things they way they were designed for". Using a stick to hunt animals? This is just crazy talk. Maybe in the end a C++/Functional language will emerge. Maybe Spirit will be stuck at some point. Maybe Joel will start a new project. Maybe Spirit will be used to program an AI that's going to enslave humanity. Or it will solve world hunger. Who knows? Let people play around with technology. I don't think it harms anyone to try new directions. Competition is good. Everybody working on the same project doesn't improve productivity or quality. Quite the contrary. 2/You overstate the importance of the language choice on the final quality of the program. Tough problems emerge in the C++ language because generally we are closer to the system. So we "see" the problems. It's also because a large part of the community is trying to improve the way we do things for more efficiency and power and people think very hard about rare but real problems. These problems exist nevertheless in the other languages. They were just solved (with more or less luck) by the language maker. Or ignored. Or avoided in a way that really don't help you. You know what's the real influence on the program? The brains working on it. 3/I am pretty sure you are free to use whatever language you fancy for your projects. Meanwhile, the galaxies of the universe will continue an approximatively identical course. (personal advice: you should play with Scheme. It's a good language to learn) In other news I've heard the latest Batman game is awesome. -- EA
Edouard A. wrote:
3/I am pretty sure you are free to use whatever language you fancy for your projects. Meanwhile, the galaxies of the universe will continue an approximatively identical course. (personal advice: you should play with Scheme. It's a good language to learn)
The problem is that you need to provide some kind of guarantee that the language is stable, supported, well-tested and somewhat durable. Otherwise your code will have to fix the language or implementation yourself, or rewrite everything in another language, meaning it ends up costing more.
Christian Schladetsch wrote:
Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*?
Depends. The main advantage of Boost.Spirit is that it's embedded in C++, making it somewhat easier than deploying regular parser generators.
Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions?
I don't even know how you can serialize a function object, especially if you lost its type information.
Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles.
shared_ptr is meant for shared ownership, not automatic resource management. Plus, you can get automatic resource management using the stack (haha! Yes I know, that's not what you meant). And finally, cycles are impossible to support on regular types by design in C++ due to destructors. You'd need to deal with a special category of types, like C++/CLI does. As you can see, this is *nothing* like what shared_ptr provides. It doesn't fit your problem at all, because it's simply not meant to. However, there could be a solution to your problem. It just doesn't exist in boost (even though some people offered to have their solutions included, but the whole formal review thing is making it hard to contribute new libraries).
Say you want to write a geometry library. Ok, stop right there....
If you want to write a geometry library, it may be a good idea to get it in Boost to make it more widespread, yes, unless you really wish not to be affiliated with Boost. I don't really understand that point.
Is Boost.Graph the best way to make a basic DAG?
It's a way. Consider the alternatives and compare them. As I understand, the main advantage of Boost.Graph is that you can reuse the generic algorithms.
I've tried all these systems. They work, there is no doubt. Do they work well, in practice?
The Boost libraries are not supposed to be the ultimate best solution to a problem domain. They're simply specific solutions for specific problems, with advantages and drawbacks. It's up to you to select the solution you think is best for your problem. The advantage of Boost libraries is that they usually fulfill certain base criteria, like being exception-safe, generic, and non-intrusive. Obviously, while those qualities are nice (especially to language lawyers), they're certainly not the most important ones in choosing a solution.
Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community?
I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it.
AFAIK, the only thing that is heavily widespread is shared_ptr, which is heavily misused as a mean to code Java-style and emulate a garbage collector. Boost.Function and Boost.Bind are also used quite a lot, mainly because they are required to deal with the STL easily, but most coders still don't understand how they work and worse, what they are (overusage of boost::function when there is no need for type erasure whatsoever is fairly common). Notice how these things are now part of TR1. Other parts that were adapted in TR1 are fairly used as well. Apart from that, I know the memory pool allocator is popular. Usage of more specific or bigger libraries is what's more scarce. People use the little general tools way more. Which is perfectly logical; it's easier to bring in small tools in a project than a dependency on a fully-fledged library.
This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm.
Well, no one is forcing you to use C++. C++ has quite a few advantages that make it a better general-purpose language than others, especially when efficiency is a concern -- and a few drawbacks as well, but as a C++ lover I don't really see them --, but if you find tools in other languages that you think are better that the ones that exist in C++, and you don't want to code your own tools, then it's really a better idea to use that other language.
I am in the position now to decide what will be the language for the next game made in company A.
Games are often written in a dialect without exceptions. If you're in this case, then you can dismiss huge portions of Boost, since that dialect is really quite different from standard C++.
Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs.
I didn't follow everything that happened with Lucanus' library. Personally I won't use it since I have no use for polygons with integral coordinates. What is the problem exactly? The QA review is too harsh?
Christian Schladetsch wrote:
I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices.
The GCC frontend hasn't been integrated into mainline GCC, the LLVM frontend is beta and similarly lives out of tree. A substantial, incompatible, rewrite of the language is currently in progress.
The same can be said for C++0x. And LLVM is not in beta w.r.t Apple.
I've used D for some fun side projects, it is a nicer language than C++. However, would I suggest using it at work, and risking a major, long-living software project on it? Unfortunatly not yet, and most people I've personally spoken to agree.
I am speaking out of my backside when I say anything on this matter, as I have not written anything substantial in D.
But my original point remains: why not? There are no tablets written in stone stating Thou Shalt Write In C++. Sure, there are many people that are "language lawyers" and understand the finer intricacies of ADL and that is their livelihood. Great for them.
I've considered writing some things in D but it lacked some extremely low level features that I needed for my project. For me it would meet my requirements for utility apps, but not my main project.
Most of us understand (or could understand) most of boost. It isn't that hard - most of the "chicanery" is to do with xplat systems creating code-paths that even the original authors don't understand.
The rest of the magic is in Spirit and similar expression-template-based systems that are only hard to understand because of their working domain. If they were written procedurally, they would be fine, or if they were written in ML they would be fine but because they are written in a strange mixture of bastardised C++ they are esoteric and deemed to be "excellent C++".
I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++ and I think that it represents a disservice to the C++ community. Further, I think it has singularly set back language development by years. The damage is untold - if only there was active C++ support for a system like ANTLR for the past few years rather than Spirit then maybe we wouldn't be in the mess we are in now.
I don't have anything to say about ANTLR, but being able to write a grammar no matter how simple or complex easily in C++ without having to rely on external tools was very appealing to me. I've used spirit to write 4 very simple parsers and the performance of them was very high. I could have used regular expressions or written a custom parser, but spirit was much easier than writing a custom parser and much faster than regex
To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base per se. I just don't think that the C++ compiler was ever meant to be a language tool. I personally have witnessed at least two groups of coders reject a DSL-based solution because they thought that to do so "correctly" would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has no C++ support. It's a crying shame. Why is there no Boost.ANTLR?
The question then stands: why stick with C++ for everything? What can D do in similar circumstances? (I know the immediate answer is "we don't use D" but can we please put that aside for a year).
I don't know. I haven't used it. I have nothing to do with Digital Mars or Alex. I care only about writing effective code.
I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code?
Because I can agree with you, when you think that you are writing a lot of boilerplate nonsense to get basic things done.
Move semantics and the problems that Ion is having is a case in point. I don't mean to be a misery-guts, but after having looking deeply at the issues I really don't see a way that it can be done without a language change. C++ is a fine language, but seriously, the authors didn't have any idea on how we'd use it and the differences are compounding exponentially.
When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later?
Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*?
Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions?
Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles.
Say you want to write a geometry library. Ok, stop right there....
Is Boost.Graph the best way to make a basic DAG?
I've tried all these systems. They work, there is no doubt. Do they work well, in practice?
Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community?
I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it.
What do you use? Which parts of boost are good to use with least impact?
I use spirit, xpressive, algorithm, foreach, shared_ptr, bind, phoenix, filesystem and program_options. I really like filesystem and spirit.
This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm.
Most games are already developed with some type of scripting front end. Unreal engine based games have unrealscript, wow and warhammer have lua, eve and pirates and age of conan have python, aoc even uses boost.python and darkfall uses java.
I am in the position now to decide what will be the language for the next game made in company A. I am strongly tempted to make the core in C# with callouts to C++ libs for physics and render. Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs.
When it comes down to it, I can't really see anything that most other languages have to offer that make them better than C++ other than libraries. C# has .NET and Java has the JDK, python and ruby both have big standard libraries and C++ literally only has a handful of algorithms and containers. That in my opinion is the #1 shortcoming of C++.
Regards, Christian. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Christian < Some extracts that ring true with me, my emphasis applied >
I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++
I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code?
When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later?
I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that.
What do you use? Which parts of boost are good to use with least impact?
I am clearly frustrated with the potential of both boost and C++ in general.
it makes me wonder if C++ is really what the real-time world needs.
I enjoyed and sympathised with pretty much everything you wrote. I want to separate the C++ aspects from the Boost-specific ones. C++ At present I'm not sure an alternative language exists that is mature, cross platform with an appropriately large, diverse, supportive community to provide programmer support in terms of tools, skills availability. I also still shudder that many advanced techniques rely on an enhanced C Preprocessor for their magic. If we want compile time and runtime behaviour, a language ought to support both, without clunky but clever (albeit mostly hidden from the user) techniques. Regarding the ecosystem surrounding a library, I compare C++'s progress with languages such as Python and see C++ as a poor relation in terms of tools to solve real world problems. Boost The focus does seem to be on creating new and novel techniques rather than solving problems or providing cookbooks on how to use these tools to make things easier. Arguably Boost was looking to the wider community and user base to develop the 'user guides' while library developers have a different agenda, focussing on the best interface and implementation. IMO the C++ standardisation process in general and Boost by association may suffer from an academic outlook that prefers to deliver well-crafted items years too late. Boost was supposed to be a test bed and experimental ground but still tries to be too perfect in creating the ultimate library in each area. I'd prefer to see more support, mentoring and advice and a shelter for promoting and improving many more libraries. Perhaps a second tier of toolkits that let evolution sort out more of what is right for programmers? By this I know we have an area for such libraries, but what web site support do we have to 'advertise, extol or document' such fledgling libs? Perhaps more of the web site could provide pointers to such libraries? As an example, consider the library 'property tree'. Its interface and implementation weren't and aren't perfect but they solve a real-world problem in the absence of an alternative. There was a lot of debate that an imperfect library perhaps shouldn't be part of Boost. Thankfully it got accepted and thanks to Sebastian for moving it forward recently. Boost should support and encourage these kinds of libraries even if perhaps not candidates for C++1X material. Paul
As an example, consider the library 'property tree'. Its interface and implementation weren't and aren't perfect but they solve a real-world problem in the absence of an alternative. There was a lot of debate that an imperfect library perhaps shouldn't be part of Boost. Thankfully it got accepted and thanks to Sebastian for moving it forward recently.
We had quite a good review IMO. What do you think it wrong with the library? -Thorsten
Let's please keep the conversation on the topic of C++ library development. Thanks. -- Dave Abrahams Boost Moderator
Am Friday 11 September 2009 01:41:57 schrieb David Abrahams:
Let's please keep the conversation on the topic of C++ library development. Thanks.
I think this proves a point: Am Thursday 10 September 2009 23:32:42 schrieb Paul Baxter:
Boost The focus does seem to be on creating new and novel techniques rather than solving problems or providing cookbooks on how to use these tools to make things easier. Arguably Boost was looking to the wider community and user base to develop the 'user guides' while library developers have a different agenda, focussing on the best interface and implementation.
IMO the C++ standardisation process in general and Boost by association may suffer from an academic outlook that prefers to deliver well-crafted items years too late. Boost was supposed to be a test bed and experimental ground but still tries to be too perfect in creating the ultimate library in each area.
I'd prefer to see more support, mentoring and advice and a shelter for promoting and improving many more libraries. Perhaps a second tier of toolkits that let evolution sort out more of what is right for programmers? By this I know we have an area for such libraries, but what web site support do we have to 'advertise, extol or document' such fledgling libs? Perhaps more of the web site could provide pointers to such libraries?
boost needs a message board/forum/community website.
participants (9)
-
Christian Schladetsch -
Christopher Jefferson -
David Abrahams -
Edouard A. -
Mathias Gaunard -
Paul Baxter -
Raindog -
Stefan Strasser -
Thorsten Ottosen