- Boost - lists.boost.org

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

[MPL] is_sequence problem
by Joel 06 May '05

06 May '05

Hi, I have a problem with this code snippet: #include <boost/mpl/is_sequence.hpp> int main() { using boost::mpl::int_; using boost::mpl::is_sequence; bool b = is_sequence<int_<0> >::value; } VC7.1 complains: C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2039: 'begin' : is not a member of 'boost::mpl::int_<N>' with [ N=0 ] C:\dev\boost\boost\mpl\begin_end.hpp(35) : see reference to class template instantiation 'boost::mpl::begin_impl<Tag>::apply<Sequence>' being compiled with [ Tag=boost::mpl::begin<boost::mpl::int_<0>>::tag_, Sequence=boost::mpl::int_<0> ] C:\dev\boost\boost\mpl\is_sequence.hpp(94) : see reference to class template instantiation 'boost::mpl::begin<Sequence>' being compiled with [ Sequence=boost::mpl::int_<0> ] C:\dev\test\mpl_is_sequence.cpp(8) : see reference to class template instantiation 'boost::mpl::is_sequence<T>' being compiled with [ T=boost::mpl::int_<0> ] C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2955: 'boost::mpl::begin' : use of class template requires template argument list C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of 'boost::mpl::begin' C:\dev\boost\boost\mpl\begin_end.hpp(35) : error C2955: 'boost::mpl::begin' : use of class template requires template argument list C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of 'boost::mpl::begin' C:\dev\boost\boost\mpl\is_sequence.hpp(94) : error C3203: 'begin' : class template invalid as template argument for template parameter 'T', expected a real type >Exit code: 2 Any hints? I am relying on is_sequence to return false in this case. Comeau and g++ throws up too. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

(Another) socket streams library
by pedro.lamarao＠mndfck.org 05 May '05

05 May '05

Hello, all. I see everybody has been talking about a networking library for a long while. Checking the wiki, I see that my own project has escaped attention. So, here it goes for the examination of the experts: http://socketstream.sourceforge.net/ -- Pedro Lamarão

11 47

[CVS] How to move a module from boost-sandbox to boost
by Andreas Huber 05 May '05

05 May '05

Dear Boosters At some point I will have to move the directories containing the Boost.Statechart library from the boost-sandbox repository to the boost repository. Is there any way to do this without losing the CVS history? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

BOOST_FOREACH and 1.33.0
by Russell Hind 05 May '05

05 May '05

This was posted under the 'BOOST_FOREACH review results' thread but was suggested to be posted as a separate thread so others can comment on it (including the review manager and author). What do people think? Could it be pushed in to 1.33.0 or do we wait for 1.34.0 before it is added to an official release? Cheers Russell -------- Original Message -------- Pavel Vozenilek wrote: > > Perhaps exception could be made - it is mature, used in apps > and the documentation can be updated quickly. > > It may serve as starting point for people exploring other libraries. > I would like to see it in there too. AFAICT, it doesn't require any changes to other libraries (the bcc32 addressof problem has already been patched in CVS) so its impact should be minimal to none on regression tests. I guess its would still then be up to Eric to decide if the current tests and docs are where he'd like them to be for general release after the review. Cheers Russell

5 6

[1.33] type traits VC8 fixes and the release schedule
by John Maddock 05 May '05

05 May '05

What's the timescale for 1.33 at present? I have some VC-8 specific fixes for type traits that hook up the compiler's intrinsic type traits support into our traits classes: these patches make VC8 the first compiler to "just do the right thing" with every single trait. That's a big milestone IMO! Assuming VC8 will be release before Boost-1.34 (which seems likely), I'd like to commit these to cvs, but won't do so if we're too close to release (as long as there's at least 10 days or so to go, then there's enough time to check for possible regressions - especially as only one compiler should be affected - and there are no regressions for me locally with gcc/vc++/borland/intel). Thoughts? Thanks, John.

3 3

[1.33.0] Need more help fixing bugs!
by Douglas Gregor 05 May '05

05 May '05

We're making progress fixing bugs for 1.33.0, but we still have over 2000 failures on our target set of compilers. We need your help! Doug

1 0