- Boost - lists.preview.boost.org

Future of threads (III)
by scott 17 Feb '04

17 Feb '04

hi y'all, i have been listening-in to the recent thread thread (intentional); its worth it! threading is a special interest for myself at the moment. i have been working on something different (distributed messaging) and have been forced to consider threading. again and again. it seems to be impossible to address the one (messaging) without also addressing the other (multi-threading). this would come as no real surprise to anyone, but the slightly unnerving thing has been the "distance" between the threading model that seems to fulfil the requirements of my distributed messaging and the model in boost::threads. this is not intended to question the validity of that model; quite the opposite. i have wondered if my model is invalid and considered the task of "porting" the messaging code to the boost model (if not the implementation) calling it the "boost model" seems a little unfair as i think i can say it is in the spirit of other implementations such as rogue wave's. recent work has taken me on a different path. i have been cornered into applying my messaging+threading model within a significant body of complex production code. millions of lines of code and dozens of threads. the interesting thing (for me :-) has been how effectively the new threading model has integrated with the existing model(s). this did make me feel better about the track i had taken. so, is there room for 2? very briefly, the boost model treats threads as a resource (fair enough to :-) and submits code fragments for asynchronous execution. in the alternate model, threads come about as a consequence of instantiating final (a la java) objects. the distinguishing attribute being that threads only run code that is "part of themselves" rather than code being submitted from "outside". execution of the code is initiated by sending of a message (within my vocabulary that is actually a signal). the message can contain arbitrary data. is this different enough? is there enough value there? cheers, scott

11 33

Perfect Forwarding (almost)
by David Abrahams 17 Feb '04

17 Feb '04

The example below shows a technique for perfect forwarding that seems to work with GCC 3.3.1. rvalues are always moved automatically, and lvalues are copied. Except for one rather important case, it works with Comeau (errors only in strict mode). The important case that causes the error clearly violates 12.2/1 of the standard, but see below. VC++ and CodeWarrior have different kinds of problems with it from Comeau/strict. I am hoping that they are wrong, but I am not enough of a core language jock to make a determination on which of these compilers is correct (if any). 12.2/1 says that the act of binding an rvalue to a (const) reference creates a temporary (which may be elided). The creation of the temporary requires the existence of a copy ctor with a const& argument. As far as I know, that rule serves no useful purpose, but I may have missed something. *If* my example actually works other than this case, I'd like to try to get the rule lifted, and soon! This is by no means the cleanest route to move semantics, but it's probably the smallest "language extension" we'd ever need to get it, and might even be possible before C++0x Enjoy, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

14 70

RE: [boost] Re: Moving Boost.Thread barrier from thread_dev to HE AD
by Bjorn.Karlsson＠readsoft.com 17 Feb '04

17 Feb '04

> From: Michael Glassford [mailto:glassfordm@hotmail.com] > One potential problem that I am aware of is that it is > possible for the > m_generation counter (see barrier.cpp) to overflow on systems that > detect overflow of integer addition instead of wrapping (I > assume there > are such systems though I've never used one). Is it > worthwhile checking > for this and forcing wrapping in code? Checking for overflow isn't needed in this case, since the underlying type is unsigned (and unsigned integer arithmetic does not overflow [per §3.9.1.4]). Bjorn

2 1

Re: boost thread static library
by Arkadiy Vertleyb 17 Feb '04

17 Feb '04

Thanks, Russell and Michael, from your responces I realise that I will probably have to leave with DLL. However, the next question then would be why am I getting these undefined refs while linking with boost_thread-mgw-mt-d-1_31d? obj\synchronizer.o(.text$_ZN5boost9condition7do_waitINS_5mutexEEEvRT_+0x29):sync hronizer.cpp: undefined reference to `boost::detail::condition_impl::do_wait(__p thread_mutex_t**)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE4lockERS3_R NS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::do_ lock(boost::mutex::cv_state&)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE6unlockERS3 _RNS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::d o_unlock(boost::mutex::cv_state&)' Thanks, Arkadiy _________________________________________________________________ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

2 1

Numeric Conversion Library and VC7.0
by Fernando Cacciola 17 Feb '04

17 Feb '04

Hi All, Michael Borghart is helping me fix some extrange problem with the numeric conversion lib on VC7.0 The problem doesn't exist on VC7.1 and it is not a compilation problem (at least not one that produces a compile fail). If anyone with VC7.0 can help me here I'll appreciate it, TIA The problem can be seen with the following simple test: #include<boost/numeric/converter.hpp> int main() { long l = -1 ; boost::numeric_converter<unsigned long,long>::convert(l); } that code is supposed to raise an exception at runtime because -1 is out of range for "unsigned long". On VC7.0, however, it doesn't. For you to help me, you'll have to step into the code to see what is it doing, Here's a description of the code and what it is should happen: There are two main kinds of converters: rounding and non-rounding: The rounding converter is used ONLY for float to integral conversions. Their conversion entry code looks like: static result_type convert ( argument_type s ) { RangeCheckerBase::validate_range(s); source_type s1 = Float2IntRounderBase::nearbyint(s); return RawConverterBase::low_level_convert(s1); } And for non-rounding converters (used by anything but float to int): static result_type convert ( argument_type s ) { RangeCheckerBase::validate_range(s); return RawConverterBase::low_level_convert(s); } There you can see the different "steps" of the conversion process. First, validate_range() performs the range checking. If this function returns (which shouldn't in case of an out of range), low_level_convert() is called to perform the actual conversion. low_level_convert() is supplied by the user as part of the RawConverter policy, but validate_range() is selected at compile time accordining the the combined properties of the Source and Target types. In our case, it appears that VC7.0 is choosing the wrong validate_range() implementation. Unless Source==Target, validate_range() calls the function out_of_range() which looks like: static range_check_result out_of_range ( argument_type s ) { typedef typename combine<IsNegOverflow,IsPosOverflow>::type Predicate ; return Predicate::apply(s); } Here you can see that the actual checking is performed by a "predicate" which is composed at compile time. Depending on the type properties, the predicate might be "combined", meaning that two cascading tests are performed instead of just one. If for a given case only a single predicate is used, the code should step into a function of the form: static range_check_result apply ( argument_type s ) { return {...some specific test....} } Otherwise, the "outer" apply simply calls two applies in a row: static range_check_result apply ( argument_type s ) { range_check_result r = PredA::apply(s) ; if ( r == cInRange ) r = PredB::apply(s); return r ; } } ; Finally, each individual "apply" is implemented by the set of objects that appear at the top of "detail\converter.hpp" These predicates perform the minimally neccesary testing to decide if the source value is out of range. For this particular conversion: long->unsigned long The only required test is (s<0), so the predicate that should be selected by the metaprogramming is the class: LT_Zero I suspect that VC7.0 is using a different predicate. So, if you could step inside validate_range() out_of_range() apply() apply() // only if it stepped into the "combiner" predicate and print the stack from there I'll see what's happening. TIA Fernando Cacciola SciSoft

1 0

Re: [boost] Re: [OT] Hiding template parameters [was: FC++ Formal review is...]
by Gabriel Dos Reis 17 Feb '04

17 Feb '04

David Vandevoorde <daveed(a)vandevoorde.com> writes: | (I'm not on the Boost list. Gabriel: Apologies if you | get this twice. I don't know if you're on the list. | So to be sure, I left you on the recipients' list.) { Don't worry: duplicate messages are automatically deleted. :-) I used to read Boost mailing list in batch mode these times, but Dave sent about this issue on Boost list with a copy to me and Steve; but later, he decided that the issue should be OT. I'm having trouble following that part. } | On Feb 17, 2004, at 6:29 AM, Gabriel Dos Reis wrote: | [...] | > Someone has characterized it as inconsistent without giving details as | > to why; all I'm saying is that, if one accepts the principle that | > "scopes nest", then the rule is a logical consequence, hence | > consistent with that principle. | | You're making one more assumption: That template | parameters really have their own full-fledged scope. No. I'm reasoning with the -fact- that the scope of template-parameters encloses the template. That is not an assumption. | I say that they shouldn't, just as function parameters | don't. But, the situation is not similar: template-parameters are introduced *before* the thingy being parameterized. You'd have the same situation with function parameters if they were introduced before the function they are part of (Note: declaring them before the function may "solve" some of the problems with auto/decltype type-deduction issues in the auto/decltype proposal). | > Now, it might be that that logical | > consequence is unacceptable for some non-rational reasons, but that | > does not mean the consequence itself is inconsistent. | | The current situation is IMO unacceptable for | _rational_ reasons, no matter what the language- | legalistic arguments for it may be. I'm not offering language-legalistic arguments. In the first message Dave sent to me (which generated this thread), he said he was just registering a strong opinion. That is not rational reasons, it is just a statement of feeelings. In subsequent messages, he made more assertions mostly based on misuderstanding of what I was proposing. As I said in another message, if one starts from a principle and you reach a logical conclusion that is unacceptable to ones believes, the thing to change is not the conclusion, but the principle that logically leads to that conclusion. At least, if one wants to stay consistent. | > | The POV is that | > | | > | class B { typename X }; | > | | > | template< typename X > class Y // 1 | > | : public B // 2 | > | { // 3 | > | ... | > | }; | > | | > | You think that template parameter X is declared in line 1, then | > hidden | > | by the base classes name introduced by line 2, thus non-accessible in | > | line 3, right? You think of the name scopes to nest in the same | > order, | > | do you? | > | > What I think is: If we accept the principle that scopes should nest, | > then we should accept its logical consequences; if don't want to | > accept those logical consequences, then we should abandon the idea | > that scopes nest. Which one do you want to pick? | | As mentioned above, I disagree that these are the | only options. Which "only options"? If you make template-parameters hide members, *then*, you no longer have nesting of scope of the template in the scope of template-parameters. It is not an option :-) | But even if you insist on thinking | in those terms, then there it is still possible | to come up with a mechanism that matches what most | of us expect: Simply consider the base class scope | to enclose the scope of the derived class parameters. Could you elaborate more on this mechanism? Not that it would not "solve" this particular issue, but so that I can see whether it actually works with rest of the rules. | > | This is a reasonable point of view, actually it's the current | > | language's interpretation of the topic, but it's not what I call | > | intuitive. | > | > One major problem is what is defined "intuitive" and when "intuitive" | > is defeated by logic. | | Oh please. I notice you posted to the thread "Opinion | sought on name hiding issue" in comp.lang.c++.moderated. | Except for you, the other dozen participants seem to | have no problem on agreeing what is intuitive. | | See above for what I think is the flaw in your logic. You did not point out a flaw. You thought I was assuming something; which I did not. | > | While it's technically correct, it still feels wrong - at | > | least to me. | > | > If you think it is wrong, while being consistent with first principle, | > then propose a a new first principle. The worst thing to do, I | > believe, is to introduce barnacled hacks that comes from nowhere. | > | > | I see things more from a visibility-point-of-view. I | > | > "scopes nest" is visitbility-point-of-view :-) | > | > | can't see the base class' names at 2, | > | > yet, you see the following | > | > struct A { | > struct iterator { }; | > }; | > | > struct B : A { | > vodi f(iteraror); | > }; | > | > don't you? Or are you proposing that to be ill-formed? | | I also see: | | struct A { typedef int I; }; | struct B: A { | typedef long I; | }; | struct C: B { | I x; // B::I hides A::I | }; Exact. So, at least you agree that the issue has nothing particular to do with templates. As I told you last week, if it is considered important, it should be solved as a general issue, not added as yet another special case to the already overly long list of special cases. | Same with template parameters: They hide the homonyms | in farther scopes. | | > We need general rules on which to decide, we don't need barnacled | > hacks that would appear "intuitive" at a moment when we don't have a | > working definition of "intuitive". | > | > | I have to go back (that is, I | > | have to go one "scope" up) to see the names that are contained. This | > | makes me think of the lines 1 and 2 to be swapped wrt the names they | > | introduce into the scope of 3. To put it another way: The names of B | > | are not declared at 2, and that line 2 is also not like a using | > | declaration, although it might seem similar. | > | | > | If we use Dave's or my POV (and we are not alone ;), the | > advantages of | > | scopes can be used in this example, too. The advantage is a smaller | > | scope to search for a name: If you need to know what a name refers | > to, | > | you just look into the scopes from the inside (nearest scope), to the | > | outside. And it feels more natural to me if the scope of the template | > | parameters is closer than the scope of the class' base(s). | > | > If the scope of the template-parameters should come after the scope | > of base classes -- that is the way I understand you "is closer" -- | > then one would not be able to use template-parameters in base classes. | | And you cannot: You can only use them to _name_ base | classes. Yes, "name" is what I intended. Sorry. Just to be clear: If template-parameters had a scope that comes after the scope etablished by base classes, you could not use them in the naming base classes. | In fact, now that I reflect on it, base | classes are not really "enclosing scopes" of derived | classes. You can simulate the lookup that way, but | you could just as well say that inheritance is a sort | of "base class using-directive" (which is how many | compilers implement it). | | > If you don't agree with the "scopes nest" principle, then propose | > another principle, but please don't label it "intuitive" :-) | | On the contrary: If that what Daniel's intuition says, | he should label it as intuitive. The point is there: according to *his* intuition. Do you see what I mean? What we need is a working definition I can consistently apply to accept of reject conclusions. | > If I were to design a new programming language, I'm not sure I would | > just stick to "scopes nest", but here we're not designing a new | > programming language. IMO, one of the the worst things we can to the | > already complex C++ scope rules, is to come up with yet another | > special scope. At this point of complexity, following logical | > consequences is less evil than "intuitive" hacks where we don't have | > working definition of "intuitive". | | You seem to imply that scope nesting is the only | mechanism that directs C++ name lookup. That is I'm actually implying that scope nesting is the first principle that directs C++ name lookup rule, and things like ADL are local deviations that reserve occasional confusions (I already mentioned that, but since you don't read Boost mailing lists you probably have missed the mention to that deviation). And those deviations are causing many confusions for many people. Two weeks ago, I had a serious discussion on that topic with Bjarne [ any discussions that followed on the CWG reflector were purely coincidental, but the fact he brought up an example he thought should be covered by nesting effect is, I guess, a sign that he thinks, scope nesting guides C++ name lookup rules. That guidance is not full, as examplified by local barnacled rules, but for the most majority part, it is the guiding principle. ] | not the case though (using directives, using | declarations, and ADL don't work that way; inheritance | doesn't really work that way either). Whowever they have been worded to display the effect of nesting scopes (except access-checking for using-declaration at class-scope). | Anyway, as many have pointed out, enabling sound | C++ engineering requires the current situation to | be fixed. As you know (since we have been discussing this issue for some time now), I don't disagree with the idea that something should be done. I disagree on the -specific- suggestion of parallel scope or enclosing scopes being injected into enclosed scopes. Did I disagree that anything should be done, I would not have made the proposal in the first place. -- Gaby

2 1

RE: [boost] FC++ Lambda
by Powell, Gary 17 Feb '04

17 Feb '04

> >> bind(delete_ptr(), _1) > > std::for_each( tests.begin(), tests.end(), delete_ ); > That is nice. I wonder why BLL didn't do this instead of delete_ptr()? *) Because I didn't think about using trailing "_" until I saw Joel use them with spirit. *) And because what to you call delete_array() ? (overload operator[T] ? for delete_ ? (With actually trying to code this:) std::for_each( tests.begin(), tests.end(), delete_[noop] ); Yours, -Gary-

1 0

Doc error on Getting Started page
by Jody Hagins 17 Feb '04

17 Feb '04

On the page (http://www.boost.org/more/getting_started.html) the following text (under the Build/Install section)is inaccurate. There are additional options as supported by Boost.Build and Boost.Jam. Of the additional options perhaps the most imporant is "-sBUILD=<features/variants>" which lets you override what is built by default. The "<features/variants>" value is a list, separated by spaces, of build requests. Features take the form of a tag and a value or values. And variants are single symbolic names for a collection of features. For example the default is to request "debug release <runtime-link>static/dynamic <threading>single/multiple", in which "debug" and "release" are variants, and the rest features with two values each. The main problem is that this is considered (by myself and maybe others) as an example. However, actually issuing this command does not properly build multithreaded code. The jamfiles apparantly interpret "<threading>multi" differently from "<threading>multiple" and we do end up with a "<threading>multiple" set of libraries, but they are not built with threading enabled. To get threading enabled, one must use "<threading>multi" instead. This brings up another issue. Should the jamfiles correctly accept threading attributes which are not properly interpreted? Since I am not a jam expert, and have no idea how difficult this is to fix, I'll leave it alone, and make sure my incantations are properly formed. However, it should be addressed in some form, especially since the official docs even seem a bit confused.

2 2

Serialization16 - xml_oarchive std::string representation
by Robert Ramey 17 Feb '04

17 Feb '04

Jeff Flinn wrote: >Knowing next to nothing about xml, I'm surprised by xml archive file that >I've generated which expresses std::string as in the following example: ><item> > <count>3</count> > <item>65</item> > <item>108</item> > <item>108</item> ></item> >which corresponds to std::string("All") >Is this intended? Is this representation configurable? The demo_file.xml >does not use this representation, rather it generates strings in the form: > <street1>24th Street</street1> >Needless to say the former representation is not very space efficient. For >a text archive of 1.2MB I get an xml archive 21.5MB. Hmmm were you sure to included boost/serialization/string.hpp (or maybe it should be left out). In any case the intention is that strings be automatically represented in a readable way and I would be curious as to how you accidently managed to get around that code. >I am unable to compile(VC7.1) the demo_xml_save project with the following >error: >Compiling... >demo_xml_save.cpp >c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : >fatal error C1055: compiler limit : out of keys This is an issue with the VC 7.1 compiler under the IDE. I had the same thing using VC 7.0 . Its amazing to me they could ship this product without fixing this. I love the MS IDE but it has lots of annoying features of this type. Anyway, this problem doesn't appear when you build with the command line. Also I've had good luck in making it go away by cleaning the projects and rebuilding. If all else fails you can redefine certain macros such as assert with something like: #undef assert #define assert(x) x Which will effectively comment out the asserts which provoke the problem. Robert Ramey

2 1

Boost Lambda Doc Buglet
by Stephan T. Lavavej 17 Feb '04

17 Feb '04

In Table 1 of http://boost.org/libs/lambda/doc/ar01s05.html#sect:construction_and_destruct ion it says: destructor()(pa) pa.->A(), where pa is of type A* That should probably say ~A(). Stephan T. Lavavej http://nuwen.net

2 1