August 2004 - Boost - lists.boost.org

[boost.test] basic_cstring troubles with tru64cxx65
by Markus Schöpflin 17 Aug '04

17 Aug '04

I think I have found the source of the internal compiler errors currently preventing boost.test to work with the toolset tru64cxx65. The following small sample fails to compile and gives me an internal compiler error when compiled with cxx. ---%<--- #include <boost/test/detail/basic_cstring/basic_cstring.hpp> using namespace boost::unit_test; // void foo(const_string const & s) // ok void foo(const_string s) // not ok { } int main() { foo(literal_string("foo")); return 0; } --->%--- Changing the declaration of foo() makes the compiler error go away. I'm currently thinking that the compiler perhaps has problems with the automatically generated copy constructors for the class basic_cstring. I tried writing an explicit copy constructor for basic_cstring but this doesn't seem to help. The compiler still crashes. Maybe someone else working with this platform has any ideas... Markus

2 3

Re: [boost] Re: 31 character limit for filenames
by Steve Ramsey 17 Aug '04

17 Aug '04

On Mon, 16 Aug, 2004, at 11:34 pm, Miro Jurisic wrote: > Steve Ramsey <steve(a)lucena.com> wrote: >> FSRefs can only refer to pre-existing file system objects - this >> merited a >> single sentence in a single tech note far away from the File Manager >> documentation - which makes them bloody useless for general path >> conversions. > > You probably want CFURL APIs for path conversions. However, you should > explain a > little more what you mean by path conversions, as there are some > non-trivial and > very subtle issues regarding HFS paths and Unicode characters. (But > they may be > completely irrelevant to you, which is why I ask what you mean.) I'm not sure sure how helpful the CFURL stuff is for what I'm doing, as I'm not sure there's an easy way to get HFS paths out of them when running under OS X (as I hinted before, why on earth would you want an HFS path at all under OS X, except to make the MSL happy). The path conversion was an obscure reference to one of my failed cunning plans to convert POSIX paths to HFS paths by having FSPathMakeRef/FSRefMakePath do the work for me; I was toggling the gestaltFSUsesPOSIXPathsForConversion bit in the gestaltFSAttr Gestalt selector between calls. This fails in the general case since FSRefs can't refer to non-existent objects, but it neatly side-steps the text encoding issues when the object does exist. In the absence of system-level hacks, I'm hoping this sort of path conversion isn't the answer. I'm now looking into re-writing certain low-level MSL source files such as path2fss.c to use POSIX paths instead of HFS paths, as there is precedent for Boost libraries providing alternative MSL files to overcome certain deficiencies (boost::thread, for example). Really, though, at this point I'm just fishing while I wait for an elegant solution to suggest itself, where elegant is something other than writing off the MSL for Mac development. Here's a quick summary of what I'm dealing with: the goal is to be able to use boost::filesystem with Metrowerks CodeWarrior and the Metrowerks StdLib/STL implementation, MSL, on a CFM Carbon program intended to run under OS 9 and OS X. Ideally, only a source implementation should be necessary, and the interface files and MSL source should be off-limits (although I'm thinking some interface files needs to be changed to be more generic, e.g. handle-body idiom for path, or I need to throw this restriction out and just litter the interface files with more preprocessor conditionals and give the classes target-specific privates). The POSIX path will not work in this scenario since the MSL uses HFS paths (HFS paths: multi-root, colon delimiters, specify relative paths in the reverse fashion of POSIX, often Pascal strings in Carbon API calls, C strings in MSL calls). You can get a lot of mileage out of a proper rewrite of fs::path::native_file_string, but for total compliance work also needs to be done in fs::operations. Without system-level conversions to handle all the gritty details, the key solution here will probably be to write a heroically specialized manual HFS<->POSIX path converter that takes into account things like multiple roots (e.g., faking a /Volumes directory under OS 9), File Manager name mangling, and possible weird issues with aliases and symbolic links (mmm...cross-volume aliases). I'd _really_ like to avoid going this route... Steve

2 1

Re: [boost] 31 character limit for filenames
by Steve Ramsey 17 Aug '04

17 Aug '04

On Mon, 16 Aug, 2004, 9:03 am, Doug Gregor wrote: > Okay, it's time to ask again: do we still need to enforce the > 31-character limit on filenames? AFAIK, we have this for MacOS 9, only. > Is that platform still significant for Boost users? I believe that the native file name size for ISO 9660 Level 2 is also 31 (32) characters, which affects a whole lot of CDs. What library does this relate to? There might be an easy way to provide an extension, depending on intended use. Speaking of Macs and filenames, has anyone created a successful implementation of boost::filesystem for use with the Metrowerks MSL? I've been trying to shoehorn one into the filesystem interfaces for a week, now, and I'm alternately cursing Metrowerks and Apple. This might be the final indignity that finally drives me away from CFM and the MSL and into the prickly, awkward arms of Mach-O and the BSD stdlib. Two highlights of my wobbly path: 1) MSL only supports HFS paths, even for POSIX-alike functions; 2) FSRefs can only refer to pre-existing file system objects - this merited a single sentence in a single tech note far away from the File Manager documentation - which makes them bloody useless for general path conversions. Right now, I'm thinking my best bet is to go with a tainted implementation that leverages off of Apple's old MoreFiles sample code. This wouldn't necessarily be compatible with the BSL, however, which makes contributing something useful to the library dicey. All this for cross-platform fstreams... Steve

2 1

generalized arithmetic functors
by Neal D. Becker 17 Aug '04

17 Aug '04

STL defines some common arithmetic operators, such as template<typename T> struct plus { T operator+(const T&, constT&); }; There is a need for more general operators: template<typename T1, typename T2, typename res> struct plus { res operator+(const T1&, constT2&); }; For example, std::complex<double> + double -> std::complex<double>. Has there been any discussion on this issue?

2 3

[preprocessor] BOOST_PP_IS_UNARY for Borland
by Daniel James 17 Aug '04

17 Aug '04

I've written an implementation of BOOST_PP_IS_UNARY which works for Borland, and hopefully any other preprocessors which the current implementation doesn't. It is: #define EAT2(x,y) #define IS_UNARY_CHECK(x) ~, 1 BOOST_PP_RPAREN() \ EAT2 BOOST_PP_LPAREN() ~ #define IS_UNARY(x) IS_UNARY_1(IS_UNARY_CHECK x, 0) #define IS_UNARY_1(x, y) IS_UNARY_2(x, y) #define IS_UNARY_2(x, y) y For a non-unary argument, the expansion is simple: IS_UNARY(x) => IS_UNARY_1(IS_UNARY_CHECK x, 0) => IS_UNARY_2(IS_UNARY_CHECK x, 0) => 0 For a unary argument, it expands like this (I might have got the expansion order slightly wrong but, hopefully, this illustrates how it works): IS_UNARY((x)y) => IS_UNARY_1(IS_UNARY_CHECK(x)y), 0) => IS_UNARY_2(~, 1 BOOST_PP_RPAREN() EAT2 BOOST_PP_LPAREN() ~y, 0) => IS_UNARY_2(~, 1) EAT2(~y, 0) => 1 The same technique can be used for BOOST_PP_IS_NULLARY and BOOST_PP_IS_BINARY. So, if this is used as for borland, could these marcros be made 'public'? Also, with a full working BOOST_PP_IS_UNARY, I think it should be possible to make BOOST_PP_SEQ_NIL act as an empty sequence, if I write a patch to do that would it be accepted? Daniel

2 4

Boost License Permission
by Cromwell Enage 16 Aug '04

16 Aug '04

I, Cromwell Enage, give permission for all my past, present, and future contributions to Boost to be distributed under the terms of the Boost Software License Version 1. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

2 1

Boost License Permission
by Bruce Barr 16 Aug '04

16 Aug '04

I, Bruce Barr, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1.

1 0

boost-python vector processing
by Neal D. Becker 16 Aug '04

16 Aug '04

I've posted a few times to the python-c++ list, but maybe this subject is of more general interest so I'm posting here. I'm interested in interfacing c++ algorithms (primarily for signal processing) with python via boost-python. I'm trying to develop a library of algorithms, but first the proper infrastructure is needed. Specifically, a choice of underlying container to be used for passing vectors between python and c++. Vector processing is in my view one of the primary interests for boost-python. By processing vectors, the overhead involved with python and the python-c++ interface becomes acceptable. I believe a suitable container for interfacing between python and c++ is of fundamental interest to the boost-python community. I'm sure there must be a lot of interest in this subject. I have tried to investigate 3 candidates. 1) std::vector 2) ublas 3) numarray So far the results are: 1) std::vector - pros: universal availability easily understood supports required operations (insert, erase...) vector_indexing_suite already implemented (could be optimized more) cons: lacks vector arithmetic - but I just implemented this and it isn't difficult even for an amateur like myself 2) ublas: pros: already has vector arithmetic cons: lacks required operations (e.g., erase) no indexing_suite (see above) 3) numarray pros: ? cons: I had a hard time finding documentation. Heavy-weight interface -> high learning curve Summary: It appears that std::vector is a good choice. Ublas might be better in the future, but at present it lacks some required functionality. A ublas vector does not fulfill all the requirements of Sequence. This topic is known to ublas developers and may be addressed in the future. Here is an initial version of vector arithmetic for std::vector:

1 0

enabling ADL even with namespace qualification
by Thorsten Ottosen 16 Aug '04

16 Aug '04

Dear All, I've put meself in a funny situation. I have a class with an begin() end() members, but I wan't to call boost::begin() boost::end() without the boost:: prefix so ADL is functional. Can that be done? Thanks Thorsten

7 25

random_test, GCC and minmax macros
by Michael Stevens 16 Aug '04

16 Aug '04

The 'random_test' has been failing on GCC-3.3 for quite some time... Looking a bit deeper the failure was rather nasty resulting in a infinite recursion. A lot of waist CPU and memory usage when running regression tests! The problem is GCC-3.3 specific and cause by a compiler bug. It was inadvertently introduced by Eric minmax workarounds. Specificly the 'max' member functions of class ruetti_gen in "random_test.cpp" and class rand48 in "linear_congruential.hpp" were defined: result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () const { return (std::numeric_limits<result_type>::max)(); } Amazingly these are recursing, with max calling itseld rather then the correct max from numeric_limits! I have committed a fix which uses a different syntax thus: result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () const { return std::numeric_limits<result_type>::max BOOST_PREVENT_MACRO_SUBSTITUTION (); } Eric, is this correct from a minmax macro point of view? -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1