December 2008 - Boost - lists.preview.boost.org

[test] Broken with VC7.1?
by John Maddock 07 Jan '09

07 Jan '09

All the math lib tests are now failing with VC7.1 due to an unresolved external from Boost.Test: http://tinyurl.com/9s9s8e Any fixes? Cheers, John.

2 2

Re: [boost] [variant]compile-time-checked boost::get<T>?
by Arno Schödl 06 Jan '09

06 Jan '09

Hello, would anyone object to changing the semantics of boost::get to do the compile time check, rather than introducing a boost::checked_get? I think changing the semantics is o.k., at least if the first version does not allow casts. If existing code does not compile, it can be fixed by a) replacing the boost::get with a NULL constant or a throw statement, b) or, if the code is generic (and I doubt there is such code), with a compile-time check, and for the case of a type not contained in the variant, using a). I think changing the semantics may reveal more unknown bugs than unnecessarily break code. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

2 1

Re: [boost] Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 06 Jan '09

06 Jan '09

>> Are we reviewing both libraries at once? That is my understanding. However, at this point, until persuaded otherwise, I'm inclined to suggest to both authors that they should find a way to work together and issue a joint release. I've looked at both libraries and the differences are subtle. Maybe we just need to persuade them that it would not diminish their work in any way if they were to submit a joint release. As both submissions are of high quality, I would not want to discourage either author. It would also seem to me that the logging library proposals have the same problem. It would be my hope that we could get the authors of the various logging library proposals to work together and issue a joint release as well. One could dream.

3 3

boost.org: Minor nitpick
by dhruva 05 Jan '09

05 Jan '09

Hi, The following link is supposed to list the header-only packages first (more intuitive) but lists the auto-link packages first. http://www.boost.org/doc/libs/1_37_0?sort=header-only -dhruva -- Contents reflect my personal views only!

3 2

[thread] thread_proxy's catch(...) destroys my stack info for unhandled exceptions
by Roberto Gimenez 05 Jan '09

05 Jan '09

When some unhandled exception is thrown inside my function, it would be good that is isn't actually handled, so I could collect the stack info from the core-dump. For example: #include <boost/thread.hpp> using namespace std; using namespace boost; void f1() { throw 1; } void f2() { throw 1; } void f() { f1(); f2(); } int main(int argc, char** argv) { thread t(f); t.join(); return (EXIT_SUCCESS); } Whe run it, the core-dump's stack info is: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640,... ffffffff7f809ff4 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (0, 0, ... ffffffff7f809770 thread_proxy (100108610, 1001086dd, 2c, ... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) With this information I cannot know where the exception was thrown. So I commented the catch(...) part in libs/thread/src/pthread/thread.cpp: extern "C" { void* thread_proxy(void* param) { boost::detail::thread_data_ptr thread_info = static_cast<boost::detail::thread_data_base*>(param)->self; thread_info->self.reset(); detail::set_current_thread_data(thread_info.get()); try { thread_info->run(); } catch(thread_interrupted const&) { } //catch(...) //{ // std::terminate(); //} detail::tls_destructor(thread_info.get()); detail::set_current_thread_data(0); boost::lock_guard<boost::mutex> lock(thread_info->data_mutex); thread_info->done=true; thread_info->done_condition.notify_all(); return 0; } } And recompiled boost, now the core dump's stack info is the desired one: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, 0, 4, 11fb1c, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, 0, 0, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ffffffff7ed00358,... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640, ... ffffffff7f809f54 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (ffffffff7f214718, ... ffffffff7f1067f4 void __Cimpl::ex_terminate() (ffffffff7f2106c0, 0, 0, ... ffffffff7f1074c8 _ex_throw_body (ffffffff7f2106c0, 0, ffffffff7e2fbf50, ... ffffffff7f10740c void __Crun::ex_throw(void*,... 0000000100004064 void f1() (0, 0, ffffffff7edf7f80, ... 00000001000040fc void f() (ffffffff7f915528, 100108610, ... 00000001000053c0 void boost::detail::thread_data<void(*)()>::run() (... ffffffff7f8095b4 thread_proxy (100108610, 3, 100106bd8, 100108610... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) I can know now where the unexpected/unhandled exception was thrown. I could solve my problem partially, puting throw() exception specs everywhere, so when some unexpected exception is thrown, the throw() will stop it. Unfortunatelly, it whould stop at the calling function, and the stack will tell me that some unexpected exception was thrown by any of the functions inside the caller. This is worse than having a stack info like the above one because in this case I wouldn't know who raised the unexpected exception. In the above stack info I can know who did it. So why is: catch(...) { std::terminate(); } there? It looks unnecesary.

5 9

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 04 Jan '09

04 Jan '09

Andrey Semashev wrote: > Sorry, couldn't resist. I think, my library fits these requirements > quite well. Why would you start your own implementation from scratch? Is > there something that doesn't suit you in my implementation? It started because I thought yours was no longer in development. I have no idea why I thought that, since looking at your cvs logs you have been consistently working on it. It was largely a mistake. I'm writing a internet spaceship game. There's a client and a cluster of servers with different types. The protocol is simple message passing, with the serialization code shared between client and server. This leads to a very simple example like: if(message.size > packet.size) { log << severity::warn() << "Packet was larger than the buffer that contains it!" << build_target::server() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); // error handling } On the client side, we note that the packet was too big and move on. On the server side, we actually log the packet since evil hackers are always trying to steal my space bucks. Since the template generates empty code at compile time, both gcc and msvc are smart enough to remove the " Packet source=" and ", account= " strings from the binary, providing less clue in the client as to what the server is watching for. On the server side, I probably want this record to go into a database, so having the entire thing as a single record is very important. That precludes items of the form: log << severity::warn() << "..."; if(server) // or #ifdef log << "Packet source = "; //... I also really don't like having the conditional in the logging. Looking at the serialization code, one shouldn't have to wade through the logic of logging. I think I could add this to your library using features. That's not a light weight thing to add, based upon what I see features need to be instantiated. In my scheme, since the if() test is built into the log record instantiation there's single point to change to affect all appropriate loggers. With your scheme I'd have to change the logger type, the if()s that wrap them or the macros that contain the ifs, and possibly client code as well. Switching to a different scheme, I could do: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); Now, on the client side I can turn off full auditing at compile time and on the server time I can turn off packet logging at run time and have a condition that turns it on when I suspect a problem. There is a separation of concerns between what audit level and severity of the record. The whole thing could be rewritten with scope variables for connection and user that would allow them to be first class denizens of the database or fed into an event processing system without having to do entity extraction on the record. In addition, immediately insertable variables prevent the overhead of setting scope variables if not needed: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << << set("User", user) << set("connection",connection) " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); --- Jason Wagner jason(a)nialscorva.net

4 8

segemented iterator support?
by k-oli＠gmx.de 04 Jan '09

04 Jan '09

Does boost support a kind of segemented iterator (Segmented Iterators and Hierarchical Algorithms, Matthew H. Austern)? Oliver

3 4

Can't access ticket?
by John Maddock 03 Jan '09

03 Jan '09

Can anyone access this ticket: https://svn.boost.org/trac/boost/ticket/764 ? It's assigned to me, but IE and Firefox return an internal Trac error: Trac detected an internal error: TypeError: a float is required Python Traceback Most recent call last: File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.py", line 423, in _dispatch_request Code fragment:try:if not env and env_error:raise HTTPInternalError(env_error)try:dispatcher = RequestDispatcher(env)dispatcher.dispatch(req)except RequestDone:passresp = req._response or []except HTTPException, e:Local variables:NameValueafter[u' except RequestDone:', u' pass', u' resp = ...before[u' try:', u' if not env and env_error:', u' raise ...dispatcher<trac.web.main.RequestDispatcher object at 0xb7aff90c>e<exceptions.TypeError instance at 0xb7a6874c>env<trac.env.Environment object at 0xb7c46aec>env_errorNoneexc_info(<class exceptions.TypeError at 0xb7f782cc>, <exceptions.TypeError ...filename'/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.p ...frames[{'function': '_dispatch_request', 'lines_before': [u' try:', u' ...has_adminTruelineu' dispatcher.dispatch(req)'lineno422messageu'TypeError: a float is required'req<Request "GET u'/ticket/764'">resp[]tb<traceback object at 0xb7a6e324>tb_hideNonetraceback'Traceback (most recent call last):\n File ...File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.py", line 197, in dispatch Code fragment:req.args.get('__FORM_TOKEN') != req.form_token:raise HTTPBadRequest('Missing or invalid form token. ''Do you have cookies enabled?')# Process the request and render the templateresp = chosen_handler.process_request(req)if resp:if len(resp) == 2: # Clearsilverchrome.populate_hdf(req)template, content_type = \self._post_process_request(req, *resp)Local variables:NameValuechosen_handler<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>chrome<trac.web.chrome.Chrome object at 0xb7c65d6c>err(<class exceptions.TypeError at 0xb7f782cc>, <exceptions.TypeError ...handler<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>req<Request "GET u'/ticket/764'">self<trac.web.main.RequestDispatcher object at 0xb7aff90c>File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/web_ui.py", line 152, in process_request Code fragment:def process_request(self, req):if 'id' in req.args:if req.path_info.startswith('/newticket'):raise TracError(_("id can't be set for a new ticket request."))return self._process_ticket_request(req)return self._process_newticket_request(req)# ITemplateProvider methodsdef get_htdocs_dirs(self):Local variables:NameValuereq<Request "GET u'/ticket/764'">self<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/web_ui.py", line 412, in _process_ticket_request Code fragment:version = int(version)except ValueError:version = Nonereq.perm('ticket', id, version).require('TICKET_VIEW')ticket = Ticket(self.env, id, version=version)action = req.args.get('action', ('history' in req.args and 'history' or'view'))data = self._prepare_data(req, ticket)data['comment'] = NoneLocal variables:NameValueid764req<Request "GET u'/ticket/764'">self<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>versionNoneFile "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/model.py", line 47, in __init__ Code fragment:self.env = envself.resource = Resource('ticket', tkt_id, version)self.fields = TicketSystem(self.env).get_ticket_fields()self.values = {}if tkt_id is not None:self._fetch_ticket(tkt_id, db)else:self._init_defaults(db)self.id = self.time_created = self.time_changed = Noneself._old = {}Local variables:NameValuedbNoneenv<trac.env.Environment object at 0xb7c46aec>self<trac.ticket.model.Ticket object at 0xb7affe0c>tkt_id764versionNoneFile "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/model.py", line 105, in _fetch_ticket Any ideas anyone? Thanks, John.

4 7

[accumulators] rolling mean
by Eric Niebler 03 Jan '09

03 Jan '09

The accumulators library now has a handful of rolling accumulators, including a rolling sum and a rolling mean. These have been on trunk for about a week, and have recently been merged to release and will be part of the 1.38 release. Enjoy, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 02 Jan '09

02 Jan '09

> -------Original Message------- > From: Emil Dotchevski <emildotchevski(a)gmail.com> > Subject: Re: [boost] [logging] Interest check on logging library. > Sent: 27 Dec '08 15:25 > > On Fri, Dec 26, 2008 at 9:48 AM, Jason Wagner <jason(a)nialscorva.net> wrote: > > Hello all, > > > > I know there are two proposed logging libraries out there for Boost, > > already, but I had a different itch to scratch on a project. I think I saw > > that Andrey Semashev was going to submit his far more mature version soon, > > but I thought I'd throw my technique out there for an interest check and > > hopefully commentary. This is very much a prototype-- there's a lot of work > > yet to be done but the basic outline and functionality is implemented. > > > > Getting the code > > ---------------- > > http://www.nialscorva.net/boost_logging-0_1.tar.bz2 > > What is the motivation for using boost::mpl in the logging library? I > didn't look too deeply into your code, but wouldn't something like > this work just as well: > > struct logging_debug; > struct logging_release; > > template <class> > struct logging_traits; > > template <> > logging_traits<logging_debug> > { > .... > }; > > In other words, let the user provide an explicit specialization to > configure the logger; once that's done, they just do: > > logger<logging_debug> log; This handles severity, but not necessarily other conditions. The library handles a more general case of this. In the use cases I'm working on, there are multiple independant tags on a record, severity being only one: severity := trace | debug | info | notice | warn | error | fatal // syslog levels, may be missing one build_type := release | debug The logger defines what, if any, conditions of these attributes a record must meet before being logged: logger< mpl::vector< condition::greater_equal<severity::info>, condition::in<build_target::debug> > > log; The logger<logging_debug> log; is equivalent to logger<mpl::vector<condition::greater_equal<severity::debug> > > log; A simple use case would be when you want to put more information into a debug build target than a release build target for the same level of severity: log << severity::info() << "An event that you should be informed of occurred" << build_target::debug() << " debugging information: " << dump_lots_of_info() << end_record(); User defined tag types are extremely easy to make and integrate seamlessly. In the application I'll be using this for, I'll have tags for build_target (client, server, possibly one of several types of server). This could be done via severity levels, but it would be fitting orthogonal concerns into a single enumeration. > My reasoning is that a logging library should be lightweight in terms > of source code; when I need logging, I'd rather not get boost::mpl > too. Understandable. Everything's a matter of tradeoffs. The project I'm working on has a slightly more involved logging use case. One concern I have is how much compile times will be affected by MPL and the templates I'm using and whether the flexibility is worth the cost. > A few more comments: > > In general I don't like using macros or #ifdefs, but one place where I > think they are OK is in a logging library interface, partially because > they make it much lighter, and partially because automatically logging > __FILE__, __LINE__, etc. is desirable IMO. I'm differentiating macros from simple defines. #define LOG_LINE filename(__FILE__) << line(__LINE__) << function(__FUNCTION__) will be in the library in some form in the future. > Finally, I think that all the machinery a typical logging lib uses to > kill logging expressions when they're not needed is an overkill. I've > found that using something as simple as the code below works just > fine: > > namespace logging > { > static bool const warnings=false; > static bool const errors=true; > } > > and then: > > if( logging::warnings ) > log << "Warning"; > > where log simply implements std::ostream. > > You could put the if in a macro but frankly, I personally don't mind > typing it every time; compared to the rest of the junk I have to type > to format a meaningful logging message, the if is not an issue. As a > bonus, you don't have to worry about functions referenced by a logging > expression being executed when logging is not enabled. I'm not a fan of the macros, either. What's really the difference between what you wrote and: LOG_DEBUG(log) << "Warning"; other than the latter being ugly. One of the needs I have is sending output to multiple sinks and reconfiguring filter conditions on the fly (runtime conditions, nt compile time conditions). The if() becomes more complicated and there's visual overhead in having code to change the condition and the potential for typos in non-trivial checks. Hiding that complexity makes the real code more readable and maintainable. That being said, my approach may be overkill for situations of writing to a single file based upon simple variables. I don't think the implementation complexity for the end-user is too high, but it's all about what your needs are. > -- > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > --- Jason Wagner jason(a)nialscorva.net

5 10