September 2004 - Boost - lists.boost.org

[Numeric/Interval] Mingw-3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Could somebody please take a look at these (from http://tinyurl.com/477vr) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\numeric\interval\test\integer.test\mingw-3.4.1\debug\integer.obj" "C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp" In file included from C:/MinGW/Bronek/boost/boost/boost/numeric/interval.hpp:20, from C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp:11: C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_up(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::acosh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:43: error: `::acosh' has not been declared [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

6 28

Why all prog-fail test are failing
by Gennadiy Rozental 30 Sep '04

30 Sep '04

I already asked this one. Did I miss an answer? Gennadiy.

3 3

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 30 Sep '04

30 Sep '04

Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: MultiMethod/Visitor Interest
by Danil Shopyrin 30 Sep '04

30 Sep '04

David Abrahams writes: > Yeah. It's hard to imagine how "compile-time multimethods" would be > any different from what C++ already provides in terms of overload > resolution and partial ordering. The main difference is that they work when particular types of participants are unknown at compile time. It is just like trying to implement unary virtual method using overloading. Jesse Jones writes: > Can a static library do better type > checking? In particular can it figure out, at compile time, if there > are no applicable methods or no unambiguous method? Yes. The compile-time library detects ambiguity and absence of proper method. It is compile-time error.

1 0

Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 30 Sep '04

30 Sep '04

Hi, Sorry if I am missing something - I can't compile (with Visual C++ 7.1) the graph library in the cvs snapshots since a couple of months. The errors are in graphviz_graph_lex.cpp and graphviz_digraph_lex.cpp due to an include of a Unix specific file "unistd.h". Although there is a preprocessor condition YY_NO_UNISTD_H around it, I can't find anywhere this would be defined for non-unix systems. I start the build with this command: libs\graph\build>bjam "-sTOOLS=vc7.1" Will this be fixed to the final 1.32 release? I do remember the graph library worked in 1.31, but with some build tweaks regarding un-/directed graphs. Regards, Christian

4 7

[filesystem] possible bug in exists(path const &)
by Angus Leeming 30 Sep '04

30 Sep '04

Beman, I notice that the Windows implementation of exists() contains the line: if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) This contrasts with DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); in is_directory(). I wonder if there are any implications in using string() as opposed to native_file_string() here? It does appear that in most places you prefer to use the "native_" flavour when invoking system functions. Regards, Angus

2 1

[review] Formal review of the Smart Container library - one week left reminder
by Pavol Droba 29 Sep '04

29 Sep '04

Hi All, This the the reminder, that there is only one week left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

Re: [uBLAS] Linux regressions
by Michael Stevens 29 Sep '04

29 Sep '04

Martin, Thanks for your work on the Linux tests. Looks like all the staleness problems are fixed. The uBLAS tests now show the expected 100% passes. Michael

2 1

Formal review of "Output Formatters" library begins today
by John Torjo 29 Sep '04

29 Sep '04

Dear boosters, The FORMAL Review of "Output Formatter" library begins today, Sept 12, 2004. Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

15 42

[tokenizer] Any expert in bjam?
by Joaquín Mª López Muñoz 29 Sep '04

29 Sep '04

tokenizer is regressing for msvc-stlport as shown in http://tinyurl.com/3mkvx The same kind of problem happens at the following cells wich are marked as expected failures: http://tinyurl.com/44pbx http://tinyurl.com/5xd8z I've built these tests locally for msvc-stlport locally (from my IDE) and they work just fine. No fundamental problem with this platform. So I guess the problem lies in the corresponding Jamfile entries (located directly in boost/status/Jamfile): test-suite tokenizer : [ run libs/tokenizer/examples.cpp <lib>../libs/test/build/boost_test_exec_monitor ] [ run libs/tokenizer/simple_example_1.cpp ] [ run libs/tokenizer/simple_example_2.cpp ] [ run libs/tokenizer/simple_example_3.cpp ] [ run libs/tokenizer/simple_example_4.cpp ] [ run libs/tokenizer/simple_example_5.cpp ] ; I'm pretty sure this is related to some messing up of stdlibs binaries (I vaguely recall that STLPort does not work with single-thread static runtime lib), but my skills of Jamfile are lousy. Could somebody please have a look at it? Another thing that left me wondering is that examples 1, 2 and 4 have the same structure as 3 and 5, and yet they do not fail. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1