New libraries implementing C++11 features in C++03
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff
Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
Hi, I think that there is a difference between Boost.Local and Boost.Move. Boost.Move provides an emulation of a C++11 feature on compilers that don't provides this feature. Boost.Local provides an emulation of a feature that has not been accepted to c++11. Note that I'm not saying that Boost.Local should not be accepted, but I'm sure that things will be different if Boost.Local provided an emulation for c++11 lambdas, that is, if in c++11 compilers the macros could be able to generate C++11 lambdas. The question I have for the Boosters that don't like the local function approach is if they will accept as a good approximation of the following use of a lambda expression std::sort(x, x + N, [](float a, float b) {return std::abs(a) < std::abs(b); }); the storage on a temporary as in auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; std::sort(x, x + N, cmp); If Lorenzo would be able to define a macro that could be used to replace the named lambda as in BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < std::abs(b); })); std::sort(x, x + N, cmp); could you consider that this is promoting good usage of C++11 features on compilers that don't provide them and be a good candidate for a Boost library? Best, Vicente
On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the
Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
Hi,
I think that there is a difference between Boost.Local and Boost.Move. Boost.Move provides an emulation of a C++11 feature on compilers that don't provides this feature.
Boost.Local provides an emulation of a feature that has not been accepted to c++11. Note that I'm not saying that Boost.Local should not be accepted, but I'm sure that things will be different if Boost.Local provided an emulation for c++11 lambdas, that is, if in c++11 compilers the macros could be able to generate C++11 lambdas.
Well, named lambdas are basically the same as local functions, no? What I really mean is, Local provides an imperfect emulation of C++11 lambdas, but by the same token, Boost.Move provides an imperfect emulation of rvalue references. The question I have for the Boosters that don't like the local function
approach is if they will accept as a good approximation of the following use of a lambda expression
std::sort(x, x + N, [](float a, float b) {return std::abs(a) < std::abs(b); });
the storage on a temporary as in
auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; std::sort(x, x + N, cmp);
If Lorenzo would be able to define a macro that could be used to replace the named lambda as in
BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < std::abs(b); })); std::sort(x, x + N, cmp);
could you consider that this is promoting good usage of C++11 features on compilers that don't provide them and be a good candidate for a Boost library?
This is drifting away from my intended thread topic a little bit. But, nonetheless... Isn't this latter syntax trivial to implement with the present macros provided by Local? And, as an aside, the significant disadvantage to the above versus splitting the declaration over 2 macro instantiations is that compiler error messages from the body of the function would be less informative (essentially missing line numbers). Oh, and I don't know if you can reliably do your BOOST_AUTO_LAMBDA syntax without variadic macros. That said...it may be convenient to provide something like that the BOOST_AUTO_LAMBDA macro for simple and small named lambdas with no unparenthesized commas. - Jeff
Le 22/11/11 21:32, Jeffrey Lee Hellrung, Jr. a écrit :
On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba< vicente.botet@wanadoo.fr> wrote:
Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
This is drifting away from my intended thread topic a little bit. But, nonetheless...
You are right. I should create a new thread instead as my questions were addressed to those that are not in favor of Boost.Local. Sorry, Vicente
On 11/23/2011 3:39 AM, Vicente J. Botet Escriba wrote:
Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
Hi,
I think that there is a difference between Boost.Local and Boost.Move. Boost.Move provides an emulation of a C++11 feature on compilers that don't provides this feature.
As Hartmut said, Boost.Move is an infrastructure library needed by Boost itself. Move semantics is crucial. Local functions are not.
Boost.Local provides an emulation of a feature that has not been accepted to c++11. Note that I'm not saying that Boost.Local should not be accepted, but I'm sure that things will be different if Boost.Local provided an emulation for c++11 lambdas, that is, if in c++11 compilers the macros could be able to generate C++11 lambdas.
The question I have for the Boosters that don't like the local function approach is if they will accept as a good approximation of the following use of a lambda expression
std::sort(x, x + N, [](float a, float b) {return std::abs(a) < std::abs(b); });
the storage on a temporary as in
auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; std::sort(x, x + N, cmp);
If Lorenzo would be able to define a macro that could be used to replace the named lambda as in
BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < std::abs(b); })); std::sort(x, x + N, cmp);
could you consider that this is promoting good usage of C++11 features on compilers that don't provide them and be a good candidate for a Boost library?
Local cannot be an approximation of lambda. As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix. I posted a Spirit example of lambda in action using Phoenix: http://tinyurl.com/7w2h2r9 Try as hard as you can, but you cannot ever come close to the clarity of the syntax presented there. Proponents of locals have cited error-messages generated by the compiler as a justification for Locals. Locals is probably a good workaround. But hear me out... Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda: http://tinyurl.com/7um5yr4 If we chose to workaround the problem of C++ error messages in 2002, we would have ended up with something like Locals and there will be no experience that will pave the way towards C++11 lambda. Instead of working around the problems and offer less than elegant APIs and libraries for the sake of portability with ancient compilers, what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages. TMP libraries are ubiquitous in modern C++. Avoiding them because of the problem of error messages is backwards thinking. What we should do instead is to find better solutions, not hide the problems. This is Boost! Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Nov 23, 2011, at 12:21 PM, Joel de Guzman wrote:
Local cannot be an approximation of lambda. As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix. I posted a Spirit example of lambda in action using Phoenix:
Try as hard as you can, but you cannot ever come close to the clarity of the syntax presented there.
Sure, there are cases where it works quite well. Nobody here has been arguing that Boost.Lambda and friends are never the best solution for any problem. As I have said before, although I don't like using Boost.Lambda for non-trivial things I frequently use it for trivial functions like the ones in your example above precisely because it is so concise.
Proponents of locals have cited error-messages generated by the compiler as a justification for Locals. Locals is probably a good workaround. But hear me out...
Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda:
If we chose to workaround the problem of C++ error messages in 2002, we would have ended up with something like Locals and there will be no experience that will pave the way towards C++11 lambda.
But that very link is all about a proposal to build lambdas into the language as a "workaround" for the fact that the current C++ standard and compilers made library-based solutions have serious limitations such as undecipherable error messages! That is, building lambdas into the C++ language so that plain C++ syntax could be used was *exactly* a "workaround the problem of C++ error messages". To the extent that Boost.Lambda did indeed pave the way for the implementation of C++11 lambdas, it was by providing an example of how it *shouldn't* be done, namely by using a library based solution that employs non-standard C++ syntax for function bodies.
Instead of working around the problems and offer less than elegant APIs and libraries for the sake of portability with ancient compilers, what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages. TMP libraries are ubiquitous in modern C++. Avoiding them because of the problem of error messages is backwards thinking.
But the whole point of using a library is to make one's life easier! Are you really saying that it is "backwards thinking" to avoid using a shiny new library merely because it is so difficult to use in practice that it makes one's life harder rather than easier?
What we should do instead is to find better solutions, not hide the problems.
Sure, but until them some of us actually want to write code *now* that solve the problems that we currently face, rather than waiting first for C++ compiler technology to improve enough that a particular library will finally become useful for us to use to solve our problem. Furthermore, for older releases of compilers there will *never* be solutions to many of these problems since their development has been frozen in favor of the newer releases.
This is Boost!
If Boost really were primarily about providing functionality that will only become truly useful on compilers that don't actually exist yet, then I am not sure why anyone would pretend that Boost was *also* intended for practical every-day use by programmers just looking to solve problems. I mean, your point that Boost should be pushing the envelope is well taken, but surely this shouldn't be done at the expense of refusing to ever address the issues that we face in the present. As a wise man once said: "As you know, you go to code with the compilers you have, not the compilers you might want or wish to have at a later time." Cheers, Greg
On 11/23/2011 12:22 PM, Gregory Crosswhite wrote:
On Nov 23, 2011, at 12:21 PM, Joel de Guzman wrote:
Are you really saying that it is "backwards thinking" to avoid using a shiny new library merely because it is so difficult to use in practice that it makes one's life harder rather than easier?
In a way, yes. It is the same reasoning why people avoided STL in the early days because of the "undecipherable error messages" it produces. Yet, for the early adopters who went ahead despite the bleeding edge, things got better and everyone benefited when more understood how things are, the limitations and gotchas. Someone even wrote a software (STLFilt) to make the errors decipherable somehow. This is boost and we push the limits. It's the same early adopters that went on to use heavy TMP libraries like Lambda. In the end, everyone, including the bleeding-edge-shy, benefited because C++ became a better language! No thanks to those who avoided using a shiny new library allegedly "because it is so difficult to use in practice that it makes one's life harder rather than easier." -- a misguided perception, IMO. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
23.11.2011 8:22, Gregory Crosswhite пишет:
If Boost really were primarily about providing functionality that will only become truly useful on compilers that don't actually exist yet, then I am not sure why anyone would pretend that Boost was *also* intended for practical every-day use by programmers just looking to solve problems. I mean, your point that Boost should be pushing the envelope is well taken, but surely this shouldn't be done at the expense of refusing to ever address the issues that we face in the present.
As a wise man once said: "As you know, you go to code with the compilers you have, not the compilers you might want or wish to have at a later time."
We lived without macro-style lambdas for more than ten years. We can wait for 2-3 years. OTOH, if the boost.local will be included into the boost, it will be neccessary to support it forever or reimplement all the code that depends on it. Please note that the boost.move was accepted before the c++11 was accepted. I think it is too late to include the boost.local into the boost. OTOH, the boost.atomic is compatible with std::atomic. It will be relatively easy to remove it from the boost when c++11-incompatible compilers become obsolete. -- Sergey Cheban
On Nov 23, 2011, at 9:15 PM, Sergey Cheban wrote:
23.11.2011 8:22, Gregory Crosswhite пишет:
If Boost really were primarily about providing functionality that will only become truly useful on compilers that don't actually exist yet, then I am not sure why anyone would pretend that Boost was *also* intended for practical every-day use by programmers just looking to solve problems. I mean, your point that Boost should be pushing the envelope is well taken, but surely this shouldn't be done at the expense of refusing to ever address the issues that we face in the present.
As a wise man once said: "As you know, you go to code with the compilers you have, not the compilers you might want or wish to have at a later time."
We lived without macro-style lambdas for more than ten years. We can wait for 2-3 years. OTOH, if the boost.local will be included into the boost, it will be neccessary to support it forever or reimplement all the code that depends on it.
Please note that the boost.move was accepted before the c++11 was accepted. I think it is too late to include the boost.local into the boost.
Just to be clear, what you quoted was my response to the apparent argument that Local doesn't belong in Boost for the reason that we should be using Lambda/Phoenix instead, with the justification being that the essence of the Boost project is to have us use libraries that give us bad experiences so that we can provide feedback based on these experiences to improve C++ compilers. I was not trying to argue that Boost should accept every library that provides useful functionality in the present without regard for its impact on the future of Boost. I do think that your argument that adding Local to Boost would add an eternal support burden for something that is only needed for 2-3 years is a fair objection; ultimately this comes down to subjective judgement.
OTOH, the boost.atomic is compatible with std::atomic. It will be relatively easy to remove it from the boost when c++11-incompatible compilers become obsolete.
That is a fair point; deprecation of Boost.Atomic would be a lot easier change for end users to deal with than deprecation of Boost.Local --- assuming that Boost.Local is destined to be deprecated. Cheers, Greg
On 11/23/2011 7:43 PM, Gregory Crosswhite wrote:
Just to be clear, what you quoted was my response to the apparent argument that Local doesn't belong in Boost for the reason that we should be using Lambda/Phoenix instead, with the justification being that the essence of the Boost project is to have us use libraries that give us bad experiences so that we can provide feedback based on these experiences to improve C++ compilers. I was not trying to argue that Boost should accept every library that provides useful functionality in the present without regard for its impact on the future of Boost.
Sigh. This is hopeless. Anyway, I've said enough and I rest my case. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
I've implemented several of the new features of the C++11 standard library for the upcoming Boost.Algorithm library. I will be putting them up for comment as soon as the library review is finished. [ Examples: copy_if, find_if_not, iota, is_partition, partition_point, and so on ] -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 23 November 2011 02:21, Joel de Guzman <joel@boost-consulting.com> wrote:
As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix.
From the lambda paper, "Unfortunately, this elegant solution suffers from serious problems in terms of usability, implementation complexity, and performance". I don't think I'd use local, but it seems clear that while the final result might be uglier, it's a lot less work to get there.
Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda:
That paper seems to see boost lambda mainly as an example of what not to do. C++11 would probably have lambdas regardless of boost; their importance and the difficulties in implementing them in a language like C++ were well understood already.
On 11/23/2011 5:17 PM, Daniel James wrote:
On 23 November 2011 02:21, Joel de Guzman <joel@boost-consulting.com> wrote:
As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix.
From the lambda paper, "Unfortunately, this elegant solution suffers from serious problems in terms of usability, implementation complexity, and performance". I don't think I'd use local, but it seems clear that while the final result might be uglier, it's a lot less work to get there.
Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda:
That paper seems to see boost lambda mainly as an example of what not to do. C++11 would probably have lambdas regardless of boost; their importance and the difficulties in implementing them in a language like C++ were well understood already.
The paper lists down the limitations of a library based lambda solution and why we need lambda in the language. While I agree that C++11 would probably have lambdas regardless of boost, I'm quite sure that the development of Bind, Lambda, Phoenix and FC++ was instrumental in the development of C++ lambda. At least 3 of the authors were proponents and/or authors of library based lambda solutions. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Tue, Nov 22, 2011 at 9:21 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 11/23/2011 3:39 AM, Vicente J. Botet Escriba wrote:
Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
Hi,
I think that there is a difference between Boost.Local and Boost.Move. Boost.Move provides an emulation of a C++11 feature on compilers that don't provides this feature.
As Hartmut said, Boost.Move is an infrastructure library needed by Boost itself. Move semantics is crucial. Local functions are not.
Boost.Local provides an emulation of a feature that has not been accepted to c++11. Note that I'm not saying that Boost.Local should not be accepted, but I'm sure that things will be different if Boost.Local provided an emulation for c++11 lambdas, that is, if in c++11 compilers the macros could be able to generate C++11 lambdas.
The question I have for the Boosters that don't like the local function approach is if they will accept as a good approximation of the following use of a lambda expression
std::sort(x, x + N, [](float a, float b) {return std::abs(a) < std::abs(b); });
the storage on a temporary as in
auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; std::sort(x, x + N, cmp);
If Lorenzo would be able to define a macro that could be used to replace the named lambda as in
BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < std::abs(b); })); std::sort(x, x + N, cmp);
could you consider that this is promoting good usage of C++11 features on compilers that don't provide them and be a good candidate for a Boost library?
Local cannot be an approximation of lambda. As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix. I posted a Spirit example of lambda in action using Phoenix:
Try as hard as you can, but you cannot ever come close to the clarity of the syntax presented there. Proponents of locals have cited error-messages generated by the compiler as a justification for Locals. Locals is probably a good workaround. But hear me out...
Nope, not just a good workaround for error-messages. Proponents of Locals mentioned two (2) main things as advantages. Please let's cite both of them correctly: 1) Use statement syntax for function definition. 2) Compiler error retain their usual meaning for the function definition. While these two things are related from an library implementation prospective, they are two different advantages for the library end-user. The politically correct sentence fro the docs: "[Local functions] can be defined using C++ statement syntax plus eventual compiler errors follow the usual format of C++ statement errors". https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca...
Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda:
If we chose to workaround the problem of C++ error messages in 2002, we would have ended up with something like Locals and there will be no experience that will pave the way towards C++11 lambda.
Instead of working around the problems and offer less than elegant APIs
"less than elegant API" is a subjective statement. I could argue that Lambda and Phoenix offer a "less" than elegant API because it differs from C++ statement and now C++11 lambda expression syntax.
and libraries for the sake of portability with ancient compilers, what
C++03 are not _ancient_ at my work, they are current and they will be for the next 2 years (optimistic), or 5 years (pessimistic)-- I think 3 years is realistic in my case. Others have expressed the same situation. On the contrary C++11 are futuristic compilers at this moment at my work. I understand that at other's work place the situation might be different.
we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages. TMP libraries are ubiquitous in modern C++. Avoiding them because of the problem of error messages is backwards thinking. What we should do instead is to find better solutions, not hide the problems.
This is Boost!
How is a library like Boost.Algorithm pushing the limit? It's a very useful library, I want its algorithms for my C++03 work (even if a lot of these algorithms are in the C++11 STL) so I voted for admission of Boost.Algorithm. I still stand for that "yes" vote because I need to use its algorithms even if trivial (e.g., all_of) on C++03. IMO, Boost.Algorithm is not pushing the limit at all but it makes my programming experience easier. Why shouldn't Boost be about marking programming easier even if it doesn't push the limit? I think it should. Actually I think that making programming easier for the library end users should the Boost main goal (no need to push the limit unless necessary to offer the user a feature that will make their programming experience easier). Otherwise, Boost is a library to show off research projects that push the limit instead of a library that provides good (best?) solutions to be used in production code. HTH, --Lorenzo
On Wed, Nov 23, 2011 at 1:53 AM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
...Why shouldn't Boost be about marking programming easier even if it doesn't push the limit? I think it should. Actually I think that making programming easier for the library end users should the Boost main goal (no need to push the limit unless necessary to offer the user a feature that will make their programming experience easier)...
+1
On 11/23/2011 5:53 PM, Lorenzo Caminiti wrote:
we should do is push the C++ compiler writers to give us library writers
more power to address the problems such as the often cited deluge of undecipherable error messages. TMP libraries are ubiquitous in modern C++. Avoiding them because of the problem of error messages is backwards thinking. What we should do instead is to find better solutions, not hide the problems.
This is Boost!
How is a library like Boost.Algorithm pushing the limit? It's a very
How did you arrive at that? I said: "what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages." Please read that again. You've mixed that with what I said earlier: "Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11." I never said that all libraries in Boost push the limits of C++. All the rest of your reply is irrelevant. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 11/23/2011 03:21 AM, Joel de Guzman wrote:
Local cannot be an approximation of lambda. As mentioned again and again, a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix. I posted a Spirit example of lambda in action using Phoenix:
DSELs for lambdas have a lot of limitations (cannot use functions and member functions as-is, they must be adapted), compile-time overhead, runtime overhead (all those small functions do inhibit certain optimizations that would happen more easily with short straightforward code, instead it relies on premature aggressive inlining) and have non-obvious interactions with the rest of the code that make them hard to use for people without advanced C++ expertise, and deal to error messages that simply overwhelming and often *cannot* be understood by average coders. Now however, they're very cool, but it's just not the best solution to the problem. It's one solution, with its own set of advantages (short concise syntax, polymorphism, compile-time AST that can be manipulated and transformed) and drawbacks (see above). Boost.Local is another solution for C++03, which is however made obsolete by C++11 lambdas. Both deserve to exist, just like there is both boost::for_each and BOOST_FOREACH (the latter being obsoleted by the C++11 range for-loop) even if it's a bit late for Boost.Local to shine.
On 11/23/2011 11:03 AM, Mathias Gaunard wrote:
hard to use for people without advanced C++ expertise, and deal to error messages that simply overwhelming and often *cannot* be understood by average coders.
Sorry, should have been hard to use for people without advanced C++ expertise, and lead to error messages that are simply overwhelming and often *cannot* be understood by average coders.
Hi, There as a discussion before where a proposition was to have two high versions of boost : 1.xx (like the current ones) that would be guaranteed to work with C++03 compilers, 2.xx that would require C++11 compilers. 1.xx would contain all the libraries but the ones requiring C++11 2.xx would contain all the libraries but the but the ones that cannot work on a C++11 compiler (I guess none) plus libraries (and versions of libraries) requiring C++11. Maybe 2.xx could even remove libraries that would be considered obsolete by the new standard. That would be too much work I guess. Or something like that. I'm guessing it have been considered as not a good idea? Too much work? Joël Lamotte
There as a discussion before where a proposition was to have two high versions of boost : 1.xx (like the current ones) that would be guaranteed to work with C++03 compilers, 2.xx that would require C++11 compilers. 1.xx would contain all the libraries but the ones requiring C++11 2.xx would contain all the libraries but the but the ones that cannot work on a C++11 compiler (I guess none) plus libraries (and versions of libraries) requiring C++11. Maybe 2.xx could even remove libraries that would be considered obsolete by the new standard. That would be too much work I guess.
I like this idea. Here's how I envision it might work: - At some point, we decide to fork Boost into Boost v1 and Boost v2. This will probably have to wait until the major compilers have reasonably complete C++11 support, so we don't have to be backwards-compatible to incomplete C++11 implementations. Obviously small issues can be worked around, but the big features should be there. At the moment of the fork, all libraries are still C++03-compatible. - Library authors/maintainers who are not interested in C++11 yet can continue treating the v1 and v2 forks of their libraries as one, making identical changes to both versions. - Library authors/maintainers interested in C++11 can start adding C++11 features to their v2 forks, or refactoring their v2 forks to take advantage of C++11 features (e.g. refactoring Boost.Fusion to use variadic templates). - For libraries which have started using C++11 in v2, and therefore their v1 and v2 forks are different, all new features and bug fixes would go into the v2 fork only by default. If it's a bug fix, or a feature that is possible even in the C++03 v1 implementation, and the library maintainer, or someone else, cares to do so, they can back-port the new feature to the v1 fork. - For libraries that are obsoleted by C++11, such as Boost.Move or Boost.Tuple, they would be kept around in v2 until all v2 forks that depend on them have been refactored to use the C++11 equivalents, at which point they will be deprecated and ultimately removed. Boost users who have upgraded to v2 have until this time to refactor their own code to use the C++11 equivalents as well. - Over time, there will be less and less interested in C++03 support, and the v1 fork will begin to fall into disuse. Ultimately, it too will be deprecated and removed (this will probably be in 10 years or more, by my guess). Thoughts? Regards, Nate
On 23 Nov 2011, at 20:54, Nathan Ridge wrote:
I like this idea. Here's how I envision it might work:
- At some point, we decide to fork Boost into Boost v1 and Boost v2. This will probably have to wait until the major compilers have reasonably complete C++11 support, so we don't have to be backwards-compatible to incomplete C++11 implementations. Obviously small issues can be worked around, but the big features should be there. At the moment of the fork, all libraries are still C++03-compatible. - Library authors/maintainers who are not interested in C++11 yet can continue treating the v1 and v2 forks of their libraries as one, making identical changes to both versions. - Library authors/maintainers interested in C++11 can start adding C++11 features to their v2 forks, or refactoring their v2 forks to take advantage of C++11 features (e.g. refactoring Boost.Fusion to use variadic templates). - For libraries which have started using C++11 in v2, and therefore their v1 and v2 forks are different, all new features and bug fixes would go into the v2 fork only by default. If it's a bug fix, or a feature that is possible even in the C++03 v1 implementation, and the library maintainer, or someone else, cares to do so, they can back-port the new feature to the v1 fork. - For libraries that are obsoleted by C++11, such as Boost.Move or Boost.Tuple, they would be kept around in v2 until all v2 forks that depend on them have been refactored to use the C++11 equivalents, at which point they will be deprecated and ultimately removed. Boost users who have upgraded to v2 have until this time to refactor their own code to use the C++11 equivalents as well. - Over time, there will be less and less interested in C++03 support, and the v1 fork will begin to fall into disuse. Ultimately, it too will be deprecated and removed (this will probably be in 10 years or more, by my guess).
Thoughts?
Several libraries poorly supported on many compilers. Stacking up more work is a bad idea, if anything boost needs to support less compiler configurations, not more! Chris
On Wed, Nov 23, 2011 at 22:00, Christopher Jefferson <chris@bubblescope.net>wrote:
Several libraries poorly supported on many compilers. Stacking up more work is a bad idea, if anything boost needs to support less compiler configurations, not more!
Chris
Actually, I agree with this, but it also suggests that at some time in the coming years boost devs will have to choose if they want the whole boost "label" to be about C++03 or C++11. Or maybe there can be a "superset" of boost (Boost++?) that would be all C++03 and C++11 compatible libraries plus C++11 only libraries. Anyway the problem of knowing what is acceptable in boost is expanded by the new standard, and so far I didn't read any policy about it. Joël Lamotte
On Tue, Nov 22, 2011 at 9:21 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Local cannot be an approximation of lambda. As mentioned again and again,
I said this many times before but I feel I should have repeated myself here in my previous reply. Yes you are correct, Locals are not an approximation of lambdas because they cannot be defined within expressions (which is a fundamental defining feature of lambdas). Locals instead define closures at local statement scope, they use statement syntax to implement the function body, they work on both C++03 and C++11, they have compile and run-time performances similar to the ones of C++11 lambdas on C++11 compilers (wow, that's a long sentence but I think it summarizes everything :) ).
a good approximation of lambda is already existing in Boost. Namely: bind, lambda and phoenix. I posted a Spirit example of lambda in action using Phoenix:
Try as hard as you can, but you cannot ever come close to the clarity of the syntax presented there. Proponents of locals have cited error-messages generated by the compiler as a justification for Locals. Locals is probably a good workaround. But hear me out...
--Lorenzo
On Wed, Nov 23, 2011 at 4:27 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
I have been watching the discussions around the reviews for the proposed Boost.Local library. I would like to weigh in on this issue that seems to be important to address from a non-involved perspective (mostly because I haven't sent in a review for Boost.Local nor would I do that even now). First, I think there's two problems here that we're all trying to solve: 1) C++11 is good but apparently people don't think it's good enough for production yet. There's a temporal dimension to this problem which means it's just a matter of time when compilers support C++11 as the de-facto version of the language that is supported. During this delay though people want to get the features in C++11 approximated in C++03. 2) C++11 doesn't include a feature that some people find may be useful but can be forced onto users (or at least is being tried to make it popular by getting it into Boost) using whatever facilities are available in the language. The categorical dimension here is not tied to time, effort, or anything else but rather the state of the standard. For solutions that address #1, I would say it depends -- if Boost.Move, Boost.Shared_ptr, Boost.Scoped_ptr, etc. get deprecated when C++11 has been made ubiquitous (which I would believe should be the correct way forward) then yes. Boost.Local unfortunately doesn't belong with the grouping of these libraries precisely because it addresses #2 however "semantically equivalent" local functions are to C++11 lambdas. For solutions that address #2, I would say probably if it's done in good taste and follows the traditions of Boost in terms of quality of implementation, quality of execution, and utility of the solution. I'd say though that addressing issues that fall under the #2 category should be implemented as compiler extensions instead of hacks using existing current language features. This is to say that although Boost.Concept_check is there as a good proof of concept for Concepts, it by itself stands as something that shows the utility of the library in the tradition of Boost's quality. Same goes for things like Phoenix and Proto -- Phoenix allows polymorphic lambdas while Proto allows for doing DSEL building in C++. I would imagine that if/when C++1x gets polymorphic lambdas and maybe expression template building facilities built in then it's worth deprecating those libraries as well. Note that neither of these things resort to using macros which are cheap alternatives to people writing it down themselves. So applying my logic to the discussion on Boost.Local, I see it as doing a not-so-good job of doing #1 while falling short in #2. If however it proves that local functions would be a good addition to the language, I would suggest that the library live outside of Boost, get critical mass, and then be proposed as an extension to the language in the form of a proposal for local functions. Although I don't see how local functions are better than C++11 lambdas that are auto-captured to a local variable, maybe other people would like to use local functions as a different syntax.
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years.
I would then think that there's nothing stopping them from using the library even if it's not in Boost.
- Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
I would think though that these transitional libraries would be deprecated as soon as the standard counterparts become ubiquitous. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
Same goes for things like Phoenix and Proto -- Phoenix allows polymorphic lambdas while Proto allows for doing DSEL building in C++.
I would imagine that if/when C++1x gets polymorphic lambdas and maybe expression template building facilities built in then it's worth deprecating those libraries as well.
I don't think Phoenix is an appropriate example here. The contribution of Phoenix to C++ goes far beyond just simulating polymorphic lambdas or providing a terser syntax for some lambdas. Phoenix allows representing pieces of code as data, which can then be traversed/analyzed/transformed. Adding polymorphic lambdas or nicer lambda syntax to C++1x isn't going to deprecate that use case.
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years.
I would then think that there's nothing stopping them from using the library even if it's not in Boost.
The name "Boost" carries with it a certain standard of excellence, quality of implementation, and ubiquity. As a result, it is often much more feasible to use a library in a project/team/company if it's part of Boost than if it isn't. Case in point: at my company, we use Boost extensively, but management is very hesitant to introduce a dependency on other libraries, especially if the library "merely" makes coding in general more convenient, rather than providing some domain-specific features or API. I think the situation is similar in many other companies and projects. For this reason, I think libraries whose purpose is to make general-purpose coding more convenient, rather than some domain-specific use, are especially appropriate for inclusion in Boost.
- Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
I would think though that these transitional libraries would be deprecated as soon as the standard counterparts become ubiquitous.
Do you consider C++03 as having been ubiquitous for the past 7-10 years? If so, Boost has really been bending over backwards to support compilers that don't support all C++03 features. And that was to support compilers that did not conform to any standard at all! I would expect just as much sympathy and support for compilers which do support a standard (C++03), just not the latest one (C++11), for at least as much time. Regards, Nate
question:What is Boost? a) A collection of libraries to make as many C++ programmers as possible more productive? b) A staging area for libraries which are aimed at being included in the standard library? c) An area for expermenting with and testing new ways of using C++ to exploit novel ideas in software developement like functional programming, DSELs, etc. (I know these aren't new ideas but implementing them within the compile time type system of a widely used language seems pretty novel to me) d) A collection of "facades" to permit one to write one program/algorithm which will efficiently run accross different combinations of OS's and compilers e) A vehicle for promoting C++ to a wider audience and promote quality software practices in general. f) Provide the "definitive" implementation of commonly required components. example shared_ptr. f) ... you're own view here. answer: yes! Do these goals conflict? Personally I don't think so - but a case could be made that they do at least in some cases. example: perhaps supporting portability encourages compiler vendors to postpon investment in compiler development. and of course f) would preclude the inclusion of multiple libraries which do the same thing. So I'm more of the view that we let stuff into boost as long at it meets quality standards. Then let users decide. I very much appreciate the documentation page which shows libraries grouped by functionality. This page isn't on the website (it should be!). I would like to see this page enhanced to include some more categories. libraries to support C++11 like features for older compilers libraries to support compatibility accross OS basically config which I use all the time for this purpose libraries which exploit C++11 and make no claim to backward compatibility. (and of course the test matrix needs to be adjusted to distinguish these - config as well I forsee a messy transitional stage which a lot of old libraries start to fail with C11x and lot's of older user code can't incorporate some libraries and much confusion as to what one can and cannot do. To remain a practical resource for many organizations we can't just say - sorry if you can't change compilers. Robert Ramey
On 23 November 2011 13:09, Robert Ramey <ramey@rrsd.com> wrote:
I forsee a messy transitional stage which a lot of old libraries start to fail with C11x
Why? There are some minor incompatibilities between C++03 and C++11, but using Boost with C++11 switched on seems to be going smoothly. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
On 23 November 2011 13:09, Robert Ramey <ramey@rrsd.com> wrote:
I forsee a messy transitional stage which a lot of old libraries start to fail with C11x
Why?
As time goes on, newer libraries and updates will start to become dependent upon C++11 features. This will be a problem for those who work with compilers which don't yet incorportate the C++11 features. So they'll be stuck for a while. And it's not clear from looking at the library documentation what it depends on.
There are some minor incompatibilities between C++03 and C++11, but using Boost with C++11 switched on seems to be going smoothly.
That's good to hear. But won't we get a lot of test matrix failures with a lot of compilers we test with as soon as C++11 features start getting used? Won't this create a problem that will have to be addressed somehow? Robert Ramey
On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey@rrsd.com> wrote:
question:What is Boost?
a) A collection of libraries to make as many C++ programmers as possible more productive? b) A staging area for libraries which are aimed at being included in the standard library? c) An area for expermenting with and testing new ways of using C++ to exploit novel ideas in software developement like functional programming, DSELs, etc. (I know these aren't new ideas but implementing them within the compile time type system of a widely used language seems pretty novel to me) d) A collection of "facades" to permit one to write one program/algorithm which will efficiently run accross different combinations of OS's and compilers e) A vehicle for promoting C++ to a wider audience and promote quality software practices in general. f) Provide the "definitive" implementation of commonly required components. example shared_ptr. f) ... you're own view here.
answer: yes!
[...]
So I'm more of the view that we let stuff into boost as long at it meets quality standards. Then let users decide.
+1 --Lorenzo
Lorenzo Caminiti wrote:
On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey@rrsd.com> wrote:
question:What is Boost?
a) A collection of libraries to make as many C++ programmers as possible more productive?
That's the usefulness criteria in our review questions.
b) A staging area for libraries which are aimed at being included in the standard library?
That was the reason for Boost in the first place, so definitely!
c) An area for expermenting with and testing new ways of using C++ to exploit novel ideas in software development like functional programming, DSELs, etc. (I know these aren't new ideas but implementing them within the compile time type system of a widely used language seems pretty novel to me)
These lead to so many things, not unlike the benefits from space exploration: pens that write upside down! Seriously, such work has led to lambdas, improved TMP support, etc.
d) A collection of "facades" to permit one to write one program/algorithm which will efficiently run across different combinations of OS's and compilers
These, ultimately, should fit under b).
e) A vehicle for promoting C++ to a wider audience and promote quality software practices in general.
By virtue of Boost's reputation, libraries in Boost gain wide exposure. Therefore, the coding practices exhibited by those libraries tend to become commonplace. That doesn't mean that efforts within Boost should be advanced to make Boost a better vehicle for those things, but rather that, because Boost is such a vehicle, the effects of things done in Boost must be considered.
f) Provide the "definitive" implementation of commonly required components. example shared_ptr.
That, to my mind, fits within b).
f) ... your own view here.
There may be a few additional items to list, but it is definitely not open ended.
answer: yes!
So I'm more of the view that we let stuff into boost as long as it meets quality standards. Then let users decide.
+1
I can go along with that to a point. Anything accepted into Boost must meet the usefulness criteria. If too few find a library useful, it should not be in Boost. That helps to keep Boost manageable. Many burdens are multiplied by the number of libraries in Boost, so keeping that number small is one of many forces to balance when considering whether a library should be accepted. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
answer: yes!
So I'm more of the view that we let stuff into boost as long as it meets quality standards. Then let users decide.
+1
I can go along with that to a point. Anything accepted into Boost must meet the usefulness criteria. If too few find a library useful, it should not be in Boost. That helps to keep Boost manageable. Many burdens are multiplied by the number of libraries in Boost, so keeping that number small is one of many forces to balance when considering whether a library should be accepted.
To me, Boost is aready too big to make for a convenient deployment. I see it as inevitable that Boost evolve it's deployment model along the following lines: a) libraries are modular. That is as an alternative to downloading the whole package one would just download the one's he want's to use (along with the pre-requisites - that's the rub!). b) Boost would be more of a "quality/usefulness" certification process. That is the boost review/etc. would stay the same or perhaps even be re-inforced. c) Libraries would be updated/versioned on their own schedule. This would have the following effects a) boost would be only as big as any user needs. b) the issue of deprecation would take care of itself. Since boost wouldn't be deploying the whole thing, any library which no one used due to obselence, lack of maintainence or whatever reason would just stop being downloaded. c) Boost could continue to grow - which is becoming tougher as it get's bigger. It would be a sad day if we have to reject quality software because we're limited by our capacity to deploy a large package. Of course implementing such an idea would require a lot of changes and effort. But I've seen attempts to evolve at least similar to these ideas (rypll, CMake, use of git). But that's not why I see this as inevitible. I see tese attempts to evolve as a response to the success of boost and the attendant growing pains. Robert Ramey
_____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of vi ruses.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 1 December 2011 14:29, Robert Ramey <ramey@rrsd.com> wrote:
a) libraries are modular. c) Libraries would be updated/versioned on their own schedule.
So how do you solve the versioning problem? If Boost.Thread.90 requires Boost.SmartPtr.76 and Boost.Filesystem.90 requires Boost.Smartptr.77, you've got a usability nightmare on your hands. I don't see any way around Boost libraries having to work together in all baseline releases (which is what we have now). And this is a practical problem, as I have yet to work anywhere that doesn't have this problem when they integrate libraries from more than one source. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
On 1 December 2011 14:29, Robert Ramey <ramey@rrsd.com> wrote:
a) libraries are modular. c) Libraries would be updated/versioned on their own schedule.
So how do you solve the versioning problem?
If Boost.Thread.90 requires Boost.SmartPtr.76 and Boost.Filesystem.90 requires Boost.Smartptr.77, you've got a usability nightmare on your hands. I don't see any way around Boost libraries having to work together in all baseline releases (which is what we have now).
I did consider this some time ago. I proposed something on this list. I forget the details right now but basically it would be along the lines of each library being able to report it's version at compile time and execution time. Libraries which use other libraries would be able to check that their requirements are met by inquiring this API. I believe that something similar - though likely more elaborate is ipmlemented as part of COM on windows to address the "DLL hell" issue. When I proposed this before, the consensus was that such as system wasn't necessary. I didn't really buy this but I other stuff to do so I just dropped it.
And this is a practical problem, as I have yet to work anywhere that doesn't have this problem when they integrate libraries from more than one source.
Hmmm - I have to address this all the time. If I make even a relatively simple Ap it might use the msvc C++ library, some version of the STL library, some version of SQL server and some version of windows. Then there might be some DLLS for special controls or whatever. All of these components have their own versioning. We don't demand that all these be deployed as a monolithic group. If we have to deploy a group of components together, we're really saying that the compoents are coupled together in their implementation which is basically an error. And this has already occured with parts of boost. ASIO, spirit, GIL and who knows what else were deployed separately before becoming part of boost. A requirement to deploy/version them concurrently isn't necessary nor is it convenient. And it's not pratical in the long run as it can't scale. Robert Ramey
On Thu, Nov 24, 2011 at 5:40 AM, Nathan Ridge <zeratul976@hotmail.com> wrote:
Same goes for things like Phoenix and Proto -- Phoenix allows polymorphic lambdas while Proto allows for doing DSEL building in C++.
I would imagine that if/when C++1x gets polymorphic lambdas and maybe expression template building facilities built in then it's worth deprecating those libraries as well.
I don't think Phoenix is an appropriate example here. The contribution of Phoenix to C++ goes far beyond just simulating polymorphic lambdas or providing a terser syntax for some lambdas. Phoenix allows representing pieces of code as data, which can then be traversed/analyzed/transformed. Adding polymorphic lambdas or nicer lambda syntax to C++1x isn't going to deprecate that use case.
My bad. Yes, Phoenix is not just for polymorphic lambdas and yes code as data is a nice feature. Point still stands though if C++1x gets that runtime introspection capability on normal code.
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years.
I would then think that there's nothing stopping them from using the library even if it's not in Boost.
The name "Boost" carries with it a certain standard of excellence, quality of implementation, and ubiquity. As a result, it is often much more feasible to use a library in a project/team/company if it's part of Boost than if it isn't.
Agreed.
Case in point: at my company, we use Boost extensively, but management is very hesitant to introduce a dependency on other libraries, especially if the library "merely" makes coding in general more convenient, rather than providing some domain-specific features or API. I think the situation is similar in many other companies and projects.
For this reason, I think libraries whose purpose is to make general-purpose coding more convenient, rather than some domain-specific use, are especially appropriate for inclusion in Boost.
Unfortunately I don't think this is Boost's problem but rather an organizational problem. Boost serves to be proving grounds for libraries for future inclusion into the standard or as a reference implementation for a proposal to be made part of the standard. It's also a place for libraries that augment and work with the current standard library. My point still stands that in reality there's nothing stopping users from using libraries that are not part of Boost since any library (even Boost) has to be vetted for and evaluated by users in any case.
- Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
I would think though that these transitional libraries would be deprecated as soon as the standard counterparts become ubiquitous.
Do you consider C++03 as having been ubiquitous for the past 7-10 years?
Yes.
If so, Boost has really been bending over backwards to support compilers that don't support all C++03 features.
Yes it does.
And that was to support compilers that did not conform to any standard at all!
Which is unfortunate.
I would expect just as much sympathy and support for compilers which do support a standard (C++03), just not the latest one (C++11), for at least as much time.
This sounds (and if history is the judge, is really) needless and unsustainable in my opinion. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
Hi Michael and thank you for bring my attention back to your original reply on this topic. On Wed, Nov 23, 2011 at 1:04 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Wed, Nov 23, 2011 at 4:27 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
I have been watching the discussions around the reviews for the proposed Boost.Local library. I would like to weigh in on this issue that seems to be important to address from a non-involved perspective (mostly because I haven't sent in a review for Boost.Local nor would I do that even now).
First, I think there's two problems here that we're all trying to solve:
1) C++11 is good but apparently people don't think it's good enough for production yet. There's a temporal dimension to this problem which means it's just a matter of time when compilers support C++11 as the de-facto version of the language that is supported. During this delay though people want to get the features in C++11 approximated in C++03.
2) C++11 doesn't include a feature that some people find may be useful but can be forced onto users (or at least is being tried to make it popular by getting it into Boost) using whatever facilities are available in the language. The categorical dimension here is not tied to time, effort, or anything else but rather the state of the standard.
For solutions that address #1, I would say it depends -- if Boost.Move, Boost.Shared_ptr, Boost.Scoped_ptr, etc. get deprecated when C++11 has been made ubiquitous (which I would believe should be the correct way forward) then yes. Boost.Local unfortunately doesn't belong with the grouping of these libraries precisely because it addresses #2 however "semantically equivalent" local functions are to C++11 lambdas.
For solutions that address #2, I would say probably if it's done in good taste and follows the traditions of Boost in terms of quality of implementation, quality of execution, and utility of the solution. I'd say though that addressing issues that fall under the #2 category should be implemented as compiler extensions instead of hacks using existing current language features. This is to say that although Boost.Concept_check is there as a good proof of concept for Concepts, it by itself stands as something that shows the utility of the library in the tradition of Boost's quality. Same goes for things like Phoenix and Proto -- Phoenix allows polymorphic lambdas while Proto allows for doing DSEL building in C++.
I would imagine that if/when C++1x gets polymorphic lambdas and maybe expression template building facilities built in then it's worth deprecating those libraries as well. Note that neither of these things resort to using macros which are cheap alternatives to people writing it down themselves.
So applying my logic to the discussion on Boost.Local, I see it as doing a not-so-good job of doing #1
Let me understand better your point. Is this because Boost.Local functions cannot be declared within expressions while C++11 lambdas can?
while falling short in #2. If
Again, let me understand your point better. Is this because Boost.Local functions use macros?
however it proves that local functions would be a good addition to the language, I would suggest that the library live outside of Boost, get critical mass, and then be proposed as an extension to the language in the form of a proposal for local functions. Although I don't see how local functions are better than C++11 lambdas that are auto-captured to a local variable, maybe other people would like to use local functions as a different syntax.
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years.
I would then think that there's nothing stopping them from using the library even if it's not in Boost.
- Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
I would think though that these transitional libraries would be deprecated as soon as the standard counterparts become ubiquitous.
Thanks a lot for the clarifications. --Lorenzo
On Fri, Nov 25, 2011 at 7:15 AM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Hi Michael and thank you for bring my attention back to your original reply on this topic.
On Wed, Nov 23, 2011 at 1:04 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
So applying my logic to the discussion on Boost.Local, I see it as doing a not-so-good job of doing #1
Let me understand better your point. Is this because Boost.Local functions cannot be declared within expressions while C++11 lambdas can?
Yes and a lot more. It's because Boost.Local functions aren't real local functions and because it doesn't do anything that C++11 lambdas don't already do.
while falling short in #2. If
Again, let me understand your point better. Is this because Boost.Local functions use macros?
Not just that. It's also because it's trying to approximate something limited as compared to what C++11 already has. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
On Thu, Nov 24, 2011 at 9:53 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Fri, Nov 25, 2011 at 7:15 AM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Hi Michael and thank you for bring my attention back to your original reply on this topic.
On Wed, Nov 23, 2011 at 1:04 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
So applying my logic to the discussion on Boost.Local, I see it as doing a not-so-good job of doing #1
Let me understand better your point. Is this because Boost.Local functions cannot be declared within expressions while C++11 lambdas can?
Yes and a lot more. It's because Boost.Local functions aren't real local functions and because it doesn't do anything that C++11 lambdas don't already do.
while falling short in #2. If
Again, let me understand your point better. Is this because Boost.Local functions use macros?
Not just that. It's also because it's trying to approximate something limited as compared to what C++11 already has.
a) OK, I think I understand. My reply if that if Boost.Local does not approximate well C++11 lambdas because it cannot be define within expressions, it instead approximates well named lambdas which are closures defined at declaration scope: int a; auto localf = [&a](int z) { ... // lots of instructions here }; This C++11 construct is well approximated by the following in C++03: int a; void BOOST_LOCAL_FUNCTION(int z, bind& a) { ... // lots of instructions here } BOOST_LOCAL_FUNCTION_END(localf) b) Other libraries like the recently reviewed Boost.Algorithm and Boost.Atomic implement C++11 features for C++03. I would expect the ability of Boost.Local to implement C++11 named lambdas (i.e., local functions) for C++03 to be just as valuable. Why wouldn't it? Thanks. --Lorenzo
On Fri, Nov 25, 2011 at 9:20 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Thu, Nov 24, 2011 at 9:53 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Not just that. It's also because it's trying to approximate something limited as compared to what C++11 already has.
a) OK, I think I understand. My reply if that if Boost.Local does not approximate well C++11 lambdas because it cannot be define within expressions, it instead approximates well named lambdas which are closures defined at declaration scope:
int a; auto localf = [&a](int z) { ... // lots of instructions here };
This C++11 construct is well approximated by the following in C++03:
int a; void BOOST_LOCAL_FUNCTION(int z, bind& a) { ... // lots of instructions here } BOOST_LOCAL_FUNCTION_END(localf)
Sorry, I don't think you *do* get it. Named lambda functions are an oxymoron. When you give a name to a function, it ceases to be a nameless function. The *utility* of having a function defined inside another function is marginal at best because they're absolutely better outside any other functions in all aspects: readability, maintainability, and functionality. There's *no* practical reason to put a lambda in a named variable when the point of lambda's are so that you can define them in-line. I would even say that it's bad practice to do this at all in C++11 code for a lot of reasons: auto f = [](...) { /* whatever */ }; Some of the reasons are: 1) This messes up ADL and would lead to hard-to-find bugs. 2) You're cluttering the function definition with logic that's supposed to not even be in the same function. 3) It's not a real function that can be referred to via function pointers. Is that clear enough for you?
b) Other libraries like the recently reviewed Boost.Algorithm and Boost.Atomic implement C++11 features for C++03. I would expect the ability of Boost.Local to implement C++11 named lambdas (i.e., local functions) for C++03 to be just as valuable. Why wouldn't it?
There's a difference between a back-port like in the case of Boost.Algorithm, Boost.Atomic, and Boost.Unique_ptr, drop-in (forwardable) approximations like Boost.Move, and a very narrow and marginally useful approximation like what Boost.Local provides. Does that make it clearer? Cheers -- Dean Michael Berris http://goo.gl/CKCJX
On Fri, Nov 25, 2011 at 5:44 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Fri, Nov 25, 2011 at 9:20 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
b) Other libraries like the recently reviewed Boost.Algorithm and Boost.Atomic implement C++11 features for C++03. I would expect the ability of Boost.Local to implement C++11 named lambdas (i.e., local functions) for C++03 to be just as valuable. Why wouldn't it?
There's a difference between a back-port like in the case of Boost.Algorithm, Boost.Atomic, and Boost.Unique_ptr, drop-in (forwardable) approximations like Boost.Move, and a very narrow and marginally useful approximation like what Boost.Local provides. Does that make it clearer?
No, it is not clear to me why you think that there a difference. Can you please list your arguments? For example, why is there a difference with respect to Boost.Algorithm so to be specific. My understanding is that you'd answer: 1) Because Boost.Algorithm all_of is useful but Boost.Local local functions are not. 2) Because Boost.Algorithm all_of uses exactly the same API as C++11 while Boost.Local uses macros. Is my understanding correct? Is there more? Thanks a lot. --Lorenzo
On Fri, Nov 25, 2011 at 10:11 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Fri, Nov 25, 2011 at 5:44 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Fri, Nov 25, 2011 at 9:20 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
b) Other libraries like the recently reviewed Boost.Algorithm and Boost.Atomic implement C++11 features for C++03. I would expect the ability of Boost.Local to implement C++11 named lambdas (i.e., local functions) for C++03 to be just as valuable. Why wouldn't it?
There's a difference between a back-port like in the case of Boost.Algorithm, Boost.Atomic, and Boost.Unique_ptr, drop-in (forwardable) approximations like Boost.Move, and a very narrow and marginally useful approximation like what Boost.Local provides. Does that make it clearer?
No, it is not clear to me why you think that there a difference. Can you please list your arguments?
I hope you're not just being facetious here.
For example, why is there a difference with respect to Boost.Algorithm so to be specific.
Anyway, I shall indulge you.
My understanding is that you'd answer: 1) Because Boost.Algorithm all_of is useful but Boost.Local local functions are not.
Good guess, but no cigar. Boost.Algorithm collects the C++11 algorithms and makes them available to C++03 *as is*. Boost.Local attempts to implement something that C++11 lambda's are perfectly capable of doing and there are already existing libraries that approximate C++11 lambdas in Boost (and do even more). Boost.Local even has an overlap with Boost.Scoped_exit. In general terms: * back-port is exactly what it means, bringing code that's written for a future version of software (usually libraries and/or software packages) to a previous version as an enhancement. * drop-in approximations are solutions that approximate functionality in a future version to a previous version (like Boost.Move for example, in C++03 it performs some tricks that are otherwise unnecessary in C++11, but in C++11 mode can just forward to std::move without losing semantics). Boost.Local is *neither* of these.
2) Because Boost.Algorithm all_of uses exactly the same API as C++11 while Boost.Local uses macros.
No. See above.
Is my understanding correct?
No.
Is there more?
Yes, but I rather not elaborate as I really want to crawl under a rock now. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
on Fri Nov 25 2011, Dean Michael Berris <mikhailberis-AT-gmail.com> wrote:
auto f = [](...) { /* whatever */ };
Some of the reasons are:
1) This messes up ADL and would lead to hard-to-find bugs.
I know it's late to ask, but... how does this "mess up ADL?" -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/16/2011 8:03 PM, Dave Abrahams wrote:
on Fri Nov 25 2011, Dean Michael Berris <mikhailberis-AT-gmail.com> wrote:
auto f = [](...) { /* whatever */ };
Some of the reasons are:
1) This messes up ADL and would lead to hard-to-find bugs.
I know it's late to ask, but... how does this "mess up ADL?"
Guessing at Dean's intent: if f is at namespace scope, it doesn't behave exactly like the equivalent function at namespace scope wrt ADL. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Nov 22, 2011 at 12:27 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
Hello all, I wish I had find this link sooner not because it settle the discussion but because IMO it provides relevant input: http://wiki.apache.org/stdcxx/C++0xCompilerSupport C++11 feature: Lambda expressions and closures N-papers: v0.9: N2550, v1.0: N2658, v1.1: N2927 HP aCC: No support EDG eccp: 4.1(v0.9) GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Sun/ Oracle C++: No support C++ Builder 2009/10: No support Digital Mars C++: No support Clang: No support Missing information are: 1) Which of these compilers is supported by Boost. 2) Which of these compilers can handle Boost.Local (currently tried on GCC, MVSC, and Clang but not others). 3) When these compilers will support lambdas (assuming there's currently a plan for that). Assuming 1) Boost supports the compilers with "no support" and 2) these compilers can handle Boost.Local (e.g., this is the case for Clang) then without Boost.Local there's no alternative to use statement syntax to define closures at local scope on these compilers. HTH, --Lorenzo
Lorenzo Caminiti wrote:
I wish I had find this link sooner not because it settle the discussion but because IMO it provides relevant input: http://wiki.apache.org/stdcxx/C++0xCompilerSupport
C++11 feature: Lambda expressions and closures N-papers: v0.9: N2550, v1.0: N2658, v1.1: N2927 HP aCC: No support EDG eccp: 4.1(v0.9) GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Sun/ Oracle C++: No support C++ Builder 2009/10: No support Digital Mars C++: No support Clang: No support
I'm not sure this list of compilers is relevant. Let's shorten the list to GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Clang: No support because these compilers at least seem to be "actively" maintained. (I based this conclusion on the fact that the cited page links to relevant information for these compilers.) These compilers are also included in the boost test matrix, which further strengthens my impression that these are "relevant" compilers. I remember that IBM XLC++ had non-standard conform name lookup in the past, I wonder whether this is still the case. Even so the resulting error were normally easy to fix, trying to fix these errors for a library like Boost.Proto seems like a daunting task. So XLC++ should only be considered relevant if the non-standard conform name lookup is fixed. And Clang is at least working on lambda support, so it won't be too long before it supports this. But of course, even after Clang supports it, some time will still pass before it is also available for apple developers. Regards, Thomas
On Fri, Nov 25, 2011 at 12:27 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Lorenzo Caminiti wrote:
I wish I had find this link sooner not because it settle the discussion but because IMO it provides relevant input: http://wiki.apache.org/stdcxx/C++0xCompilerSupport
C++11 feature: Lambda expressions and closures N-papers: v0.9: N2550, v1.0: N2658, v1.1: N2927 HP aCC: No support EDG eccp: 4.1(v0.9) GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Sun/ Oracle C++: No support C++ Builder 2009/10: No support Digital Mars C++: No support Clang: No support
I'm not sure this list of compilers is relevant. Let's shorten the list to
GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Clang: No support
because these compilers at least seem to be "actively" maintained. (I based this conclusion on the fact that the cited page links to relevant information for these compilers.) These compilers are also included in the boost test matrix, which further strengthens my impression that these are "relevant" compilers.
Makes sense.
I remember that IBM XLC++ had non-standard conform name lookup in the past, I wonder whether this is still the case. Even so the resulting error were normally easy to fix, trying to fix these errors for a library like Boost.Proto seems like a daunting task. So XLC++ should only be considered relevant if the non-standard conform name lookup is fixed.
Could anyone please check if Boost.Local in its current implementation compiles on IBM XLC++?
And Clang is at least working on lambda support,
Yes, I was able to find this (sorry in advance if it turns out to be not the very latest info): http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gigabytes...
so it won't be too long before it supports this. But of course, even after Clang supports it, some time will still pass before it is also available for apple developers.
I can confirm that Vicente has tried Boost.Local on both Darwin and Clang On Mon, Nov 14, 2011 at 12:49 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
- Did you try to use the library? With what compiler? Did you have any problems?
I have compiled the examples with darwin 4.2.1, clang-2.9,3.0 with and without c++0x enabled.
Thanks, --Lorenzo
On Fri, Nov 25, 2011 at 12:54 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Fri, Nov 25, 2011 at 12:27 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Lorenzo Caminiti wrote:
I wish I had find this link sooner not because it settle the discussion but because IMO it provides relevant input: http://wiki.apache.org/stdcxx/C++0xCompilerSupport
C++11 feature: Lambda expressions and closures N-papers: v0.9: N2550, v1.0: N2658, v1.1: N2927 HP aCC: No support EDG eccp: 4.1(v0.9) GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Sun/ Oracle C++: No support C++ Builder 2009/10: No support Digital Mars C++: No support Clang: No support
I'm not sure this list of compilers is relevant. Let's shorten the list to
GCC: 4.5(v0.9) Intel C++: 11.0(v0.9), 12.0(v1.0) MSVC: 10.0(v1.0), 11.0(v1.1) IBM XLC++: No support Clang: No support
because these compilers at least seem to be "actively" maintained. (I based this conclusion on the fact that the cited page links to relevant information for these compilers.) These compilers are also included in the boost test matrix, which further strengthens my impression that these are "relevant" compilers.
Makes sense.
I remember that IBM XLC++ had non-standard conform name lookup in the past, I wonder whether this is still the case. Even so the resulting error were normally easy to fix, trying to fix these errors for a library like Boost.Proto seems like a daunting task. So XLC++ should only be considered relevant if the non-standard conform name lookup is fixed.
Could anyone please check if Boost.Local in its current implementation compiles on IBM XLC++?
And Clang is at least working on lambda support,
Yes, I was able to find this (sorry in advance if it turns out to be not the very latest info): http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gigabytes...
so it won't be too long before it supports this. But of course, even after Clang supports it, some time will still pass before it is also available for apple developers.
I can confirm that Vicente has tried Boost.Local on both Darwin and Clang
On Mon, Nov 14, 2011 at 12:49 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
- Did you try to use the library? With what compiler? Did you have any problems?
I have compiled the examples with darwin 4.2.1, clang-2.9,3.0 with and without c++0x enabled.
I've also asked the current status of compiler support for C++11 lambdas to the larger community: http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/... http://groups.google.com/group/comp.lang.c++/browse_thread/thread/39857289df... HTH, --Lorenzo
participants (20)
-
Ben Robinson -
Christopher Jefferson -
Daniel James -
Dave Abrahams -
Dean Michael Berris -
Eric Niebler -
Gregory Crosswhite -
Jeffrey Lee Hellrung, Jr. -
Joel de Guzman -
Klaim - Joël Lamotte -
Lorenzo Caminiti -
Marshall Clow -
Mathias Gaunard -
Nathan Ridge -
Nevin Liber -
Robert Ramey -
Sergey Cheban -
Stewart, Robert -
Thomas Klimpel -
Vicente J. Botet Escriba