- Boost - lists.boost.org

bug in signals library? - segmentation fault (only linked) -> exit(11) called
by Oliver.Kowalke＠infineon.com 23 Dec '05

23 Dec '05

Hello, I get an segmentation fault if I try to link against libboost_signals-gcc-1_33_1 or libboost_signals-gcc-mt-1_33_1! The application consist only of an empty main function and the binary is linked against the signals library. I've appended an output (tusc.out) of tusc (trace unix system calls) which indicates, that exit(11) is called and so a core dump created. System: HP/UX 11.11 PA-RISC Compiler: gcc-3.4.4 (with posix thread support) Code: int main( int argc, char* argv[]) { return 0; } Compiled with: if g++ -DHAVE_CONFIG_H -I. -I/eda-home/kowalke/Projects/test/src -I.. -I/opt/boost/include/boost-1_33_1 -O0 -g3 -MT test.o -MD -MP -MF ".deps/test.Tpo" -c -o test.o /eda-home/kowalke/Projects/test/src/test.cpp; then mv -f ".deps/test.Tpo" ".deps/test.Po"; else rm -f ".deps/test.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g3 -o test -L/opt/boost/lib test.o -lboost_signals-gcc-1_33_1 mkdir .libs g++ -O0 -g3 -o test test.o -L/opt/boost/lib -lboost_signals-gcc-1_33_1 <<tusc.out>>

2 1

asio pooled_list/hash_map implementation
by christopher baus 23 Dec '05

23 Dec '05

I've been playing around with ways to remove some of the hits to the global allocator from asio/detail/reactor_op_queue.hpp, and decided to try an alternative approach to pooling. Instead of overriding STL allocators or global new/delete, I decided to implement pooled lists in terms of lists themselves. I take advantage of the fact that list::splice doesn't realloc nodes to move value data between the active and free lists during insert and erase operations. Chris's hash_map stores the value data in a std::list. I made that a template parameter, which allowed me to optionally specify the pooled_list. The implementation is here: http://baus.net/static/hash_map.hpp http://baus.net/static/pooled_list.hpp http://baus.net/static/pooled_hash_map.hpp This doesn't address the bigger problem of the handler allocation, but pre-allocing of the hash_map on *nix makes me a bit happier with the implementation. christopher

2 1

Re: [boost] Typeofand mpl(was Interest in dimension/unit-checking library?)
by Andy Little 23 Dec '05

23 Dec '05

"Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote in message news:... > Hi Arkadiy, > > Its late and I'll have to reply on the rest of your post later. Meanwhile > enclosed is a small sample of the error output, which happens when I comment > out > registration for boost::mpl::math::reduced_rational in my registration Sorry I meant boost::mpl::math::simplified_rational rather than reduced_rational in my last post regards Andy Little

1 0

asio review
by Jody Hagins 22 Dec '05

22 Dec '05

I know it was started at 2 weeks. Any chance on an extension?

2 1

[review] asio review
by Brock Peabody 22 Dec '05

22 Dec '05

What is your evaluation of the design? I think the design is good. Asio has an easy to use, modern interface that doesn't compromise on portability or performance. What is your evaluation of the implementation? I haven't inspected the code but it sounds pretty impressive that it selects the optimal library for your platform while maintaining a consistent interface. What is your evaluation of the documentation? I found the tutorial easy enough to follow, but I haven't actually implemented anything with the library yet so I can't comment much on the reference section. What is your evaluation of the potential usefulness of the library? Highly. Everyone wants a cross-platform networking library for C++. Did you try to use the library? With what compiler? Did you have any problems? I compiled and ran some of the examples in the tutorial under VC 7.1 with no problems. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've been following discussions from other reviews. I read the tutorial and glanced through some of the rest of the documentation. Are you knowledgeable about the problem domain? I've written my own cross platform synchronous networking library. I've written countless client and server applications mostly under windows, all synchronous. I have no experience actually doing asynchronous IO. I vote to accept asio. Christopher has done a great job, thanks a lot! I'm excited to start using asynchronous IO. I've got server applications that will be pushing the limit on the number of threads soon. I will happily throw out all of my own networking code in favor of this library if it is accepted. My one small concern is that asio rewrites part of Boost.Thread. In the last couple of versions boost has become so easy to install and link against that I don't see the benefit of a header only implementation. Brock

1 0

who's using boost page
by Max Khesin 22 Dec '05

22 Dec '05

Just a style note: the "who's using" page is not (yet ;) big enough to justify a page with just categories (open source, shrink-wrap, etc). If the categorization is really desired it could be done with anchors within a page. Right now it just adds an extra click, and fragments the list that is more impressive as a single entity. 2c. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Interest in a function object to sort strings more naturally?
by Andy Tompkins 22 Dec '05

22 Dec '05

I have written a function object to sort string alpha-numerically. If a string contains a number, that part is converted to an int and compared as ints. Thus "2" comes before "10". For example the list {a1, a10, a11, a2} would be sorted as {a1, a2, a10, a11} Example use code: { vector<string> my_list; //populate list sort(my_list.begin(), my_list.end(), lt_alphanum<char>()); } The class lt_alphanum splits the strings into sections containing digits, and non-digits. It then compares successive sections such that if two sections both contain digits, they are converted to ints and compared. Otherwise the sections are compared normally. I hope I am being clear. Andy Tompkins

1 0

[MPL.Math] compile-time double macro and printing
by Chris Weed 22 Dec '05

22 Dec '05

Hi, I am trying to simply print a compile-time double using gcc 4.0.0 on Sun. The following prints out : 1.9036e+185 #include <boost/metamath/double.hpp> #include <boost/metamath/double_macros.hpp> #include <iostream> int main() { typedef BOOST_DOUBLE(3.3) D; D d; std::cout << (double)d << std::endl; return 0; } Am I doing something wrong? Chris

4 5

Serious fix needed for the new Boost.Test
by Daryle Walker 22 Dec '05

22 Dec '05

[Maybe I just messed up my XCode #include directories and/or order, or maybe my CVS is fried.... (After writing the post--) please ignore the first sentence and excuse any anger instead.] I've been trying out the auto-test items in Boost.Test, re-doing them when the recent changes were uploaded to CVS. I decided to template-ize a test case I had, going from BOOST_AUTO_TEST_CASE to BOOST_AUTO_TEST_CASE_TEMPLATE with a MPL list of the types I wanted. The complier spit out 10 errors. (I think that's a lot, but for some posters here that's a little.) After using the preprocessor to copy & paste the expansion of BOOST_AUTO_TEST_CASE_TEMPLATE directly into my test file, I narrowed down the errors to two actual problems: 1. The compiler never heard of boost::type 2. And it never heard of boost::unit_test::ut_detail:: template_test_case_gen These can be found in the <boost/type.hpp> (after 10 minutes of searching) and <boost/test/test_case_template.hpp> (after 30 minutes of searching) headers, respectively. Directly #including them in my test file got my testing to work. The simple solution is to make sure to _directly_ include the headers for the items you need to compile.... [Does some checking of the auto-test examples.] The example for BOOST_AUTO_TEST_CASE_TEMPLATE shows that <boost/test/test_case_template.hpp> needs to be manually #included. This is similar to me having to #include <boost/test/floating_point_comparison.hpp> in order to make BOOST_CHECK_CLOSE work. (Is it just me, or does anyone else find the need to manually add #includes to avoid "missing-item" compiler errors within the main testing headers _extremely_ annoying?! I figure that it saves compiling time if the specialized macro is never used, and therefore the auxiliary types aren't needed, but is it worth it?) Well, it seems that I can only complain about the main problem only for <boost/type.hpp>. It seems like the author counted on that header being indirectly #included, and that hope evaporated whenever some other author purged that header (and boost::type) from his/her library. So please directly #include <boost/type.hpp> in <boost/test/unit_test_suite.hpp>. (And if possible, end the "batteries not #included" scenario for the other testing macros & headers.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

asio review
by Dirk Moermans 22 Dec '05

22 Dec '05

Hi, I vote to accept asio into boost. It will still require a lot of work and is by no means finished. My impression is that most issues can be solved incrementally though. The supported features are sufficient (number of platforms + IPV4) to prove that the concepts will work. The documentation is insufficient to understand the interface. I had to read the implementation and the examples. I have spent 8 hours on the review (reading documentation and reading code, I have not written any code using asio). I have experience with ACE, MFC and socket.h (mostly synchronous though, so asio has been an eye-opener for me). This is my first boost-review. -- design: I like the acceptor-connector pattern as used in ACE. It seems that you do use an acceptor class, but did not implement connector classes. It would be nice to have separate classes for connection-establishment and for connection-handling, for both client- and server-side (separation of concerns). I dislike the use of the "services pattern". It might make sense to put the service classes in the details section but they do not belong in the public interface. Such a design would not be appropriate for standardization. I wonder if you can reach the same goals by using concept-checks and some socket_traits classes instead of duplicating every interface. I did read the description in the design section and I am still not convinced that they are a good solution for the stated problems. I think the following code-snippet in the tutorial could be written more elegantly, through an interface change of the deadline_timer: { boost::asio::deadline_timer t; ... t.expires_at(t.expires_at() + boost::posix_time::seconds(1)); } by giving direct access to the time member. t.expiry_date()+=boost::posix_time::seconds(1); For more complex cases or error-checking, some proxy classes could be used. You might want to add swap member-functions implemented in e.g. the address class. You could overload more functions that take a const std::string& parameter with a const char* parameter (e.g. the host constructor). You seem to return a std::string in the some member functions of host and address classes, where you could return a const std::string&. e.g. in host.hpp std::string host::name() const -- implementation Why do you catch exceptions by reference instead of const reference :-) ? Why do you roll out your own threads-implementation and don't rely on boost.threads . It would improve consistency among boost-libraries? The basic demuxer-work class is copy-constructable so that it may be used as a data member in a handler class. It is not assignable. I have never seen this idiom in a correctly designed class, so it would be nice to elaborate a bit on it. Documentation: I would like to see a clear distinction between what is considered a public and private class. A split between basic and advanced topics would ease understanding as well. it would improve readability if you would omit the boost::asio namespace throughout the tutorial. Everybody knows the library-name when reading the tutorial. adding a line "use namespace::boost::asio" in the beginning is sufficient. I did not have time to look in detail into the scatter-gather mechanism, nor the demuxer classes, nor the ssl implementation ... so I am only scratching the surface here. I am impressed by the library and I would use it. Dirk

4 4