- Boost - lists.boost.org

Re: [boost] [asio].[hp-ux].[1_33_1] Build related issue
by Gaurav.Jain＠iflexsolutions.com 08 Feb '07

08 Feb '07

Christopher Kohlhoff <chris <at> kohlhoff.com> writes: > > If possible, can you retry with the boost.asio 0.3.8 release candidate: > > http://sourceforge.net/project/showfiles.php?group_id=122478 > or against the CVS HEAD version of boost. It won't work for HP-UX yet, > but I'd like to make the changes against the latest source code. If the > changes are trivial (meaning changes to #ifdefs only) then I'd be happy > to add support for HP-UX in 0.3.8 (but only with _XOPEN_SOURCE_EXTENDED > undefined). > > Cheers, > Chris Hi Chris, I am yet to try boost.asio 0.3.8. But I have tried to build the daytime_client.cpp on AIX 5.3 with xlC 8.00 and Solaris 10 with Studio 11 without any success. Following errors relating to msghdr crop up often on Solaris: /boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 170: Err or: msg_control is not a member of msghdr. "/boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 171: Err or: msg_controllen is not a member of msghdr. "/boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 172: Err or: msg_flags is not a member of msghdr. "/boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 197: Err or: msg_control is not a member of msghdr. "/boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 198: Err or: msg_controllen is not a member of msghdr. " /boost/1_33_1/64/boost/asio/detail/socket_ops.hpp", line 199: Err or: msg_flags is not a member of msghdr. Errors on AIX 5.3: "/home/gauravj/1_33_1/include/boost/asio/error.hpp", line 292.21: 1540-1260 (S) An obj ect of type "std::basic_string<char,std::char_traits<char>,std::allocator<char> >" can not be constructed from an rvalue of type "int". "/home/gauravj/1_33_1/include/boost/asio/detail/socket_ops.hpp", line 600.61: 1540-025 6 (S) A parameter of type "hostent_data *" cannot be initialized with an expression of type "char *". "/home/gauravj/1_33_1/include/boost/asio/detail/socket_ops.hpp", line 600.61: 1540-120 5 (I) The error occurred while converting to parameter 5 of "gethostbyaddr_r(const cha r *, size_t, int, hostent *, hostent_data *)". "/home/gauravj/1_33_1/include/boost/asio/detail/socket_ops.hpp", line 655.49: 1540-025 6 (S) A parameter of type "hostent_data *" cannot be initialized with an expression of type "char *". "/home/gauravj/1_33_1/include/boost/asio/detail/socket_ops.hpp", line 655.49: 1540-120 5 (I) The error occurred while converting to parameter 3 of "gethostbyname_r(const cha r *, hostent *, hostent_data *)". Regards, Gaurav Jain

1 0

[Boost-bugs] [ boost-Patches-1652860 ] Unused variable in format date parser
by SourceForge.net 08 Feb '07

08 Feb '07

Patches item #1652860, was opened at 2007-02-05 17:52 Message generated for change (Comment added) made by alexis_wilke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1652860&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexis Wilke (alexis_wilke) Assigned to: Jeff Garland (az_sw_dude) Summary: Unused variable in format date parser Initial Comment: May sound silly, but an unused variable could represent a bug. Thus, Coverity found it and signaled it. It would be nice to have it removed to avoid that error in the future. The variable seems to be a left over from other parsing functions which do make use of it. ---------------------------------------------------------------------- >Comment By: Alexis Wilke (alexis_wilke) Date: 2007-02-07 21:53 Message: Logged In: YES user_id=554061 Originator: YES Hi guys, I also noticed that by removing the code I removed, the current_char variable is actually unused. I uploaded a newer patch with all the fixes. Alexis Wilke File Added: format_date_parser.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1652860&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

asio failures on Borland compiler
by AlisdairM 08 Feb '07

08 Feb '07

I am only set up for testing with Borland compilers at the moment, and the test results aren't visible at the moment, but ... I am looking into two test cases, buffer.cpp and buffer_select.cpp. Both fail for the same reason - an attempt to instantiate array< const char, 1024 >. That looks like a genuine error to me, array does not support const PODs, instead you must declare a const array. However, I have not tracked down the source of this instantiation yet, so it might be a bad type deduction by the compiler as well. Any hints on where to look more closely appreciated. -- AlisdairM

2 5

[fusion] doc error
by Steven Watanabe 07 Feb '07

07 Feb '07

AMDG The documentation of find says template< typename Sequence, typename T > /unspecified/ find(Sequence const& seq); This should be template< typename T, typename Sequence > /unspecified/ find(Sequence const& seq); In Christ, Steven Watanabe

2 1

[fusion] Polymorphic Function Object doc error
by Steven Watanabe 07 Feb '07

07 Feb '07

AMDG The description of Polymorphic Function Object says that it is a refinement of MPL Metafunction Class. In Christ, Steven Watanabe

2 1

[Review] accumulators
by Bernhard Mäder 07 Feb '07

07 Feb '07

Hello all Hope I'm not too late with a small review of the accumulators library: • What is your evaluation of the design? I very much like the user interface of the library, it's pretty clean and concise; writing something like accumulator_set<double, stats<tag::median(with_p_square_quantile) > > acc; is as expressive as it gets. This is just cool. On the other side of the library, when defining new features, things are a bit more complicated. I experienced some ugly compile-time troubles when trying to implement a group of features that depended on each other. Writing that code took considerable more time than writing the same functionality without the framework. I'm quite willing to take this effort, though, for all the benefits of the accumulators framework. Then, I can't really get warm with the automatic feature resolution. On the one hand, it's a great feature for reducing accumulator set definition code. On the other hand, the programmer has to know which features get pulled in anyway (you'll need to include those header files, right?). Furthermore, it seems a bit dangerous to have such automatisms in a field, where you should always know what you're doing anyway (which is again exemplified by the discussion of the various implementations of the mean and variance features on this list). Then there is BOOST_ACCUMULATORS_MAX_FEATURES, which has to take into account even those features that are pulled in automatically. This is a bit counter intuitive and caused some troubles on my side. I'd wish that accumulator_set provided an operator<< to print it to console or files. We're often using accumulator sets from an interactive python console, which would further benefit from a pretty-printed output. Equally, they should be made serializable. The formerly discussed combine() feature could also come in very handy for some of our applications. Overall, I think the library's complexity is as high as I'm willing to go for every day's business. It's really nothing for C++ beginners to start with, as it requires some intermediate level "boost" thinking. • What is your evaluation of the implementation? The framework code is inspiring, as most of Eric's work. The stats are very well separated and pretty easy to read. • What is your evaluation of the documentation? A bit short at times. Some tools lack detailed description (depends_on, feature_of etc.), the external<> mechanics are not clearly described. The overall structure of the user's guide is very good, though. • What is your evaluation of the potential usefulness of the library? Well, we're already using it in production code, so I guess it's very real. There are many other application fields where I could imagine using it (signal processing, imaging, embedded systems with limited memory etc.) • Did you try to use the library? With what compiler? Did you have any problems? We're using the library on debian sarge with GCC3.4. Apart for some long and obscure compiler outputs on errors (and that's hardly boost accumulator's fault), all went fine. • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've been using the library as end-user for quite some time now. I did not study all of the source code nor all of the design decisions, but come across many aspects of the library during normal usage. • Are you knowledgeable about the problem domain? I do know our requirements for statistics on current project, and see where they cause problems, But I'm not really a statistics expert. • Do you think the library should be accepted as a Boost library? Of course, it's a great enhancement to boost. Bernhard

2 1

[promotion traits]
by John Fletcher 07 Feb '07

07 Feb '07

What is the status of the promotion traits library as I would like to evaluate it? I have found it as conditionally accepted (April 12 2006) but I cannot find it in the CVS regressions. John Fletcher

2 3

Re: [boost] formal review request : mcs::units
by Matthias Schabel 07 Feb '07

07 Feb '07

> - I had to modify <boost/units/system/si/base.hpp> to include > <boost/units/io.hpp>, otherwise the compiler claimed syntax errors for > all of the specializations of the unit_info class. Good point; I'll fix this. > - Compile times even for a relatively small sample were rather large, > but this is understandable. Yeah, compile time is a bear. On the other hand, I haven't gone through the MPL code with a fine-toothed comb yet, so it might be possible to make some improvements there. In any case, for most projects, you would just throw the quantities you want into a precompiled header file, so it should really only be a one-time cost... > - unit_info specializations for the CGS system typedef'd base_type as > SI::system, not CGS::system. Is this a bug? This typedef is also > omitted in the docs, so I'm not even sure it's necessary. The quantity conversion code has seen more change than anything else since v0.5.6 - base_type is no longer necessary as I no longer assume that conversions between two unit systems have to be mediated by a base system. Instead, as you can see in <boost/units/systems/si/convert_si_to_cgs.hpp>, you simply provide a template specialization for the base_unit_converter class for each fundamental unit. This marginally increases the typing involved in implementing unit system conversions, but significantly increases the flexibility... I have removed the unnecessary base_type declarations for the next version. > So far my sample program makes two new units, nautical miles and feet. > Nautical miles resides in SIext::system, feet resides in > imperial::system. It then defines a radar struct that stores a range > in nautical miles, and a ceiling in feet, as well as a location in UTM > coordinates as meters. There is one function in_range that takes in a > UTM coordinate and says whether or not it's in range of the given > radar system. Cool - this sounds like a much more interesting application than most of the largely SI stuff that I use it for... > One issue that using feet brought up was how to correctly specialize > the unit_info struct for the unit name string when the name changes in > plural form. Could you provide a plural() function that does nothing > but forward to name() if it's not over-ridden? e.g. > > template <> > struct unit_info<imperial::system, length_tag> > { > typedef imperial::system base_type; > static string name() { return "foot"; } > static string plural() { return "feet"; } > static string symbol() { return "ft"; } > }; I guess it would not be a problem in principle to do this. Since the current IO doesn't use the full name anyway, you could just add plural() and have it work. The only downside I can see to adding this to the library (assuming I can figure out how to get an ostream manipulator to enable the choice of full unit names or abbreviations) is that operator<< would have to compare value() against Y(1). Another potential issue is this: What should you call 1 lb. ft.? I'd say one foot pound. How about 2 lb. ft? I'd say two foot pounds. But it could equally reasonably be called two pound feet - it's just a convention. With more involved composite units, these issues become progressively messier, which is one of the reasons why I've tried as much as possible to avoid the morass of IO... > minor nit. Just in implementing this small program I was warned by > the compiler of comparing feet to meters multiple times (comparing > altitudes). I will try to clean up the code and send it to you if you > are interested. I would also be interested if I used your library's > facilities correctly. I'd be very interested to see what you've done with it and to get your overall impression on the documentation and ease of use. Thanks, Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

3 3

Vault suggestion
by Matthias Schabel 07 Feb '07

07 Feb '07

Perhaps this already exists and I just haven't found it; if not, I would like to propose that a new area in the Boost Vault be set up for libraries that have been submitted for formal review. I think this would make it significantly easier to find libraries that will be coming up for review and give them a spin. Just a thought - Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

1 0

Re: [boost] Review of the Accumulators Library
by Tom Brinkman 07 Feb '07

07 Feb '07

>> The design is complex, but not needlessly so. Take the "pass an array to >> a function" design, and think about how you might answer the following >> questions: >> - What if you wanted the function to calculate 5 different statistics, >> specified by you, and you want to call the function once, not 5 times. >> - What if some of those statistics shared some intermediate partial >> results? You would want the function to only calculate them once, right? Yes, I see your point. Maybe you could show and compare the two styles and where each is appropriate in the "getting started" portion of the documentation. John Maddock's statistic's library, which is also in the "review queue" presumably will have some overlap with the "accumulators" statistics library. Do you see this as an issue that would need to be addressed. How familiar are you with John's library? I wonder what the result would be if two of boost's best statisticians/mathmaticians got together on a design (one can only dream). I'm also interested your "data-series" library. I download it a few weeks ago, but it had some dependencies on libraries not currently in the boost distribution and I was unable to compile it. I did quickly read the documentation however and it looks to be built upon some of the same concepts of "accumulators" library. I suspect that the idea behind the two libraries (accumulators and data-series) evolved together, given their similar characteristics of how they handle intermediate values. (5 day-moving average of a 10-day moving average kind-of stuff). I have a background in data-series analysis and I'll make an effort to contribute in a more meaningful way when that one comes up for review.

3 2