- Boost - lists.boost.org

Any Intel on Linux Gurus (help wanted with toolset for 8.1)?
by John Maddock 30 Sep '04

30 Sep '04

Apparently from Intel 8.1 onwards, we can no longer link C++ programs with icc as the current intel-linux toolset does: icc is now Intel's equivalent to gcc and performs a C only link, we need to use icpc to link C++ programs (and ideally to compile them as well, although icc currently still recognises C++ source and internally calls icpc). So here's the big question - does anyone have access to Intel 6 and/or 7 on Linux and do these also have icpc? If they do, then this is a no-brainer change to the toolset, but if not then we're going to have to get creative :-| Thanks, John.

2 2

ublas problem
by Matthias Troyer 30 Sep '04

30 Sep '04

Hi, I encounted a strange assertion failure in ublas: Assertion failed in file /Users/troyer/src/boost/boost/numeric/ublas/matrix_sparse.hpp at line 2603: !preserve internal logic Can anyone shed light on this? Matthias

1 0

[config] bcc configuration fix
by Tobias Schwinger 30 Sep '04

30 Sep '04

Just tripped over this (maybe still "sleeping") bug: Neither Builder 5 nor the free 5.5.1 tool chain do support member function specializations: 27a28 > # define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS

2 2

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

30 Sep '04

Hi! I think about multimethods as about generalized version of virtual method. There are compile time virtual methods in C++, and it's ok. Everyone practically use compile time virtual methods. And, by my opinion, the generalized version of them also should be compile time. Maybe we speak about different things? Maybe there should be at least two versions of multimethods: 1) as a generalization of traditional virtual methods; 2) as a generalization of "fully runtime polymorphism". >> Which file are you talking about? I talk about *.h/*.cpp files that aren't located in mm subfolder.

3 2

[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