- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1348061 ] regex fails to Compile unter Windows and VC++ 7.1
by SourceForge.net 04 Nov '05

04 Nov '05

Bugs item #1348061, was opened at 2005-11-04 01:11 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=1348061&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex fails to Compile unter Windows and VC++ 7.1 Initial Comment: Hello regex-Developers I have tried to download boost_1_33_0.zip and install boost regex on Windows 2000 using Microsoft Visual Studio .NET 1.1 (C++ compiler version 7.1). Unfortunately, after changing to boost_1_33_0 \libs\regex\build and running nmake -fvc71.mak I get the error that VC++ doesn't know how to make "allocator.hpp" and "regex_library_include.hpp" It appears that allocator.hpp and regex_library_include.hpp are both missing in version 1.33. I copied the files from the 1.32 version, and that solved my problem. Everything compiles fine and seems to work nicely now. Not sure why these files are missing... Could you please include them into the 1.33- version again (they go into boost_1_33_0 \boost\regex\config). Thanks and best regards /Christoph Hänle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1348061&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] vc8 failures in bind mem_fn_eq
by Victor A. Wagner Jr. 04 Nov '05

04 Nov '05

At 04:14 2005-11-03, Bronek Kozicki wrote: >On 11/3/05, Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > has the problem been fixed? the results from metacomm show that my > > run at 2005/11/02T2200 has no failures in bind. > >I can definitely see failed test in my today's results. any thoughts on why they're not in my results? the last results of yours I see "posted" are: Wed, 2 Nov 2005 19:01:46 +0000 >B. > >-- >Bronek Kozicki brok(a)spamcop.net http://b.kozicki.pl/ > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Feature Request
by Abajyan, Hambardzum 04 Nov '05

04 Nov '05

Hi (I've already been subscribed my address as you told me to do.) I would like to now why there isn't an implementation of TCP(UDP) Sockets ? I think it's possible to write a good platform-independent architecture based on Berkeley socket interface (supporting asynchronous (non-blocking) sockets), because both Linux and Windows systems support that architecture. There are many libraries like that: e.g. Boost.Thread library which is also platform-independent. In my opinion, this feature is very usefull as with it programmers can develop network applications on Boost. Thanks Best Regards Hambik

1 0

Re: [boost] Sermon at the Soup Kitchen
by Michael D. Crawford 04 Nov '05

04 Nov '05

Peter Dimov saved me from a collosal blunder by correcting my impression that shared_ptr wasn't thread-safe. I've posted a revised draft here: http://www.goingware.com/tips/smart-pointers-and-automated-testing/#thread-… I hadn't previously understood that thread-safety is not an all or nothing proposition, that is, that one can only guarantee that certain kinds of simultaneous operations will work. My revised text points that out and quotes the first paragraph of shared_ptr's doc on thread safety. I *did* know that there are different degrees of exception safety, so I compare thread-safety guarantees to that. When I cover exception safety in a week or so I'll discuss what that means; sometimes for reasons of performance or memory conservation, one must choose not to be completely exception-safe. Sermon at the Soup Kitchen http://www.goingware.com/tips/smart-pointers-and-automated-testing/ It's going to be about three hours before I post the final section and submit to Kuro5hin. My first try at "The Right Tool for the Job" in my Kuro5hin diary was characterized by one K5 member as "Utterly incomprehensible", and I realize now he's absolutely correct, so I need to address that. I'm going to add a small section to it that I think I'll call "Every Engineer's Solemn Duty" that exhorts the reader to do the right thing when his company plows ahead with a disastrous engineering decision, even if one risks losing one's job, getting blacklisted, sued or even imprisoned. I don't think most engineers ever spend much time thinking about such things until they are suddenly faced with actually making the awful decision to issue an ultimatum, as I did, or blow the whistle, as I still might. I'm lucky I only lost my job. Think of the poor Morton Thiokol engineer who didn't trust his conscience when he knew the Space Shuttle's O-rings had frozen. He settled for reporting the risk of explosion through company channels, and trusted that Morton Thiokol would do the right thing. By not raising Hell and going directly to NASA when he realized the launch hadn't been canceled, he allowed seven people to lose their lives, a billion dollar spacecraft to be destroyed, and the US space program to be set back several years. If I can find a good web page about it, I'm also going to mention the Ford Pinto's exploding gas tank. It came out in a lawsuit that Ford's engineers made a calculated decision to let the gas tank go ahead and explode because they didn't think the cost of paying the inevitable lawsuit damages would be as much as the added manufacturing costs of a safer tank. Before quitting it to run "Yoyodyne" full time, "Jack's" last job was managing a team designing a novel, experimental new medical device, the failure of which would doom the patient to certain death within minutes. I might send a link to "Sermon at the Soup Kitchen" to his ex-employer, along with an explanation of just who Jack and Yoyodyne really are. And yes, I'm well aware that if Jack ever reads my sermons he might try to drag me into court. At least I can sleep soundly at night. You should see all the emails I *don't* post online. Yours, -- Michael D. Crawford

4 5

Active objects?
by Jason Hise 03 Nov '05

03 Nov '05

I watched the talk Herb Sutter gave recently regarding concurrency, and I have to say I find the ideas of active objects and future variables to be very exciting. (A link to the talk is provided below, which must be viewed with Internet Explorer). I noticed that Boost already has a futures library in the sandbox under development, which from what I can tell looks well designed. Are there any plans to add the functionality of active objects to boost as well? I would be interested in hearing how you think the problem would be best approached. From what I can tell, it should ideally be possible to use 'active' as a modifier like 'const' or 'volatile' in front of a specific object instance, and have all member function calls automatically add themselves to a queue when called, instead of actually being called. Because this syntax is probably impossible to pull off, I think the next best thing would look something like the following: struct MyClass { int foo ( int arg1, const char * arg2 ); }; void test ( ) { active < MyClass > object; future < int > i = object.request ( MyClass::foo, 42, "blah" ); } 'request' could also be spelled 'enqueue', 'invoke', or 'operator ()', although I'm not sure if the terseness of the latter would be sensible. 'active' would probably use CRTP to derive privately from 'MyClass', enforcing that member functions of MyClass are not called directly. Thoughts? Herb Sutter's video: http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreloa… -Jason

13 29

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 03 Nov '05

03 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Comments, feedback very welcome! > Actors > > The Actor is the main concept behind the library. Actors are ^^^ strike > function objects (functors). An actor can accept 0 to N arguments ^ "sometimes called" > (where N is a predefined maximum). What does that mean? If I define a function object that accepts fewer than N arguments it can't be an Actor? What is N really? Why not give the actual symbolic name here? > You can set PHOENIX_LIMIT, the predefined maximum arity an actor can > take. By default, PHOENIX_LIMIT is set to 10. Ah, there it is. Still, the use of N seems superfluous. > While the Actor is a concept representing a function, there is also > the actor template class which models the concept. The template > class has a sole template parameter, Eval, from which it derives > from. The actor class doesn't have the smarts to actually evaluate > the function, Eval does. Eval is a concept, representing the > function body (i.e. the implementation of the function). Rewrite that paragraph: Phoenix supplies an actor class template whose specializations model the Actor concept. actor has one template parameter, Eval, that supplies the smarts to actually evaluate the resulting function. It's too early to say that Eval must conform to the Eval concept. > template <typename Eval> > struct actor : Eval > { > return_type > operator()() const; > > template <typename T0> > return_type > operator()(T0& _0) const; > > template <typename T0, typename T1> > return_type > operator()(T0& _0, T1& _1) const; > > //... > }; > > The actor class accepts the arguments through a set of function call > operators for 0 to N arities (Don't worry about the details, for > now. For example, note that we skimp over the details regarding > return_type, above). The arguments are then forwarded to the actor's > Eval for evaluation. As long as you're doing this you could solve the forwarding problem for the first N arguments with 2^N overloads for some reasonable N, say, 5. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 03 Nov '05

03 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Comments, feedback very welcome! Basics Almost everything is a function in the Phoenix library that can be evaluated as f(a..n), where n is the function's arity, or number of ^^^^ This notation is not familiar to me. I would have expected: f(a[sub 0], a[sub 1], ...a[sub [italic n]]) (using a made up quickbooky syntax) arguments that the function expects. Operators are also functions. For example, a + b is just a function with arity == 2 (or binary). a + b is the same as add(a, b), a + b + c is the same as add(add(a, b), c). I don't know if remarks like Amusingly, functions may even return functions. We shall see what this means in a short while. assume a background that's compatible with your use of the lambda symbol on that page with no explanation. The expression arg1 % 2 == 1 evaluates to a lambda function. arg1 represents an unsupplied argument. I would say arg1 is a placeholder for an argument to be supplied later or if you need a short term for such a thing, arg1 is lazy argument---a placeholder for an argument to be supplied later However, in this document and in the examples and tests provided, don't be surprised to see the first and second steps juxtaposed. ^ in order to illustrate the complete semantics of Phoenix expressions -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 03 Nov '05

03 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Hi, > > Here's a pre-release package of Phoenix-2. Jaakko and I agreed > that it will be the basis of the Phoenix and Boost Lambda > merger. This version is Phoenix 1 + Lambda + a lot more. > > Take note though that this is not a drop-in replacement of > Phoenix-1 for Spirit users. In particular, there is no > closure support. Phoenix-2 has true local variables. The > plan for Spirit-2 is to replace closures with local variables. > > Docs: http://tinyurl.com/77pz5 > > The pre-release package is here: > http://spirit.sourceforge.net/dl_more/phoenix_v2.zip > > Just drop it where Phoenix-1 is and run the examples/tests. > Comments, feedback very welcome! Composites What we have seen so far, are what are called primitives. You can think of primitives (such as values, references and arguments) as atoms. They are not decomposable. ^^^^^^^^^^^^^^^^^^^^^^^^^ What does that mean to me, the reader? Is not this primitive/composite distinction purely an implementation detail? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 03 Nov '05

03 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Comments, feedback very welcome! Lazy Functions As you write more lambda functions, you'll notice certain patterns that you wish to refactor as reusable functions. When you reach that point, you'll wish that ordinary functions can co-exist with phoenix functions. Unfortunately, the immediate nature of plain C++ functions make them incompatible. Lazy functions are your friends. The library provides a facility to make lazy functions. The code below is a rewrite of the is_odd function using the facility: struct is_odd_impl { template <typename Arg> struct apply { typedef bool type; }; template <typename Arg> bool operator()(Arg arg1) const { return arg1 % 2 == 1; } }; I kept looking for where the library facility was in use... and then I saw this: function<is_odd_impl> is_odd; ^^^^^^^^ I guess that's it. It would help to leave a phoenix:: qualification on names from the library, or if you can't do that, use color or bold to emphasize them. Y'know, what I really expected, though, was something I could pass the old is_odd function to: make_function(is_odd) -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost regression notification (2005-11-03 [RC_1_33_0])
by Douglas Gregor 03 Nov '05

03 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-03T14:11:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0