- Boost - lists.boost.org

CVS at boost-consulting.com
by Christoph Ludwig 17 Aug '04

17 Aug '04

Hi, my Boost CVS working directory used to be rooted at :pserver:anonymous@boost-consulting.com:/boost. However, for some time I didn't get any updates any more. Since it's not plausible that there were no check-ins in the last week I checked out the boost directory from SourceForge. And indeed, there are many differences between the two working directories. For instance: After `cvs up' I have revision 1.4 of boost/algorithm/string/classification.hpp in the working directory rooted at boost-consulting and its status is up-to-date according to `cvs stat' (no sticky tag or date). But in the working directory rooted at sourceforge there's revision 1.5. `cvs log' says it was checked in on 2004-07-30. Even if the CVS at boost-consulting is mirrored only once a day, revision 1.5 of boost/algorithm/string/classification.hpp should be in the repository by now. Do others experience the same problem? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 1

[Boost-bugs] [ boost-Bugs-1010681 ] boost::filesystem::exists is broken on cygwin
by SourceForge.net 17 Aug '04

17 Aug '04

Bugs item #1010681, was opened at 2004-08-17 14:19 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=1010681&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists is broken on cygwin Initial Comment: Compile the following code snippet: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { boost::filesystem::path p = "/usr"; if (!boost::filesystem::exists(p)) std::cerr << p.string() << " doesn't exist according to boost::filesystem" << std::endl; } $ uname -a CYGWIN_NT-5.0 vmware 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown Cygwin $ g++ -g -I"/usr/src/install/3.3.1/include/boost-1_31" test.cc -L"/usr/src/install/3.3.1/lib" -lboost_filesystem-gcc-d-1_31 $ ./a.exe /usr doesn't exist according to boost::filesystem Needless to say that /usr does exist: $ ls -ld /usr drwxrwxrwx+ 18 carlo Gebruike 4096 Aug 8 14:49 /usr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1010681&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: tru64 ICE
by David Abrahams 17 Aug '04

17 Aug '04

Daveed Vandevoorde <daveed(a)edg.com> writes: > Hello, > > On Aug 16, 2004, at 2:57 PM, David Abrahams wrote: > [...] >> This construct is causing tru64cxx6.5 to ICE. Is there any chance >> this is an old bug of yours for which you know a workaround, or is it >> all Compaq? > > We couldn't get it to abort in our released versions > of the last few years. So our suspicion is that this > is a Compaq-specific issue. > > Is there anything in the wording of the internal error > message (if any) that would indicate that it originates > in an EDG front end? Nobody showed me the actual error, so I can say. Sorry :( Thanks for looking at this. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

[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 16 Aug '04

16 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