February 2005 - Boost - lists.preview.boost.org

[range] iterator_range fixes for gcc-2.95.x
by Jonathan Turkanis 09 Feb '05

09 Feb '05

Hi Thorsten, I see that gcc-2.95.x is not one of the supported platforms for range, and I assume that there is a good reason for this. However, I have a couple small changes to iterator_range which will make it work well enough on gcc-2.95 for the purposes of the iostreams library, and I'd like permission to commit. I also added some fixes for Intel. Here are the tests I've conducted: VC7.1: passes all tests but mfc Intel 8.0 (windows): passes all tests but mfc Borland 5.6.4: passes all tests but mfc and array (failure in Boost.Test) GCC 3.4.1: passes all tests but mfc GCC 3.2 (MinGW): passes all tests but mfc VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing) Also, I've updated mfc/cstring and carray to use the new metafunction names, and made some fixes so that they compile on windows, but have not tried linking them. Jonathan

3 4

RE: [boost] class diagrams for template heavy design
by Randy Bowen 09 Feb '05

09 Feb '05

There's an Eclipse plug-in available for feature modeling, described in a paper by Czarnecki (http://www.swen.uwaterloo.ca/~kczarnec/etx04.pdf) > -----Original Message----- > From: Iain K. Hanson [mailto:ikh@hansons.demon.co.uk] > Sent: Tuesday, February 08, 2005 6:05 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] class diagrams for template heavy design > > On Sun, Feb 06, 2005 at 08:57:30AM -0700, Jeff Garland wrote: > > On Sun, 06 Feb 2005 07:32:53 +0100, Vasco Lohrenscheit wrote > > > > > > > Also, if you are willing to go outside UML pick up a copy of > > Generative Programming -- they describe other visual > modeling techniques. > > > > Czarneecki, Krzysztof and Eisenecker, Ulrich, "Generative > Programming: > > Methods, Tools, and Applications", Addison-Wesley, 2000 > > There are no case tools that I know of that do this but the > techniquck is callled FODA ( Feature oriented Domain Analysis > ). I think Don Batory at utexaqs first came up with it. It is > closley associated with a method called GenVoca. Krzysztof > Czarnecki wrote a book and his web page has a downloadable > chapter on FODA. > > I don't know if it is still there but Beman Dawes wrote an > article on how to do this on the boost site. > > Take care > > /ikh > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

class diagrams for template heavy design
by Vasco Lohrenscheit 09 Feb '05

09 Feb '05

Hi, sorry if this offtopic, but I don't know any other good place to ask this question: I'm currently in the situation to document a heavy templated class design (generic with templated policies and partial specializations, but nothing too exotic like boost::mpl ;-). I always prefer graphical UML like class diagrams to describe the basic design. Now I wonder if there are any good graphical representations for templated code but haven't found anything on this with a quick google search. As there are so many template wizards on this list, has someone any hints, links, suggestions on this? Thanks. best regards, Vasco Lohrenscheit

3 2

[serialization] automatic linking and intrusive serialization support
by JOAQUIN LOPEZ MU?Z 08 Feb '05

08 Feb '05

Suppose I'm the user of a class called foo which supports serialization through intrusive methods. So, foo.h will look like: // foo.h #include <boost/serialization/access.hpp> // other, non serialization-related includes class foo { ... }; Now, a programmer uses foo, but does not take advantage of its serialization capabilities. // user.cpp #include <foo.h> // use foo and a second programmer uses foo *and* serializes it. //user2.cpp #include <foo.h> #include <boost/archive/text_oarchive.hpp> // use foo and its serialization capabilities. So far so good. Boost 1.33 release of Boost.Serialization, if I'm not wrong, will include automatic linking, and here comes the problem: when doing the upgrade to 1.33, user2 will be delighted that he'll no longer need to do the linking stuff by himself; but user1 will get mysterious "not found" linking errors, or worse yet, he'll have Boost.Serialization automagically bundled into his final executable, when he never explictly dealed with this lib in the program! Of course, user1 can set BOOST_SERIALIZATION_NO_LIB and be done, but this is a burden which I'd like to save users from, if possible. So, here comes the question. Suppose the implementer of foo changes foo.h as follows (please bear with any preprocessor mistake by my part if there's any, I hope you get the point nonetheless): // foo.h #if defined(BOOST_SERIALIZATION_DYN_LINK) # define BACKUP1 #endif #if defined(BOOST_SERIALIZATION_NO_LIB) # define BACKUP2 #endif #undef BOOST_SERIALIZATION_DYN_LINK #define BOOST_SERIALIZATION_NO_LIB #include <boost/serialization/access.hpp> #if defined(BACKUP1) # define BOOST_SERIALIZATION_DYN_LINK #endif #if defined(BACKUP2) # define BOOST_SERIALIZATION_NO_LIB #endif // other, non serialization-related includes class foo { ... }; Now, if my idea is correct, user1 won't get Boost.Serialization autolinked (since <boost/serialization/access.hpp> was included with BOOST_SERIALIZATION_NO_LIB), and user2 will benefit from autolinking, as he included another Boost.Serialization header on his own. The best of both worlds. Do you think this approach would work? Any foreseeable problem? Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[probing interest]AssocVector (and other parts of Loki)
by Mikhail Glushenkov 08 Feb '05

08 Feb '05

>From my experience, the main parts of Loki that people are missing in Boost are: a) Singleton b) policy-based smart_ptr c) AssocVector d) Factories e) (rarely)Visitor Nobody uses multimethods apparently. Since there are people working on a, b, d and e, I would like to ask the following questions: 0) Are you interested in adding AssocVector to Boost? (there seems to be at least _some_ interest[1]) 1) Is there interest in additional interfaces(set, multiset, multimap) described in [1] or is std::map-like container enough? 2) What other parts of Loki you would like to see in Boost? [1]http://article.gmane.org/gmane.comp.lib.boost.devel/116873

5 8

Type mismatch warning in multi_array::subarray
by Mark Ruzon 08 Feb '05

08 Feb '05

In boost_1_32_0, I often get a type mismatch warning in the MSVC++ 7.1 compiler in the end function of multi_array::sub_array: iterator end() { return iterator(*this->index_bases()+*this->shape(),origin(), this->shape(),this->strides(),this->index_bases()); } index_bases() appears to return a signed quantity (index*), while shape() appears to return an unsigned quantity (size_type*). Their sum is unsigned, but iterator takes a signed type as its first argument. Does anyone see a problem with casting the result to type index until a fix is made? I don't like disabling warnings.

1 0

io state and multi-restore
by Gennadiy Rozental 08 Feb '05

08 Feb '05

Is there a way to use io state savers in single save/multiple restore mode? Gennadiy

3 9

Re: More on Serialization Link Issue
by Jared McIntyre 08 Feb '05

08 Feb '05

> If you do discover that this is indeed the problem, you would have two > choices: > > a) rebuild the libraries with wchar_t set to be the same as a 16 bit > integer. > b) alter your app to use wchar_t as an intrinsic type. > > Personally I would recomment the latter. VC 8.0 uses wchar_t as an > intrinsic type so you're going to be on the losing side of the tide of > history if you don't make the change. Your program will be more correct and > more portable as well. And you'll have less problems like this in the > future.. I am using VC7.1, and I ended up having to go with solution A. I agree with you that solution B is a much better solution, but I'm afraid I will have to deal with that another day -- when management is more malliable 8-) Thanks for the help and the excellent library, Jared

1 0

Re: [boost] Re: Re: Re: Boost Profiler Proposal
by brangdon＠cix.compulink.co.uk 08 Feb '05

08 Feb '05

In-Reply-To: <001d01c50d76$7f669b20$d9958242@heronnest> cdiggins(a)videotron.ca (christopher diggins) wrote (abridged): > stop() and resume() are not part of the design. > > You would write the above code as: > > { > { > basic_profiler<collecting_policy> p("profile1"); > // some code > } > // some other code we do not want to profile > { > basic_profiler<collecting_policy> p("profile1"); > // continue profiling > } > collecting_policy::generate_report(); > } > } It seems to me the tail is wagging the dog here. The RAII class is no longer a helper but a hinderance that we have to work around. Your suggestion of adding block-scopes will not work if the first code declares variables that are used by the second block. For my own profiling I have a class which is effectively an array of timers, that can be stopped and started arbitrarily. RAII, when I need it, is a thin layer on top of that - but usually I don't need it. What I sometimes need instead is fairly sophisticated interactions between timers, eg starting one timer implicitly pausing the previous one. -- Dave Harris, Nottingham, UK

1 0

[boost] inspect tool updated, violations of min/max guidelines found
by Eric Niebler 08 Feb '05

08 Feb '05

I just updated the Inspect tool to find violations of Boost's min/max guidelines (which you can find at http://boost.org/more/lib_guide.htm#Guidelines) I just ran the tool with the new -minmax switch to find all the violations in CVS-current. I've attached the report. Some of these are false positives -- violations in comments -- but most look legit. Below is the summary: Library Problems -----------------+---------- algorithm 2 archive 2 config 2 conversion 2 date_time 4 detail 1 graph 20 iostreams 16 multi_index 2 numeric 24 program_options 4 regex 14 serialization 1 spirit 6 -- Eric Niebler Boost Consulting www.boost-consulting.com /G53G29: Permission denied

1 1