- Boost - lists.boost.org

Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

I have searched the list archive and have not found anything on this subject. I have what looks like to be an issue with MSVC7.1 and unnamed namespaces (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) See below: #include <boost/bind.hpp> #include <boost/Lambda/lambda.hpp> // adding my code to the boost::lambda namespace // below works fine namespace boost { namespace lambda { void MyFunction() { using namespace std; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below works for_each(v.begin(), v.end(), std::cout << _1 << ' '); } } } // Now global namespace void MyFunction() { using namespace std; using namespace boost; using namespace boost::lambda; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below fails with a "error C2872: '_1' : ambiguous symbol" for_each(v.begin(), v.end(), std::cout << _1 << ' '); // This line DOES work for_each(v.begin(), v.end(), std::cout << boost::lambda::_1 << ' '); } Has anyone else run into this? Also- I do not have the current CVS tree handy (I am using 1.31), is this a problem on 1.32? If it is workedaround in some fashion, I can just qualify every _1 and _2 until 1.32 comes out. Thanks for any help or suggestions Brian Braatz

4 5

Re: MPL - mpl::sequence to std::sequence
by Jaap Suter 10 Oct '04

10 Oct '04

>Yeah, I guess Aleksey and Dave have been busy with >the forthcoming MPL book, but as I understand >from list postings, the MPL docs will be updated in >Boost 1.32, and mpl::for_each is one of the more useful >components. Since it's not documented, I learned how it >works from Aleksey. The following works with your code: Thanks! A lot better than my code :).

1 0

RE: [boost] Re: Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

> "Brian Braatz" <brianb(a)rmtg.com> writes: > > > I have searched the list archive and have not found anything on this > > subject. > > > > I have what looks like to be an issue with MSVC7.1 and unnamed > > namespaces > > (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) > David Abrahams Writes: > Don't you mean in Boost.Bind? [Brian Braatz] Yes, sorry, my mistake.

1 0

[Boost-bugs] [ boost-Bugs-1043616 ] boost::rational documentation typos(?)
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043616, was opened at 2004-10-09 08:53 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=1043616&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::rational documentation typos(?) Initial Comment: <http://www.boost.org/libs/rational/ rational.html#Integer%20Type%20Requirements> states: "I must be an integer-like type, that is the following expressions must be valid for any two values n and m of type I, with the "expected" semantics. [...] n / m (must truncate, and n/m must be positive if n and m are positive)" I doubt that that is what boost::rational requires. int n = 1; int m = 3; int n_over_m = n/m; if( n_over_m > 0) { std::cout << "all OK\n"; } else { std::cout << "Can't use 'int' as base type for boost::rational\n"; } <http://www.boost.org/libs/rational/rational.html#Constructors> states: "Rationals can be constructed from a pair (numerator, denominator) of integers, or a single integer" I think that the documentation should read: "Rationals can be constructed from a pair (numerator, denominator) of I's, or a single I" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043616&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

3 5

[Boost-bugs] [ boost-Bugs-1043942 ] boost::serialization - strings with '&' character included
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043942, was opened at 2004-10-10 04:06 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=1043942&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::serialization - strings with '&' character included Initial Comment: The issue is related to xml serialization only. I am trying to serialize strings with & character included. When I am trying to deserialize such a string, everything after '&' just disappeared. Also I noticed that serializer doesn't convert '&' to xml entity '&'. I guess it should. However it converts from amp entity when deserializing. Even if I convert '&' to xml entity manually, the problem still occur. As I found debugging the source code, the problem happens because of wrong spirit rule in basic_xml_grammar.ipp file: CharData = (*(anychar_p - chset_p(L"&<"))) [ append_string< StringType, BOOST_DEDUCED_TYPENAME std::basic_string<CharType>::const_iterator >(rv.contents) ] ; when I deleted '&' I was able to deserialize strings with '&' at least. I do not know how it can affect other aspects of deserialization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043942&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

true64cxx regresion reports
by Fernando Cacciola 10 Oct '04

10 Oct '04

Hi, While adding failure markups, I noticed that the Optional library is shown as failing with true64cxx. However, looking at the error I can see that it is using an older version of the library (one which indeed is defective) I'm also seeing similar results for this toolset and the Numeric Conversion Library Can anyone fix this? TIA Fernando Cacciola SciSoft

4 7

The Concept Traits Library: naming - opinions sought
by Terje Slettebø 09 Oct '04

09 Oct '04

Hi all. In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious. The library will be put in a CVS at the http://www.neoscientists.org/ server, and we're not sure how to deal with the maximum filename length. The current directory structure is, e.g.: #include <boost/concept_traits/std/is_default_constructible.hpp> #include <boost/concept_traits/std/is_random_access_container.hpp> #include <boost/concept_traits/std/is_random_access_iterator.hpp> #include <boost/concept_traits/std/is_generator.hpp> Tobias suggested the following (the "model" part is still not decided, and may be considered separately): #include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp> The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>. To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there. The same goes for PP-lib. However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject. What do you think? Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits) and "utility" (for components to define new traits), so "model" might more clearly separate out that these are the concept traits, themselves. Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular). Regards, Terje

6 11

Re: [boost] Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 09 Oct '04

09 Oct '04

In-Reply-To: <ck6la2$kki$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > Conclusion: disallowing 0 will not only lead to simpler, safer > programs, but it will probably also boost performance. The null object pattern can only be used if all the object's member functions have trivial post-conditions. If instead I have code like: dog.walk_to( pTree ); assert( dog.location() == pTree ); // ... more code assuming the dog's location. then it is not going to work with a null_dog. If people use it anyway there will be tears before bedtime. Of course, this is no more an argument against ptr_vector<Dog> than it is against std::vector<Dog>. I think the problem here is the name. "ptr_vector" sounds so much like a vector of pointers that people expect null pointers to be supported. There is a gap between what those people want and what ptr_vector supplies. The null object pattern is not a solution here. It just papers over the crack. -- Dave Harris, Nottingham, UK

2 1

shared_object
by Andy Little 09 Oct '04

09 Oct '04

Hi, Any interest in a shared_object? In this case its the object that is shared, not the pointer.... Nah... too obvious ;-) regards Andy Little

3 5

Trial history file; error in Boost CSS file
by Daryle Walker 09 Oct '04

09 Oct '04

I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? Pretend that the file is at 'BOOST_ROOT/more/version_history.html'. The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. The problem is in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: <p>Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah.</p> That way people who need the default space-collapsing attribute of CODE (like me) don't get screwed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0