- Boost - lists.boost.org

[lexical_cast] Error casting void* to std::string
by GMan 24 Nov '11

24 Nov '11

I did a search on the mailing list and found nothing, but apologies if I missed it. This bug seems to be new to 1.48. Compiling the following code in MSVC2010: #include <boost/lexical_cast.hpp> #include <string> int main() { void* ptr = 0; boost::lexical_cast<std::string>(ptr); } Results in an error, pointing to line 1738 in boost\lexical_cast.hpp, stating: 'removed_ptr_t': illegal sizeof operand. ('removed_ptr_t' is, however, defined a few lines above.) I see nothing wrong with the code from a C++ point-of-view, so I'm guessing this is another MSVC bug. Is this known? I don't see an immediate permanent workaround. A client-side workaround exists by introducing this small class: struct print_ptr { explicit print_ptr(void* ptr) : mPtr(ptr) {} friend std::ostream& operator<<(std::ostream& sink, print_ptr printPtr) { return sink << printPtr.mPtr; } private: void* mPtr; }; And using: boost::lexical_cast<std::string>(print_ptr(ptr)); -- GMan, Nick Gorski

3 3

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

From: Gregory Crosswhite > Perhaps, but could you give us some examples of what you mean to provide a better sense of what you are thinking? Thanks! :-) If a library hasn't had a maintainer for a certain period then it gets removed. If I'm using a library that is close to being removed I'd either have to do something to help maintain it or decide to use another library. I'm OK with it becoming easier to add libraries if it also becomes easier to remove them. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 2

Policy when duplicate code detected
by Ioannis Papadopoulos 24 Nov '11

24 Nov '11

Hi, I was wondering what is the policy when someone finds code that is clearly duplicated or implements the same thing with just different interface? What is the best way to report it? Thanks

2 1

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

Lorenzo Caminiti: >On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> >> 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 I guess, but is there any way to remove libraries from Boost? I think it almost needs pruning more than it needs more libs. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] [Boost.Local] Review
by Brent Spillner 24 Nov '11

24 Nov '11

On 23 Nov 2011 10:24:53 Leo Goodstadt wrote: >For "acknowledgment" / "acknowledgement": both spellings started out in the >16th c. but the first form historically was found more in the US. Citations >from the 19th and 20th c show that both variants are found on both sides >of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) >though the long form seems to predominate in the 20c only in U.K. >newspapers. I too appreciate the clarification--- guess I didn't understand this quite as well as I thought. In the US, "acknowledgement" does seem to correlate frequently with a casual attitude toward spelling, but it looks like I need to broaden my horizons a bit.

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 23 Nov '11

23 Nov '11

> > Ok, I am not sure if there are no better ways to write it in each variant, > > and I may be biased. I also didn't try to compile the examples. But it > > should give the potential users an overview of options they have. > > Yep. This highlights the verbosity well: > for_each( vec.begin(), vec.end(), if_(empty(_1)) [_1 = "n/a"] ); > vs: > BOOST_CLOSURE_PARAMS( std::string & n ) { > if( n.empty() ) n = "n/a"; > }BOOST_CLOSURE_NAME(replace_empties); > for_each( vec.begin(), vec.end(), replace_empties ); Honestly, my goal was to show an example where Phoenix has limitations and Local could be considered an attractive alternative. Obviously my example failed to do that. I wanted to see how you can call member functions. I can see Phoenix has nice support for container-like operations. But how about changing the rules a bit, and calling an arbitrary member function? for_each( vec.begin(), vec.end(), if_(bind(&SuperLib::SuperString::IsVulgar, arg1)) [arg1 = "unknown" ] ); vs. BOOST_CLOSURE_PARAMS( SuperLib::SuperString & n ) { if( n.isVulgar() ) n = "unknown"; }BOOST_CLOSURE_NAME(replace_vulgar); for_each( vec.begin(), vec.end(), replace_vulgar ); I realize that one can tweak examples to show whatever one wants. But member access does not appear too unusual. This really happened to me that I used a very complicated bind statement where I had to bind some variables and leave some free, pass some by reference, some by value. I thought "it was the right way because this is Boost way", until I realized no-one else in the team knows what that is suppose to mean. Regards, &rzej

2 1

[parameter] increase BOOST_PARAMETER_MAX_ARITY
by Tim Blechmann 23 Nov '11

23 Nov '11

hi, i've been using boost.parameter extensively with boost.heap and now came to a point, that i need to raise BOOST_PARAMETER_MAX_ARITY to at least 7 in order to be able to compile it. i am planning to merge boost.heap into trunk in the next few days, so i wonder, would it be reasonable to increase the default of this value to e.g. 8 (patch attached)? currently, boost.heap defines BOOST_PARAMETER_MAX_ARITY before including boost/parameter.hpp, but this will break, if boost/parameter.hpp is included before the boost.heap headers. it would be great, if the default would be high enough to compile all boost libraries, or could this cause any issues? thanks, tim

1 0

[local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)
by Lorenzo Caminiti 23 Nov '11

23 Nov '11

Note: I've changed the title of the email because this part of the discussion is not related to Boost for C++11 or C++03. On Wed, Nov 23, 2011 at 6:21 AM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > 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++. I see, yes that is what you wrote for example here "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". I miss read your email, I didn't understand that it was pushing the limits of compilers to give library programmers more control over error detection/reporting. Thanks for the clarification. > All the rest of your reply is irrelevant. Well, no. The following part of my reply is now even more relevant because it repeats that Local is not just about (2) better error messages (your point above about pushing the limit) but also about (1) usual statement syntax for the function body (which every programmer in your team will understand at once). >> 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_loc… --Lorenzo

1 0

Re: [boost] [Boost.Local] Review
by Leo Goodstadt 23 Nov '11

23 Nov '11

> John Bytheway <jbytheway+boost <at> gmail.com> writes: > > > > On 19/11/11 20:39, Brent Spillner wrote: > > > On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: > > >>> The title is spelt wrong (should be Acknowledgements) > > > Actually, "Acknowledgments" is the traditionally correct spelling. > > > There are some dictionaries that accept "Acknowledgement," but this > > > reads as faddish and less literate. A similar word is "judgment"--- > > > both are frequently misspelled even by native speakers. > > BTW, I grew up spelling both as "acknowledgement" and "judgement". Online > sources seem to indicate that in Britain those spellings are the norm while in > the US the 'e' after 'g' is usually dropped. But I was born and raised here in > the US so what gives? Given that my first name is "Geoff" (English spelling) and > not "Jeff" (American spelling) the confusion is readily apparent? This is where the Oxford English Dictionary with all its historical citations comes in handy. For "acknowledgment" / "acknowledgement": both spellings started out in the 16th c. but the first form historically was found more in the US. Citations from the 19th and 20th c show that both variants are found on both sides of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) though the long form seems to predominate in the 20c only in U.K. newspapers. For "judgement" / "judgment": judgement seems slightly more consistent etymologically (with the Old French/Norman "iugement"?). This may be why it seems to be preferred by the OED. However, both forms are equally old, and >80% of the modern citations have the *short* form not the long form, on both sides of the Atlantic. Conclusion: Spell these words however you want! Hope that clears thing up. Leo

3 2

[local] Review
by John Bytheway 23 Nov '11

23 Nov '11

To begin with, my overall opinion: I say yes, Boost.Local should be accepted. > - What is your evaluation of the design? The design is clearly well thought-out. I admire Lorenzo's dedication to discussing his design decisions as thoroughly as possible on the mailing list. I've watched the development of the library with interest, and have been glad of the opportunity to comment along the way. On one specific pleasant surprise: thank you for providing the inline feature to offer your users the chance to choose their optimization trade-offs for themselves, and I'm glad you found a faster alternative to the virtual function trick. However, I still have a few concerns: I question the choice to bind const variables by const value by default, with (as far as I can see) no means to bind them by non-const value. This runs contrary to my instincts in regard to functions in C++ more generally (although I see C++11 lambdas have similar behaviour...). It's not a serious problem, but I would have chosen differently. On binding this: I vote that this_ is a better name than _this. The name is not a placeholder in the sense the term is used in libraries using the leading underscore convention for placeholders. Also, how do your various choices of syntax behave in the context of nested local functions? Consider: void BOOST_LOCAL_FUNCTION_PARAMS(bind this) { void BOOST_LOCAL_FUNCTION_PARAMS(bind this_) { this_->f(); } BOOST_LOCAL_FUNCTION_NAME(g) } BOOST_LOCAL_FUNCTION_NAME(h) If you change the syntax (as I think you were proposing) so that "this_" appears in the first line here in place of "this", then how would the second line behave? I would want it to bind the this pointer for the outer object, not the inner instance of the class that Boost.Local defines for me. You discuss exception specifications for the various objects that can be defined. If this includes noexcept in C++11 (which I imagine it does) then you should mention that. The ability to write noexcept local blocks (which can easily be made to work in C++03 too) might be another motivating feature for local blocks. Furthermore, you should seriously consider whether BOOST_LOCAL_EXIT's function should be declared noexcept by default where possible, since it is in many ways like a destructor. How feasible would it be to allow overload to be used without declaring all the function types. So, your example: boost::local::function::overload< void (const std::string&) , void (const double&) // Overload 1st param type. , void (const double&, const char*) // Overload giving default param. , int (int, int) // Overload giving 2 params (from function pointer). > print(print_string, print_double, print_double, print_add); might be written instead: auto print = make_overload(print_string, print_double, print_double, print_add); (with suitable use of BOOST_AUTO for C++03). I guess this only works if all the functors passed are monomorphic and expose (or could be made to expose) their argument types, but that covers function pointers, boost::function objects, and Boost.Local functions, which is a fairly wide applicability. Writing the above inspires me to ask: Do Boost.Local functions expose their argument types and return types at compile time? If there is a widely accepted way for monomorphic functors to do so, then they should. If there is no such widely accepted way, then one should be created, but that's probably not a job for you right now :). In a similar vein, as I was pondering potential uses of the overload feature, I wondered whether it could be used to write a visitor for Boost.Variant. I suspect that it could not, because such a visitor must declare its return type in a manner tat the overload object will not. It would be nice if that could be made to work. Can you think of a good way? > - What is your evaluation of the implementation? I have not looked at the implementation, but I have followed the discussions and examined some earlier versions of it. Any problems I noted before have, I think, as far as reasonable, been resolved. However, I would like to ask: on the overloading features: It looks like boost::local::function::overload could be written with variadic templates where available and thereby avoid the maximum arities in the configuration macros (and be much simpler and faster to compile). Have you done so? > - What is your evaluation of the documentation? The documentation is very good. Allow me to praise in particular the detailed rationales. A few niggles: * General You have various examples which write to stdout. I realise it's fairly clear, but it might be nice to drive the point home by explicitly showing what the expected output of these programs is. Alternatively, use asserts instead of writing to stdout. * Introduction "the object this can be bound (eventually by constant value" - I don't understand "eventually". * Tutorial The code "if (size && nums) delete[] nums;" perpetuates the myth that one should not delete NULL pointers. Please don't do that. Go ahead and delete[] nums even if it's NULL. "The maximum number of parameters that can be passed to a local function (excluding eventual bound variables)" - I don't understand "eventual". You have the "Important" warning about registering types with Boost.Typeof. I presume this applies only to compilers without typeof support. If so you should probably make this a little more clear. * Advanced Topics Does the existence of the recursive "keyword" mean that a local function cannot be named recursive? If so, you should mention that in passing. "Compilers have not been observed to be able to inline recursive local function calls (not even when the recursive local function is also declared inlined)." - do you mean "not only when"? "C++03 local classes cannot be templates." - this is also true in C++11, right? * Macro BOOST_LOCAL_FUNCTION_NAME "The local function name can be prefixed by the "keyword" inline to declare the local function inlined or by the "keyword" recursive to declare the local function recursive" - can both "keywords" be used? This wording suggests to me that they cannot. If they can, then I suggest changing "or" to "and/or". If not, this should be made clearer. * Macro BOOST_IDENTITY_TYPE I don't understand the "Warning" at the bottom; can you expand? * Macro BOOST_IDENTITY_VALUE The implementation provided on this page doesn't look like it could possibly work. Surely the type T cannot be deduced in a call to identity_value without template arguments? * Examples Should a chunk of the variadic macro version of the Emulating D's Scope Guards" example be commented out? Surely not... * Appendix: Alternatives In the benchmarking note, you say "For all tested compilers, this function pointer prevents the compiler optimization algorithms from inlining the local function calls.". You might want to mention that it is in theory possible for the compiler to inline it, and some other compilers or future versions may do so. (Or you may not, if you think it sounds too weasely or hypothetical) I don't see any of the benchmarking images. Should I? I'm experiencing some very odd symptoms from my graphics card since I first tried to view them, so it may well be a problem at my end. * Release Notes Why is there a "TODO" at the bottom? * Acknowledgments The title is spelt wrong (should be Acknowledgements) Thanks for the thanks :). > - What is your evaluation of the potential usefulness of the > library? Personally, my C++ development has mostly moved to C++11, and I do not expect to have reason to want this functionality, settling for lambdas instead. However, I might yet be in a situation where I am forced to use C++03, and I'm sure many others will be in just that situation for a while yet. In that context, I think this library has significant potential usefulness. Certainly there have been times when I have wanted something like it. Much as I admire Phoenix, I think there will always be circumstances where Boost.Local will be an easier, more useful and more readable alternative. As part of your struggle to motivate the utility of const binding in local blocks, you might want to mention in the documentation the possibility of using it to assure the behaviour of code received in macro parameters as (I imagine) you are doing in Boost.Contract. > - Did you try to use the library? With what compiler? Did you have > any problems? I did not try to use this version, but I have experimented briefly with previous versions, with gcc, clang, and icc (IIRC). I had no problems serious enough that I recall them. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I read the documentation with moderate care. Also, I have been following the development on the list over recent months. > - Are you knowledgeable about the problem domain? I have faced problems that this library would have solved neatly, and I discussed some implementation details with Lorenzo at times. > Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then > some) as Boost.ScopeExit. Does this duplication of functionality > need to be dealt with, and if so, how? Since I think the Boost.Local version is strictly superior to the Boost.ScopeExit version, I would suggest that the ScopeExit version be deprecated (but not removed, unless it is proving a significant maintenance burden). On the other hand, ScopeExit is a good name for that functionality, and so it is well worth seriously considering upgrading that library and not including the functionality in this new place. Should that be possible to achieve smoothly, it might be a better choice. > - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. Indeed it sounds reasonable to put it there. If so, it should be implemented with due regard for the possibilities of C++11 features (variadic macros, perfect forwarding) as mentioned above. > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. This seems reasonable. > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. I am struggling to see any situation where BOOST_IDENTITY_VALUE is necessary. Can you provide one? When will simply wrapping the expression in parentheses not suffice? Is it because you might be in a preprocessing context that requires an alphanumeric initial character? That's all for my review. Thanks to Lorenzo, Jeffrey, Gregory, and good luck! John Bytheway

2 2