January 2005 - Boost - lists.preview.boost.org

RE: [boost] Yet another variant-style type, and boost inter-library dependencies
by Brian Braatz 05 Jan '05

05 Jan '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > In general I am curious about how other boosters feel about boost library > sizes and inter-library couplings. For me this is a big obstacle to using > boost in many circumstances. It doesn't seem to be a concern at all for > the > boost community, but I wonder if other programmers have similar sentiments > and find themselves often seeking out simpler alternatives. > Hmmm.... What you "get" with boost, to me, far outweighs library dependency. If you decouple TOO much, you end up re-inventing the wheel too many times. I am currently, for example, writing a Domain Specific Language on top of boost.lambda. It would not make sense to decouple, nor does the boost dependency bother me. In some ways this is like saying that since I never use std::list<> and always use vector<> that I would like to purchase my compiler without this header. The std libraries are "standard" and you can publish code with list<> or vector<> and know it will work on people's compilers. It is in the same way that I see boost. It is something of a "standard". (though also a work in progress) It is not clear to me what the "big obstacle" is? If you are publishing an article, then say "boost 1.32 required". Maybe I am way off base, but I just don't see the issue. " For me this is a big obstacle to using > boost in many circumstances." If you could tell us about the circumstances where this is a problem, we might be able to better see where you are coming from.

1 0

Re: Anyone interested in network interface (sockets)library?
by Don G 04 Jan '05

04 Jan '05

Jonathan - thanks for the info. I hadn't seen the wiki before; is it an "official" boost area? The giallo project looks light on the surface. Perhaps more is available in its CVS repository. I will have to see figure out why my search didn't turn up any messages - several threads were referenced in the wiki. Odd. You mentioned several works in progress, but only giallo was mentioned on the wiki. I will look at the Yahoo files area next. Were is the best place to discuss the design of this library? Here? Thanks again! Don >Don G wrote: >> I was curious if others have discussed this before. I searched and >> found nothing on "socket" or "network". > Yes, everyone is interested in a sockets library ;-) > > There are several works in progress. A number of them are in the > Yahoo files section. The furthest along, I think, is Hugo Duncan's > Giallo project. > > http://sourceforge.net/projects/giallo/ > > There's also some discussion on the Wiki: > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket > >> Best, >> Don > >Jonathan __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

3 2

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