August 2004 - Boost - lists.preview.boost.org

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

boost::filesystem with network paths on windows
by Arne.Adams＠t-online.de 25 Aug '04

25 Aug '04

Hi, I am trying to use boost filesystem to copy files from a local directory to a directory on a network server (the latter having a path like \\databaseserver\c$\importfiles\myTabledump.txt <file:///\\databaseserver\c$\importfiles\myTabledump.txt> ) Unfortunately the leading double backslashs (\\) get converted in the constructor of filesystem::path to double slashs - yielding a different meaning. Is there a way to copy files on windows to network servers like this? Regards, Arne Adams Nerotal 23 65193 Wiesbaden Tel.: (+49) 611 3413745 Mobil: 0172 6147473 Mail: inbox(a)arneadams.com

3 2

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 25 Aug '04

25 Aug '04

Hi, I will be shorter, as I answered some pointes before. > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick > > [Bennett, Patrick] Yes, you could pass UTF-8 through as-is in > Linux. If your application was running in Japan on Windows, > boost::filesystem would not work at all. So, yes, you can > pass all sorts of extended characters to Windows in an 8-byte > string (the majority of which aren't really valid for > filenames), but that does nothing for Unicode support. > It simply won't work. For Unicode support the application > must call the xxxxxW versions of the windows API's and pass > in a UCS-2 string. I will run as long as you use ASCII and Japanese characters from an ANSI codepage, for example from SJIS only. Yes the application will not be capable of the full Unicode support as ANSI-C and STL is not. See my last e-mail for some discussion. > > What you can't do is use the same encoding on all platforms, because > the > > underlying platform API's won't understand them. > > [Bennett, Patrick] Correct, this was my whole point. If I > can't write a portable (to at least Linux and Windows), > internationalizable application with boost::filesystem then > it's of no use to (at least) me. :-) Workarounds are being build all the time in multiplatform applications. You have to workaround ANSI-C for that. STL too. It is a question if to workaround boost::filesystem as well, if Windows (only?) provide Unicode methods. > This is why I suggested that UTF-8 be used as > boost::filesystem's encoding. It can be passed through as-is > or converted as needed on each platform and it would be > backwards compatible with existing boost::filesystem code. It will not be compatible. It is not the way to force UTF-8, breaking the current local encoding only support. Moreover, it would force all people to recode to UTF-8 even if they would not need. That is why std::streams use imbuing - no reader is forced to accept UTF-8 only. See my last e-mail. Note: here I put together filenames with file content, with filenames it is not so painful, but though... > 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 do not agree with you suggestion because it breaks the compatibility with the current interface and would force me to recode into UTF-8. I sketched a solution for the interface, which is non-intrusive to the current interface and the underlying implementation can use XxxW for Unicode input. However, I still think it is a cannon for a sparrow... What do the others think about this extension: * provide methods for std::wstring and wchar_t (or generalize them for basic_string<T>) * implement the <wchar_t> methods to support Unicode by imbuing * provide the most common imbuing objects in boost::filesystem (at least the null one - see 1) 1) unicode <-> local: wcstombcs and mbcstowcs to support the current locale functionality (imbue local) 2) unicode <-> unicode: UTF-8 conversion from boost::xxx to support UTF-8 encoding on UN*Xes and _wxxx or XxxW on Windows to support Unicode on Windows (imbue unicode) 3) using externally implemented codecvt-like objects (using ICU, libiconv, Win32...) can be achieved any conversion from the applications model into filesystem codepage Ferda > Cheers... > Patrick Bennett

1 0

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

25 Aug '04

Edward Diener wrote: >Why not use boost::signals for your event interface. It is much better than >hand-coded actions and listeners, since any type of function can handle an >event. The technology is already in Boost so why re-invent the wheel. The signals library looks very good, but it solves half the problem. You need to work out what types of signals are raised: MouseUp MouseDown MouseDoubleClick MouseMove and have a signal for each. This would mean that you could have hundreds of signals! It might be easier to group events by type, use signals to dispatch them and an event handler like I suggested to deal with them, e.g. MouseEvent( unsigned int event, const MouseEvent & info ); KeyEvent( unsigned int event, const KeyEvent & info ); This might be useful for command/reflection type events, having a std::list< boost::signal< bool ( const Event & ) > > or even std::map< std::string, boost::signal< ... > > Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 14