"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:c21hhr$tfp$1@sea.gmane.org...
[...] If I understand you correctly what you are saying is: "let's have it just because it's cool example of what could be done with C++, good example of GTM in use".
Almost, but not quite. What I'm saying is: "We need more examples of working GTM libraries to advance the state of the art." If everyone who looked at FC++ said: "Been there, done that", then FC++ would not bring this benefit. But because GTM as a programming style is not as mature as, say, OOP, I think we need more instances of GTM code to help establish what constitutes good GTM code.
[...] 1. FC++ is freely available on the web. Do you want to rake up all the code written under boost hood?
Boost has numerous advantages. 1) It's peer-reviewed, so you know that at least some knowledgable people have looked at the library and offered comments. 2) It has higher standards of portability than your average project. Also, people who find it useful are more likely to port it to another platform if it is in Boost than if it is hiding somehwere with less exposure. Considering the wide variety of implementation qualities, I think having another big GTM library that stresses compilers helps to expose weaknesses and find workarounds. 3) It fosters competition. I know that sounds like a bad thing for Boost libraries, but I don't know why it should be. Why should any library enjoy a monopoly by fiat? The differences between libraries get debated, and at the least, users get even more rationale as to why various design choices were made, and more commonly, have a *choice* when making certain trade-offs. And I think the primary benefit of C++ as a language is the huge amount of choice it gives you as far as implementation qualities go.
2. There is nothing cool about class designed and implemented the way so it works 320 times slower then similar solution written in different style. And I am not talking about minor issues related to abstraction overhead and portability workarounds. There should be something wrong in the very heart of the design, for this to happened.
No, what was wrong is that you were comparing apples to oranges. If I write a bubble sort, and you write a quicksort that is 320 times faster, and say that it's "similar", I'm going to think you're crazy.
3. One of the main lessons I brought from numerous examples of GTM is actually that we need to stay away from FP in our production programming as far as possible. After all usage of FP techniques it's primary reason why compilation more and more taking ridiculously long time nowadays.
Is it FP techniques, or GTM techniques? Because those are logically orthogonal, as far as I can see.
[...] My understanding is that there exist already solution in sandbox to implement support for result_of. And example of PP usage are all over the place (not mentioning that PP has pretty good docs). If you need more examples let's then just have new section dedicated to an example of usage and put some staff there. [...]
I think you're missing the forest for the trees. For instance, would people care about a standardized result_of<>, rather than a custom one, if it were only used in one library? I only mentioned that because I happened to see it mentioned in the thread. But I'm sure there are many other mechanisms that are common among FC++, Lambda, and several other related libraries. But maybe some of the libraries only share a mechanism with one other library, and it's not evident that the mechanism should become idiomatic. But if more libraries (like FC++) are considered, then the patterns start to emerge, and we get a better idea of which code patterns are being reused across libraries/applications. Whereas, if we say: "Let's go for the smallest possible number of libraries", you might miss out on possibilities for abstraction because many devices might appear on the surface to only be singularly useful. In the early days of coding, programmers focused on basic algorithms. We now have those algorithms, and they are so standard that we can write an entire library of them in a very generic way. The same is true of data structures. Now we have entered a new era in programming where the entities being explored are Concepts. Concepts are not nearly so obvious to formalize as algorithms and data structures, partly because we need to see several uses of a concept before we determine its usefulness. And we cannot establish this baseline of usage unless we look at a lot of GTM code. It's a statistical process, after all. I wouldn't say that FC++ should be accepted on this basis alone. I think there are other reasons to consider the library. But I think it is an advantage in having the library as part of Boost (because Boost is perhaps considered more authoritative than other library collections). Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004