- Boost - lists.boost.org

pthread_handle_sigrestart boost 1.31
by Gaetano Mendola 04 Jan '05

04 Jan '05

Hi all, some time my application die from back trace this is what I see: #0 0x400369d5 in pthread_handle_sigrestart () from /lib/i686/libpthread.so.0 #1 <signal handler called> #2 0x420292e5 in sigsuspend () from /lib/i686/libc.so.6 #3 0x40036679 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0 #4 0x40032f2c in pthread_cond_wait () from /lib/i686/libpthread.so.0 #5 0x40017bf2 in ?? () #6 0x080628e0 in boost::detail::function::void_function_obj_invoker0<PacketSwitcher<PacketContainer<IpPacket*> >, void>::invoke(boost::detail::function::any_pointer) () at buffer.h:106 #7 0x4001a646 in ?? () #8 0x40033fef in pthread_start_thread () from /lib/i686/libpthread.so.0 I'm using the version boost 1.31 ( just the thread library ) am I missing something or is a known problem? Regards Gaetano Mendola

1 0

[Boost-bugs] [ boost-Bugs-1095697 ] bug in ublas/storage.hpp
by SourceForge.net 04 Jan '05

04 Jan '05

Bugs item #1095697, was opened at 2005-01-04 04:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1095697&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug in ublas/storage.hpp Initial Comment: Hi all, I have found a bug in boost-1.32.0-1.fc3: /usr/include/boost/numeric/ublas/storage.hpp:707: error: declaration of `class T' /usr/include/boost/numeric/ublas/storage.hpp:703: error: shadows template parm `class T' template<class T> class shallow_array_adaptor: public storage_array<shallow_array_adaptor<T> > { template<class T> struct leaker { typedef void result_type; typedef T *argument_type; BOOST_UBLAS_INLINE result_type operator () (argument_type x) {} }; Pls, replace name of the template parameter T in struct leaker. Thanks. witali.kusnezow(a)neuroinformatik.rub.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1095697&group_… ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

auto-link and comeau?
by Robert Ramey 04 Jan '05

04 Jan '05

I've made source changes to accommodate Comeau. Now even static libraries fail to compile on with this compiler. Is this the intention or am I missing something. Robert Ramey

6 21

RE: [boost] Re: FYI Lambda Question
by Brian Braatz 04 Jan '05

04 Jan '05

> -----Original Message----- > On Behalf Of Aleksey Gurtovoy > Subject: [boost] Re: FYI Lambda Question > Brian Braatz writes: > > We MIGHT have some missing files? I am about to convert to > > boost 1.32 I am still on 1.31. In the 1.31 zip file I > > downloaded (and am using), the header does not exist in the > > utility dir. > > That's 'cause 'result_of' was introduced in 1.32. > > > I grepped the boost tree for result_of and only > > found one comment in transform_iterator.hpp which is stated > > as a question ("do we need to adjust the way > > function_object_result is computed for the standard proposal > > (e.g. using Doug's result_of)?") (line 64). > > > > The link to the web page you sent me points to a HPP file. > > This file does not seem to exist in utility. For experimenting, > > I copied the file referenced in the page below to > > boost\utility. It complained on the line > > > > #include <boost/mpl/has_xxx.hpp> > > > > That has_xxx.hpp does not exist. > > Again, it does in 1.32. > Thanks you *very much* for help here. This issue is pushing me to convert to 1.32 (which is good- I am doing that NOW). And without help from everyone who is added thoughts, I would still be in the bicycle shed. (I still am but I now see the door). :) Once I get converted and get my code working, I will post to this list a quick how to on what the resolution to the original question was (this way other folks can find the solution in the future by searching mail archives). ****************** SEPARATE THREAD: It would be nice if boost doc pages pointed to a WIKI or something for people to add things to the documentation (not officially added mind you- just ammendums)(similar to how people can comment on products on amazon.com for example) . I.e. once I get code working on how to deduce return type from a lambda functor, it would be nice if I could put that info someplace easy for others to find. OR- Is the solution for me to write up a page of documentation and simply request it be added to the lambda documentation? (which raises the issue)- is there any process for this? Thanks Again Guys. It is the people that give boost the real "boost" :)

2 1

Re: [thread] Resource usage in Win32 version of condition class
by Don G 04 Jan '05

04 Jan '05

Hi Roland, >>I may be worried over something inconsequential, but the condition >>class creates three kernel objects per instance. >> > There is quite a lot of archived discussion available about this > topic. There is agreement, that on windows this is the only reliable > way of doing it. Beneath the boost list you might also google for > "condition win32". > As far as I understood the main issue that it is not possible to > implement a condition on win32 with a single event is that it is not > possible to awake a single thread _and_ awake all threads. > You can't achive both available semantics with an event alone. I agree that if _all_ capabilities of a posix condition variable are required, my approach would not work. I used one event per waiting thread, the condition variable was permanently associated with the mutex (not just when waiting), and the caller to notify/notifyAll had to have the same mutex. Adding a lightweight_mutex to the condition variable would enable the missing features, but as I said, I saw no need. Sadly, I must confess that I don't understand your reference to the Monitor pattern (been too long since I read that book) and how it relates. > As opposed to conditions your construct also would create a > condition with "state". This is not a condition anymore. It has nearly all the benefits of a full condition variable, is more convenient (safer?) in cases where the mutex passed to wait() is always the same, and is implementable on both platforms with minimal overhead. Unless I am missing something quite fundamental (which is certainly possible<g>), the extra power of on-the-fly association and notify-w/o-holding-mutex don't justify the cost these features entail. I just wrote this off as a satisfactory, least-common-denominator to gain most of the benefit condvars offer. Thanks & Best regards! Don PS: I searched on "condition win32" on www.boost.org and got only 9 hits. A full google turned up an article by Douglas Schmidt that I had read some years back (the top hit). How should I search to find these old discussions? ===== __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com

1 0

OOPSLA2004/Workshop Results?
by Joaquín M López Muñoz 04 Jan '05

04 Jan '05

Any estimated date to have the results posted on the Wiki? Happy new eyar to everybody, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Re: [gui] The Big Picture [and wxWidgets]
by Brian Braatz 03 Jan '05

03 Jan '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Marcelo E. Magallon > Sent: Saturday, January 01, 2005 2:12 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: [gui] The Big Picture [and wxWidgets] > > On Sat, Jan 01, 2005 at 01:50:28PM -0700, Brian Braatz wrote: > > > I will end my thoughts here with the (repeated) suggestion that > > making a thin layer above the current WxWindows will allow for a > > Boost.Gui in a short timeframe that has an incredible API interface. > > Ugh... yet another layer. wxWidgets has enough of those already :-\ > > Just to understand you, what would be the purpose of such a layer? > > Marcelo [Brian Braatz] My thoughts: 1- Make a layer that hides WxWidgets- but uses modern template techniques to present an "new" interface (which uses WxWidgets for an underlying implementation) 2- Allow access to the underlying WxWidgets if the programmer so desires 3- Eventually, you will have built a new "api" for accessing WxWidgets 4- WxWidgets becomes an underlying "personality" plugged into boost.gui, it would should then be possible to develop a personality for MFC, OWL, Foxtrot whatever, either as a part of Boost.gui, or as something a user of Boost.gui may wish to do on their own. 5- Eventually, a "boost official" personality could be developed to swap for WxWidgets This has the advantages of: 1- Get something going quickly 2- can attack the problem one piece at a time 3- gives boost.gui developers an ability to pick and choose which problems they solve and which they do not. 4- addresses the problem of having a STANDARD interface for common functionality (boost.gui), but allowing the user to use whatever gui framework they wish. This gives an application developer the flexiablity to use the boost.gui layer for 90% of their code, and then "drop into" the underlying framework if there was something their specifically they wanted to use. 5- It is much easier to scope out "common functionality" and focus on that, instead of burning resources on trying to do EVERTHING at once Example: I would want to use boost.gui for my MFC app, but I might want to use the Internet Explorer control for one screen in my app. I can now write MOSTLY standard code (boost.gui) and then specialize (Mfc IE class) where I care to. As an app designer, though I have the choice as opposed to an all or nothing. This is similar to the concept that that we all like C++, but some folks run OSX or Windows or Linux. I can use BOOST in my app for most things, if I want to use the Win32 thread pooling API, I can, or I may choose to use Boost.Thread. Motivation: Choice of frameworks is kinda like choice of computer language. It can be personal, political, or just what you are used to. By positioning boost.gui in such a way as to be open to all categories, not only will it be easier to establish a standard, it will be easier to get people to USE boost.gui. I believe it is better for boost.gui to be something that brings all these pieces together instead of being "Yet another gui library". </2Cents> :)

1 0

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 03 Jan '05

03 Jan '05

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. Fixed in CVS. Thanks for the report, --Beman

1 0

[thread] Resource usage in Win32 version of condition class
by Don G 03 Jan '05

03 Jan '05

I just joined the mailing list, so please pardon me for (and educate me on) failed points of etiquette. You all have done some fine work! I may be worried over something inconsequential, but the condition class creates three kernel objects per instance. Granted, one would have to instantiate hundreds of these objects to notice a problem, but STL collections make such things trivial. For example, in a previous job one of our teams created a large, in-memory database that had a mutex/condvar on lots of objects. I guess that I am concerned by the non-portable "cost of use" equation (say vs. pthreads). One could write code that was perfectly reasonable on Unix and quite terrible on Windows. Some years ago I also implemented a condvar on Win32, but the technique I used required only one event per thread (a CondVar was nothing more than a list of stack structures guarded by the associated mutex). In the FWIW category, I could see no benefit (and lots of pain) binding the condvar to the mutex at the time of wait(), so in my implementation a condvar was permantently bound to its mutex (as in "condvar::condvar(mutex & m)"). I have yet to find a case where the posix-style, free association was needed. Best regards, Don Griffin __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

[shared_ptr] Why aren't atomic integer operations used?
by Don G 03 Jan '05

03 Jan '05

I was reading the shared_ptr and shared_count classes and noticed that a mutex is used when it appears that atomic inc/dec could be used instead. Unless I am missing something? The atomic operations would be far better in terms of resource usage. It seems (to me anyway) far too expensive to have a mutex allocated for every object under management. On platforms where atomic inc/dec don't exist (if there are any<g>), a pool of mutexes be used. The object's pointer would be hashed to produce the appropriate mutex, thereby ensuring a consistent mutex for each object and a low likelihood of undesired contention. Also, an upper bound on the number of mutexes allocated vs. objects. Best, Don PS: This is now only my 2nd post, so if I am not following proper protocol, please feel free to advise. __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

2 1