- Boost - lists.boost.org

[patch] typo in more/getting_started.html
by Jonathan Wakely 06 May '05

06 May '05

Simple typo

2 1

[filesystem] Operations predicates
by Beman Dawes 06 May '05

06 May '05

I've completed an analysis of expectations for the exists() and is_xxx() family of functions, and the previously suggested status() and symlink_status() functions. See http://www.esva.net/~beman/filesystem_operations_predicates.htm Thanks to Peter Dimov, Rob Stewart, and Jeff Garland for their suggestions. Errors are mine alone. Comments? --Beman

7 41

Re: Boost filesystem documentation
by James Gregory 06 May '05

06 May '05

> You are right that there is a clash. But it seems to me std::runtime_error > should be the base class, so it is the implementation that is wrong. > > Comments? > > --Beman 1. The boost guidelines at http://www.boost.org/more/error_handling.html say "Derive your exception class from std::exception. Except in *very* rare circumstances where you can't afford the cost of a virtual table, std::exception makes a reasonable exception base class" 2. But runtime_error does derive from std::exception, and the error is a run time error 3. Whilst I'm here, I would also like to point out the following silly code I need to use boost filesystem for a program designed to run in Linux and Windows: #ifdef __linux__ fs::path::default_name_check(fs::windows_name); #else //ie we are compiling for Windows fs::path::default_name_check(fs::native); #endif If I use fs::native at all times then I cannot use paths with spaces in under Linux, but if I use fs::windows_name at all times then I cannot use a colon to specify drive names in Windows (e.g. C:\). James

2 1

boost configuration issue
by François Dumont 06 May '05

06 May '05

Hello I think I found a configuration issue while building boost 1.32.0 with VC .Net 2003 (VC71) using STLport 5.0 beta (latest from cvs STLPORT_5_0 branch). Maybe someone already notive this problem but the latest boost CVS version still show it. With the STLport lib the macro configuration is : - BOOST_NO_INTRINSIC_WCHAR_T defined - BOOST_NO_STD_WSTRING _not_ defined, wstring are supported Thanks to the BOOST_NO_STD_WSTRING macro the date_time lib instanciate code for wstring specific type. For instance in libs/date_time/src/gregorian/greg_month.cpp you will find a block of code in a #ifndef BOOST_NO_STD_WSTRING block. The date_time lib use the lexical_cast tool. But the lexical_cast tool do not care about BOOST_NO_STD_WSTRING and rather check, among other macros, BOOST_NO_INTRINSIC_WCHAR_T and so do not grant the necessary specialization for wchar_t and wstring. The error message is then something like: D:\boost_1_32_0\boost/lexical_cast.hpp(137): error: no operator "<<" matches these operands operand types are: std::basic_stringstream<wchar_t, std::char_traits<wchar_t> , std::allocator<wchar_t> > << const std::basic_string<char, std::char_traits<char> , std::allocator<char>> return stream << input; Sorry for not having the accurate message but I have the compiler on an other computer. I see 2 possible solutions to this problem: - concider that there is no wstring support if there is no intrinsic wchar_t support. - make lexical_cast less strict and do not require intrinsic wchar_t support. Bests

2 2

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

This is not my problem (just piqued my interest :) ) But for grins I tried this on 7.1 boost::mpl::is_sequence< list<int> >; // compiles boost::mpl::is_sequence< int_<0> >; // compiles boost::mpl::is_sequence< int<0> >; // doesnt compile boost::mpl::is_sequence< int_<0> >::value; // doesnt compile so replacing with int didn't work > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:25 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Brian Braatz wrote: > > Could it be as simple as missing the namespace on the is_sqeuence<> > > call? > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > Try replacing int_<0> with int. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

Hehehe There are others out there either on another timezone, or not sleeping :) I put the code into VC71 and have been playing with it. I got the same error. (it WASN'T namespace weirdness with VC) (I get soo grouchy with VC I tend to blame the compiler too quickly) I then degenerated into digging through the MPL reference and trying different examples in the project. As of yet, though nothing useful to report. I think I am going to bed. I > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:54 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Joel wrote: > > Brian Braatz wrote: > > > >> Could it be as simple as missing the namespace on the is_sqeuence<> > >> call? > > > > > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > > Try replacing int_<0> with int. > > I think the problem is the way mpl::is_sequence is implemented. > It tries to detect the presence of a "tag" typedef and a "begin" > typedef and concludes that a type is an mpl::sequence if it > has both. I've complained a long time ago about this. I think > this behavior is error prone. It's quite easy to come up with > a situation where I have a type T with a "tag" and a "begin" > but is not an MPL sequence. There must be a better way. MPL > should not monopolize on the usage of "tag" and a "begin" > in a type. > > Anyway, in any case, is_sequence<int_<0> >::value should never > fail to compile. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

I only suggest that because with VC I have seen weirdness like that. I.e. you THINK you have brought something in with a using, but it , in some weird case, doesn't work for whatever reason. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:25 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Brian Braatz wrote: > > Could it be as simple as missing the namespace on the is_sqeuence<> > > call? > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > Try replacing int_<0> with int. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Fwd: [boost] [patch] lambda bug with GCC debug mode
by Jonathan Wakely 06 May '05

06 May '05

Ping! Originally posted a few weeks ago. I've CC'd Jaakko's SourceForge account, should I raise a sourceforge bug instead? jon

3 2

What is the easiest way to assign mulitply value for a defined number array?
by zlf 06 May '05

06 May '05

Hi all, What is the easiest way to assign mulitply value for a defined number array? Assigning mulitply elements' value when defining like this will be OK. int test [ 2 ] = { 1 , 2 }; If I want to assign value for the number array [test] after defining it. I only know I can achieve this by the following step. int test [ 2 ]; test [ 0 ] = 1; test [ 1 ] = 2; [int test [ 2 ]; test = { 1 , 2 };] seems easy and reasonable. But executing it will get a compile error. What is the easiest way to assign mulitply value for a defined number array? Thx zlf

2 2

RE: [boost] Re: Logging Library over Iostreams? (was Logging Library-- Formal Review Request)
by Brian Braatz 06 May '05

06 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Darryl Green > In what way isn't this a "well designed bolt on to IOSTREAMS"? I can see > is that > it is more general than is necessary if one takes the view that iostreams > provide all the facilities/customisation points you could need. I'm not of > that > view. [Brian Braatz Writes:] Hmm.. I can better explain what I am suggesting this way: There are a lot of smart people throwing a lot of good points of variations at the logging library. Logging is somewhat of an issue that is difficult to solve because you cannot make everyone happy (everyone seems to have varying needs) I see the logging concept as either a device or a sink in iostreams. One that has the right balance of concrete design and points where the user can supply functionality (policies) to allow for at least speaking to most of the issues. I see this device as something I can build using template programming to meet my needs. I also see the dynamic filtering in iostreams as something very useful for production usage of logging. I see how to output and split and or manipulate the log output as something that, again, rides on iostreams. Things for example I PERSONALLY need out of a log: 1- Might Need to be able to re-direct to the ACE logging service 2- Windows Event Log 3- A file on disk 4- I might need multiple files on disk- one that is HIGH LEVEL interesting information and another that is the details (previous work has shown me this works very well in a production environment) 5- I might need to send the log to different "devices' simultaneously -I.e. another program over a socket, and my normal logging file. Because this is an issue that has so many perspectives, my suggestion is to think along the following lines: 1- Put enough policies into the design so the user can get what they need out of the lib (everyone has very different needs is my assumption) 2- Think about making the logging lib a conceptual extension of iostreams in design

2 1