- Boost - lists.boost.org

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

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

03 Jan '05

I was curious if others have discussed this before. I searched and found nothing on "socket" or "network". Best, Don __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com

2 1

Boost Files Section
by Robert Ramey 03 Jan '05

03 Jan '05

Following the "Files" link on the main page takes me to the Yahoo files section - which turns out to be full. Where should files be loaded to and downloaded from - and shouldn't the link on the main page point to that? Robert Ramey

1 0

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

03 Jan '05

> -----Original Message----- > On Behalf Of Matt S Trentini > Subject: [boost] Re: [gui] The Big Picture [and wxWidgets] > > Heya Rene, > > That all sounds great; perhaps we should be helping out the wx guys > rather than come up with our own library...? > > Does anyone else have any good reason why we should create a completely > new library assuming that those issues are addressed? (License could be > one problem quite aside from the technical issues.) > > Keep in mind that starting a GUI library from scratch is going to take > *significant* time. > > And is wxWindows our "best bet"? It's certainly going to be easier than > trying to convince the Qt folks to get rid of their preprocessor... ;) > > It'd be fantastic if all the issues I brought up with wxWidgets were > addressed and we ensured that it worked well with the other boost > libraries. > > Is there anything anyone else wants or needs that wxWidgets couldn't > supply? [Brian Braatz] I have been watching this whole thread closely, and just wanted to send out a mail in support of the idea of collaboration. I have written many UI Frameworks ON TOP of things like MFC and OWL, and even just writing something ON TOP Of one of those things is a huge task. In one case this was my primary job for several years. It is one of those things where to get something demo-able is easy. But "Completing" it is a different issue entirely. If you look at all the fundamental issues discussed in this thread, i.e. do we have our own point coordination system etc, you can see that there is more here than meets the eye. 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. :) Brian

6 13

Named Template Params
by David Greene 03 Jan '05

03 Jan '05

I see that a Named Params library has been accepted into Boost. Great! Is this named template params or named function params? I've actually been working on a named template params implementation of my own so I'm particularly curious about what Dave and Daniel have done, whether it be for templates or functions. Is there an accessible page of documentation somewhere? There's been a named_template_params.hpp in the sandbox for a long time. What's going on with that? Is there general interest in a named template parameters library? -Dave

5 10

GUI History
by David Abrahams 02 Jan '05

02 Jan '05

2 2