February 2004 - Boost - lists.boost.org

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

18 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 18 Feb '04

18 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

Re: Three questions about the new license
by David Abrahams 17 Feb '04

17 Feb '04

"Diane Cabell" <dcabell(a)law.harvard.edu> writes: > "David Abrahams" <dave(a)boost-consulting.com> wrote: >> >> Diane, I want to clarify something you may have missed: the point in >> question does not concern the Boost license itself, but the way in >> which our source files declare the license to be applicable to them. >> They do not contain a copy of the license, but instead make reference >> to it in a comment, typically: >> >> // Copyright David Abrahams 2004. Use, modification and distribution is >> // subject to the Boost Software License, Version 1.0. (See accompanying >> // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > No, I didn't understand that. > > You could just say > // Copyright David Abrahams 2004 and made available subject to the terms of > Boost Software License, > // Version 1.0. (See accompanying > // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > Thanks, that seems less prone to misinterpretation to me also. Would // Copyright David Abrahams 2004. Distributed under the Boost // Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) do just as well? It's just just a little less wordy -- "made available subject ot the terms of" sticks in my craw a bit. > (....) >> > David Abrahams wrote: >> > >>(....) >> >> Ugh I don't think we ever considered that "display" would be >> interpreted other than to mean "display publicly". Does that mean >> that in the license: >> >> Permission is hereby granted, free of charge, to any person or >> organization obtaining a copy of the software and accompanying >> documentation covered by this license (the "Software") to use, >> reproduce, display, distribute, execute, and transmit the >> Software, and to prepare derivative works of the Software, and to >> permit third-parties to whom the Software is furnished to do so, >> all subject to the following: >> >> "display" ought to be "display publicly"? > > Yes. But again, private display doesn't require permission, so a > court would likely interpret this to language to mean "public > display." If it went to court, you'd get to testify as to that > intention. So IIUC, changing the license wording isn't critical. We should probably wait 'till a critical issue comes up before making any non-critical changes. >> This is what makes me think you might have missed the fact that "use, >> modification and distribution" isn't in the license itself. The >> suggestion is that "use, modification and distribution" be removed >> from source files to avoid having to repeat all the rights named in >> the license. > > Yes, I did miss that. I think it will be solved by deleting reference to > any specific rights in the comment. Great. >> >> (....) >> >> Sorry, I think I was just bringing up a linguistic technicality. >> >> These are all copyrightable files. The question is whether a *thing* >> >> can be subject to a license, or only actions that might be performed >> >> on that thing. That's why I suggested "licensed under ... " instead >> >> of "subject to ... ". >> > >> > Copyright licenses copying; patents protect operations. Since patent >> > rights were only recently recognized for pure software, the line is >> > not really clear in a lot of cases. Interpretation of the licenses >> > isn't just limited to the linuisitics, however, but looks at the >> > purpose the agreement is trying to accomplish, what people in the >> > trade normally intend to happen in such situations, etc. >> >> I'm not sure how to apply that information to our situation. My >> remark about "subject to" was akin to saying "I think you're using a >> noun as a verb; here's a way to phrase it that avoids grammatical >> problems." > > Then I still don't understand your query. The file is a thing and you are > licensing rights to use the thing. The rights are verbs, permitting people > (or machines) to perform certain activities using the thing. Both of them > are subject to the license. I think we're OK. Maybe Devin has another > perspective. > dc Great, thanks for all your help. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Serialization16 - xml_oarchive std::string representation
by Jeff Flinn 17 Feb '04

17 Feb '04

Robert, 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. 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 Thanks, Jeff

1 0