[boost] Re: libs/config/configure screwed up in DOS format in 1.30.1
Pascal Bleser <[EMAIL PROTECTED]> writes: > Just discovered that libs/config/configure is spoiled with CRLF in 1.30.1 > Shouldn't be the case for a UN*X script ;) Fixed now. I wonder if it really ought to be checked in as binary so this doesn't happen? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Bug tracking (was: Re: [boost] Re: Release Manager's Checklist added)
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 09, 2003 11:58 PM Subject: [boost] Re: Release Manager's Checklist added [...] > >> > That's probably wrong. They should use a tracker first and then discuss > >> > them on the mailing lists. > >> > >> I disagree. I think that we should try to focus information instead of > >> spreading them around. > > > > That's exactly what a tracker is good for IMHO. > > Yes, agreed. One big problem though is that the SF trackers kinda > suck. I'd be interested in trying something else, like > http://roundup.sourceforge.net/ Interestingly enough they seem to use the SF trackers for their own bugs ;-). But the more important question probably is if there are any volunteers providing an alternative tracker for us? [...] > >> The trackers are IMHO a problem because they require a lot of work. > > > > That could be, yes. > > Yeah, but that might just be the SF trackers. We don't have to use > them as-is. Quality assurance simply is a lot of work. > >> The current state shows that it is not maintained well, e.g. there > >> are open bugs which are long closed in CVS, see #451535. Sure we > >> could do better in theory, but is it worth it? Why not use > >> regression tests to track bugs? AFAICS people pay a lot of > >> attention to the regression tests and the whole systems work pretty > >> well. > >> > >> Also, I hope that it could make the release manager's work easier to > >> have fewer sources to track :) > > > > In my opinion it should be easier for the release manager to look > > into the tracker than to follow *all* mailing list traffic. > > Yeah. Also, you can't always get people who find bugs to make > reproducible test cases in a form that integrates with the regression > suite. OK, I'd be willing to spend some time working with the SF trackers in the near future (assumed we don't change the tracking system). > >> OK, what do others think? Am I the only one who feels uncomfortable with > >> the SF-trackers? > > Nope; I dislike them also. That doesn't mean trackers in general are > a bad idea. I'd still be interested to hear some more opinions, especially user's. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bind/lambda - unsupported use case?
Peter Dimov wrote:
> Aleksey Gurtovoy wrote:
> > Consider the following snippet:
> >
> > void show_warning( message_dialog const&, user_message );
> > void post_command( boost::function );
> >
> > int main()
> > {
> > boost::function f(
> > bind( &post_command
> > , ( bind( &show_warning, message_dialog(), _1 ) )
> > // what goes here?
>
> "protect", in boost/bind/protect.hpp. Lambda has both "protect" and
> "unlambda", either will work (I think).
>
> > )
> > );
> > }
I am afraid it's not that simple. Note that 'post_command' takes a
_nullary_, not an unary function. To clarify the semantics of the above,
I need to construct a bind expression which would allow the original code
to become equivalent to the following:
void
post_show_warning_command(
message_dialog const& a_dialog
, user_message a_message
)
{
post_command( boost::bind( &show_warning
, a_dialog
, a_message
) );
}
int main()
{
boost::function f(
boost::bind(
&post_show_warning_command
, message_dialog()
, _1
)
);
}
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > >> As far as I know the CVS is in very good health at the moment. > > > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > > there are lots of regressions comparing to 1.30.0, and IMO we ought to > > fix all these before we branch for the release or anything. > > I can't really tell what these represent. As usual, a red cell means a regression from the 1.30.0 tarball, a dark green one - an improvement. > All of the new iterator library tests which weren't in 1.30.0 are > showing up as regressions if they're failing. Yes, it's a known shortcoming - or a feature, depending of how you look at it. By default, new tests are expected to pass. > Many are simply not going to get better; they're due to compiler bugs > which can't be worked around. Which is totally fine. If you provide us with the list of expected failures, these will be cleared. > As for the others, the failures you're reporting with intel-7.1 are > very strange; my 7.1 compiler doesn't have these problems AFAIK. Hmm, looks like another configuration problem to me. We'll take a look at it. > What does the "meta-" prefix mean? "meta-" is our prefix for non-boost toolsets. > Do you have some special configuration of each of these compilers? Well, most of them are not really special. For instance, bcc-* ones were introduced for the only purpose of being able to test 5.5.1 and 5.5.4 compilers simultaneously. The complete list of differences is available here - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: >David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >... >>>I would be interested in >>>hearing about the plans for a Boost 1.31 release >> >> >> As far as I know the CVS is in very good health at the moment. The >> only major thing I know needs to be done is to complete the >> documentation for the new iterator adaptors. I'd like to get that >> over with soon, so it isn't hanging over our heads much longer. > >In order to avoid problems to be discovered too late for fixing them >I'll list the tests that fail for many compilers/compiler versions >on Linux: > >- filesystem::operations_test >- function::sum_avg_portable >- iterator::interoperable_fail (a compile_fail test that fails, > probably not a real problem) >- math::octonion_test > math::quaternion_test >- test::errors_handling_test > >I hope that lists helps. Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
At 07:30 PM 8/6/2003, Joel de Guzman wrote: >Beman Dawes <[EMAIL PROTECTED]> wrote: >> At 10:54 AM 8/5/2003, Brock Peabody wrote: >> >> >> I don't know much about other GUI systems but win32 >> >> and MFC. I think we can try to define the low-level >> >> layer using win32 and/or MFC as the starting point. >> >> If we cover these two, it'll be a good start and prove >> >> of concept. >> > >> >Actually for a proof of concept we could get by with just one. >> >> Given the major differences between underlying GUI API's, your really >need >> to be developing in parallel for both Windows and Linux right from the >> start. > >And don't forget the Mac ;-) For a "proof-of-concept", implementations are needed for enough of the framework to make it obvious it can be make to work with GUI API's that follow the same general model. Particularly the event/callback/other-flow-of-control mechanisms. I know that Windows and X Window are major API's that follow very different flow-of-control models. Is the Mac sufficiently different to be an important proof-of-concept case? Are there others? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: time_duration bug in Boost 1.30.0
At 05:27 PM 8/7/2003, Bo Persson wrote: > >"Paul A. Bristow" <[EMAIL PROTECTED]> wrote: > >> >> (And other MS specific unhelpful warnings which could be dealt with >by >> >> #ifdef _MSC_VER or BOOST_? >> #pragma warning (disable : 4800) // inefficient bool conversion? >> #endif >> >> As a general point, is there any reason why 'known to be unhelpful' >> warnings like this cannot be disabled in Boost code? >> > >A problem here is that the "inefficient bool conversion" often >actually *is* an inefficient implicit conversion to bool. IME, most of >these warnings can be removed by actually producing a bool value. >Adding == 0 or != 0 is often all it takes. FWIW, I've done that for years in my own code, and have come to believe that it results in better code. It makes the intent clear to someone reading the code. With an implicit conversion, a reader is unsure whether or not the conversion was intended. To answer Paul's question, some of the toolsets do disable "known to be unhelpful" warnings. But I agree with Bo that this warning shouldn't be one of them. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Can't get from anonymous CVS
At 11:29 PM 8/7/2003, Victor A. Wagner, Jr. wrote: >At Thursday 2003-08-07 17:28, you wrote: >>cvs server: [11:59:06] waiting for anoncvs_boost's lock in >>/cvsroot/boost/boost/libs/numeric/mtl/test >>cvs server: [15:35:09] waiting for anoncvs_boost's lock in >>/cvsroot/boost/boost/libs/numeric/mtl/test >> >>that's been going on every 30 seconds for 5 1/2 hours >> >>does anyone know how to "fix" that problem? >[deleted] >Ok, so I can't subtract...but it's now >cvs server: [20:28:39] waiting for anoncvs_boost's lock in >/cvsroot/boost/boost/libs/numeric/mtl/test When a SourceForge CVS lock goes stale you have to put in a request to SourceForge for them to clear the lock. They are pretty prompt about fixing such problems, although it is past all understanding why they don't put some automated fix in place. Numerous project admins have asked for this in the past. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Hey, I have a replacement test file here! (was: Added new testfile, need help testing)
At 01:32 AM 8/9/2003, Daryle Walker wrote: >I uploaded a new test file for the I/O state saving classes over a >month ago. How do we get the regression test guys to use the new file >instead? Add to or otherwise modify the Jamfile that drives the test? Looks like the io tests are specified in boost-root/status/Jamfile: run libs/io/test/ios_state_test.cpp ../libs/test/build/boost_test_exec_monitor # sources : # args : # input-files : static # requirements (static runtime required by Metrowerks) ; So add another test or change this one. The "regression test guys" just run bjam against the Jamfile. It is up to library maintainers to make Jamfile changes when needed. When a library grows beyond a single simple test, it becomes worthwhile to set up a test directory with its own Jamfile. Look at say filesystem for how it is done. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release Manager's Checklist added
At 05:58 PM 8/9/2003, David Abrahams wrote: >[EMAIL PROTECTED] (Joerg Walter) writes: >>> OK, what do others think? Am I the only one who feels uncomfortable with >>> the SF-trackers? > >Nope; I dislike them also. That doesn't mean trackers in general are >a bad idea. I'm not happy with the S/F trackers either. But like Dave, I definately feel we need some form of tracking. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Brock Peabody wrote: On Behalf Of E. Gladyshev Don't know where to start... Greek and Roman mythology? [...] Other ideas: Atlas ATLAS: Automatically Tuned Linear Algebra Software http://math-atlas.sourceforge.net/ f. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Matthias Troyer <[EMAIL PROTECTED]> writes: > > > Dear Boosters, > > > > Since some of the applications and libraries we plan on releasing soon > > rely on Boost features and bugfixes that are in the CVS but not in > > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 > > release? Since we would prefer to base our released software on a > > Boost release instead of a CVS snapshot I would be interested in > > hearing about the plans for a Boost 1.31 release > > As far as I know the CVS is in very good health at the moment. Uhmm, I really wouldn't say so! If you look at the main trunk report - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, there are lots of regressions comparing to 1.30.0, and IMO we ought to fix all these before we branch for the release or anything. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Peter Dimov wrote:
> I think that this specialization is ill-formed if the primary swap<> isn't
> in std. Your code is broken by STLport's tricks, even though it looks
> correct. :-)
I think this is the consensus.
> Try
>
> template<> void std::swap( empty &lhs, empty &rhs )
> {
> }
>
> instead and see if it works. (I think it's broken too but the compiler may
> like it better.)
Has problems implementing functions inside namespaces with earlier BCBs
so I didn't think to try it. This is much better, as the compiler
rejects the swap straight away, so the error is found on the correct
line, rather than in shared_ptr
I am still not clear on the 'best' solution though.
Clearly the quickest fix is to simply put the swap specialization in the
correct namespace.
However, boost code does not seem to specialize std::swap at all, but
rather provide its own swaps in namespace boost. Is this the preferred
approach? [using my own namespaces, obviously!]
No-throw swap operations are clearly important tool when we are worrying
about the exception guarantees, but I am not 100% clear on the 'correct'
way to do this anymore.
--
AlisdairM
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Preliminary submission: FC++
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Brian McNamara | Sent: Tuesday, July 29, 2003 5:43 AM | To: Boost mailing list | Subject: Re: [boost] Re: Preliminary submission: FC++ | | | Based on David's suggestion, I'll try to briefly define all the terms | I've used in my earlier post. This is most helpful and shows impressive potential. But there is quite a lot to curry ones mind ;-) May I suggest that as well as promised documentation, the excellent set of examples would benefit from a couple of enhancements: 1 Paste the output at the end as a comment, /* Output is: 2 4 6 8 10 */ 2 paste output or notes for more significant lines as a comment, for example: f(3, 2); // yields 5 3 Don't put using namespace boost::fcpp; but instead using fcpp::plus; using fcpp::minus; ... so the less functional programmer can see immediately what fcpp is providing for this module. (Just as using std::cout; std::transform; is very helpful to the less STL literate). 4 And of course examples like BOOST_CHECK(plus(2, 2) == 4); will also be useful to readers as well as providing a test suite. I look forward to getting my mind further round this stuff. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: Re: [boost] boost and DLL's
--- Edward Diener <[EMAIL PROTECTED]> wrote: > Exporting/importing C++ classes is completely > implementation dependent, due > mainly to name mangling, and requires a DLL for a > particular > platform/compiler/release to be built. There are several issues with DLL and C++, to name few: 1. Name mangling 2. Using inline methods in the exported class. 3. Global class instanses in the DLL. How does boost ensure that inline methods don't conflict with the exported methods. The conflict can be platform specific. Is it allowed to have global instances of a class in boost's DLLs? Are there any development policies on how exported C++ classes should be implemented/tested in boost? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] FW: Eric Ford Units - changes needed for MSVC 7.1
--- Begin Message --- I have found that there are some changes are needed for Eric Ford Units system in ebf_units.zip (in the files section) to meet the requirements of MSVC 7.1 - I presume to comply with C++ Standard better. (I surmise that other recent compiler versions will also require this). In dimension_list.hpp there are numerous requirements for typename to prefix add_frac, sub_frac ... so these already long lines become, for example: typedef dimlist< typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value > diml_type; I suspect there are many other similar changes needed. There is also what looks like a mistake in base_dimen.hpp where 'type' should be 'inv_diml' // struct mul_return_type::type > struct mul_return_type::diml_type > With these changes, I can execute example1. It compiles without 'langauge extensions' but there are also very many warnings at level 4 about unused variables, and very many examples of: j:\Cpp\FordFunctions\units\base_dimen.hpp(82): warning C4180: qualifier applied to function type has no meaning; ignored Is anyone working on this units system? Eric? Is anyone working on NIST/ Walter Brown units system now that it might compile with MSVC 7.1? There is still a great need for a units system. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- End Message --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] GUI sublanguage ?
Recently there was idea about "spirit-like" dialog sublanguage
implemented in c++. I still can't get why someone may need
it ?
Spirit is forced to use such language to build QUOTED code, which
works only when parsing occur. In case of GUI lib
sutiation is different :
We are not building code, but tree of gui objects placed in
2d (+z order). Sure boost::gui should deal with actions,
but generally they are much more compicated than spirit ones
and can't be easyly implemented by binders/bll/phoenix.
Besides, average gui control has a lot of properties which
may change in runtime. Would be convenient and
effective to fill/change such properties using spirit like
language ?
Why invent new shape for wheel ? :
void my_action( component & sender )
{
show_dialog( "sender is " + sender.title() );
}
main()
{
window w;
w.title("sample boost application");
w.width( 400 );
w.height( 200 )
button b;
b.title("click it!");
b.on_click.connect( &my_action );
w.insert( b );
b.align( alignment::vcenter | alignment::hcenter );
progress_bar pb;
pb.align( alignment::bottom );
pb.min( 0 );
pb.max( 100 );
pb.step( 5 );
pb.smooth( true );
w.insert( pb );
w.show(); //or w.show_modal();
window::main_loop();
}
regards,
bohdan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
--- Brock Peabody <[EMAIL PROTECTED]> wrote: > > > > Oh, and I really want the ability to select layers > 1 and 2 at runtime, > in > > a > > single place in my code, on a per top-level window > basis. > > Let's just try to get it working first. I don't > doubt that we could do > this but is it worth the cost in increased > complexity to both the > implementation _and_ the interface? If decide to use method 1, I think the ability to use different layer1 implementations in the same program will come as a natural benefit w/o any additional complexity. Actually it is true for method 2 as well. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
- Original Message - From: "Beman Dawes" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]>; "Boost mailing list" <[EMAIL PROTECTED]> Sent: Sunday, August 10, 2003 3:51 PM Subject: Re: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library] [...] > Well, a Vice-President is normally an officer of the corporation, so can > give permission. I'm not quite sure "thinks it's great" is what a lawyer > would call "permission". To protect yourself, you might want to be sure the > VP understands that you have posted an excerpt from some code owned by the > company. Thanks for the advice Beman, it never hurts to CYA :) This makes me wonder what the legal ramifications are of developing code for a boost or other non 'work' project while at work? I also made it clear to my boss, who is a good programmer and uses boost, that I planned on devoting a significant amount of time to this new GUI project. Again, he thought it was great. Should I get this permission formalized? Thanks, Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.30.1 released
- Original Message - From: "Fredrik Blomqvist" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 4:40 PM Subject: [boost] Re: Boost 1.30.1 released > Shouldn't the documentation for function and signals be added when your're > making an official release also? Yep, we should add that to the release manager's TODO list. We can just pull in the 1.30.0 docs, because nothing has changed in either library for 1.30.1. > What's the status regarding the new doc-system btw? (too lazy/tired to dig > through the archives right now ;-) It's there, and it's not half bad, although development has been a little slow over the summer. Doxygen extraction has been improved a bit in recent times. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] question regarding boost array
Currently boost array contains a copy of the array that initialized it. Is there any reason that boost array can't be enhanced to contain a reference to the original C array? I think this would make it more useful to me as well as others. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
"Daryle Walker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [...] > Yikes!! The "X" in "Mac OS X" has NOTHING to do with X-Windows! I didn't mean to suggest that it does. > (The Mac's "X" is for the Roman numeral for "ten".) Macs use an > independent GUI API. But, like Windows, there are programs that > allow X-Windows programs to work on Macs. Oh, one of my die-hard Mac programmer friends told me that OS X was using X, but with their own custom X server (and widget set, and window manager, obviously). Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Wrong version.hpp in Boost 1.30.1 download
At 01:13 PM 8/5/2003, Daryle Walker wrote: >On Monday, August 4, 2003, at 11:27 PM, David Abrahams wrote: > >> Alisdair Meredith <[EMAIL PROTECTED]> writes: >> >>> version.hpp still claims to be version 1.30.0 >> >> Oh well. I guess there are some details missing from the release >> manager's responsibilities on the release procedure page. > >Can you (or Beman, who I think usually does the releases) add these >directions to CVS? You may want to ask Beman if there are any other >details not yet mentioned in the docs. I'll try to update it. The problem is that the actual checklist I use is quite a bit longer, and a lot of the steps are specific to my environment. For example, it gives the steps needed to run the particular graphical FTP program I use. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: automating registering of events (was: Re: GUI/GDI templatelibrary)
"John Torjo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Eugene, > one more thing when you implement the GUI library. > > I ALWAYS hated the message maps from MFC/WTL. > So now I came up with a quite cute method of automating registering of events for a given window. > > (this should work for registering messages, etc.) > > It's very flexible. In other words, when you add an event for wnd_widget, > it does not couple the header file wnd_widget.h to the resource file (think MFC > for a moment ;) ) So, in case you modify the ID of a resource, all > you have to do is recompile the source file (wnd_widget.cpp), not the whole files > depending on wnd_widget.h. AFAIK, some gui toolkits use not event, but callback system. IMHO it is more evective. Definitely it should be discussed carefully. regatds, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Filesystem: naming, canonical path
At 08:06 PM 8/9/2003, David Abrahams wrote: >As a user of the filesystem library, I am having the experience that >obvious things are hard to find, and the docs are much harder to >understand than they ought to be. The use of creative naming really >gets in the way. For example, the term "complete" is never defined >anywhere. It is defined by the is_compler() returns clause. > The closest we come is in the following naming rationale. > >is_complete > >bool is_complete() const; > >Returns: For single-root operating systems, >has_root_directory(). For multi-root operating systems, >has_root_directory() && has_root_name(). > >Naming rationale: The alternate name, is_absolute(), causes >confusion and controversy because on multi-root operating systems >some people believe root_name() should participate in >is_absolute(), and some don't. > >I'm sorry if this sounds harsh, but I think the cure for someone being >confused about the term "absolute" on multi-root OSes is to pick the >definition that allows the term to be meaningful (an absolute path >identifies a specific location, and so must include the root) and *add >a clarifying note or definition for the corner case*, not to pick some >new term which nobody knows about and makes the library hard to >approach. The library isn't all that large that people can't just read about each function. There were lengthy discussions on the list of this and other naming issues during development, during review, and during the resolution of review issues. Many people had fairly strong views. IIRC, the idea that is_absolute( "/foo" ) was false on some operating systems was impeded by long-held beliefs. By giving the function an unfamiliar name, people are forced to actually read the specs instead of just assuming what it does, and that ends up being a good thing, IMO. I suppose if we were to discuss the names all over again we would come up with a different set of names. But unless the new names are markedly superior to the old names, it would just be churn to change them, and might be a real step backwards. >--- aside --- >Regarding complete paths, is there any guarantee that they are >canonical? Is foo/bar/../baz reduced to foo/baz? Yes. That is documented as a postcondition specifying canonical form for all the functions that modify a path. I've just double checked, and it doesn't look like any were missed, but let me know if you spot any way to alter path state that doesn't supply that postcondition. > See >http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#getCanonicalPath() >for an example of the possible semantics. We could learn a lot about >what's useful and broadly implementable by studying the libraries of >Java and/or Python (yes, I realize that the portability of Java ain't >quite what it's cracked up to be). Yes, I often found other libraries helpful, although many of them offer syntactic portability rather than semantic portability. The legacy operating system API's interesting because they sometimes take different approaches. Sometimes what we think of as a path is just a key used to find the actual path via some external mapping mechanism. >--- aside --- > >The formal description of some of the function semantics leaves >something to be desired. For example, the docs for remove_all say: > >unsigned long remove_all( const path & ph ); > >Precondition: !ph.empty() >Postcondition: !exists( ph ) >Returns: The number of files and directories removed. >Throws: if ph.empty(). See empty path rationale. > >So, what does this do? At first I thought it removed all the >directories along the branch described by ph. I think I'm now >inferring that if ph is a file, it is the same as remove( ph ) and >otherwise it removes all of the files and subdirectories in ph and >then removes ph. A plain English description would help a lot here. >This applies to many other functions in the library also. Yes, a general prose description for each library would help. >I also have some doubts about the validity of the postcondition, since >another process can come along and create ph again before remove_all >returns. This applies to many other functions in the library also. The docs really weren't clear enough about postcondition/race-condition interactions. I've just added a paragraph to boost-root/libs/filesystem/doc/index.htm#Common_Specifications to make it clear that postcoditions don't hold if race-conditions exist. Because of the race-condition problem, the original docs did not specify postconditions. Someone pointed out how much clearer they because if postconditions were used, and the docs got converted at that point. >The difference between is_empty(ph) and ph.empty() is too slight, IMO, >for their differing semantics. IMO it's not useful to have one >function which reports both empty files and empty directories - the >implications of the two are much too different. Early v
Re: [boost] Re: Re: Re: the boost::signal sample crashes
--- Bohdan <[EMAIL PROTECTED]> wrote: > > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Well, how can I use boost::threads with my toy > > operating system? > > If you are writing application for your toy OS, you > should : > 1. Edit boost::thread implementation to > work for your OS. > 2. Edit build system to produce > boost::thread > library for your OS. > 3. Link your toy OS applications with THIS > library . > > Idea is simple : you are writing application for ONE > OS (toy or serious) hence you don't need > boost::thread > implementation for more than ONE OS in ONE > application. > IMO, it is true for GUI library :) > What is exactly wrong with my solution that doesn't have the ONE OS limitations, doesn't have any compilation time problems and supports my toy OS (or any other OS) directly (w/o editing the boost::thread implementation)? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Files of types *.ipp are unfriendly, especially to MSVC ?
"Paul A. Bristow" <[EMAIL PROTECTED]> writes: > OK, I'm persuaded. > > Yet another thing one needs to know and my brain is already full :-( > > Since I couldn't find how to make the editor work with .ipp files from the MS > documentation, but it ws kindly provided by a diligent Booster, can you suggest > where this info shold be stored? I dunno. Wiki? > PS Do files of type .ipp get checked for nasties like tabs, dud newlines? I dunno. You can check the "scripts" as well as I can. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Files of types *.ipp are OK even for MSVC ?
RTFM again :-(( Except that even knowing that answer, I couldn't get the help system to help. But Thanks Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Victor A. Wagner, Jr. | Sent: Saturday, August 09, 2003 8:38 PM | To: Boost mailing list | Subject: Re: [boost] Files of types *.ipp are unfriendly, especially to | MSVC ? | | | in vs.net 2003 you can menu->tools->options->projects->VC++Build | add *.ipp to the list | things then hilight, etc, just fine ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |>1) Since only 1 object can be passed to the iterator adaptor |>constructor, I |>had to pass a pair. | | | Use object generators. | | |>2) Distance uses only one of the base iterators. | | | Use minimal distance. Different distances are most certainly a precondition violation. AFAIAC assert on differing distances. | | |>3) iterator_category uses only 1 of the iterators. | | Use most restrictive category. In general don't use the old iterator_adaptor unless you really have to. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MWiy0ds/gS3XsBoRAg/mAKCFxhPTSwxfrqQloTThZN9HfNjt0gCgkgKB 32RUc1R4EOJzUgw4dmlRgoE= =gADX -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration bug in Boost 1.30.0
In that case, you might prefer to mail me off-list a zip of your most recent version. This might help you get a MSVC 7.1 strictly tested version ready for 1.31.0 Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | Sent: Saturday, August 09, 2003 10:59 PM | To: Boost mailing list | Subject: RE: [boost] Re: time_duration bug in Boost 1.30.0 | | | On Sat, 9 Aug 2003 20:00:08 +0100, Paul A. Bristow wrote | > I suggest that I wait for the 30.1 release to be available, retest | > with strict mode and then mail you off-list with results from .net | > 2003 aka 7.1. | | Do you mean 1.31.0 or 1.30.2? The changes I'm speaking of are not | in 1.30.2. I expect it will be awhile before 1.31.0. | | Jeff | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Hi, I read today all this thread because this subject is very interesting. I know I am coming very late so I don't want to re-ignite the discussion again Just to put a word I have some doubts about the TraitsImpl approach, as opposed to the pImpl approach. On one side the use of template can give you more flexibility. On an other side less. IMO it will depend on what you what to do with them. The use of templates is a very good tool for create flexible components, building blocks of a program, and integrating them in your program. But to put all of them(components) together in the form of some template of template of ... of template... that I think it will be too much and you'll end up by loosing flexibility and giving to the final users a big headache. Similarly, because you are working for Boost you are going to probably set a programming paradigm for the GUI programming in C++ as the STL has successfully become for data structures and other algorithms. Even MFC has somehow done that. And you know with what results. At the beginning it was seeming to be a good framework. But now, at least by experience, we know that it is better not to use it unless for creating very 'standard' programs. In other words, the choice of putting everything in terms of TraitsImpl and of always avoiding the pImpl approach risks to force people to do GUI programming in a way that is going to give people more trouble than it is worth it. Perhaps this can be decided only after you'll make your efforts in your new project. For me the whole template thing boils down to this: template are great for compile time components. I.e. I have a list that I *know* at compile is going to be a list of double. It will not change dynamically into a list of std::string at runtime. However, much of UI programming/frameworks is about dynamic changes at *runtime* NOT compile time. That's why I am more convinced of the pImpl approach Also, IMHO, I would keep in mind that programmers successfully use the templates only after some experience with a more common programming. I wouldn't start to set up a standard keeping an eye only to 'real' programmers and scare all the others away. Which are the vast majority. I felt I had to express my opinion even if I come very late in the discussion Maybe it will help. About the boos_gui and boos_gui_test projects, they do not link under vc6 sp5 ( And if I use STLport the not even link, not with vc7.0 either ) It would have been useful to have them working in order to better understand your concepts. Best Regards, Marcello "E. Gladyshev" wrote: > --- Douglas Gregor <[EMAIL PROTECTED]> wrote: > > > template < typename IT, typename PhysicalGuiLayer > > > > > > class ListControl > > I came with a name for this idiom, ImplTraits idiom. > > template <... typename ImplTraits > > class someclass > > It is like the name of the pImpl idiom. > > Eugene ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Filesystem: naming, canonical path
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [...] > As a user of the filesystem library, I am having the experience that > obvious things are hard to find, and the docs are much harder to > understand than they ought to be. > [...] Just out of curiosity, is the filesystem library being used to create a new build or regression test system, like it was originally designed to do? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI sublanguage ?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Philippe A. Bouchard > Sent: Thursday, August 07, 2003 4:04 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: GUI sublanguage ? > > [EMAIL PROTECTED] wrote: > > [...] > > > After having followed this thread I wander if we are trying to > > reinvent > > the wheel. By googling a bit one can find plenty of "Gui Toolkits" and > > here I saw little of them. Not a word on Qt, for example. I never > > used it for an important project but they give a (good ?) solution for > > example to the layout issues discussed so far. > > If I should criticize them (as a lazy user who is in troble finding > > his way among all those features) if the fact that there are huge > > classes that probably need further decomposition of resposibilities. > > > > Anyway Qt make life simple for simple apps and provides something > > that scales quite well for larger projects (I haven't used it but > > I can use KDE as witness). > > > > So I would like to have a clearer idea of the difference between > > the goal of this thread and existing solutions (i.e. Qt). > > At some degree it becomes political issues. I doubt Boost would want to > take the same risky path I took (Corel). > Qt is a commercial library for one thing. For another, developing a platform independent GUI environment is only half of our purpose. The other is to leverage modern C++ techniques to simplify making GUIs. A quick glance at Qt's class hierarchy should be enough to see that they are not using such a design: http://www.trolltech.com/images/classchart.gif. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [MPL] Metafunction classes
"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> [...]
>> Don't pass metafunctions directly; it's bad for interoperability.
>> Then you get a metafunction taking a template template
>> parameter, and you can't use it in lambda expressions.
>
> Hmm...ok, I'm not getting anywhere talking about it abstractly, so
> I'll just say that I'm trying to figure out how to improve the policy
> adaptor interface for smart_ptr. In particular, I would like to go
> from this:
>
> smart_ptr, my_other_policy<_> > p;
>
> to this:
>
> smart_ptr p;
>
> I know I can do this by changing my_*policy to a metafunction
> class.
Yes, and I'm trying to say, "don't do it by switching to template
template parameters".
> But then smart_ptr doesn't know where the guts are.
Huh? What guts? Precise speaking, please!
Aren't they in the nested apply<>?
> Aleksey gave me the impression that I could mix and match, since the
> policy adaptor uses lambda to deal with the policies. But when I
> tried to do that
What, specifically, did you try?
> I found out the rude way that the policy client (smart_ptr) could no
> longer find the stuff in the nested apply<> template, because it
> assumed the policy contained all the stuff.
This is way too vague for me to say anything useful.
> Now that I think about it, things would "just work" if I declared
> the policies this way:
>
>
^--something's missing here
> class smart_ptr
> {
> public:
> typedef OwnershipPolicy::apply ownership_policy;
> typedef StoragePolicy::apply storage_policy;
> // ...
> };
>
> But then, that doesn't work for policies which are *not*
> metafunction classes. I have a feeling the policy adaptor
> needs to detect whether the policy is a metafunction class
> or a lambda expression,
No; just transform everything into a metafunction class using lambda,
and you're done.
> but I don't really know what I'm talking about at this point.
Me neither ;->
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration bug in Boost 1.30.0
On Sat, 9 Aug 2003 20:00:08 +0100, Paul A. Bristow wrote > I suggest that I wait for the 30.1 release to be available, retest > with strict mode and then mail you off-list with results from .net > 2003 aka 7.1. Do you mean 1.31.0 or 1.30.2? The changes I'm speaking of are not in 1.30.2. I expect it will be awhile before 1.31.0. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] bug in incremental_components examples /documentation
Thanks Janusz. I've checked in the fixes. On Saturday, August 9, 2003, at 12:27 PM, Janusz Piwowarski wrote: Hi all I've found bug in incremental_components examples and documentation. Type _Rank_ is expected to be size_type, but container _rank_ is created from vertex_descriptor. Examples work because adjacency_list VertexList container type is vector. // ... typedef adjacency_list Graph; typedef Graph::vertex_descriptor Vertex; // ... // create the disjoint-sets structure, which requires // rank and parent vertex properties std::vector rank(num_vertices(G)); //^^ std::vector parent(num_vertices(G)); typedef std::vector::iterator Rank; // typedef std::vector::iterator Parent; disjoint_sets ds(rank.begin(), parent.begin()); //... Regards, Janusz ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |>-BEGIN PGP SIGNED MESSAGE- |>Hash: SHA1 |> |>Rozental, Gennadiy wrote: |> |>| What is the problem adapting pair of iterators to scalar vectors to |>produce |>| an iterator with complex value type? |> |>The problem is you can hardly adapt a pair. So using |>iterator_adaptor (the new class template) does not provide |>any benefit. | | | Why is that? The whole point in adapting is that you modify some but not all behaviour/interface of a thing. Ther is nothing a pair provides that can be reused so adaption is pointless. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. | I did not look in depth on new version but I remember that old | one allowed to adapt any source. You needed to do this as the iterator interface implementation was not seperated from the actual iterator_adaption. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MVHC0ds/gS3XsBoRAsJLAJ4gb8KM3GJGi3wYM65ppMSfasuXtACghiD3 dGgVfgSioFYgEm0ihB0r9zY= =wm0V -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Gcc problem in variant library
Eric Friedman wrote: > > > The variant library developers were checking in changes > almost daily > > > until a week or two ago, so you might want to make sure > you have the > > > latest from CVS. > > > > Thanks for your response. > > Yes, I have the latest CVS (Boost::HEAD) snapshot. BTW this error > > shows up for the variant tests too. > > > > > They haven't been active since then, however, so may be > on vacation > > > or otherwise busy. > > > > Ok, I'll wait a bit and retry it later. > > I believe the problem should now be fixed. Let me know if it > still doesn't work. I've checked a new CVS snapshot just right now, but the problem persists. Sorry. cd $(BOOST_ROOT)/libs/variant/test gcc -I$(BOOST_ROOT) test1.cpp In file included from D:/cvs/boost/boost/variant/variant.hpp:25, from D:/cvs/boost/boost/variant.hpp:22, from test1.cpp:18: D:/cvs/boost/boost/variant/detail/forced_return.hpp:57: default argument specified in explicit specialization Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: switch-based runtime type selection (for variant)
Brian,
Brian Simpson wrote:
> A fundamental problem encountered by boost::variant is that of invoking an
> overloaded function for the correct type, where the type is not known
until
> runtime. As near as I can tell, all proposed solutions to this problem
have
> involved uncomfortable space or time tradeoffs. I have read several posts
> which asked why we couldn't use a switch statement--it would avoid the
> expenses of the current solutions without incurring any of its own.
> Until recently, I agreed with those (whose expertise I highly respect) who
> said it was not possible.
I don't think anyone ever said it wasn't possible. It was just whether it
would actually improve anything -- i.e., it was unclear whether compilers
would optimize recursively-inlined switch statements better than
recursively-inlined if statements.
> However, while perusing the source for the current implementation of
> boost::variant, a possible solution occurred to me.
> I have spent some time fleshing out the proposed solution, and it seems to
> be all standard C++ (no non-standard). I think it might be referred to as
> "sequence unrolling".
> Here's how it works:
[snip]
>
> Questions or comments?
Sorry, I've just gotten back from vacation. I haven't spent *too* much time
looking through your code, but I can't see how it improves on my current
code, which features sequence unrolling. If you could explain to me I'd
appreciate it.
> p.s. I must acknowledge Itay's and Eric's efforts in the current
> implementation of boost::variant. I've learned a lot just from studying
the
> code.
Thanks! It's nice to know our efforts are being recognized :)
> It was while I was browsing the recently added implementation of
> switched type selection based on the variadic template parameters that
this
> idea occurred to me.
Wait, hold on a second. The current implementation isn't tied to any
particular "unrolling constant." The current visitation mechanism after
preprocessing should like like this (see function template
apply_visitor_impl):
typedef typename step0::type T0;
typedef typename step0::next step1;
typedef typename step1::type T1;
typedef typename step1::next step2;
// ...and so on until unrolling constant...
switch (var_which)
{
case (Which::value + (0)):
return apply_visitor_impl(visitor, storage, static_cast(0),
1L);
case (Which::value + (1)):
return apply_visitor_impl(visitor, storage, static_cast(0),
1L);
// ...and so on until unrolling constant...
}
// ...else continue unrolling next "chunk" of types (by recursively
calling the above w/ stepN)...
Thus, if we are to assume O(1) complexity for a switch, then the complexity
of the visitation mechanism becomes O( N / unrolling-size ), where
unrolling-size is exposed as BOOST_VARIANT_APPLY_VISITOR_UNROLLING_LIMIT. I
think this is as good as it gets.
Let me know if your implementation is achieving a better result.
Thanks,
Eric
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > --- Brock Peabody <[EMAIL PROTECTED]> > > > > We can get a simple sub-language running on top of > > those few controls > > quickly enough. > > I agree. I was thinking about setting up a sourcesafe > project. What do you think about the name, boost::SGTL > (Standrad GUI Template Library)? > 1. Boost isn't standart but near :) 2. Finally your lib may become non-template ( i mean cpp files) ... What about simple boost::gui ? regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of E. Gladyshev > Sent: Wednesday, August 06, 2003 3:42 PM > To: Boost mailing list > Subject: RE: [boost] GUI/GDI template library > > > --- Brock Peabody <[EMAIL PROTECTED]> > wrote: > > I think now we need to decide which > > *nix GUI API to use > > and get started on a proof of concept. > > I am currently working with win32 only. I can take > care of this one. I think it'll be nice to have > support for X as well. > > > Maybe we should decide which elements of the layer 1 > > API to implement > > first. What do you think about: window, button, > > edit, and static_text? > > We can get a simple sub-language running on top of > > those few controls > > quickly enough. > > I think it'll be nice to include a container like > control like list/tree control to demonstrate how they > could be linked to STL iterators. Agreed. I vote for the list control then, I think it's a little more straightforward. > > I was thinking about starting to work on on the layer > 2 design first. The idea is to design the layer 2 the > way we'd like it to be first. It'll provide a set of > natural requirements for layer 1. Agreed. I think the layer 2 interface is where we're going to need the most feedback from other boosters too. > Using these > requirement, we'll try to design the layer 1 > traits/polices. Then we review it and decide whether > it could be implemented on win32/X platform. If it > doesn't work, we'll revisit the layer 2 design again > and correct the layer 1 requirements. I'd suggest a > recursive design procedure. :) Agreed. > > I think we'll have to establish some basic > design/implemntation polices/idioms. > 1. For instance how we handle memory allocations, are > we going to use std::allocator idiom or just > new/delete. > 2. Is the library thread-safe or not. > 3. Event handling polices (send/post, etc.). I think we're going to have to allow the users to specify traits at layer 2 at least. You could specify things like allocators and and default behaviours. Maybe we could even use some sort of named template parameter mechanism since there are so many different things that can be specified. I don't think we need to worry about traits in the first cycle or two of our recursive (I thought they called it iterative?) design though. (2) I'd say the library should be no less thread safe than the underlying API. Some APIs may be inherently thread-unsafe (MFC for instance). (3) Use function objects ala boost::function<>? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
