September 2004 - Boost - lists.boost.org

[numeric/conversion] fixes for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 26 Sep '04

26 Sep '04

These are trivial fixes taking care of BOOST_NO_STDC_NAMESPACE. With them, converter_test and udt_support_test (the latter is currently marked as known fail) work for Intel 7.1. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 33a34 > #if !defined(BOOST_NO_STDC_NAMESPACE) 35a37,38 > #endif > 52a56 > #if !defined(BOOST_NO_STDC_NAMESPACE) 55c59 < --- > #endif 81a86 > #if !defined(BOOST_NO_STDC_NAMESPACE) 82a88,89 > #endif > 97a105 > #if !defined(BOOST_NO_STDC_NAMESPACE) 98a107,108 > #endif > 496a497,498 > > #if !defined(BOOST_NO_STDC_NAMESPACE) 497a500,501 > #endif >

3 5

[Signals] Regressions/crashes on Linux and CodeWarrior
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs) Run output []: /boost/head-regression/boost/boost/test/minimal.hpp(127): exception "signal: memory access violation" caught in function: 'int main(int, char **)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 Same for CodeWarrior 8.3 on Windows. Could somebody with access to the environment take a look at it, please? -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

[random] intel-win32-8.0 failures
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Could somebody take a look/comment on this one (from http://tinyurl.com/4k3f2) "C:\Programme\Intel\CPP\Compiler80\Ia32\bin\icl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope /Zc:wchar_t /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qansi_alias -D_NATIVE_WCHAR_T_DEFINED /Qvc7.1 -I"C:\boost_regression\results\bin\boost\libs\random\test" -I"C:\Programme\Microsoft Visual Studio .NET 2003\VC7\include" -I"C:\boost_regression\boost" -Fo"C:\boost_regression\results\bin\boost\libs\random\test\random_demo.test\intel-win32-8.0\debug\threading-multi\random_demo.obj" -Tp"C:\boost_regression\boost\libs/random/random_demo.cpp" random_demo.cpp C:\boost_regression\boost\libs/random/random_demo.cpp(122): error: no operator "<<" matches these operands operand types are: std::ofstream << base_generator_type file << generator; ^ compilation aborted for C:\boost_regression\boost\libs/random/random_demo.cpp (code 2) ? It seems like Intel 8.0 for Windows is the only compiler that has this problem (the one for Linux is OK). -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Python again
by Stefan Slapeta 25 Sep '04

25 Sep '04

Anybody an idea what is the reason for the "new" white cells (Intel-win32, cw, vc*)? I can find nothing about these tests in bjam.log but a single line in the list at the beginning boost-test(COMPILE) "python/select_arg_to_python_test" : "libs\python\test\select_arg_to_python_test.cpp" ...so it very much looks like they are not compiled at all! Stefan

3 3

Please, comment design decision of simple FSM
by Alexander Nasonov 25 Sep '04

25 Sep '04

After playing with my overloads library and trying to apply it to FSM I realized that some metaprogramming can be replaced with natural overload resolution rules. After realizing it, I come to conclusion that simple FSM can be implemented as a set of call operators and a list of states. Each call operator represents a transition and follows this pattern: NewState operator()(State,Event) const; Transition functions are generated in process_event function on first call (in a constructor of static variable, for example). Each function extracts current state from StatesAsVariant (boost::variant of all states): template<class StatesAsVariant, class State, class Event> void transition(FSM& fsm, StatesAsVariant states, Event event) { states = fsm( get<State>(states), event); // select best transition // according to overload // resolution rules } The only metaprogramming algorithm is for_each<States> to initialize transition table for the event. Comments? -- Alexander Nasonov

3 13

Re: CW 9.3 results (or lack thereof) - uBLAS fails
by Michael Stevens 25 Sep '04

25 Sep '04

Stefan Slapeta wrote: > I've noticed that once again all ublas test cases threw a gpf in the > last run or CW 9.3. I think I used the latest sources, but at the moment > I've switched back to non-incremental builds and thus we can be sure > tomorrow. I suspect we have some real problem. The failure conditions are interesting. In all cased the first test set which is instantiated with double is successful. Then when instantiated with std::complex<double> the same test fails. Generally this failure is in a swap operation. test4 is however interesting. The first test only constructs two vectors and then destructs them on function return. It also fails with std::complex<double>. So I am suspecting some memory management problem related to complex<double>. If anyone has the time I would to see a call trace at the point of failure. Thanks, Michael

2 1

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 25 Sep '04

25 Sep '04

Vladimir, I don't have my compiler handy right now, but I think this is due to an overlook when doing the adaptation to the new MPL. In particular, the line 50 in boost/multi_index/detail/node_type.hpp: typedef typename IndexSpecifierIterator::type index_specifier; should be changed to typedef typename mpl::deref<IndexSpecifierIterator>::type index_specifier; (also, the corresponginf #include <boost/mp/defer.hpp> must be inserted) Could you please try this locally and report the results? If the problem is solved, I'll commit something along this line next Monday. I don't know the rationale for having to use deref, since I thought these two expressions are equivalent, but there must be some difference, for Alexsey changed some of the code in multi_index to do that when mergien the new MPL. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Sábado, Septiembre 25, 2004 2:41 pm Asunto: [boost] [multi_index + mpl + bind] Regression? > > The attached code, which use the multi_index library, produces > screens of > errors from mpl. The STLfilted log is attached too. > > Commenting out #include <boost/bind/arg.hpp> makes the error go > away, as well > as including it after multi_index. > > This happens with: > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > The code used to work some time ago, but I can't give the exact date. > > I've tried too look at the problem, but got lost in MPL internals. > > - Volodya > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[multi_index + mpl + bind] Regression?
by Vladimir Prus 25 Sep '04

25 Sep '04

The attached code, which use the multi_index library, produces screens of errors from mpl. The STLfilted log is attached too. Commenting out #include <boost/bind/arg.hpp> makes the error go away, as well as including it after multi_index. This happens with: gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) gcc version 3.4.1 (Debian 3.4.1-4sarge1) The code used to work some time ago, but I can't give the exact date. I've tried too look at the problem, but got lost in MPL internals. - Volodya

1 0

[serialization] scoped_ptr.hpp broken
by Vladimir Prus 25 Sep '04

25 Sep '04

Hello, I'm getting this error: ......./boost/boost/serialization/scoped_ptr.hpp:36: error: `make_nvp' undeclared (first use this function) The attached patch fixes the problem. BTW, Robert, this problem was introduce when you moved the content of the header from boost::serialization to just boost::. What was the rationale? The log only says: fixes for cw/comeau implement ADL - Volodya

1 0

RE: [boost] Re: GUI Windowing Framework in C++
by Brian Braatz 25 Sep '04

25 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Thomas Witt > Sent: Friday, September 24, 2004 7:21 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Windowing Framework in C++ > > David Abrahams wrote: > > Reece Dunn <msclrhd(a)hotmail.com> writes: > > > >>[1] Support constructor-based window creation, e.g.: > >> > >> frame.add( new gui::button( "Boost!" )); > > > > > > Get rid of the new operator, though. IMO there's no excuse for a GUI > > framework to expose users to unmanaged resources. > > Hmm, do you know of a C++ GUI framework that gets this right? > > Just curious [Brian Braatz] The problem is handling the "dual lifetimes" of "system" GUI objects and C++ objects. BeOS is the only system I know that does not have this issue, because they extended C++ in such a way so that when you "create" a C++ window object- you now have a window. In frameworks like MFC, they have to internally track a windows resources "object" that the system understands as the gui object. You will always need a dynamic nature to things, but one could take a Rogue Wave approach here and hide all those new's behind accessor type objects which pass around by value and internally hold something like a boost::shared_ptr<> (my 2 cents) Brian

2 1