- Boost - lists.boost.org

Re: [boost] [1.32 Plan] Stalled forever?
by Robert Ramey 26 Aug '04

26 Aug '04

Aleksey Gurtovoy wrote: >JOAQUIN LOPEZ MU?Z writes: >> I don't want to sound harsh or anything, and I truly appreciate the >> effort that's being put in this, but a month has slipped by since the >> first schedule for releasing, and AFAIK we don't even have an agreed >> upon branching date for the near future. >The branching date is pending MPL check-in. The latter has been postponed >several times as the new issues surfaced (in particular, due to better >tests), but it's crucial to ensure that the library is in the predictable >state before the release (remember that it goes on the CD with the TMP >book), so please bear with us. The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved. > There are external constraints for this release's timeframe, > but within those, the release is criteria-driven. One of the > criteria is regression-free codebase, This is criteria for release - not for branching > and another is the new > MPL version. There is no point of releasing "on time" if the > release is useless. Nothing in the current development tree - i.e. the 1.32 release candidate depends on the MPL update that has yet to be integrated. There is no reason to hold up branch/release for new features. > > Shouldn't we settle now on a realistic branching date > and proceed with the release? Or, should I shut my mouth > and let the release manager handle this as he deems > convenient? > > Again, don't get me wrong. I am not willing to push > anybody, but the process looks, well, erratic. > Please don't forget that we are all volunteers here. The best > way to speed up things is to contribute to them. MPL issues > notwithstanding, we still have the regression field to be > cleared -- > http://www.meta-comm.com/engineering/boost-> regression/developer/summary.html. > Turning it green while MPL is in works will make a huge difference. The only way an MPL update can be expected to not create new issues is it makes only small changes. If that's the case its not worth holding things up for. If the changes are not small, it likely will create a slew of new issues. >> If you are willing to take over managing that one >> until the MPL check-in, be my guest. I wish we could all do as well as Joaquin has been doing in clearing issues related to his library. He has been doing an excellent job. When this topic was discussed at the beginning of the release process, it was indicated that subsequent releases would already be scheduled and would be soon after 1.32 . This was to assure developers that if they missed this release, it wouldn't be a big issue as the next one would be soon anyway. This is still a good idea and should be implemented. So Branch now Release branch available only for bug fixes and test clearing Main branch new MPL and what ever else. Robert Ramey

2 1

[filesystem] Status of issues
by Beman Dawes 26 Aug '04

26 Aug '04

For reasons unrelated to Boost, I've been sidelined from most work on filesystem issues since late March and am just now starting to catch up. It will take awhile just to read backed up email. Thanks to John Maddock, Dave Abrahams, and Vladimir Prus for resolving several issues when I wasn't available. As far as the 1.32.0 release goes, I'll try to give priority to bug fixes. But there probably won't be a lot of change compared to the current CVS state, since the library is pretty stable (and has a number on nice fixes and tweaks compared to 1.31.0.) --Beman

5 4

RE: [boost] Re: Java style GUI in C++
by Reece Dunn 26 Aug '04

26 Aug '04

Ralf W. Grosse-Kunstleve wrote: >--- Reece Dunn <msclrhd(a)hotmail.com> wrote: > > Thus, in Java Swing-style C++, you can do something like: > > > > boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); > > frame -> set_pane( new boost::gui::button( "PUSH" )); > > frame -> set_size( 500, 400 ); > > frame -> show(); > > > > boost::gui::message_loop msg; > > return msg.execute(); > >How does main get deallocated here? Oops :) >I am very surprised to see "new" and raw pointers in a library designed >from >scratch. Manual lifetime management is going to lead to a lot of clutter, >memory leaks, and is incompatible with exception handling. A system based >on >smart pointers like boost::shared_ptr and reference-counted container types >is >essential IMO. The library currently uses reference counted types to manage allocated types. I understand the use of smart pointers and agree that it is essential. I was just using this example as a guideline. Regsrds, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] Re: Java style GUI in C++
by Reece Dunn 26 Aug '04

26 Aug '04

Miro Jurisic wrote: >I also believe this community is capable of producing such a framework, but >I >think that it's telling that the title of this thread is "Java style GUI in >C++"; a Java style GUI typically implies making user experience sacrifices >on >every platform, and therefore I believe that a "Java style GUI in C++" is >likely >to be driven by misguided goals. What I meant by "Java style GUI" is not in terms of L&F, but in terms of programming the framework. I understand how important having a native L&F is to the particular OS you are using (implemented using OS components for native feel): this is one of the goals I am aiming for. Thus, in Java Swing-style C++, you can do something like: boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show(); boost::gui::message_loop msg; return msg.execute(); And this will work, creating a window with a button in it's "client" area. That is, allow the user to: [1] create components/widgets using constructors instead of Create functions (like MFC); [2] allow "native" components (buttons, etc.) and windowless components (for performance); [3] provide a set of "layout managers" that are windowless components allowing you to specify scrolling panes, splitter panes, grid layouts, flow layouts, fixed/stretchy layouts and so on -- I personally find using layout managers easy to produce interfaces rapidly; [4] avoid message maps if possible -- I personally don't like message maps and feel there is a better way to implement event handling. From the discussions here boost::signal seems to be the way to go, but some effort needs to be taken to produce a flexible, portable way of handling messages that can both write generic handlers and OS-specific handlers; That is what I mean by a Java-style C++ GUI framework. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

7 8

more fixes in como-vc71
by Bronek Kozicki 26 Aug '04

26 Aug '04

I have received two more fixes from Comeau for libcomo 31, run on como 4.3.3, backend MSVC71: - better support for "long long" type - "int swprintf(wchar_t*, size_t, const wchar_t*, ...)" is available As usually, all fixes are available to everyone upon request. I believe these fixes will be incorporated into future version of libcomo, but this might require some more work (eg. make swprintf available on other backends etc.). B.

1 0

boost::add_reference breaks type deduction
by Judd Tracy 25 Aug '04

25 Aug '04

I am trying to use boost:add_reference in a template function to protect against the reference of reference problems, but it is breaking type deduction and I was wondering if any one know of a solution to this. template<typename Type> read(std::istream& stream, Type& data); This works properly of course. ----------------------------------------- template<typename Type> read (std::istream& stream, typename boost::add_reference<Type>::type data); This one does not work properly and I have to explicitly specify the type. Judd Tracy Assistant in Simulation Institute for Simulation and Training University of Central Florida

2 1

[mpl] A simple question about using lists/vectors
by Jody Hagins 25 Aug '04

25 Aug '04

I apologize in advance for this seemingly simple question, but I am having a hard time finding a simple solution in the online docs (I am in line for the MPL book, though ;-) Lets say I have some code like this... template <class A, class B> class Bar { public: Bar() { foo.template do_something<A>(); foo.template do_something<B>(); } private: Foo foo; }; Bar<Type1, Type2> bar; but I want to create a Bar with an arbitrary number of classes... Bar<boost::mpl::vector<Type1, Type2, Type3, ..., TypeN> > bar; and in the ctor, I want to call the do_something template method for each type, so that it expands to something like... Bar() { foo.template do_something<Type1>(); foo.template do_something<Type2>(); foo.template do_something<Type3>(); ... foo.template do_something<TypeN>(); } Any help would be appreciated. Thanks!

2 1

C++ Template Metaprogramming
by David Abrahams 25 Aug '04

25 Aug '04

For the past year Aleksey Gurtovoy and I have been working on a new book, titled _C++ Template Metaprogramming: Concepts, Tools and Techniques from Boost and Beyond_. The book has recently entered copyediting. If you're interested you can peruse some sample chapters at http://boost-consulting.com/mplbook. Regards, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

9 16

RE: [boost] Re: New design proposal for boost::filesystem
by Bennett, Patrick 25 Aug '04

25 Aug '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Wednesday, August 25, 2004 9:08 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: New design proposal for boost::filesystem > > "Bennett, Patrick" <Patrick.Bennett(a)inin.com> writes: > > > I'll probably not talk about this topic too much more. I think I've > > pretty much said everything I'm going to say, so if no one else agrees, > > I'll just move along. ;) > > I wouldn't take the fact that people are correcting technicalities of > your statements as an indication of universal disagreement. > [Bennett, Patrick] Fair enough. It just doesn't seem like anybody else really sees it as an issue for then, so I don't think it's worth repeatedly beating a drum when no one particularly cares to hear it. :) Cheers...

1 0

Overload resolution & boost::bind
by Arturo_Cuebas＠bpmicro.com 25 Aug '04

25 Aug '04

The program below contains a compile error. Following the program you will find the typical fix then my idea for a library that facilitates a syntactically prettier fix. #include <boost\bind.hpp> using namespace boost; struct C { void F(char, char){} void F(int, int){} void F(char, int){} void F(char){} }; int main() { C o; bind( C::F, // error: which C::F? &o, _1); } Typical solution: bind(static_cast<void (C::*)(char)>(C::F), &o, _1); And if you're a nice guy: typedef void (C::* OneCharOverload)(char); bind(static_cast<OneCharOverload>(C::F), &o, _1); Here's my idea. If we had these: template<typename TC, typename TR> TR (TC::* resolve_cast0(TR (TC::* Func)(void)))(void) { return Func; } template<typename TP, typename TC, typename TR> TR (TC::* resolve_cast1(TR (TC::* Func)(TP)))(TP) { return Func; } template<typename TP1, typename TP2, typename TC, typename TR> TR (TC::* resolve_cast2(TR (TC::* Func)(TP1, TP2)))(TP1, TP2) { return Func; } template<typename TP1, typename TP2, typename TP3, typename TC, typename TR> TR (TC::* resolve_cast3(TR (TC::* Func)(TP1, TP2, TP3))) (TP1, TP2, TP3) { return Func; } ...etc; the bind call would look like this: bind(resolve_cast1<char>(C::F), &o, _1); If I want to specify C::F(char, int): bind(resolve_cast2<char, int>(C::F), &o, _1, _2); If the struct looked like this: struct D { void F(char, char){} void F(char){} }; Things would be even nicer: If I want to specify D::F(char, char): bind( resolve_cast2(D::F), // Notice no template parameters specified. &o, _1, _2); If I want to specify D::F(char): bind(resolve_cast1(D::F), &o, _1); Benefits: - No ugly syntax due to specifying member function pointer type with static_cast. or - One less line of code due to no typedef. It would be nice to do this, but I can't find a way: If I want to specify C::F(char): bind( resolve_cast<char>(C::F), // Notice no number appended. &o, _1); If I want to call D::F(char, char): bind( resolve_cast<2>(D::F), // Notice no number appended. &o, _1); Is this worth the trouble? Has anyone seen this before? Is it possible to implement a form without a number appended? Is there a name better than resolve_cast? This was tested only in VC7.1.

10 32