- Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Support Requests-1012276 ] test framework does not compile on cygwin
by SourceForge.net 19 Aug '04

19 Aug '04

Support Requests item #1012276, was opened at 2004-08-19 08:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1012276&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test framework does not compile on cygwin Initial Comment: Hello, My e-mail address is : javier.revilla(a)free.fr I am trying to compile Boost on CygWin with gcc 3.3.3. My machine is a Windows 2000 PC. To install Boost I do : bjam "-sTOOLS=gcc" install I cannot compile the Test Framework. I obtain the following error report : gcc-Link-action bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll chmod 755 "bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll" ...failed Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll.. . ...skipped <@boost! lib>libboost_prg_exec_monitor-gcc-d-1_31.dll for lack of <@boost!libs!test!build/libboost_prg_exec_monitor. dll/gcc/debug>libboost_prg_exec_monitor-gcc-d-1_31.dll. .. etc... What should I do ? Thank you very much for your help. Javier Revilla ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1012276&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

regex bit
by Yitzhak Sapir 19 Aug '04

19 Aug '04

Going on past my previous ETI problems thanks to Dave Abrahams' fix, I now had a problem in regex. In boost/regex/v4/regex_match.hpp, line 149+, we have: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator, wregex::allocator_type>& m, const wregex& e, match_flag_type flags = match_default) This should be: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator>& m, const wregex& e, match_flag_type flags = match_default) Otherwise passing a wsmatch to regex_match fails.

2 1

RE: [boost] Re: [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 19 Aug '04

19 Aug '04

> What about > > const_string const LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > That would work too. Is that ok for you? If yes, the File scope const declaration automatically assumes static anyway if I am not mistaken. Update from cvs and let me know how did it work. Gennadiy.

2 1

[signals] trackable object limitations
by Jeff Flinn 19 Aug '04

19 Aug '04

Any changes in 1.32 pertaining to: Warning: User-defined function objects and function objects from other libraries (e.g., Boost.Function or Boost.Lambda) do not implement the required interfaces for trackable object detection, and will silently ignore any bound trackable objects. Future versions of the Boost libraries will address this limitation. Thanks, Jeff

2 1

typeof and ODR
by Arkadiy Vertleyb 19 Aug '04

19 Aug '04

David Abrahams wrote: >We should try this stuff [typeof] out with EDG-based compilers in their >"template repository" link-time-instantiation mode. Also I think >Metrowerks now supports the same thing. These are the most likely >configurations to report problems from ODR violations. Can anybody help me with this? (I do realize that it's not a good timing now, but I just want to see if I can count on it once things get quieter) Thanks in advance, Arkadiy

1 0

test_read_write_mutex trouble under Tru64 Unix
by Ralf W. Grosse-Kunstleve 19 Aug '04

19 Aug '04

Last night I started Aleksey's regression.py script under Tru64 Unix. It used to finish after 6 hours, but now the test_read_write_mutex process has consumed 16 CPU hours already without finishing. I am going to kill it. I hope the failure shows up at the meta-comm site. Let me know if more information is required. Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

3 3

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

19 Aug '04

John Torjo wrote: >Hi Reece, > >Just a few thoughts: > >>I am currently designing a GUI framework in C++ (initially targeting the >>Windows platform) that uses a model similar to that which Java uses in > >Take a deep breath if you want to make it cross-platform ;) >I think that's Windows work x 10 or so. Maybe more ;) ... I was thinking about having a compatibility layer, e.g.: namespace windows { class window { public: inline handle_type create( const string_type title, ... ); inline void set_size( long, long ); // ... }; } namespace linux{ class window{ ... }; } Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction. >>it's AWT and Swing libraries. Specifically: >> >>[1] Being able to use constructors to create the windows/components. This >>means there is no need to explicitly call a Create method like in the MFC >>framework. > >win32gui does that ;) :) I am having a look at all the links to the various libraries, so it may take a while to process them all. (Thanks for everyone who compiled the links). >>[2] The use of layout managers. I like the various layout managers in Java >>and how easy it is to construct complex GUI interfaces. > >I like the idea of layout managers. Still, it seems (to me) in real-life >they kind of fail. You'll always want that special case where you need to >hide control X and show control Y, etc. So why not have that ability in the framework? That is the reason I posted this, to get ideas. It should not be that difficult to be able to change the layouts at run-time... once the layout managers have been written, that is. >So far, I've created splitters on dialogs at design time (still beta ;)). >If you use them correctly, you can specify a lot ot design time. Also, you >can easily hide/show the left/right panes. cool. >>[3] The support for events via "listeners". This will most likely be >>geared towards key/mouse events and "action" events (e.g. when the user >>presses on a button). > >I'm not a big fan of listeners. You need to do a lot of coding manually to >set them, etc. I've implemented them totally different - using event >handler classes. My idea was something along the lines of: class MouseEvent { public: static const int LeftButton = 0; static const int MiddleButton = 1; static const int RightButton = 2; private: int button; unsigned int vkeys; win::api::point pt; public: inline MouseEvent( int, WPARAM, LPARAM ); }; MouseEvent::MouseEvent( int btn, WPARAM wp, LPARAM lp ): button( btn ), vkey( wp ), pt( lp ) { } class MouseListener { public: virtual void mouseMove( const MouseEvent & ); virtual void mouseButtonDown( const MouseEvent & ); virtual void mouseButtonUp( const MouseEvent & ); virtual void mouseButtonDoubleClick( const MouseEvent & ); public: virtual ~MouseButtonListener(); }; With a common listener interface for GUI object actions, e.g. pressing a mouse button, selecting an item in a listbox, editing text, etc. >>At the moment, I have a basic working version that allows you to write the >>following: >> >>int PASCAL WinMain( HINSTANCE, HINSTANCE, LPSTR, int sw ) >>{ >> swing::JFrame frame( L"Swing JFrame!" ); >> frame.setPane( new swing::JPanel()); >> frame.setSize( 500, 500 ); >> frame.show( sw ); >> >> MessageLoop msg; >> return( msg.Execute()); >>} > >can you break the message loop? >That is, specify when a message loop should end (when a certain signal is >received). You can call ::PostQuitMessage( 0 ), but that is Windows specific. At the moment the message loop doesn't do anything fancy (accelerator/dialog box message processing), but it is on the list of things to work on. >>This creates two windows: the main frame and a panel that is a child of >>that frame. The JFrame is created in the constructor, but is not displayed >>until show is called. Likewise, the JPanel is created inside its >>constructor and the JFrame.setPane method makes that window a child of the >>frame. >> >>I would appreciate comments and ideas as to what people would like out of >>a GUI framework, especially one that will be multi-platform. > >I'm all for it, but again, I think it's so much work... But it will be fun! :D Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 4

[Boost-bugs] [ boost-Bugs-1012135 ] boost::filesystem is systematically broken
by SourceForge.net 19 Aug '04

19 Aug '04

Bugs item #1012135, was opened at 2004-08-19 14:01 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=1012135&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem is systematically broken Initial Comment: As is currently discussed on the boost mailinglist, cygwin is supposed to support windows paths (at least, when compiled with BOOST_WINDOWS, which is currently the default). I understand that Beman, the author of boost::filesystem, wants it that way. However, boost::filesystem does not accept a path like "/usr" (fs::exists fails in that case), when compiled with BOOST_WINDOWS and it *also* doesn't accept windows paths, like "c:/cygwin/usr", "C:\cygwin\usr" or anything remotely 'windows' like, because it throws when you try to construct a fs::path with a colon in it! As a result, one can ONLY construct usable paths on cygwin in the very non-portable format "/cggdrive/c/cygwin/usr" which is neither POSIX (on linux the same path would be "/usr") nor native (the _users_ of the application will view this path as "C:\cygwin\usr"). It is 100% cygwin specific. OR one has to construct paths on cygwin using 'native' all the time (or no_check) as path checker, because even windows_name doesn't work :/ Consider the following code: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { try { boost::filesystem::path p("C:\cygwin\usr", &boost::filesystem::windows_name); } catch(std::exception const& error) { std::cerr << "Exception: " << error.what() << std::endl; } } With the following result: Exception: boost::filesystem::path: invalid name "C:\cygwin\usr" in path: "C:\cygwin\usr" Same thing with any other variation that starts with 'C:'. I believe that this is a structural failure of boost::filesystem, revealing a major error in the design. A re-design seems to be in order before it can be considered to be usable in multi-platform applications. The most important problem with the current design is that a single type (namely fs::path) is being used for effectively two different types: canonical paths and native paths. A new design should provide a new type, fs::native_path that cannot be mixed with the canonical path representation. This native_path should have builtin checks that are native and fs::path should only check for portability (and allow relaxation of that when lesser OS need to be supported). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1012135&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Java style GUI in C++
by Johannes Brunen 19 Aug '04

19 Aug '04

Hi, 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. I would like to emphazise this. I use the boost signal library for handling the tree view control and list view control events in an extension of the Zinc gui library. It works pretty well. Johannes

1 0

Re: Re: Java style GUI in C++
by Johannes Brunen 19 Aug '04

19 Aug '04

Hi, Pavel Vozenilek wrote: > To stop it: ultimate list of all (dozens) known GUI frameworks > is on http://www.free-soft.org/guitool/. I'm well aware of the link. But it is not up to date. For instance http://www.torjo.com/win32gui/ and http://notus.sourceforge.net/ aren't mentioned at all. http://gtkmm.sourceforge.net/ valuation is not correct with respect to the win32 platform. For some time I'm searching for the ultimate GUI framework. I didn't know of TnFox, Notus and Ultimate++. So I learned something from the contributions. Johannes

1 0