- Boost - lists.preview.boost.org

RE: [boost] [Signals] Named slot group usage?
by Brian Braatz 11 Feb '05

11 Feb '05

Below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Friday, February 11, 2005 10:34 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Signals] Named slot group usage? > > > On Feb 11, 2005, at 11:49 AM, Peter Dimov wrote: > > > Doug Gregor wrote: > >> On Feb 11, 2005, at 9:51 AM, Peter Dimov wrote: > >> > >>> Douglas Gregor wrote: > >>>> Background: Signals performance is sub-par, and much of the problem > >>>> can be traced back to support for named slot groups. I'm trying to > >>>> determine the best way to proceed. > >>> > >>> Are you sure that this is the case? > >> > >> There may be other issues, but going from a std::list to a std::map > >> (as needed to efficiently support connection of named slots) hurts > >> iteration performance and increases executable code size. To counter > >> the latter problem, I've done some type erasure that slows it down > >> further and causes some of the extra heap allocations :( > > > > You mean disconnection of named slots, right? List connection is O(1), > > map - O(log N). You get ordering for free with a map, sure, but this > > is a separate issue. > > Both connection and disconnection of named slots are O(lg N), since we > need to keep the whole list ordered when named slots are present. > Connection/disconnection of unnamed slots is O(1) now. > > Iterating through a map really is slow, though... loops in operator++ > really hurt us. I've tried a few times to come up with some ultra-slick > formulation using a list for primary storage and a map indexing into > the list... but I've always failed to deal with the iterator > invalidation issues. > > > Anyway, I'm sure that few people would miss named slots. > > That's what I'm trying to figure out; but I suspect that you're right. > > > Lets' drop them. :-) > > You're not the only one to say that :) > > Doug [Brian Braatz] What about allowing the internal type to be policy\traited? i.e. I can use a vector instead of a map<> and is it possible to allow for meta-data while you're at it? Sincerely, Brian "wants the world on a silver platter" Braatz ;)

2 1

[fsm] Preliminary formal review version available
by Andreas Huber 11 Feb '05

11 Feb '05

Dear Boosters If everything goes according to plan, the fsm review will start on the 21st of February. A version that I expect to be *very* close to what will be available during the review period is available here: http://boost-sandbox.sf.net/fsm.zip The docs can also be browsed online: http://boost-sandbox.sf.net/libs/fsm This version has undergone testing on MSVC7.1 and various GCC versions. Tests on Intel are in progress. Results of tests on other compilers are very welcome. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

See below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Friday, February 11, 2005 6:51 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Re: Re: Latest version of the profiler > > ----- Original Message ----- > From: "Brian Braatz" <brianb(a)rmtg.com> > > I might want to accumulate ALL of the calls, in one big honking list. > > You can already do that in a few different ways: > > 1) simply naming all of the profiles the same, > > 2) writing a new stats policy, > > 3) write: > > { > stats_map::iterator i = default_stats_policy::stats::begin(); > counted_sum cs; > while (i != default_stats_policy::stats::end) { > cs += *i++; > } > cout << "total profiler entries : " << cs.first << endl; > cout << "total elapsed time : " << cs.second << endl; > cout << "average time per profile : " << cs.second / cs.first << endl; > } > > 4) I could simply add some features to the default_stats_policy, if that > is > more appropriate. > > I don't know what the best option is. > > > Or > > I might want a "overview" of the average of each profile point. > > Currently also already provided in the default_stats_policy, if I > understand > you correctly. [Brian Braatz] YES- current implementation already gives me an average of the profile points. > > > I think we need both, in addition to allowing me to put metadata into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > I am seriously considering the metadata idea. > [Brian Braatz] BIG GRIN :) > I agree with your earlier ideas that the identifier for a profile should > not > be restricted to a char*. > A problem with the current design is that a by passing a type for the > profile idenitifer affects not just the profile, but also the stats policy > and the log policy. In this case of having three dependant policies, I > would > far prefer to have a single profile_management policy. This is not a huge > problem however. > > Thanks for your suggestions, > Christopher [Brian Braatz] Personally- I don't think having one honker policy object is the end of the world. In this case it is appropriate because the independent policies are somehow implicitly "bound" by concept. If they were not, I would argue for separate policies. Please check out the multi-index idea post earlier by me :) (that may give the flexibility, with just a little extra work, to make the profiler be "better than off the shelf". Which to me, is what Boost libraries are about :) )

1 0

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > > On Thu, 10 Feb 2005 17:33:19 -0700, Brian Braatz <brianb(a)rmtg.com> wrote: > > Yes- those are the words I was trying to say. > > > > I might want to accumulate ALL of the calls, in one big honking list. Or > > I might want a "overview" of the average of each profile point. > > > > I think we need both, in addition to allowing me to put metadata into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > > > ** this is the big piece that is missing for me from off the shelf > > profilers ** > > smells like mixins to me. something like this would be apropriate (pseudo > code)? > { > profiler< log_all< log_overview<> > > prof; > // profiled code > } > > Sérgio [Brian Braatz] Hmm.. I think so. As long as there were enough methods available to me in the right fashion to allow the weave above to be able to do that. That answer would require more study. Part of the issue though, is I cannot put the metadata in, so the log_overview<> implementation might be convoluted since it is trying to double track things. Please see my next mail suggesting multi-index- I THINK that would speak to the issues I am talking about and it would give the users enough power to be able to use the profiler in MANY different ways.

1 0

What about Multi-Index? \ RE: [boost] Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

(Responding to my own post again. I guess I am one of those guys who could sit in a closet and carry on a conversation with himself) :) (Joaquin: ARE YOU OUT THERE?- Your thoughts appreciated) Was thinking about this more last night. I have NOT had deep experiences with the multi-index container from Joaquin Munez. So please excuse me if this is a bad idea. :) I am posting this as a question- What if instead of a map, you used Boost.MultiIndex container?. Then exposed the configuration of that to the users of the profiler. I propose you have a "stock, out of the box" simple version of profiler that "just works" with minimal work by the user. But also allow the user to re-configure the multi-index you are using internally. What this will buy: - The profiler now has multiple "views" - The different "ways" of looking at the data can be configured by the user - What I am storing in the profiler is also changeable via policy\traits Why do I want multiple Views? - Well in my example below, multi-index could give me all the operations that occurred with the given file - it could also give me a view that showed the average of all the calls to "savestufftofile()" - I could also JUST have a view that showed all the calls to savestufftofile() where the filename was "splat.txt" TAKING THIS FURTHER: I have not played with it, but Multi-Index supports serialization. You can now do this: * Run the test * Save the profile information * send your internal multi-index to disk * end the testing program * go make some coffee * come back later * run another program which re-serializes the data sent to file into ram again * I can now choose to report on it. Or I may have a "viewer" that I wrote specific to my application which allows me to travel through the different views of the multi-index container. SCOPE: All I am proposing is a heavily traited\ policy based implementation that uses multi-index and supports me giving it MY TYPES for id and metadata and configuring multi-index I am not proposing you write a viewer or what have you. But if you DO support this by design, I can now user your profiler class until the end of time because it does everything I could ever need until I die. (sorry for quoting all of below- it is relative to the conversation above) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Thursday, February 10, 2005 4:26 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Latest version of the profiler > > > > > -----Original Message----- > > [Brian Braatz] Wrote: > > > I for example- MIGHT take your library and stuff __FILE__ __LINE__ > into > > > the id. For this I would use a macro. This is also why I made the > > > request for the char*name type to be a template param. I may want to > > > plop in my own struct that has the __FILE__ and __LINE__ in it. > > > > The current implementation uses a map<string, pair<int, double> > for > > gathering of stats. This makes it easy to access data by profile name > and > > to > > accumulate data for a named profile. Of course this could be > rewritten, > > but > > my goal is to do as little work as possible. ;) > > > > Christopher Diggins Wrote: > > What if instead you wrote: > > > > #define PROFILE(TKN) BOOST_PROFILE(#TKN##__FILE__##__LINE__) > > > > Or better yet: > > > > #ifndef BOOST_PROFILING_OFF > > map<string, pair<int, string> > my_map; > > #endif > > > > #ifndef BOOST_PROFILING_OFF > > #define PROFILE(TKN) mymap[#TKN] = pair<int,string>(__LINE__, > __FILE__); > > BOOST_PROFILE(#TKN); > > #else > > #define PROFILE(TKN) /* */ > > #endif > > > > Would these be acceptable alternatives? > > > > [Brian Braatz] > I spent a little more time (that I really don't have today but the boost > mailing list "Draws me in..." :) ) Looking at your code at: > > http://www.cdiggins.com/profiler/profiler.hpp > > One thing that AT FIRST looked problematic for my usage is this: > > typedef map<string, counted_sum> stats_map; > > .... > > struct default_stats_policy > { > static stats_map stats; > > ... > > But, then I realized this is in a default Policy. So I can change that > (cool). I need to track on a per-thread basis each thread's profile > information. > > Hmm... > > On the metadata issue, things I need to track > __FILE__ > > > > I have the following needs: > 1- I have some code that is using wstring for everything else. > So the std::string seems weird here (yes I know boost is not completely > wstring compatible). > 2- I need to store BOTH the "average" for that area of code, and > also track the history of all the calls. I.e. look at the profile for > the last time we were in that function > 2- I need to be able to plug a structure of my metadata in there > somewhere. > - This will allow me to after the fact, scan the map and > find "sets" of profile information based on my specific stuff. > Examples: > Stuff threadID in there, so "later" I can filter > out just the stuff for that thread. > At runtime, set a particular flag on the > metadata based on a business condition in the code. > > > What I would like to see in the profiler: > > * An ability to give it something other than std::string for the KEY > type of the map > * An ability to track these readings in a list with my metadata > > Examples: > > Struct ProfileDataFileOperations > { > string sId; > std::string sFILE; > int iLine; > string sfiletouched; > > MyProfileData(string id, string file, int line,string > sFileYouTouched) > : sId(id), sFILE(file), iLine(line), > sfiletouched(sFileYouTouched) > {} > Bool operator==( ProfileDataFileOperations const & other) > { > return sId == other.sId; > } > } > > void savestufftofile(std::string sfile) > { > FileOpProfiler > > p(ProfileDataFileOperations("savestufftofile",__FILE__,__LINE__, > sFile)); > > } > > I would like to then, go back and generate a report on ALL operations > that touched a specific file. > > I would also like to go back and see all the things that touched > savestufftofile > > I might also want to go back and filter out based upon some other > combination of data. > > The things I am describing fall into my basic issue with using > profilers. They gave you MORE information than you need, without an > easily ability to filter out or cross cut the information. > > So the implementation of what I am suggesting is this: > > * Make the TYPE in the map be a typedef in the policy (the template > could default to std::string) > * allow me to provide my OWN way of storing the information > For above, I might want to keep a big old list > Or maybe I want what you have, but I want to plug a list<> into > the element you are using to track the profile information for a > "thing". > > I am sorry if it feels like I am blowing the scope of what you are > trying to do out of the water. > > I do think with some tweaks, though, you could have a profiler class > that could stand up to most of not all of the "weird" desires of folks > like me :) > >

2 1

RE: [boost] Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

For me, I should be ready in a few weeks to apply the profiler to a rather large body of code and actually use it in production. HOWEVER, I need the functionality approximating what I have previously stated before I can do that. (please see the mail where I suggest Multi-Index as the internal container) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > Sent: Friday, February 11, 2005 5:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Latest version of the profiler > > Hi, > the library evolved a lot since your first proposal, and it seens > very impressive. I agree with you about do not adding new > functionalities, in fact I would even remove some, I´m not > particularly liked the pause/resume thing, but that´s just me. I am > interested in submitting it to boost, but I have to say: I would never > be able to develop it as fast as you been doing, and I never made a > boost submission before, but I would like to give it a try. still I do > thing there is need to polish and stabilize the design a little, > gather some more use cases and document a fill "best pratices" before > trying to submitting it > > Sérgio > > On Thu, 10 Feb 2005 15:48:28 -0500, christopher diggins > <cdiggins(a)videotron.ca> wrote: > > Hey Sergio, > > > > It's nice to have a friendly and supportive voice. So what do you think > of > > the library so far? Personally I don't want to add much more > functionality > > at this time. I am however very open to helping out anyone who wants to > make > > changes and/or take over the responsibility of submitting it to boost. > Is > > this something you still might be interested in? > > > > CD > > > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost.Bind overload failure
by John Maddock 11 Feb '05

11 Feb '05

I'm trying to figure out what the problem is with the following code, given: double test_proc(int a, char b, long c) { return a+b+c; } Then: boost::bind<double>(&test_proc, 0, 0, 0); The code compiles fine with VC7.1 but with gcc-3.3.3 I get: ../../../libs/tr1/test/test_3_6.cpp:65: error: call of overloaded `bind(double (*)(int, char, long int), int, int, int)' is ambiguous c:/data/boost/develop/boost/boost/bind/bind_cc.hpp:47: error: candidates are: boost::_bi::bind_t<R, R (*)(B1, B2, B3), typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(R (*)(B1, B2, B3), A1, A2, A3) [with R = double, B1 = int, B2 = char, B3 = long int, A1 = int, A2 = int, A3 = int] c:/data/boost/develop/boost/boost/bind.hpp:1148: error: boost::_bi::bind_t<R, F, typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(F, A1, A2, A3) [with R = double, F = double (*)(int, char, long int), A1 = int, A2 = int, A3 = int] And with Intel 8.1 I get: ..\..\..\libs\tr1\test\.\test_3_6.cpp(65): error: more than one instance of over loaded function "boost::bind" matches the argument list: function template "boost::bind(R (*)(B1, B2, B3), A1, A2, A3)" function template "boost::bind<R,F,A1,A2,A3>(F, A1, A2, A3)" argument types are: (double (*)(int, char, long), int, int, int) check_bind0(boost::bind<double>(&test_proc, 0, 0, 0), double(0)); ^ Who's correct here? Normally I would trust EDG/Intel to get this correct if anyone would. Thanks, John.

2 1

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > ----- Original Message ----- > From: "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> > >> > 1. Profiler type 1 > >> > Log clock units and report mks into ostream > >> > 2. Profiler type 2 > >> > Log system/user time anf reports into Boost.Test log > >> > > >> > Both profiler I want to be able to use as scoped or accumulating. > >> > > >> > Gennadiy > >> > >> Can you please be more specific. I don't understand what you want and > >> precisely what the problem is. I am pretty sure we have different ideas > >> of > >> what a "report" is and what it means to "log". > > > > 1. Profiler type 1 > > Collect clock units and report mks into ostream > > 2. Profiler type 2 > > Collect system/user time anf reports into Boost.Test log > > > > Both profiler I want to be able to use as scoped or accumulating. > > > > Gennadiy > [Brian Braatz] Yes- those are the words I was trying to say. I might want to accumulate ALL of the calls, in one big honking list. Or I might want a "overview" of the average of each profile point. I think we need both, in addition to allowing me to put metadata into the profile point. Because with the metadata, I can now go back through the accumulated list and filter out what I care about. ** this is the big piece that is missing for me from off the shelf profilers ** > Christopher Diggins Wrote: > > Gennadiy, > > Your post makes almost as little sense as before, simply changing "Log" to > "Collect" doesn't help me out much. What you wrote is virtually > incomprehensible! It seems to me that you aren't really making an effort > to > help me out here. > > What does "report mks into ostream" mean? When do you want to do these > reports? What do you want reported. As far as I can tell you can do this > with my code. Why do you think you can't? How and when do you want to > "collect system/user time"? Why would you want to log it? How would you > report it? And why can't you do this with the current library? Is "anf" > some > kind of acronym? > > If you don't want to take the time to respond to my questions carefully, > and > respectfully than I would ask that you simply don't respond. I am at the > limit of my patience with your negative attitude and lack of courtesy. > [Brian Braatz] Part of the problem with all communication is we all have buzzwords and different ways of phrasing concepts. I know I for one, have a HARD TIME getting an idea typed out (as you will see in my previous post :) ). I cannot speak for Gennadiy, but I believe he was just trying to share his thoughts and I do not think you should get offended. This list is a pretty big thing and we are bound to run into situations where a few lines of text make sense to some but not others. The funny thing, is I saw his post and went "YES! That is what I was trying to say!". Which is a different reaction than you had. Brian

3 2

BOOST_CHECK_THROW gives spirious warning
by Vladimir Prus 11 Feb '05

11 Feb '05

Hello, when running "bjam test" in libs/program_options/test, I get this: ../../../libs/program_options/test/cmdline_test.cpp:472: warning: statement with no effect Line 472 contains: BOOST_CHECK_THROW(cmdline cmd(1, (const char*const *)argv, allow_long), invalid_command_line_style); and I did not touch that line for a long time. I think the warning is caused by some Boost.Test change. Any change to fix this? Thanks, Volodya

2 1

RE: [boost] Re: Profiling Library suggestion
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > Sent: Friday, February 04, 2005 2:45 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Profiling Library suggestion > > christopher diggins wrote: > > I was searching around boost for mention of a profiling library. A > > fellow by the name of Carl Daniels posted something about an invasive > > profiling library. I was wondering in anyone knows what happened to > > that project? Profiling seems lacking at Boost, is anyone else > > interested in such a thing? > > > > Would a trivial policy driven RAII type be sufficient to garner > > interest as > > a mini-library? > > > > e.g. > > > > struct ProfilerDefaultPolicy { > > OnElapsed(int msec) { > > cout << "time elapsed (msec): " << msec << endl; > > } > > }; > > > > template<typename Policy_T = ProfilerDefaultPolicy> > > class Profiler { > > public: > > Profiler() { mnStart = GetTickCount(); }; > > ~Profiler() { Policy_T::OnElapsed(GetMSecElapsed()); }; > > int GetMSecElapsed() { return GetTickCount() - mnStart; }; > > int GetTickCount() { return int(double(clock()) * 1000 / > > CLOCKS_PER_SEC); }; > > private: > > int mnStart; > > }; > > > > usage: > > > > void MyRoutine() { > > Profiler<> p; > > // do stuff > > } > [Jonathan Turkanis]: > How about: > > typedef profiled< MyClass, Interface, Profiler<> > > MyProfiledClass; > > ? [Brian Braatz] That is a good idea (use a AOP style weave). It begs asking here- when we talk about profiling, what are the use cases you guys see. I have some stuff to implement profiling on in the coming weeks. My situations are as follows: * Profile and log the profiling results of my unit tests between the checkpoints -> Either explicitly or I may redefine BOOST_CHECKPOINT * Profile an application for when makes certain method calls on some COM objects- Also log this information. -> Problem is, folks have coded directly to the COM objects proxy class. Because of this, the AOP style typedef trick will not work unless I push the proxy classes into a namespace- and redefine them in the global namespace with a weave in place. (structurally this might be more work than I want to deal with) * profiling specific operations which cross cut many areas of the system and only doing that when certain dynamic conditions exist I am asking you guys for how you need to use profiling because by talking aobut the problem that is to be solved, it might make the discussion of what the solution is easier to address.

4 4

Boost.TR1 implementation take 2
by John Maddock 11 Feb '05

11 Feb '05

Here's an updated version of a TR1 wrapper-implementation for Boost, currently supports chapters 2-5 of the TR, which means: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. But not: Mathematical Special Functions. Rather better looking docs than last time are online at: http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1.html And the full download is at: http://boost-sandbox.sourceforge.net/vault/index.php?direction=0&order=&dir… Feedback welcomed; enjoy, John Maddock

1 0

Feedback for composite_visitor
by Klaus Nowikow 11 Feb '05

11 Feb '05

I am currently evaluating (not testing!) Dave Handley's composite_visitor from the sandbox. It seems to be quite useable so far, I like it. Some thoughts: Instead of providing different functions begin_shallow(), begin_deep() etc. and the corresponding iterator types, I'd provide an iterator template with a "traversal policy", like that: template <class TraversalPolicy> iterator<TraversalPolicy> begin(); The iterators should be implemented using Boost.Iterator, of course. At the moment I could think of these traversal policies: * shallow: like shallow_iterator * postorder: like deep_iterator * preorder: parent node first, then it's children, recursively * ancestor: start node, then it's parent, the parent's parent etc. Does that sound reasonable to you? Best regards, Klaus

1 0

RE: [boost] Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- [Brian Braatz] Wrote: > > I for example- MIGHT take your library and stuff __FILE__ __LINE__ into > > the id. For this I would use a macro. This is also why I made the > > request for the char*name type to be a template param. I may want to > > plop in my own struct that has the __FILE__ and __LINE__ in it. > > The current implementation uses a map<string, pair<int, double> > for > gathering of stats. This makes it easy to access data by profile name and > to > accumulate data for a named profile. Of course this could be rewritten, > but > my goal is to do as little work as possible. ;) > Christopher Diggins Wrote: > What if instead you wrote: > > #define PROFILE(TKN) BOOST_PROFILE(#TKN##__FILE__##__LINE__) > > Or better yet: > > #ifndef BOOST_PROFILING_OFF > map<string, pair<int, string> > my_map; > #endif > > #ifndef BOOST_PROFILING_OFF > #define PROFILE(TKN) mymap[#TKN] = pair<int,string>(__LINE__, __FILE__); > BOOST_PROFILE(#TKN); > #else > #define PROFILE(TKN) /* */ > #endif > > Would these be acceptable alternatives? > [Brian Braatz] I spent a little more time (that I really don't have today but the boost mailing list "Draws me in..." :) ) Looking at your code at: http://www.cdiggins.com/profiler/profiler.hpp One thing that AT FIRST looked problematic for my usage is this: typedef map<string, counted_sum> stats_map; .... struct default_stats_policy { static stats_map stats; ... But, then I realized this is in a default Policy. So I can change that (cool). I need to track on a per-thread basis each thread's profile information. Hmm... On the metadata issue, things I need to track __FILE__ I have the following needs: 1- I have some code that is using wstring for everything else. So the std::string seems weird here (yes I know boost is not completely wstring compatible). 2- I need to store BOTH the "average" for that area of code, and also track the history of all the calls. I.e. look at the profile for the last time we were in that function 2- I need to be able to plug a structure of my metadata in there somewhere. - This will allow me to after the fact, scan the map and find "sets" of profile information based on my specific stuff. Examples: Stuff threadID in there, so "later" I can filter out just the stuff for that thread. At runtime, set a particular flag on the metadata based on a business condition in the code. What I would like to see in the profiler: * An ability to give it something other than std::string for the KEY type of the map * An ability to track these readings in a list with my metadata Examples: Struct ProfileDataFileOperations { string sId; std::string sFILE; int iLine; string sfiletouched; MyProfileData(string id, string file, int line,string sFileYouTouched) : sId(id), sFILE(file), iLine(line), sfiletouched(sFileYouTouched) {} Bool operator==( ProfileDataFileOperations const & other) { return sId == other.sId; } } void savestufftofile(std::string sfile) { FileOpProfiler p(ProfileDataFileOperations("savestufftofile",__FILE__,__LINE__, sFile)); } I would like to then, go back and generate a report on ALL operations that touched a specific file. I would also like to go back and see all the things that touched savestufftofile I might also want to go back and filter out based upon some other combination of data. The things I am describing fall into my basic issue with using profilers. They gave you MORE information than you need, without an easily ability to filter out or cross cut the information. So the implementation of what I am suggesting is this: * Make the TYPE in the map be a typedef in the policy (the template could default to std::string) * allow me to provide my OWN way of storing the information For above, I might want to keep a big old list Or maybe I want what you have, but I want to plug a list<> into the element you are using to track the profile information for a "thing". I am sorry if it feels like I am blowing the scope of what you are trying to do out of the water. I do think with some tweaks, though, you could have a profiler class that could stand up to most of not all of the "weird" desires of folks like me :)

1 0

[mpl] vector_c with enumerators?
by Larry Evans 11 Feb '05

11 Feb '05

Is the following supposed to compile: enum visitor_numerals { visitor_n0 , visitor_n1 }; typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type; it does with intel but with gcc, I get: bjam --v2 toolset=gcc vector_enum_test ...patience... ...found 751 targets... ...updating 4 targets... gcc.compile.c++ ../../../../bin.v2/lje/libs/fields_visitor/test/vector_enum_test.test/gcc/debug/vector_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp: In instantiation of `boost::mpl::vector_c<visitor_numerals, 0l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l>': /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/has_tag.hpp:20: instantiated from `boost::mpl::aux::has_tag<test()::vec_viz_type, mpl_::bool_< false> >' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/sequence_tag.hpp:115: instantiated from `boost::mpl::sequence_tag<test()::vec_viz_type>' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/at.hpp:45: instantiated from `boost::mpl::at_c<test()::vec_viz_type, 0l>' vector_enum_test.cpp:11: instantiated from here /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp:47: error: invalid conversion from `long int' to `visitor_numerals'

3 8

thread_group.count()?
by Preston A. Elder 10 Feb '05

10 Feb '05

Is there any fantastically good reason why there is no way of getting a count of how many threads are being handled by a thread_group? I want to set up a worker thread pool, a new thread is added as the queue size goes up, and it removed itself if the queue size is not enough to warrant it. This mechanism, however, is complicated muchly when thread_group doesn't have a way for me to determine how many threads I currently have, in an effort to ensure the ending the thread will cause it to go below the minimum, or spawning a new one go above the maximum. Obviously, I could write my own thread_group, but I can think of no reason for boost's thread_group to not have a count() method. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 3

Boost Profiler Proposal
by christopher diggins 10 Feb '05

10 Feb '05

I have updated the Profiler (and done some testing using Visual C++, 7.1) at http://www.cdiggins.com/profiler/ . I have mostly decided to freeze the features for the profiler mini-library as described and posted at http://www.cdiggins.com/profiler/ . My question to the group is: would you use this library as it is? If you don't want to mail the group, I would appreciate even just a quick note: yes, no, maybe. If anyone has a POSIX high-resolution timer modeled on the Boost.Timer concept to share, it would be greatly appreciated! I would also appreciate new profiling policies, to include as examples. PS: this profiling tool seems to be a natural fit for the Boost.Test macros like BOOST_CHECK_NO_THROW, I currently use something like: BOOST_PROFILE_AND_CHECK_NO_THROW(TKN) BOOST_CHECK_NO_THROW(BOOST_PROFILE(TKN)) Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

6 16

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > Subject: [boost] Latest version of the profiler > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > [Brian Braatz] Hahahahaha " Macros were avoided because everyone knows macros are evil, unless we are the ones writing them." I LOVE THIS LINE. Please keep it in :) On a serious note though, with your lib done the way it is , if someone WANTS macros, there is nothing preventing them from having them. I for example- MIGHT take your library and stuff __FILE__ __LINE__ into the id. For this I would use a macro. This is also why I made the request for the char*name type to be a template param. I may want to plop in my own struct that has the __FILE__ and __LINE__ in it.

2 1

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > > If you have brought an issue up previously (or think of a new one) which > you > feel is a significant omission of this library and would affect whether or > not you could use it, please feel free to bring it up again. > > I am still looking for a posix high-resolution timer. Hartmut suggested a > couple of Posix timers which he got off of Google, which unfortunately > were > unusable: one was GPL'ed and the other lacked source code. Gennadiy said > there were some on the mailing list (I couldn't find ), and that he uses > one > in the CVS but I don't know how to use the CVS. I also can not test Posix > timers, since I only use visual C++. I believe that perhaps > boost::date_time > contains a good resolution timer, but I can't tell. > [Brian Braatz] Christopher, I really like the way this is shaping up. I encourage you onward :) I am in the thick of some deep work things right now and will not be able to really play with this for a week or two, but by reading the docs it looks like it would be very usable for the types of problems I have with profiling. Suggestion \ Comments: A suggestion would be to make the TYPE for the name be a template param. (or maybe a typedef in the policy). For my needs, I need to store a structure in this place and not just a string. This goes back to the meta-data discussion awhile back. I believe the users of the library need to be able to give you the type to store for the id, this way I can use whatever ID concept I need to, and it means I can store extra metadata in that (without having to look it up in a separate map<> or something)

1 0

Re: boost::rtl / rel where can I get some more infos
by Vinzenz Feenstra 10 Feb '05

10 Feb '05

What do you think, how long it would take that rtl would be released with boost? ( I know I am asking too much but this would be the last question) BR and Many thanks Vinzenz

1 0

function_traits
by Joel de Guzman 10 Feb '05

10 Feb '05

Hi, I find the interface: function_traits<F>::arity function_traits<F>::result_type function_traits<F>::argN_type (especially the last) awkward in TMP code. In the interest of not having metafunction blobs, I'd suggest the interface: function_arity<F>::value function_result<F>::type function_arg_c<N, F>::type function_arg<mpl::int_<N>, F>::type In particular, I need the function_arg(_c) metafunctions. It is very awkward to get the Nth function argument, given a constant N. Thoughts? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 6

Release 1.33
by Robert Ramey 10 Feb '05

10 Feb '05

I would hope that soon we might think of releasing an updated version of boost - 1.33 As far as I know this might include a)bug fixes for herefore untested combinations of compilers, varients, etc b)Jonathon Turkanis stream bufffer library c)Other libraries (Ranges?) d)Serialization library - bugfixes and DLL version Robert Ramey

6 15

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: woensdag 9 februari 2005 17:23 > To: boost(a)lists.boost.org > Subject: Re: [boost] Wave C++ Review Begins Today - February 7, 2005 > ... > Even dereferencing *last could be a bug, if it is > past-the-end. For iterators referencing contiguous memory > (vectors and pointers only, as you've said), one would need to write > > scanner.last = scanner.first + std::distance(first, last); True, but that's an partial fix. For now, I've fixed that bug too in my vector<char> wrapper but it's becoming complex. I'm afraid someone will have to write re2cpp. > > I really have to say Dinkumware did a fine job here, this > would have > > been very hard to find without these checks. > > FWIW, STLport and newer versions of GCC (Apple GCC 3.3, FSF > GCC 3.4) have similar debugging modes. They've been > invaluable in rooting out subtle bugs like those that stem > from iterator invalidation. Yep, although I'm currently wondering if they're 100% right. Is it legal to compare iterators from different containers? I can't find the appropriate wording so I'll just trust Dinkumware here. My current problem is, somewhere deep down in cpp_macromap.hpp a simple innocent if (first != last) statement (line 433) triggers another assertion. These are iterator_facade's (which I don't grok) and end up comparing iterators to two distinct containers. Looking the other way on the callstack, I see some deeply suspect iterators (singular, destroyed, ?) Too messy to say what happened. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

6 7

RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Mensonides > Sent: woensdag 9 februari 2005 23:44 > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: Wave C++ Review Begins Today - > February 7, 2005 > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser [ attribution already lost ] > > > b. Sometimes it may be useful to be able to "partially > > > preprocess" given source. E.g. I would like to > > > have cleaner version of STLport just for my platform. > > > > > > It would be nice if I could specify list of > > > #defines and #undefines to be processed, the rest > > > left as is. > > > > Hmmm, that's more complex, I'll have to think about this. > > That is actually a lot more complex. It implies a heavy duty > dependency analysis on, for example, macros. I think that > implementing this would be more complex (to do correctly) > than the entire preprocessor altogether. I've been thinking about this as well. I'm not sure if we actually want the same, but my idea was to have a partial-evaluation mode which would replace only those tokens actually defined, and evaluate only those #ifdef( )/#if statements that depend on the macros explicitly defined or undefined. I suspect the major internal difference is that in full evaluation a macro is either defined or undefined, while in partial evaluation it can also be not evaluated. The technically tricky stuff is probably neatly rewriting complex #if (a&&b||c) conditions. Requirement-wise it's what to do with #include'd files. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[range] wrong OS assumed when intel compiler is used
by Martin Wille 10 Feb '05

10 Feb '05

Hi, there's again code in Boost which incorrectly assumes Windows when Intel C++ is used. E.g. I see this error here: intel-linux-C++-action ../bin/boost/libs/range/test/mfc.test/intel-8.1-linux/debug/mfc.o /boost/head-regression/boost/boost/range/detail/mfc/cstring.hpp(18): catastrophic error: could not open source file "afx.h" #include <afx.h> // for CString The range library also has problems regarding its use of Boost.Test: intel-linux-C++-action ../bin/boost/libs/range/test/std_container.test/intel-8.1-linux/debug/std_container.o ../libs/range/test/std_container.cpp(27): error: namespace "boost::unit_test" has no member "test_suite" using boost::unit_test_framework::test_suite; Regards, m

1 0

[boost.indirect container] RFC on interface changes
by Thorsten Ottosen 09 Feb '05

09 Feb '05

Dear all, I'm working on getting the indirect container library (former smart container lib) ready for a post-review. During the review it was decided to provide overloads of assign(), insert() etc that takes a Range instead of two iterators. That is often a problem because of multiple overloads, that is, we get ambiguity. Basically I think we got two alternatives: 1. template< class Iter > void container::assign( const iterator_range<Iter>& ); ... container c; c.assign( make_iterator_range( some_range ) ); 2. template< class Range void container::assign_range( const Range& ): .... container c; c.assign_range( some_range ); Which one do you prefer? Another issue relates to the null pointer policy, that is, the way we specify how the container is allowed to include nulls. Here's two alternatives: 1. container< T > // null not allowed container< nullable<T> > // null allowed 2. container<T&> // null forbidden container<T*> // null allowed Thansks for your feedback. -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/

2 4

Checking out latest Boost lock problem
by Edward Diener 09 Feb '05

09 Feb '05

Attempting to check out the latest Boost I am being stopped by: cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc

22 57

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 09 Feb '05

09 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser > Sent: woensdag 9 februari 2005 14:42 > To: boost(a)lists.boost.org > Subject: RE: [boost] Wave C++ Review Begins Today - February 7, 2005 > > > Michiel Salters wrote: > > one serious bug in wave\cpplexer\re2clex\cpp_re2c_lexer.hpp: > > template <typename IteratorT, typename PositionT> inline > > lexer<IteratorT, PositionT>::lexer(IteratorT const &first, > > IteratorT const &last, PositionT const &pos, > > boost::wave::language_support language) > > : filename(pos.get_file()), at_eof(false) > > { > > memset(&scanner, '\0', sizeof(Scanner)); > > scanner.fd = -1; > > scanner.eol_offsets = aq_create(); > > scanner.first = scanner.act = (uchar *)&(*first); > > scanner.last = (uchar *)&(*last); > > ... > > [ IteratorT = std::string::iterator in the example ] > > > > This assumes that the range [first,last] is dereferenacable and > > contiguous in memory. This of course is not mandated by the > standard. > > Yes, this is a known problem (see the Changelog file), I > didn't realise, that it will assert on some systems. Seems, > that I'll have to fix that soon ;-). This shouldn't be a > problem on other systems, though, if you're using iterators > acting on a continuous chunk of memory (such as > std::string::iterator). No, you're mistaken here and in the Changelog as well. Even std::string::iterator doesn't have to refer to contiguous memory. std::vector<char>::iterator would, though, so I built a string around that and found the actual bug (and a VC8 bug as well I think). The bug is that context<IteratorT> stores the two iterators first and last as const&. The cpp example passed .begin() and .end(), which are temporaries and they go out of scope. The result is that the context ends up with references to destructed iterators. Again, the VC8 STL iterator debugging found the problem on first access. Line 281, cpp_context.hpp I really have to say Dinkumware did a fine job here, this would have been very hard to find without these checks. > OTOH this isn't exactly a problem in the preprocessor > library, it's merely a problem of the re2c generated lexer > used in the driver. The other provided lexer (SLEX based) > won't expose this problem (i.e. the cpp_tokens example > shouldn't assert). Might be (didn't get there yet), but it too uses cpp_context.hpp, right? BTW, if you try VC8, mail me for the string class I used. Using std::vector<char> directly appears to trigger a VC 8(beta1) bug with typenames longer than 2KB Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

3 3

BOOST_CHECK_EQUAL broken/changed?
by John Maddock 09 Feb '05

09 Feb '05

This one really bit me badly: BOOST_CHECK_EQUAL now evaluates it's arguments *more than once*, for example I have many tests that look like: BOOST_CHECK_EQUAL(*it++, 0xD800u); But the expression *it++ gets evaluated multiple times, and that really screws up the tests :-/ IMO I can't see any good reason for such a change? John.

2 1

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 09 Feb '05

09 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Brinkman > Sent: dinsdag 8 februari 2005 3:48 > To: boost(a)lists.boost.org > Subject: [boost] Wave C++ Review Begins Today - February 7, 2005 I'm currently looking at the library, trying to get the (included) command-line executable to work. So far, I've found two documentation minor nits: * Source and zip say version 1.1.2, index.html says 1.2 * index.html says program_options must be downloaded, but it's in boost 1.32 ? one serious bug in wave\cpplexer\re2clex\cpp_re2c_lexer.hpp: template <typename IteratorT, typename PositionT> inline lexer<IteratorT, PositionT>::lexer(IteratorT const &first, IteratorT const &last, PositionT const &pos, boost::wave::language_support language) : filename(pos.get_file()), at_eof(false) { memset(&scanner, '\0', sizeof(Scanner)); scanner.fd = -1; scanner.eol_offsets = aq_create(); scanner.first = scanner.act = (uchar *)&(*first); scanner.last = (uchar *)&(*last); ... [ IteratorT = std::string::iterator in the example ] This assumes that the range [first,last] is dereferenacable and contiguous in memory. This of course is not mandated by the standard. I found this, because VC8.0 has iterator debugging, and it asserted. Not sure if this is the exact cause, I just found the code in the stacktrace. I tried to hack the Scanner by replacing its uchar* with iterator's but that really doesn't work. The generated code uses memcpy's and malloc's. I'll try to see if I can avoid this, perhaps try another string type. Perhaps the command-line example should use BOOST_WAVE_STRINGTYPE iso std::string? Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 09 Feb '05

09 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-02-09 09:54 Message: Logged In: YES user_id=1211438 Yes, its a templated getline that is using a bare '\n' instead of a specialised form for wchar_t or calling widen() etc. Kevin ---------------------------------------------------------------------- Comment By: Vladimir Prus (vladimir_prus) Date: 2005-02-09 09:07 Message: Logged In: YES user_id=321498 I've applied the program_options patches. Thanks. Does the compiler has the same getline problem as Comeau -- calling wide version without explicit L'\n' fails? ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 09 Feb '05

09 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by vladimir_prus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: Vladimir Prus (vladimir_prus) Date: 2005-02-09 09:07 Message: Logged In: YES user_id=321498 I've applied the program_options patches. Thanks. Does the compiler has the same getline problem as Comeau -- calling wide version without explicit L'\n' fails? ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [serialization] automatic linking andintrusiveserialization support
by JOAQUIN LOPEZ MU?Z 09 Feb '05

09 Feb '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Febrero 9, 2005 0:20 am Asunto: [boost] Re: [serialization] automatic linking andintrusiveserialization support [...] > fJOAQUIN LOPEZ MU?Z wrote: [...] > > 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! > > I don't believe this is the case. Templated code is not emitted unless > explictly invoked. If user2 never serializes anything the then > the member > serialization template won't be expanded. This view is supported > by the > fact that if serialization isn't used - then no *_iarchive.hpp > file is > included so the template argument Archive has no known value so its > impossible for the compiler emit the code. > I think I'm not explaining myself clearly. I agree with you that user1 won't cause any serialization-related code to be emited by the *compiler*. The problem is that, by virtue of the internal #include <boost/serialization/access.hpp> in foo.h, he will get Boost.Serialization autolinked, because <boost/serialization/access.hpp> (or some other serialization header, don't know precisely) ultimately includes auto_link.hpp. In other words: he will stumble upon Boost.Serialization binary without ever explicity mentioning or trying to use this library. At the risk of repeating myself, try compiling the following: #include <boost/serialization/access.hpp> int main(){} If I'm correct, autolinking will kick in yet the program does not use Boost.Serialization at all. Of course the program has included a serialization header so it should face the consequences, but in the problem I describe that header is included internally and the user who won't be using serialization capabilities shouldn't be forced to explicitly disable autolinking. Get my point? If so, and if you agree with my analysis, do you think the workaround I propose would work? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[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

subgraph test and BOOST_CHECK
by Stefan Slapeta 08 Feb '05

08 Feb '05

Hi all, there are a few cases where I didn't touch the code when replacing BOOST_TEST. One of them is the subgraph test, as there occurs a slightly different problem: It seems to me that this code worked so far: // ...cpp file #include <boost/test/minimal.hpp> // ...some header file #include <boost/test/test_tools.hpp> BOOST_TEST(...); For the code above, the initial declarations of test/minimal.hpp have been used. When you do the same now (after replacing BOOST_TEST), the compiler complains about macro redefinition _and_ you get unresolved externals at linking time. C:\views_cvs\boost\boost\test\test_tools.hpp(81) : warning C4005: 'BOOST_CHECK' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(21) : see previous definition of 'BOOST_CHECK' C:\views_cvs\boost\boost\test\test_tools.hpp(82) : warning C4005: 'BOOST_REQUIRE' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(26) : see previous definition of 'BOOST_REQUIRE' C:\views_cvs\boost\boost\test\test_tools.hpp(92) : warning C4005: 'BOOST_ERROR' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(29) : see previous definition of 'BOOST_ERROR' C:\views_cvs\boost\boost\test\test_tools.hpp(93) : warning C4005: 'BOOST_FAIL' : macro redefinition C:\views_cvs\boost\boost\test\minimal.hpp(31) : see previous definition of 'BOOST_FAIL' Is it intended that these macros are defined differently for the minimal testing facility? If yes, another testing strategy has to be chosen for this case. Nevertheless, I've replaced the occurances of BOOST_TEST now. Stefan

3 5

RE: [boost] A library: out-of-core containers and algorithms
by Brian Braatz 08 Feb '05

08 Feb '05

> -----Original Message----- > On Behalf Of Roman Dementiev > Subject: [boost] A library: out-of-core containers and algorithms > > Hello, > > I am developing a library called Stxxl. > It is an implementation of STL for external memory (out-of-core) > computations, i.e. Stxxl implements > containers and algorithms that can process huge volumes of data that > only fit on disks. > > Currently I have implemented vector, stack, and priority_queue. External > memory map, list, and queue are coming soon. The containers > take only specified (given) fixed amount of main memory, but can contain > more elements than can fit into the main memory. > The containers are compatible with STL algorithms, an example: > > #include <stxxl> > > // ten billion doubles > stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); > std::fill(HugeVector.begin(), HugeVector.end(), 0.0); > [Brian Braatz] Roman- Thank you for submitting this. I am interested in this library and encourage you onward in bringing this to boost. Question: In a nutshell, if you could please describe * How it works * what the implications\dark corners are Are you using memory map files? What other libraries or os specific functions does your library need. Thank You Brian Braatz

3 2

BOOST_CHECK_EQUAL_COLLECTIONS changed?
by John Maddock 08 Feb '05

08 Feb '05

Has BOOST_CHECK_EQUAL_COLLECTIONS been changed to take 4 parameters? I would actually support this change if it makes the macro more robust (it should IMO), but there's been no mention of this on the list as a breaking change, and the Boost.Test docs still refer to the 3 argument version, so at the moment it's not clear what those of us whose test-code has been broken should do about this :-( John.

2 1

Metadata for boost boost.signal and profiling library :was [RE: [boost] Re: Profiling Library suggestion
by Brian Braatz 08 Feb '05

08 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > > How is it better than what boost::timer provide? > > > > Gennadiy > > Hello, > > I was unaware of timer's existance, thanks for pointing it out. I had > searched for "profiling", and "profiler". > > So I just took a look at: http://www.boost.org/libs/timer/timer.htm and I > would humbly submit that perhaps what is lacking in progress_timer is a > policy, and the ability to name profiles. I would like then to propose: > > struct profiler_default_policy { > typedef boost::timer timer_t; > static void on_profiled(const char* name, const timer_t& t) { > double sec = t.elapsed(); > cout << "time elapsed (msec) during profile " << name << " was " << > sec / 1000; > if (sec <= t.elapsed_min()) { > cout << " *underflow* "; > } > if (sec >= t.elapsed_max()) > cout << " *overflow* "; > } > cout << endl; > } > }; > > struct interesting_profiler_policy { > typedef boost::timer timer_t; > static map<string, double> profiles; > static void on_profiled(const char* name, const timer_t& t) { > double sec = t.elapsed(); > profiles[name] = sec; > } > }; > > template<typename policy_t> > class basic_profiler { > public: > profiler(char const* s = "") : name(s) { }; > ~profiler() { policy_t::on_profiled(name, timer); }; > private: > char const* name; > typename policy_t::timer_t timer; > }; > > typedef basic_profiler<default_profiler_policy> profiler; > > This would have an advantage over progress_timer that library users may > modify the behaviour of the profiler, without rewriting the class. It can > also be used with more high-performance timers if the user has one at > their > disposal. > > Any comments or suggestions? > > Christopher Diggins [Brian Braatz] Christopher, I like this idea and thank you for writing that up. I haven't had the time to write it up, but I was going to make a similar request of boost.signals. The main reason for this, I built something on top of boost.signal and it uses a lot of signals\slots, it can be difficult to runtime debug due to not having the ability to query the signal for dumping all that meta-data out. (i.e. give me the debug strings for each slot)- what I do instead is keep a separate vector of those debug strings. This seems to be a similar issue to the profiling metadata suggestion that you have written up. My question to this list: * What do you guys think of Christopher's Suggestion in general for supporting extra metadata for profiling? Boost.Signal? With some libraries some it is easily possible (hahaha boost.variant) for me, I have not figured out how to cleanly do it to a slot yet :) (though honestly I have not had the time to further analyze how that lib works internally) (<< disclaimer in case I missed something dirt simple) Converse argument would be: Put your profiler in a named collection. That might work for profiler (sorry I am not familiar with that lib to know if it supports copy or what the implications of copying one are). For signal- In a few hours of analysis I don't see how to do it yet.

2 1

[graph] Adjacency bug after swapping undirected adjacency_list
by Eelis van der Weegen 08 Feb '05

08 Feb '05

I've stumbled upon a strange bug in the graph library. It seems that swapping an undirected adjacency_list back and forth to a copy of itself somehow causes some internal damage that becomes apparent when observing adjacenct vertices. I've attached a testcase that shows the problem. I'm using Boost 1.32 with gcc 3.4.2. Regards, Eelis #include <algorithm> #include <iterator> #include <iostream> #include <boost/graph/adjacency_list.hpp> int main () { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> G; G g (3); add_edge(0, 1, g); add_edge(0, 2, g); G::adjacency_iterator i, j; boost::tie(i, j) = adjacent_vertices(0, g); std::copy(i, j, std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl; // Prints "1 2", as it should. { // This should not alter g: G t = g; g.swap(t); g.swap(t); } boost::tie(i, j) = adjacent_vertices(0, g); std::copy(i, j, std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl; // Prints "1 2 1 2", while it should still be "1 2". }

2 2

possible bgl problem?
by Maxim Khesin 08 Feb '05

08 Feb '05

I am trying to read a seemingly simple dot file (produced by pygraphlib) with read_graphviz and I am getting 'syntax error' exception. The file looks like this (copy attached). digraph G { "there" []; "here" []; "here" -> "there" []; } boost_1_32_0, OS X Panther Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) thanks, max.

2 1

[iterator + program_options] borland problem
by Vladimir Prus 08 Feb '05

08 Feb '05

Hello, one of program_options' iterators no longer work on borland 5.6.4. The iterator is defined like: class environment_iterator : public eof_iterator<environment_iterator, std::pair<std::string, std::string> > Where eof_iterator is define like this: template<class Derived, class ValueType> class eof_iterator : public iterator_facade<Derived, const ValueType, forward_traversal_tag> So, the ValueType passed to iterator_facade is const std::pair<string, string>. The error produced by Borland is: Error E2034 C:\Users\Administrator\boost\main\boost\boost/iterator/iterator_facade.hpp 326: Cannot convert 'const pair<string,string> *' to 'pair<string,string> *' in function operator_arrow_result<pair<string,string>,const pair<string,string> &,pair<string,string> *>::make(const pair<string,string> &) Error E2342 C:\Users\Administrator\boost\main\boost\boost/iterator/iterator_facade.hpp 326: Type mismatch in parameter 'x' (wanted 'pair<string,string> *', got 'const pair<string,string> *') in function operator_arrow_result<pair<string,string>,const pair<string,string> &,pair<string,string> *>::make(const pair<string,string> &) It happens when instantiating this class. template <class ValueType, class Reference, class Pointer> struct operator_arrow_result { On borland, non-const type is passed as Pointer, which leads to the problem. Looks like the logic which computes the ::reference type confuses borland. On gcc, const type is passed as Pointer. The attached patch fixes the problem, by replacing add_const<value_type>::type with const value_type I haven't used #ifdef, because I think that the change should work on other compilers, too. At least it does not break any iterator tests with gcc. Comments? - Volodya

1 0

Boost 1.32 patches for IBM z/Series S390 Linux
by Jonathan Biggar 08 Feb '05

08 Feb '05

Attached are a couple of patches needed to compile boost 1.32 on S390 running Linux. Can someone apply these to the boost source? -- Jon Biggar Levanta jon(a)levanta.com --- boost/detail/limits.hpp Thu Feb 26 10:26:47 2004 +++ boost/detail/limits.hpp.new Sat Jan 29 13:56:49 2005 @@ -49,7 +49,7 @@ // The macros are not named appropriately. We don't care about integer // bit layout, but about floating-point NaN (etc.) bit patterns. -#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) +#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__s390__) #define BOOST_BIG_ENDIAN #elif defined(__i386__) || defined(__alpha__) || defined(__ia64) || defined(__ia64__) #define BOOST_LITTLE_ENDIAN --- tools/build/v1/gcc-tools.jam Fri Jan 28 21:00:04 2005 +++ tools/build/v1/gcc-tools.jam.new Fri Jan 28 20:55:18 2005 @@ -297,6 +297,11 @@ flags gcc CFLAGS <address-model>32 : -mgp32 ; flags gcc CFLAGS <address-model>64 : -mgp64 -mlong64 ; } +#S390 +if $(OSPLAT) = 390 +{ + flags gcc CFLAGS <threading>multi : -D_REENTRANT ; +} # # define compiler names if not set:

6 15

No semaphore in Boost.Thread
by Serguei Kolos 08 Feb '05

08 Feb '05

Boost.Signal is clamed to be non thread safe. Boost.Thread does not have semaphores. So how in the world I can synchronize signal handlers with threads? I have found an old discussion about this issue in the mailing list archive but it has no conclusion and no practical advises. Do people think this is non issue? Cheers, Sergei

4 5

unordered static type-list
by Nagender Parimi 08 Feb '05

08 Feb '05

Hi, I am looking for a static list of types, albeit one in which the order of types does not matter. I have looked into the Metaprogramming library (MPL) and some related work in BGL on property lists, but could not find anything that would make the list unordered (though they do provide a static type-list). To clarify what I mean, using the MPL: typedef boost::mpl::vector<float, int> type1; typedef boost:mpl::vector<int, float> type2; the above usage makes type1 and type2 distinct types since the ordering of types matters. Is there a library compenent with which I can construct a static list of types (just like usage of boost:mpl::vector above) and can query for presence or absence of a type, making the order irrelevant? Furthermore, I would prefer this presence/absence check to be resolved compile-time. The reason for this requirement is that I wish to use this presence/absence test as means by which the compiler can call the appropriate specialized functions for this static list. thanks, Nagender

2 1

boost::program_options extensions
by Preston A. Elder 08 Feb '05

08 Feb '05

I've been working with boost::options, and these is one gaping hole in it, that I have noticed. There is no way to use a custom converter in the default po::typed_value class. This is such a flaw, I've actually copied typed_value, and created one that accepts a function of parser(), which you would supply a boost::function2<void, boost::any &, const std::vector<std::basic_string<charT> > & Why would I want to do this? I have created a bunch of generic converters that can be used for a number of things, from validation to translation. The ones I have so far are: validate_oneof - used as: value<T>()->parser(validate_oneof<T>(first_val) + second_val + third_val + fourth_val)) This will then ensure that the value supplied is one of these values (obviously validate_oneof is a class with an overridden operator+ and an operator() for calling). validate_range - used as: value<T>()->parser(validate_range<T>(first, last)) This will ensure that the value lies between these values. You might be able to achieve the same with notifiers, I don't know, but from here, it gets more interesting. validate_mapped - used as: value<T>()->parser(validate_mapped<K,T>(first_key, first_val) + std::make_pair(second_key, second_val) + std::make_pair(third_key, third_val)) This will then allow you to specify a value of one type, but have a different type stored. This is particularly useful to allow, say: LogLevel = info and then have that actually stored as an in (say, 5) in the values. I have others to do syntax validation too, so say validate_ipaddr which will ensure that it is a valid IP address before storing it, and so on. Again, I'm not sure how much notifiers would do this too. But also consider the following. A 'validator' that allows you to take an IP address as text, verify it is a valid IP address (hell, if someone wanted to add logic, verify it is within a certain range if they wanted to), and then store it as an in_addr_t. Or even better, a 'validator' that checks to see if 'http://' is prefixed to a web address, and either removes it or adds it, depending on what you need. A notifier might be able to catch bad values, but not change types or correct the data. And all in all, the change to do this was minimal, apart from adding the 'parser' function, my xparse function is simply: if (m_parser) m_parser(value_store, new_tokens) else validate(value_store, new_tokens, (T*) 0, 0); Feel free to e-mail me if you want my code, or want me to post it. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

2 8

[Boost-bugs] [ boost-Support Requests-1118381 ] Link VC6 to Boost
by SourceForge.net 08 Feb '05

08 Feb '05

Support Requests item #1118381, was opened at 2005-02-07 23:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1118381&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MichKinE (michkine) Assigned to: Nobody/Anonymous (nobody) Summary: Link VC6 to Boost Initial Comment: Hi, I'm not very familiar with all this Boost libs stuff. I wanted to use only the regex libs. Assuming that I'm working on WinXP + MSVC6, i have proceeded with the following build according to the "Getting Started" instructions: bjam "-sTOOLS=msvc" --with-regex install It took a while which surprised me coz i just wanted the regex libs, but it seemed to just work fine. It ended up with two dll in the VC98\bin dir, and a new dir : c:\Boost with a lot of stuff inside. My very nOOb question is : how do I link a C++ page in MSVC6 to get my boost regex libs ?? I tried many solutions on #include, but nothing worked. Does someone can help ? Thanks, MichKinE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1118381&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] More on Serialization Link Issue
by Jared McIntyre 07 Feb '05

07 Feb '05

I have a workaround for the purpose of my project, I am currently compiling xml_iarchive.cpp and xml_oarchive.cpp into my project and linking into libboost_serialization.lib to get everything else. This is working, but isn't an optimal solution. Honestly, I'm not sure why I can wstring working in the demo code, but not my code. It might have to do with wchar_t not being set as a built-in type, but I've been unable to validate that since my codebase won't work that way. Thanks for all the help, Jared

2 1

Re: More on Serialization Link Issue - solved
by Jared McIntyre 07 Feb '05

07 Feb '05

Turns out it was the difference between treating wchar_t as a default type or not. When I modified the build process for the library to not treat wchar_t as a default type, everything linked clean. Once again, thanks for all the help. Jared

1 0

Solaris/gcc integer_traits #error on build
by Christopher Wiedel 07 Feb '05

07 Feb '05

I ran into a problem with the integer_traits.hpp file in the boost subdirectory at build time, specifically while trying to build the libboost_python-* files. It seems to be the same problem that was earlier encountered here: http://lists.boost.org/MailArchives/boost/msg76535.php I downloaded the patched version of integer_traits.hpp from CVS, but the problem persisted. I checked the #if statement beginning on line 87 of the newer version of the file, and there didn't appear to be any case for Solaris. I was building on a Solaris 8 machine, using gcc 3.3.2. I modified the file to add another case (line 101): 87 #ifndef BOOST_NO_INTRINSIC_WCHAR_T 88 template<> 89 class integer_traits<wchar_t> 90 : public std::numeric_limits<wchar_t>, 91 #if defined(WCHAR_MIN) && defined(WCHAR_MAX) 92 public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> 93 #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32_ _) || (defined(__BEOS__) && defined(__GNUC__)) 94 // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: 95 public detail::integer_traits_base<wchar_t, 0, 0xffff> 96 #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0 x400))\ 97 || (defined __APPLE__)\ 98 || (defined(__OpenBSD__) && defined(__GNUC__))\ 99 || (defined(__NetBSD__) && defined(__GNUC__))\ 100 || (defined(__FreeBSD__) && defined(__GNUC__))\ 101 || (defined(__sun__) && defined (__GNUC__) && (__GNUC__ == 3)\ 102 || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defined(__SGI_STL_PORT)) 103 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. 104 // - SGI MIPSpro with native library 105 // - gcc 3.x on HP-UX 106 // - Mac OS X with native library 107 // - gcc on FreeBSD, OpenBSD and NetBSD 108 public detail::integer_traits_base<wchar_t, INT_MIN, INT_MAX> 109 #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !defined(__SGI_STL_PORT) 110 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigned int. 111 // - gcc 2.95.x on HP-UX 112 // (also, std::numeric_limits<wchar_t> appears to return the wrong values). 113 public detail::integer_traits_base<wchar_t, 0, UINT_MAX> 114 #else 115 #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits< > for your compiler. 116 #endif 117 { }; 118 #endif // BOOST_NO_INTRINSIC_WCHAR_T The file then compiled without a problem when inluded in the python libraries. The question I still have is whether this has the potential to break something somewhere else in the code. -- Christopher Wiedel Software Installs Group University of Southern California

2 1

RE: [boost] Re: Problem with code in common_factor_ct.hpp
by Brian Braatz 07 Feb '05

07 Feb '05

> -----Original Message----- > On Behalf Of David Abrahams > Daryle Walker <darylew(a)hotmail.com> writes: > > > On 2/2/05 5:24 PM, "David Abrahams" <dave(a)boost-consulting.com> wrote: > > > >> Daryle Walker <darylew(a)hotmail.com> writes: > >> > >>> On 1/31/05 4:29 PM, "David Abrahams" <dave(a)boost-consulting.com> > wrote: > >>> > >>>> "John H. Spicer" <jhs(a)edg.com> writes: > >>>> > >>>>> This file includes the code below in an #else for > >>>>> BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. We give an error on that > code > >>>>> because of a missing "template" keyword (between :: and helper). > >>>>> > >>>>> What is the proper channel for reporting things like this? > >>>> > [Dave Abrahams] > Yes, we still have compilers with > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. Not every library has > officially dropped support for vc6/7 yet. [Brian Braatz] Humble request from the "Front Lines" :) Please continue supporting vc7. I am currently in the unenviable position of BACK PORTING code that uses boost from vc7.1 to vc7. The first thing to go was lambda. The funny thing is about 6 months ago I was thinking it seemed silly to keep things like boost.bind around. But now I am using that heavily instead of lambda. My situation is we have 1.7 million lines of code we are trying to upgrade. Unfortunately we have about 40-50 people who have had vc7 purchased for them by the project and we do not have the budget to upgrade compilers. Vc7 is, in my opinion probably (unfortunately) still a compiler many folks are stuck with.

1 0

Re: Problem with code in common_factor_ct.hpp
by David Abrahams 07 Feb '05

07 Feb '05

"John H. Spicer" <jhs(a)edg.com> writes: > This file includes the code below in an #else for > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. We give an error on that code because > of a missing "template" keyword (between :: and helper). > > What is the proper channel for reporting things like this? http://www.boost.org/more/bugs.htm shows several alternatives. > template < unsigned long Value2 > > struct helper > { > BOOST_STATIC_CONSTANT( unsigned long, value > = static_gcd_helper2_t<Value2>::helper<Value1 % Value2>::value ); > }; > -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Re: [boost] Re: [boost.tr1?] request for a hash<> implementation
by JOAQUIN LOPEZ MU?Z 07 Feb '05

07 Feb '05

Hi Daniel, ----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Domingo, Febrero 6, 2005 7:12 pm Asunto: [boost] Re: [boost.tr1?] request for a hash<> implementation > JOAQUIN LOPEZ MU?Z wrote: > > What I'm interested in in the short term is the hash<> functor > > alone. Of course unordered containers are much more interesting, > > but this will have to undergo the usual review process, I guess. > > Do you think we can put your hash<> implementation under > > boost/functional/hash.hpp and have some short docs for it? > > I've just uploaded a new version. I've rewritten the hash > functions > based on Peter's design. I'll write some documentation and some > more > tests soon. > You've been fast! I've taken a look at your stuff and have a couple of concerns/suggestions: 1. Now the file is boost/hash/functional.hpp. Wouldn't it be better to call it boost/functional/hash.hpp? As I see it, hash<> is part of TR1 future <functional>, so the naming I propose looks more consistent. 2. The header includes <set> and <map>, which can be quite heavy if the user has no intention to use the corresponding hash_value overloads. Alas, I don't know of any way to avoid the inclusions, since a forward declaration of these containers can fail due to the freedom stdlib implementers have to add additional template parameters to those specified by the standard. Any idea? I'll soon bundle your header with a preview of hashed indices for Boost.MultiIndex, probably the next week. Thank you so much for your effort, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

RE: [boost] Boost Profiler Proposal
by Brian Braatz 07 Feb '05

07 Feb '05

Yes. I would use this library. Though, personally, I would like a greater scope of what it does. The details of other things I would like to see from this library or a companion library are here: http://tinyurl.com/5sbyx > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Monday, February 07, 2005 7:38 AM > To: Boost mailing list > Subject: [boost] Boost Profiler Proposal > > I have updated the Profiler (and done some testing using Visual C++, 7.1) > at > http://www.cdiggins.com/profiler/ . I have mostly decided to freeze the > features for the profiler mini-library as described and posted at > http://www.cdiggins.com/profiler/ . My question to the group is: would you > use this library as it is? If you don't want to mail the group, I would > appreciate even just a quick note: yes, no, maybe. > > If anyone has a POSIX high-resolution timer modeled on the Boost.Timer > concept to share, it would be greatly appreciated! I would also appreciate > new profiling policies, to include as examples. > > PS: this profiling tool seems to be a natural fit for the Boost.Test > macros > like BOOST_CHECK_NO_THROW, I currently use something like: > > BOOST_PROFILE_AND_CHECK_NO_THROW(TKN) > BOOST_CHECK_NO_THROW(BOOST_PROFILE(TKN)) > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: [boost.tr1?] request for a hash<> implementation
by JOAQUIN LOPEZ MU?Z 07 Feb '05

07 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Sábado, Febrero 5, 2005 5:36 pm Asunto: [boost] Re: [boost.tr1?] request for a hash<> implementation > John Maddock wrote: > > Anyone else want to throw in their thoughts? What's the > timescale on > > the unordered container development, how much is there left to do? > > I'll upload a new version to the file vault later today, or maybe > tomorrow, which should be compliant to the draft. I haven't > written any > documentation yet, I guess I'll probably just write an > introduction and > refer to the draft for reference (as Beman Dawes suggested), if > that's okay. > > There are a few areas which could do with some improvement, such > as the > hash functions, which are pretty basic. But I guess they can be > left for > later if you want to get it in soon. > Hi Daniel, What I'm interested in in the short term is the hash<> functor alone. Of course unordered containers are much more interesting, but this will have to undergo the usual review process, I guess. Do you think we can put your hash<> implementation under boost/functional/hash.hpp and have some short docs for it? Are you planning to improve the hashing algorithms (in particular for strings, which I guess it's the most improvable part)? If I could have this in time for Boost 1.33 I'd be extremely grateful, since Boost.MultiIndex hashed indices (practically finished now) need a hash<>, and I don't think it is convenient that each library ships with its own version. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 8

ANN: new ml dedicated to Generic Linear Algebra
by Toon Knapen 07 Feb '05

07 Feb '05

Hi all, I would like to inform you that a new mailinglist has been created that is dedicated to Generic Linear Algebra Software (GLAS). The aim of the glas-ml is to define a generic interface for linear algebra operations and to provide a reference implementation for this interface in C++. This forum is intended for people with a strong interest in numerics and/or C++ (actually the combination of both is absolutely necessary to achieve our goals). The list was created a few weeks ago and it has been suggested already to join the MTL3 (a new rewrite of MTL) effort and this glas effort. So you might want to dive into the archives already to read some more about the initial design discussions. The ml is hosted by the Open Systems Lab of Indiana University (thanks!) and you can join the list at: http://lists.boost.org/mailman/listinfo.cgi/glas. Toon Knapen

3 3

program_options docs on options_description_easy_init( value_sema ntic * )
by Michiel Salters 07 Feb '05

07 Feb '05

The class options_description_easy_init is supposed to provide "convenient creation syntax to option_description" but I find it's a bit less convenient than advertised. The problem is that the class isn't documented, and that's a serious problem if you take raw pointers. I found out that a value_semantic object was being desroyed by a shared_ptr<value_semantic> dtor, even though I had passed the address of a local object. Besides the fact that it's undocumented, shouldn't it take a shared_ptr<value_semantic> in the first place? The orginal owner miught like to keep a pointer to the object as well. ( I'm porting Wave to boost 1.32, so I'm not writing the program_options code from scratch. Even so, I found the documentation under par - wouldn't use it myself. For instance, the 'overview' section talks a lot about the value_semantic class but uses the value<T> class. ) Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

Documentation error for program_options::positional_options_description::add
by Lars Iversen 07 Feb '05

07 Feb '05

In boost/boost/libs/program_options/doc/overview.xml revision 1.14, examples state that function program_options::positional_options_description::add accepts three parameters, but the function in boost/boost/boost/program_options/positional_options.hpp revision 1.3 only accepts two parameters. Regards, Lars

2 1

Configuration bug (xcode on OS X)
by Benjohn 07 Feb '05

07 Feb '05

Compiling with xcode on OS X, and targeting a cocoa, objective c++ application, we've had some configuration trouble with boost (shared_ptr in particular) not compiling with multithreaded support. This seems to come down to a problem in the "file boost/config/platform/macos.hpp" which has the lines: # ifndef TARGET_CARBON # include <boost/config/posix_features.hpp> # endif Because TARGET_CARBON is defined as part of Apple's framework (which I think is normal for a cocoa application), "posix_features.hpp" doesn't get a chance to make sure BOOST_HAS_THREADS gets defined. Posting [1] to this list indicates that the "ifndef TARGET_CARBON" was added as a work around for codewarrior's environment, and [2] mentions that there's a problem with it as a solution. I've patched this based on a suggestion by Glen Simmons (thanks) by: * creating a modified copy of "macos.hpp" that always includes "posix_features.hpp", * define BOOST_PLATFORM_CONFIG (in our prefix file) to point at the patch. Of course, it would be splendid if boost figured all this out itself. I'd be more than happy to test out an official fix. Cheers, Benjohn Barnes [1] http://lists.boost.org/MailArchives/boost-users/msg02664.php [2] http://lists.boost.org/MailArchives/boost-users/msg07979.php

2 3

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 07 Feb '05

07 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Link problems
by Dave 07 Feb '05

07 Feb '05

Hello all, I'm trying to use the RegEx library and am running into some link issues. My platform is VC++ 7.1. For my project, I have specified all of the Boost static libs so that anything I need should be available: libboost_date_time-vc71-mt-sgd-1_32.lib libboost_filesystem-vc71-mt-sgd-1_32.lib libboost_prg_exec_monitor-vc71-mt-sgd-1_32.lib libboost_program_options-vc71-mt-sgd-1_32.lib libboost_regex-vc71-mt-sgd-1_32.lib libboost_serialization-vc71-mt-sgd-1_32.lib libboost_signals-vc71-mt-sgd-1_32.lib libboost_test_exec_monitor-vc71-mt-sgd-1_32.lib libboost_thread-vc71-mt-sgd-1_32.lib libboost_unit_test_framework-vc71-mt-sgd-1_32.lib libboost_wserialization-vc71-mt-sgd-1_32.lib However, I am seeing the following errors: LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library main.obj : error LNK2019: unresolved external symbol "void * __cdecl boost::re_detail::get_mem_block(void)" (?get_mem_block@re_detail@boost@@YAPAXXZ) referenced in function "public: __thiscall boost::re_detail::save_state_init::save_state_init(struct boost::re_detail::saved_state * *,struct boost::re_detail::saved_state * *)" (??0save_state_init@re_detail@boost@@QAE@PAPAUsaved_state@12@0@Z) main.obj : error LNK2019: unresolved external symbol "void __cdecl boost::re_detail::put_mem_block(void *)" (?put_mem_block@re_detail@boost@@YAXPAX@Z) referenced in function "public: __thiscall boost::re_detail::save_state_init::~save_state_init(void)" (??1save_state_init@re_detail@boost@@QAE@XZ) Debug/cookbook_tests.exe : fatal error LNK1120: 2 unresolved externals What do I need to do to get my program to successfully link? Thanks, Dave

2 1

Initial Subversion/RapidSVN experience
by Beman Dawes 07 Feb '05

07 Feb '05

I've spent several hours playing with the Subversion Boost repository that Troy Straszheim was kind enough to set up. Here is my initial experience: * The downloads and installation of WxWidgets, Subversion, and RapidSVN went smoothly; everything worked right away the first try. * The initial Boost checkout using RapidSVN worked right away the first try. However, there doesn't seem to be any RapidSVN documentation, so if you aren't already familiar with WinCVS or similar, you might have more trouble. ***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users. * Boost Subversion updates are much faster than CVS; with CVS it took over 12 minutes this morning, versus a bit more than one minute with Subversion/RapidSVN. * Starting RapidSVN on the Boost SVN working copy is very slow; over 60 seconds if the machine has just been turned on. The disk is being worked hard. 10 seconds if the cache is warm. For comparison, WinCVS starts in a second or so, even on a cold disk cache. * The Subversion revision numbering scheme is so different from CVS that it will take quite a bit of reorientation (at least for me) to learn how to use it. It is very counter-intuitive for me that the previous revision of a file isn't 12345 if the current revision is 12346. I found myself constantly having to run "log" to figure out what the previous revision was. I often look at past revisions, so this is important to me. I suppose there is some way to do this as easily as with CVS, but I haven't figured that out yet. * RapidSVN doesn't save location on exit, so every time you start it up you have to navigate to wherever you want to be. It also crashed on me several times. My sense is it is a nice piece of software, but also very immature as yet. * The branching and tagging approaches seem different; we would have to work out new best practices before switching to SVN. --Beman

8 22

RE: [boost] Re: Microsoft XML serialization patent
by Hurd, Matthew 07 Feb '05

07 Feb '05

> Jonathan Turkanis wrote: > > Robert Ramey wrote: > >> I just came upon an incredible thing. > >> > >> It seems that microsoft has filed a U.S. Patent Application for XML > >> serialization. I'm sort of dumbfounded at this. Truth be told > >> I've seen > >> a lot of even more ridiculous patents but somehow this strikes closer > >> to home. I'm really at a loss to appreciate the ramifcations of this > >> - if any. It's hard to take it seriously ;-) <quote> [0019] The serialized data of an object may be thought of as a "dehydrated object" where all of the water (object functions in this metaphor) has been squeezed out of the object. This leaves only dry potato flakes (the data). Later, a hungry person wishes to have mashed potatoes (the object with the data), the potato flakes may be rehydrated. To "add water" to a dehydrated object, an empty object is created and the stored data is inserted therein. </quote> Especially as you go down the patent and read the silliness and contextual incoherence ( ;-) ) of the ever broadening clauses. Just highlights the failing of the patent system rather than having any consequence for boost I'd think. Matt. matthurd(a)acm.org IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Microsoft XML serialization patent
by Robert Ramey 06 Feb '05

06 Feb '05

I just came upon an incredible thing. It seems that microsoft has filed a U.S. Patent Application for XML serialization. I'm sort of dumbfounded at this. Truth be told I've seen a lot of even more ridiculous patents but somehow this strikes closer to home. I'm really at a loss to appreciate the ramifcations of this - if any. Robert Ramey http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p= 1&u=/netahtml/srchnum.html&r=1&f=G&l=50&s1=20040261020.PGNR.

3 4

RE: [boost] Re: Was [RE: Moving from CVS to Subversion?] Now is "Subversion experiences from the field"
by Brian Braatz 06 Feb '05

06 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David B. Held > Sent: Wednesday, February 02, 2005 3:50 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Was [RE: Moving from CVS to Subversion?] Now is > "Subversion experiences from the field" > > Brian Braatz wrote: > > [...] > > Anyone else have any experience with these two side by side they > > wish to share? > > I've just started using SVN with some Java projects, and I have to > say that the SVN integration with Eclipse is pretty good. I've > never used such intuitive version control anywhere. There's a few > complexities, like trying to merge changes between branches; but for > the vast majority of tasks, it's a pleasure to work with. That said, > I don't know how painful it is to use SVN from the command line, but > TortoiseSVN is about as easy to use from the filesystem as > TortoiseCVS (if not more so). The ability to store filesystem > changes is a big win for SVN, IMO. I just get the impression that > the overall design of SVN is more elegant and robust, since it isn't > a legacy system built up out of a series of hacks. The two-way > diff transfer is also very nice, and the way it handles binaries > makes me confident storing binaries in a repository. I only have > a handful of developers hitting my server, but I haven't heard of > any scalability problems from other SVN projects. > > If it came to a vote, I'd say switch to SVN. > > Dave > [Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this? We have had more admin with SVN than with CVS. (the Berkley db needs tending to from time to time)

15 20

Re: [boost] Microsoft XML serialization patent
by JOAQUIN LOPEZ MU?Z 06 Feb '05

06 Feb '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Domingo, Febrero 6, 2005 11:28 pm Asunto: [boost] Microsoft XML serialization patent > I just came upon an incredible thing. > > It seems that microsoft has filed a U.S. Patent Application for XML > serialization. I'm sort of dumbfounded at this. Truth be told > I've seen > a lot of even more ridiculous patents but somehow this strikes > closer to > home. I'm really at a loss to appreciate the ramifcations of this > - if any. > Hi Robert, You shouldn't let this deprive you of your sleep :) Fact is, the primary reason for big companies patenting everything in sight is just the opposite than many people may think: this is a legal way to protect themselves from rogue firms trying to sue them. By being the first in patenting something, a future contender won't have the opportunity to file his own submission. A patent becomes invalid if somebody proves that the invention was in public use before submission of the patent. In the crazy case MS decided to enforce this serialization apparatus, one can easily claim that the two key ideas (namely XML as a serialization language and object tracking) were publicly used well before Dec 2004. But as I said, I don't really think it is MS' intention to go sue anybody. On a related theme, it is sad that patent offices all over the world will accept just everything submitted to them --from what I've learned about these issues in the past, the only requisite is that the submission is written according to some funky rules: for instance, in Spain you cannot patent an algorithm, but you can embed the algorithm into some kind of hypotethical physical apparatus and that will pass OK :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Off-topic, what happened to that article of yours relating the experiences of a Boost submitter? I really wanted to read it.

1 0

Boost.Instrument library Proosal \ RE: [boost] Profiler Library Proposal
by Brian Braatz 06 Feb '05

06 Feb '05

Further thoughts added below (which is why I would be responding to my own post :) ) Including additional features \ design ideas to either add to Profiler, or make as a separate library. Additionally some thoughts on boost performance measurement of tests in general by using these ideas. > > -----Original Message----- > > On Behalf Of Martin Slater > > Subject: Re: [boost] Profiler Library Proposal > > > > christopher diggins wrote: > > > > > I have posted preliminary documentation and source code for a > proposal > > > for the boost profiler library at http://www.cdiggins.com/profiler/ > . > > > The code has been successfully compiled on Visual C++ 7.1 but not > > > tested yet. > > > > > > There have been some updates to the code as a result of the > > > suggestions made so far. Any further comments are appreciated. > > > > Being able to generate a heirarchicle recording / output would be very > > useful (the profiler we use at work does this) so you can drill down > > into code areas that are running slow. > > > > cheers > [Brian Braatz] > Sharing some experiences in relation to where this thread looks like it > may go :) > > I am not proposing a library, just sharing with you a library I wrote > and what the results were of building it. > > About a year ago, I played around with some similar concepts. > > I fundamentally wanted to "see what it would look like" if I could > converge > * Design By contract, > * hierarchical logging > * profiling > Both by function and by cross cut concepts from a set of > functions AND the operations IN those functions > * reverse time debugging- > I.e. you can go back in time and see how the call stack > got you to where the error occurred. In addition to the previous call > stacks that are now "gone". > * Thread specific data tracking burned into the design > > By building the library, I got all of the above working. However many > questions remained for me as to if the syntax required was "too much". > This is still an open question in my mind in that I have not personally > decided either way. > > As you will see the "requirements" for a simple function are quite > verbose. > > > What I built: > Simple syntax for both profiling and for logging of the > "context" of a concept. > Ability to grab the callstack of "where" an error occurred and > what the code was doing when it hit an error. > Ability to put the local variables and the parameters into a > call stack > Ability to plug in profiling in such a way as to view a > cross\cut of the performance of a set of operations > Also time profiling was done on EVERYTHING- so with a fancy XSLT > modifer, you can cross cut and get whatever kind of "executive level > analysis" you want on the sheer volumne of data you have > Basically, to the application coders, what this looks like is an > "Eiffel" style programming model in C++, with the behind the scenes > advantage of > Profiling > Call stack tracing > Heirarchcal logging- > With context concepts embedded in the log so you can go > back later and look at a "slice" of the performance of something. I even > built a debugger that let me look at the xml files and do this. > [Brian Braatz] I was thinking about this for the last few hours. Primarily I was thinking about how to get the advantage of the lib I described last post, without having the pain involved in the app code with bulky standards to conform to. One of the problems with profiling is you have to, when you design the library, decide how intrusive to be. When I did my experiment\bunny trail, I found that there are *A LOT* of interesting things that can be done, you just have to have an extremely intrusive library to do that. It should be possible however to do the following. 1- Keep going on the profiler thinking. This is good 2- Build either a separate lib (Boost.Instrument?) or a separate piece of Boost.Profiler which: * Is built on top of Spirit * Is capable of parsing C++ code and re-generating an instrumented version of that * Is HEAVILY policy\trait driven in such a way as people can "decide for themselves" what they want to tweak or add to in the outputted instrumented files ** I.e. by modifying the policies for Boost.Profiler and modifying the policies for Boost.Instrument you can "Have it your way :) " * Is built part and parcel with the profiler libray, since what the Instrument library is doing is delivering code which uses the profiler library Why I think this idea is a good one: * I can go buy Boundschecker. Or some other profiler \ debugger. ** I cannot "dig inside it and change it" (!) ** Too frequently these things give me TOO MUCH information and not the right information I need. If I could modify how they work , then I could tailor it to my own problems. * for boost, this means we could run a instrumented build of all of boost and we could analyze\report on the different performance charaistics of lib\os\compiler combinations Part of this idea is inspired by the signal performance issue Jody Hagins: " Are there any docs which describe the performance of the signal/slot library? I was about to embark on a performance study because I want to use it in a very high performance critical code path, but I thought I'd ask if anyone else may have already done some work in this area. " http://tinyurl.com/5bpzq I am sorry, I have to run, and I have run out of time. There was another issue in regards to signals I recall where there looked like we had some performance issues. I regret I have not yet found that mail in the archive. I would love the regression tests, to also be able to spit out performance issues. This would also help me, as a user of boost, to ascertain for time critical code which compiler I wanted to use and how the boost libraries perform under X environment.

1 0

RE: [boost] Profiler Library Proposal
by Brian Braatz 06 Feb '05

06 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Martin Slater > Sent: Saturday, February 05, 2005 10:30 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Profiler Library Proposal > > christopher diggins wrote: > > > I have posted preliminary documentation and source code for a proposal > > for the boost profiler library at http://www.cdiggins.com/profiler/ . > > The code has been successfully compiled on Visual C++ 7.1 but not > > tested yet. > > > > There have been some updates to the code as a result of the > > suggestions made so far. Any further comments are appreciated. > > Being able to generate a heirarchicle recording / output would be very > useful (the profiler we use at work does this) so you can drill down > into code areas that are running slow. > > cheers [Brian Braatz] Sharing some experiences in relation to where this thread looks like it may go :) I am not proposing a library, just sharing with you a library I wrote and what the results were of building it. About a year ago, I played around with some similar concepts. I fundamentally wanted to "see what it would look like" if I could converge * Design By contract, * hierarchical logging * profiling Both by function and by cross cut concepts from a set of functions AND the operations IN those functions * reverse time debugging- I.e. you can go back in time and see how the call stack got you to where the error occurred. In addition to the previous call stacks that are now "gone". * Thread specific data tracking burned into the design By building the library, I got all of the above working. However many questions remained for me as to if the syntax required was "too much". This is still an open question in my mind in that I have not personally decided either way. As you will see the "requirements" for a simple function are quite verbose. What I built: Simple syntax for both profiling and for logging of the "context" of a concept. Ability to grab the callstack of "where" an error occurred and what the code was doing when it hit an error. Ability to put the local variables and the parameters into a call stack Ability to plug in profiling in such a way as to view a cross\cut of the performance of a set of operations Also time profiling was done on EVERYTHING- so with a fancy XSLT modifer, you can cross cut and get whatever kind of "executive level analysis" you want on the sheer volumne of data you have Basically, to the application coders, what this looks like is an "Eiffel" style programming model in C++, with the behind the scenes advantage of Profiling Call stack tracing Heirarchcal logging- With context concepts embedded in the log so you can go back later and look at a "slice" of the performance of something. I even built a debugger that let me look at the xml files and do this. App Code Requirements: The application code must do the following: Have a Root object Get a context object from root Pass the context object into each function with the name ctx This is for both thread reasons and the Use a Eiffel style syntax in the functions What this looks like in app code (sample code below actually works) void MyFunction3(Context ctx,int i,Object *p) { Function ( MyClass, MyFunction3, "Function Used for rotation" ); Parameters Param (i,"Integer for how many times to loop" ); Param (p,"Object to do something with" ); Locals int w = 0; Local(w,"Value for the weather"); int x = 0; Local(x,"Drag Coefficient"); Pre Execute comments << "Func3 is reobooting windows 95" << endl; ctx.SetError(std::string("DATABASE IS MISSING"),FLUID); Post EndFunc } void MyFunction2(Context ctx,int i,Object *p) { Function ( MyClass, MyFunction2, "Function Used for calculation" ); Parameters Param (i,"Integer for how many times to loop" ); Param (p,"Object to do something with" ); Locals int w = 0; Local(w,"Value for the weather"); int x = 0; Local(x,"Drag Coefficient"); Pre Execute comments << "Searching for weapons of mass destruction" << endl; MyFunction3(ctx,i,p); Post EndFunc } void MyFunction1(Context ctx,int i,Object *p) { Function ( MyClass, MyFunction1, "some other Function Used for calculation" ); Parameters Param(i,"Integer for counting") ; Param(p,"Object to destroy" ); Locals int w = 0; Local(w, "Value for the weather"); int x = 0; Local(x, "Drag Coefficient"); Operation (opAddToVector, "Add passed string "); Operation (opFindAllElements, "Find all elements "); Pre ctx.Check( i == 1,"i Must be greater than one ",FLUID); ctx.Check( Valid(p) || IsNull(p) , "p must be a valid object or null", FLUID); Execute { Scope (opAddToVector); comments << "Adding to vector" << endl; { Scope (opFindAllElements); Comments << "Finding all elements" << endl; MyFunction2(ctx,i,p); } } Post EndFunc }

1 0

Re: [boost] class diagrams for template heavy design
by Igor Kholodov 06 Feb '05

06 Feb '05

Vasco Lohrenscheit wrote: > 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. You may try latst version of doxygen http://www.stack.nl/~dimitri/doxygen/ which uses graphviz drawing kit, http://www.research.att.com/sw/tools/graphviz/ Doxygen now supports template partial specialization in produced diagrams the way you expect. Regards, Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

1 0

[mpl][doc]range-c.html size<r>::type -> size<r>::value
by Larry Evans 06 Feb '05

06 Feb '05

Shouldn't size<r>::type in the table be size<r>::value? The examples following the table do show the use of value.

1 1

[boost.assign] RFC on small updates
by Thorsten Ottosen 06 Feb '05

06 Feb '05

Hi All, For the next revision of boost.assign I have planned the following changes: 1. all arguments are passed by const reference 2. support for boost.graph 3. list_of()'s type has begin() and end() member functions. These will now return a mutable iterator even though they are const. (to allow better use of anonymous arrays) 4. a new super-efficient version of list_of() which can be used whenever efficiency matters and when references needs to be forwarded. For example: template< class Range > typename Range::const_iterator max_element( const Range& r ) { return std::max_element( r.begin(), r.end() ); } ... int a=1,b=5,c=3,d=4,e=2,f=9,g=0,h=7; ... int& max = *max_element( list_of<8,int&>(a)(b)(c)(d)(e)(f)(g)(h) ); BOOST_CHECK_EQUAL( max, f ); max = 8; BOOST_CHECK_EQUAL( f, 8 ); The question is if we should allow list_of<5,T> where T is not a reference or if we should require a reference argument (for the sake of efficiency). Thanks for your feedback -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/

2 2

A Refcounting Handle Class that supports CrossCasts
by Tommy Nordgren 06 Feb '05

06 Feb '05

I have developed a nonintrusive Reference Counting Handle class that supports crosscasts. The limitaions are that both source and target parameter types must have virtual methods, and that currently it don't supports access from multiple threads, Do the esteemed members of this list think that such a class would be a useful addition to the library?? "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone"

2 1

Profiler Library Proposal
by christopher diggins 06 Feb '05

06 Feb '05

I have posted preliminary documentation and source code for a proposal for the boost profiler library at http://www.cdiggins.com/profiler/ . The code has been successfully compiled on Visual C++ 7.1 but not tested yet. There have been some updates to the code as a result of the suggestions made so far. Any further comments are appreciated. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

2 1

[boost.tr1?] request for a hash<> implementation
by Joaquín Mª López Muñoz 05 Feb '05

05 Feb '05

Hi, There are several Boost-related projects underway around the theme of unordered containers (in my case, I'm pretty much on the verge of releasing a preview of hashed indices for Boost.MultiIndex.) All these projects have the common need of a hash<> implementation being available, preferrably promoted to a public namespace rather than as an implementation detail. Although Boost.TR1's purpose is not to implement new features but rather wrap them to achieve std::tr1-compliance, I think it'd be very useful if some tr1-hash implementation could be added to Boost. For the record, I'm currently using Jeremy Maitin-Shepard and Daniel James' implementation in Sanbox files/unordered.tar.gz. I think it is a rather solid implementation, taking care of compilers witohut PTS such as MSVC++ 6.0/7.0. As for the location, my pereference would be boost/functional/hash.hpp. Boost.TR1 could embrace this later in boost/tr1/functional.hpp. Could this be done? Maybe as a separate activity from Boost.TR1? Am I entitled to do it myself as part of the upgrade of my library, even though this would be adding a new library in disguise? As it happens, I think I'll be able to release hashed indices in time for Boost 1.33, but this detail can be a showstopper :( Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Two alined_storage classes in the CVS
by JOAQUIN LOPEZ MU?Z 05 Feb '05

05 Feb '05

With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge. Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas? Joaquín M López Muñoz Telefónica, Invstigación y Desarrollo

10 14

Latest CVS: Boost.Python -> Illegal instruction
by Ralf W. Grosse-Kunstleve 05 Feb '05

05 Feb '05

I am working with the very latest boost CVS. Most Boost.Python tests fail with a segmentation fault with these compilers: gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc version 3.4.3 # compiled from sources, running under RH WS 3 gcc version 3.4.3 # compiled from sources, running under RH 8.0 In contrast, these gcc's do *not* have any problems: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) valgrind reports no errors for gcc version 3.2 under RH 8.0, but complains about the gcc 3.4.3 compiled code on the same machine (see below). The problem appears to be independent of the Python version (problem observed with 2.2, 2.3, 2.4) and the optimizer (problem observed with -O3 and -O0). The Boost CVS from 2005-Jan-26 11:43 PDT didn't have this problem. I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells? # gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) % valgrind --tool=memcheck /usr/bin/python $BOOST_DIST/libs/python/test/object.py running... ==19174== Memcheck, a memory error detector for x86-linux. ==19174== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==19174== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==19174== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==19174== For more details, rerun with: -v ==19174== disInstr: unhandled instruction bytes: 0xCD 0x5 0x90 0x55 at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== ==19174== Process terminating with default action of signal 4 (SIGILL) ==19174== Illegal operand at address 0xB0021520 ==19174== at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== by 0x1BE89B32: boost::python::api::object::object<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:310) ==19174== by 0x1BE8D921: boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:501) ==19174== by 0x1BE8BFCD: boost::python::objects::class_base::class_base(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:514) ==19174== ==19174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 47 from 1) ==19174== malloc/free: in use at exit: 714158 bytes in 8967 blocks. ==19174== malloc/free: 34052 allocs, 25085 frees, 6930352 bytes allocated. ==19174== For a detailed leak analysis, rerun with: --leak-check=yes ==19174== For counts of detected errors, rerun with: -v Illegal instruction __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

5 14

type_traits changes break Boost.Python under IRIX
by Ralf W. Grosse-Kunstleve 05 Feb '05

05 Feb '05

The recent changes to the type_traits library break our Boost.Python builds under IRIX, using the old MIPSpro 7.3.1 compiler. This compiler is based on EDG 238. The problem is illustrated by this simple piece of code: template <class T> struct is_signed_helper { static const bool value = (static_cast<T>(-1) < 0); }; % CC -n32 -mips4 -LANG:std -c foo.cpp cc-3314 CC: ERROR File = foo.cpp, Line = 4 The expression must have arithmetic, enum, or pointer type. static const bool value = (static_cast<T>(-1) < 0); ^ 1 error detected in the compilation of "foo.cpp". I tried several ideas for a workaround. The only one that worked in the end is the patch attached to this message. I know it is not pretty, but it has no effect on compilers other than EDG 238. I'd be happy to try other ideas, but all of Boost.Python compiles and runs with the patch. Unless someone else needs a more general fix (that works for user-defined types) I doubt the old compiler is worth more effort. Is the attached patch acceptable as a workaround? Cheers, Ralf Index: is_signed.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_signed.hpp,v retrieving revision 1.1 diff -u -r1.1 is_signed.hpp --- is_signed.hpp 30 Jan 2005 15:47:45 -0000 1.1 +++ is_signed.hpp 2 Feb 2005 06:42:43 -0000 @@ -21,12 +21,35 @@ namespace detail{ +#if !(defined(__EDG_VERSION__) && __EDG_VERSION__ == 238) + template <class T> struct is_signed_helper { BOOST_STATIC_CONSTANT(bool, value = (static_cast<T>(-1) < 0)); }; +#else + +template <class T> +struct is_signed_helper; + +template <> struct is_signed_helper<char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<signed char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<short> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned short> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<int> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned int> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<long long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned long long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<float> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<double> { BOOST_STATIC_CONSTANT(bool, value = true); }; + +#endif + template <bool integral_type> struct is_signed_select_helper { Index: is_unsigned.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_unsigned.hpp,v retrieving revision 1.1 diff -u -r1.1 is_unsigned.hpp --- is_unsigned.hpp 30 Jan 2005 15:47:45 -0000 1.1 +++ is_unsigned.hpp 2 Feb 2005 06:42:43 -0000 @@ -21,12 +21,35 @@ namespace detail{ +#if !(defined(__EDG_VERSION__) && __EDG_VERSION__ == 238) + template <class T> struct is_unsigned_helper { BOOST_STATIC_CONSTANT(bool, value = (static_cast<T>(-1) > 0)); }; +#else + +template <class T> +struct is_unsigned_helper; + +template <> struct is_unsigned_helper<char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<signed char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<short> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned short> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<int> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned int> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<long long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned long long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<float> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<double> { BOOST_STATIC_CONSTANT(bool, value = false); }; + +#endif + template <bool integral_type> struct is_unsigned_select_helper { __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 5

More on Serialization Link Issue
by Jared McIntyre 05 Feb '05

05 Feb '05

I've continue to play around with this for a few days. The problem revolves around std::wstring. I can serialize just about anything, with the exception of a std::wstring, using the library. Am I required to use the wide version of the archives to do std::wstring? If so, is there some mechanism by which a compiler error can be triggered if you try to use a std::wstring with a non wide version of an archive? As a side note, I've tried to incorporate the wide version of the library and use that, but I'm running into a different batch of link errors: error LNK2019: unresolved external symbol "public: __thiscall boost::archive::xml_wiarchive_impl<class boost::archive::xml_wiarchive>::xml_wiarchive_impl<class boost::archive::xml_wiarchive>(class std::basic_istream<unsigned short,struct std::char_traits<unsigned short> > &,unsigned int)" error LNK2019: unresolved external symbol "public: __thiscall boost::archive::xml_woarchive_impl<class boost::archive::xml_woarchive>::xml_woarchive_impl<class boost::archive::xml_woarchive>(class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > &,unsigned int)" error LNK2019: unresolved external symbol "public: __thiscall boost::archive::basic_text_oprimitive<class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > >::~basic_text_oprimitive<class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > >(void)" (??1?$basic_text_oprimitive@V?$basic_ostream@GU?$char_traits@G@std@@@std@@@archive@boost@@QAE@XZ) referenced in function "public: virtual __thiscall boost::archive::xml_woarchive_impl<class boost::archive::xml_woarchive>::~xml_woarchive_impl<class boost::archive::xml_woarchive>(void)" Any thoughts? I actually still get the same errors caused by the use of std::wstring as well. Jared

2 2

Complex type failure with boost::lexical_cast
by Preston A. Elder 04 Feb '05

04 Feb '05

Hi, check out this code: #include <boost/lexical_cast.hpp> #include <iostream> struct my_type { int a; int b; }; template<typename C, typename T> std::basic_istream<C,T> &operator>>(std::basic_istream<C,T> &is, my_type &mt) { is >> mt.a >> mt.b; return is; } int main() { std::string input = "1 2"; my_type mt; try { mt = boost::lexical_cast<my_type>(s); std::cout << "TEST 1: " << mt.a << " " << mt.b << std::endl; } catch (boost::bad_lexical_cast &) { std::cout << "TEST 1 FAILED" << std::endl; } input = "3 4"; std::stringstream ss; ss << s; ss >> mt >> std::ws; if (ss.eof()) std::cout << "TEST 2: " << mt.a << " " << mt.b << std::endl; else std::cout << "TEST 1 FAILED" << std::endl; return 0; } The output I get is: TEST 1 FAILED TEST 2: 3 4 My investigation has shown that this occurs because boost::lexical_cast calls stream.unsetf(std::ios::skipws); My question is, why does it do this - as this specifically stops lexical_cast from working with complex types. So could this be an option, or completely disabled, or made an option (somehow) to lexical_cast? I understand some logic to not skipping whitespace, however I believe its use is limited - especially since there is a specialization for std::string and std::wstring already which does not even use operator>>. As a side note, yes, I could change my operator>>, however the sample operator>> above is typical for an operator>> for a complex class, almost always they assume that skipws is turned on, and don't bother checking. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

5 11

Broken Links on Boost.org
by Brian Braatz 04 Feb '05

04 Feb '05

http://lists.boost.org/mailman/listinfo.cgi/boost-users This is what I see in my web browser (IE \ Windows XP) " Boost is a repository of free, portable, peer-reviewed C++ libraries. It acts as a proving ground for new libraries, particularly those which work well with the ISO C++ Standard Library. The main web site is <a href="http://www.boost.org">http://www.boost.org</a> This list is for discussion of issues related to using these libraries. Before subscribing, please read our discussion policy at <a href="http://www.boost.org/more/discussion_policy.htm">http://www.boost. org/more/discussion_policy.htm</a> If your interest is in library submission, development, or review, please subscribe to <a href="http://lists.boost.org/mailman/listinfo.cgi/boost">the Boost developer list</a>. " Notice the : Before subscribing, please read our discussion policy at <a href="http://www.boost.org/more/discussion_policy.htm">http://www.boost. org/more/discussion_policy.htm</a>

2 1

[Test] BOOST_TEST removed?
by Doug Gregor 04 Feb '05

04 Feb '05

BOOST_TEST has been used for testing Boost since the dawn of time, but it's just been removed from CVS, breaking a whole lot of test cases both in Boost and elsewhere. Some warning would have been nice. Not removing it would have been nicer. Doug

11 26

[iostreams] MAP_FILE not available on some platforms
by Caleb Epstein 04 Feb '05

04 Feb '05

The iostreams module mapped_file.cpp fails to compile on (at least) Solaris because it makes use of the mmap flag MAP_FILE which does not exist on that platform. I think this should be protected in an #ifdef MAP_FILE block or similar. http://tinyurl.com/4gv9p -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Bug in Boost.Thread?
by John Eddy 04 Feb '05

04 Feb '05

I noticed a potential hazard in exceptions.cpp of the thread library. The method: const char* thread_exception::message() const returns the c_str of a string with local scope. This is a problem at least in VC 7 .NET 2003. The error can be exposed by the following code. try { throw boost::lock_error(1); } catch(boost::lock_error& e) { cerr << e.message(); } Thanks, John

2 2

[boost.range] RFC on small updates
by Thorsten Ottosen 04 Feb '05

04 Feb '05

Hi All, I have planned to add a few extra convenience function to iterator_range and sub_range. Some people have said the classes could have been a little easier to use. The changes I suggest are the following: iterator_range: -------------- value_type& front() const; value_type& back() const; value_type& operator[]( size_type ) const; value_type& at( size_type ) const; void advance( size_type ); void narrow( size_type left, size_type right ); iterator_range& operator++(); value_type& operator*() const; sub_range: ---------- the same, but now constness is propagated freestanding: ------------ iterator_range make_sub_range( range&, size_type left, size_type right = 0 ); iterator_range make_super_range( range&, size_type left, size_type right = 0 ); iterator_range make_range( range&, difference_type left, difference_type right = 0 ); Comments? -Thorsten

6 18

atomic_count on MSVC/Win32, Tim Fenders optimization
by Hauptmann Peter 04 Feb '05

04 Feb '05

Hi, I noticed that boost/detail/atomic_count.hpp uses the intrinsic verisons of _InterlockedIncrement, _InterlockedDecrement only for Win64 builds. is there a reason? it is documented for VC 2003 without target platform restrictions (and it's "known to work" on VC6, too). thanks peter __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

2 1

Singleton/Multiton Longevity
by Jason Hise 04 Feb '05

04 Feb '05

Just a status update on the singleton/multiton library, so that people know I am still alive ;). After much chaos trying to write a multiton longevity lifetime policy, I had the sudden realization that both singletons and multitons should be able to play nicely together. Thus, I am writing a single(ton) class to manage a priority queue of shared_ptrs to nodes. The longevity policies will derive privately from their respective dependency policies, and create their own derived node types which hold dependencies. As the inheritance is private, these will be the only dependencies in existence. Both multitons and singletons will be destroyed as the dependency-holding nodes are popped in the destructor of the instance registry, which itself will have a static dependency to ensure existence for the entire lifetime of the program. Thoughts and suggestions, as always, are welcome. -Jason

2 2

Semaphore in boost.Thread
by Serguei Kolos 04 Feb '05

04 Feb '05

Hello As far as I know semaphores have been removed from the boost.Thread library. But the point is that on many platforms (Linux for example) semaphore is the only async-signal safe synchronization object. Does anybody know how to synchronize signal handlers with the other programming threads without semaphores? Cheers, Sergei

1 0

A swapping implementation of the C++ library
by Chris Jefferson 04 Feb '05

04 Feb '05

While this isn't strictly related to the development of boost, I believe it may be interesting to developers of boost, and I would also be very interested in hearing any opinions (good and bad) from users and developers of boost. I am currently in the process of implementing all applicable (sort, rotate, partition, etc..) functions in the C++ standard library using only calls to iter_swap. Obviously for those classes with expensive copies and cheap swaps (list, vector, map, set, etc) this is a big win, however it unfortunatly can be slightly slower for classes and types which fall on the basic definition of swap. Therefore there will be an implementation-specific type trait defined (name to be decided) which can be defined to enable the swapping versions of functions. I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library). While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements. I would be interested in knowing if anyone has any comments, and also should such code be implemented in g++ if boost would be willing to add the compiler-specific extra information to mark any classes with efficent swap as such. Note: I am aware there are various ways of trying to approximate if someone has specialised swap, such as checking for a swap member function. However at least at first, it is my belief such a library should probably be strictly op-in. Thank you, Chris

2 2

boost v 1.33 ?
by Robert Ramey 04 Feb '05

04 Feb '05

Could we consider fixing a date for boost 1.33. I would like to agree to just concentrate on fixes, tests and resolving pending issues regarding code currently checked into cvs.. I think this would be relatively painless - at least compared to the last time. Robert Ramey

8 19

[serialization] add_facet question
by Jonathan Turkanis 04 Feb '05

04 Feb '05

Hi Robert, I'd like to use add_facet from serialization in the iostreams library, but I don't understand why the generated locale is dynamically allocated. It would seem be more reusable to declare it as follows: template<typename Facet> inline std::locale add_facet(const std::locale& loc, Facet* facet); If you need a dynamically allocated locale, you could write new std::locale(add_facet(loc, facet)) Jonathan

2 4

Re: [boost] Re: Two alined_storage classes in the CVS
by JOAQUIN LOPEZ MU?Z 04 Feb '05

04 Feb '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Jueves, Febrero 3, 2005 9:51 pm Asunto: [boost] Re: Two alined_storage classes in the CVS > Since these are in different namespaces, can this not be just > ignored? Is > it worth spending any time on? > Hi Robert, I'm afraid both classes live directly in namespace boost. Joaquín M López Muñoz Telefónica, Investigación y Desarollo

3 2

Gauging Interest: New Functional Library and Programming Language
by christopher diggins 03 Feb '05

03 Feb '05

I have just completed a prototype for a functional programming language called Unimperative, which is also valid C++. This language is implemented in C++ by overloading the comma operator and use of the boost::any library. The language syntax is similar to Scheme but with the significant difference that a Function is called as (MyFxn, x, y). For instance where in Scheme you might write a factorial function as: (define factorial (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))) In Unimperative you could write it as: Function Factorial = (If, (Eq, _1, 0), 1, (Mult, _1, (Eval, self, (Dec, _1)))); You can also write procedural code in Unimperative Function F = (Proc, (Output, 1), (Output, 2), (Output, 3), End); I have written a bit more on the language and provided some code examples at http://lambda-the-ultimate.org/node/view/512 . Well anyway, my question to the group, is whether there is some potential interest in this kind of library, and to find out if anyone wants to collaborate. Also, any suggestions on the kinds of features that would make this language/library more interesting to users and/or the boost community? Thanks in advance. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

4 8

boost::basic_wrap_stringstream SIGBBUS with SunPRO
by Caleb Epstein 03 Feb '05

03 Feb '05

I'm running into numerous examples of the regression test programs hanging/crashing today due to what may be a problem with basic_wrap_stringstream. Here's an example: /home/nbde52d/src/boost-regression/results/bin/boost/libs/assign/test/my_vector_example.test/sunpro-5_3/debug/my_vector_example --log_level=all Running 1 test case... Entering test suite "List Test Suite" Entering test case "check_list_inserter" ../libs/assign/test/my_vector_example.cpp(98): info: test vec.size() == 10u passed. Exception in "check_list_inserter": signal: memory access violation /home/nbde52d/src/boost-regression/boost/boost/test/impl/unit_test_suite.ipp(179): fatal error in "check_list_inserter": Testing aborted Leaving test case "check_list_inserter" Leaving test suite "List Test Suite" *** errors detected in test suite "List Test Suite"; see standard output for details Here's a stack trace from dbx (same program): (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) run Running: my_vector_example (process id 10116) Running 1 test case... signal SEGV (no mapping at the fault address) in _free_unlocked at 0x7fa42bbc 0x7fa42bbc: _free_unlocked+0x0040: ld [%i0 - 0x8], %o0 Current function is boost::test_tools::predicate_result::~predicate_result 47 ~predicate_result() { delete m_message; } (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where [1] _free_unlocked(0x2000, 0x7fabc008, 0x2000, 0x7fabc008, 0x22310, 0x7fa42b64 ), at 0x7fa42bbc [2] free(0x2000, 0x5, 0x5, 0x7fabc008, 0x22310, 0x7fa42b64), at 0x7fa42b6c [3] operator delete(0x2000, 0x7fabc008, 0x0, 0x7fabc008, 0x22310, 0x7fa42b64), at 0x7fb46260 [4] std::basic_stringbuf<char,std::char_traits<char>,std::allocator<char> >::~ basic_stringbuf(0xffbedb60, 0xffbed7b0, 0x34a68, 0x2, 0x222e8, 0x7fb46260), at 0 x71630 [5] std::basic_ostringstream<char,std::char_traits<char>,std::allocator<char> >::~basic_ostringstream(0xffbedb58, 0xffffffff, 0x60, 0xa1768, 0x220b8, 0x4d774) , at 0x66450 [6] boost::basic_wrap_stringstream<char>::~basic_wrap_stringstream(0xffbedb58, 0xa0034, 0xa11bc, 0xffbed838, 0x2f8, 0xa1490), at 0x38250 =>[7] boost::test_tools::predicate_result::~predicate_result(this = 0xffbed88c), line 47 in "predicate_result.hpp" [8] check_list_inserter(), line 98 in "my_vector_example.cpp" [9] boost::unit_test::function_test_case::do_run(this = 0xab248), line 138 in "unit_test_suite.hpp" [10] boost::unit_test::ut_detail::unit_test_monitor::function(this = 0xa0a10), line 79 in "unit_test_monitor.ipp" [11] boost::execution_monitor::run_function(this = 0xa0a10), line 197 in "exec ution_monitor.ipp" [12] boost::detail::catch_signals(exmon = CLASS, catch_system_errors = true, t imeout = 0), line 418 in "execution_monitor.ipp" [13] boost::execution_monitor::execute(this = 0xa0a10, catch_system_errors = t rue, timeout = 0), line 223 in "execution_monitor.ipp" [14] boost::unit_test::ut_detail::unit_test_monitor::execute_and_translate(thi s = 0xa0a10, target_test_case = 0xab248, f = 0xffbee024, timeout = 0), line 46 i n "unit_test_monitor.ipp" [15] boost::unit_test::test_case::run(this = 0xab248), line 173 in "unit_test_ suite.ipp" [16] boost::unit_test::test_suite::do_run(this = 0xab168), line 277 in "unit_t est_suite.ipp" [17] boost::unit_test::test_case::run(this = 0xab168), line 186 in "unit_test_ suite.ipp" [18] main(argc = 1, argv = 0xffbee4dc), line 84 in "unit_test_main.ipp" -- Caleb Epstein caleb dot epstein at gmail dot com

1 1

BIL and boost::any
by christopher diggins 03 Feb '05

03 Feb '05

Hello all, I just realized that an empty BIL interface, BOOST_IDL_BEGIN(IAnything) BOOST_IDL_EMPTY(IAnything) has some common ground with: boost::any Where boost::any stores a copy of a value of practical any type for later extraction, IAnything can point to just about anything. void BoostAnyTest() { int x = 5; boost::any a = x; TEST(any_cast<int>(a) == 5); } void AnythingTest() { int x = 5; IAnything a = x; TEST(extract<int>(a) == 5); } void ObjectTests() { BoostAnyTest(); AnythingTest(); } I just thought this could lead to some kind of connection between the libraries. It might be nice to see this in the boost::any namespace, i.e. a boost::any::any_ref. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

7 25

is_incrementable fixes for VC6
by Jonathan Turkanis 03 Feb '05

03 Feb '05

Hi, I've encountered some compile errors using is_incrementable with VC6. They can be fixed by fully qualifying remove_cv and by using macros from type traits to define the traits is_incrementable and is_postfix_incrementable: # include <boost/type_traits/detail/bool_trait_def.hpp> .... // Local macro, #undef'd below # define BOOST_DETAIL_BOOL_TRAIT_DEF1(trait,T,C) \ template< typename T > struct trait \ BOOST_TT_AUX_BOOL_C_BASE(C) \ { \ BOOST_TT_AUX_BOOL_TRAIT_VALUE_DECL(C) \ }; \ /**/ BOOST_DETAIL_BOOL_TRAIT_DEF1(is_incrementable, T, ::boost::detail::is_incrementable_::impl<T>::value) BOOST_DETAIL_BOOL_TRAIT_DEF1(is_postfix_incrementable, T, ::boost::detail::is_incrementable_::postfix_impl<T>::value) # undef BOOST_DETAIL_BOOL_TRAIT_DEF1 Can I go ahead and add this stuff? Also, should I put in lambda and template arity support? Other options would be: * add a header detail/bool_trait_def.hpp for defining traits in namespace detail. * write a macro for generating traits like is_incrementable Jonathan

2 1

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 03 Feb '05

03 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_PP_EXPR_IF Behavior
by John Eddy 03 Feb '05

03 Feb '05

I am not terribly familiar with the rules of the preprocessor. Is it the case that the expression of the BOOST_PP_EXPR_IF macro is expanded regardless of the resulting value of the condition? The reason I ask is because the following code produces a warning with VC7 .NET 2003. #define MY_MACRO(array) \ BOOST_PP_EXPR_IF( \ BOOST_PP_ARRAY_SIZE(array), \ BOOST_PP_TUPLE_TO_SEQ( \ BOOST_PP_ARRAY_SIZE(array), \ BOOST_PP_ARRAY_DATA(array) \ ) \ ) MY_MACRO((0, ())); The warning is: C4003: not enough actual parameters for macro 'BOOST_PP_EXPR_IIF_0' The macro expands correctly. Perhaps there is a better way to do what I am after. I would like to create a comma separated list (no parenthesis as would be the case if I only took the array data) from a possibly empty set. Thanks, John

2 2

allocator_utilites: problems with VC6
by Jonathan Turkanis 03 Feb '05

03 Feb '05

Hi, I'm trying to use allocator_utilities with VC6 in the following manner: template<typename Alloc> struct bzip2_allocator_traits { typedef typename boost::detail::allocator::rebind_to< Alloc, char >::type type; }; template< typename Alloc, typename Base = // VC6 workaround: C2516 BOOST_DEDUCED_TYPENAME bzip2_allocator_traits<Alloc>::type > struct bzip2_allocator : private Base { ... }; Unfortunately, I get the error C2039: 'rebind' : is not a member of 'fake_allocator<0>' Any suggestions? Jonathan

2 2

[filesystem] readdir_r on SunPRO
by Caleb Epstein 03 Feb '05

03 Feb '05

Just noticed this compile error for the latest CVS code using the SunPRO compiler: "/home/nbde52d/src/boost-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp", line 121: Error: readdir_r is not a member of file level. Here's the compile command: CC -c -g -xtarget=generic +d -features=rtti -features=except -features=tmplife -instances=static -I"/home/nbde52d/src/boost-regression/results/bin/boost/libs/filesystem/build" -I"/home/nbde52d/src/boost-regression/boost" -I"/home/nbde52d/src/boost-regression/boost" -o "/home/nbde52d/src/boost-regression/results/bin/boost/libs/filesystem/build/libboost_filesystem.a/sunpro-5_3/debug/operations_posix_windows.o" "/home/nbde52d/src/boost-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp" The -mt flag is not present, so including <dirent.h> does not pull in the readdir_r prototype. I think the use of ::readdir_r needs to be further protected with a check for whether MT code is being compiled (BOOST_HAS_THREADS?) -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Was [RE: [boost] Moving from CVS to Subversion?] Now is "Subversion experiences from the field"
by Brian Braatz 03 Feb '05

03 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Walter Landry > Subject: Re: [boost] Moving from CVS to Subversion? > > David Abrahams <dave(a)boost-consulting.com> wrote: > > > > I am just posting this here to alert those who look at subject lines > > to what we're discussing. To review the whole discussion, see > > http://news.gmane.org/find- > root.php?message_id=%3cuk6pujjyu.fsf%40boost%2dconsulting.com%3e > > One thread you might find interesting > > http://news.gmane.org/find-root.php?group=gmane.comp.version- > control.subversion.devel&article=53583 > > It talks about the troubles Mono had in going from CVS to Subversion. > YMMV. > > My personal opinion is that, if you want a centralized version control > system, you aren't going to do significantly better than Subversion. > There are a fair number of large projects using it, and, especially > with the new fsfs backend, it seems to work pretty well for most > people. [Brian Braatz] I am currently running cvs and subversion side by side and wanted to share my experiences: We have been running CVS for 4 years and SVN for about 2 CVS **** We have about 50 people hitting one server CVS seems to handle this nicely We are using cvs for 2 projects Cvs add not being recursive is a pain in the butt. I am several states away from the cvs server I am currently STILL adding boost 1.32 to a repository I started this last Friday On the SVN repository, this took a few hours (same net connection) Also the recursive "svn add" command meant I did not have to baby sit it SVN (Subversion) **************** Svn add is recursive Most of the SVN commands are very similar to cvs Seems significantly faster than cvs We had ONE instance in 2 years where we lost data- IT guys never figured out what it was- might have been a power surge or SVN we don't know We have never lost data on the cvs server We are only running about 5 guys against our svn box You can move files and retain history Retrieving files FROM history is not as simple as cvs It uses the berkely db backend Which I am not familiar with nor are my people experts in it I can "svn add" while on an airplane, but I have to be online to "svn commit" It has transactional commits- Which means if something bombs halfway through a commit- NONE of the files are added We have been bit by this one on CVS in our projects My Opinion: I like SVN, but we have not completely switched over to it For Boost, the redundant servers from sourceforge is a compelling reason to stay cvs. I am not aware if you can get the same thing from sourceforge with svn. Svn does not however tax the server as much as cvs, hence there is more client side processing Anyone else have any experience with these two side by side they wish to share?

4 3

Simple regex problem
by Preston A. Elder 03 Feb '05

03 Feb '05

Hum, Consider the following application (running on Linux with GCC): === BEGIN CODE #include <boost/regex.hpp> #include <iostream> #include <exception> #include <typeinfo> int main() { try { std::string rx_string = "^([[:alpha:]][-[:alnum:]]*[[:space:]]*)+$"; boost::regex rx(rx_string, boost::regex_constants::char_classes | boost::regex_constants::intervals); std::string test = "GlobalMSG HelpServ DevNull"; if (boost::regex_match(test, rx)) std::cout << "Matched." << std::endl; else std::cout << "Not Matched." << std::endl; } catch (const std::exception &e) { std::cout << "Exception " << typeid(e).name() << ": " << e.what() << std::endl; } return 0; } === END CODE The result of running this is: Exception N5boost14bad_expressionE: Memory exhausted My question is, why? The regex is simple enough, and the source string is quite short. Please note, the same regex with the test string of: "OperServ Magick-1" runs and completes successfully without a problem. Any ideas on how to fix this? -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 3

CW and NOMINMAX
by Stefan Slapeta 03 Feb '05

03 Feb '05

Hi all, I wonder why NOMINMAX is defined globally for _all_ platforms in cw-tools.jam. # Some language related options flags cw C++FLAGS : -DNOMINMAX ; This produces warnings for some regressions due to redefinitions in the code! Aside from that, IMO it doesn't make sense to define NOMINMAX on other platforms than windows, no? If nobody objects, I would like to remove this line to see what happens. Stefan

1 0

New Library?
by John Eddy 03 Feb '05

03 Feb '05

Would anyone be interested in a library for doing logging? I've written one for my own purposes and thought others might find it useful. It will store log entries at various levels (FATAL, SHOUT, ERROR, WARN, INFO, DEBUG, DETAIL). There is a default level and the level can be customized for entries by individual instances of any type and for entries by any types as a whole. I'll be glad to provide more information if anyone is interested. John

8 14

Re: [boost] Re: Help needed with BGL & multi_index_container
by JOAQUIN LOPEZ MU?Z 03 Feb '05

03 Feb '05

Hi Alexander, ----- Mensaje original ----- De: Alexander <rhjrjlbk2002(a)yahoo.com> Fecha: Miércoles, Febrero 2, 2005 8:38 pm Asunto: [boost] Re: Help needed with BGL & multi_index_container > Hi Joaquin and Jeremy, > > Below you may find latest version of my test program. > This time it compiles, links and works :-). I have to > say - it was not easy to make it working. > > The only trouble I have is clumsy code in templated > ItemHolder::operator()(const P&p) and correspondent call > to template ItemHolder::get_int(...). See my comments > below. > > I'm looking for advice to make it nicer. I think I've got something, please read below. > > Replacement of "const P& p" to "void*" breaks VS 7.1. > [...] > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > Date: Tue, 01 Feb 2005 22:51:12 +0000 > > MG::vertex_descriptor vd1 = > > add_vertex( ItemHolder( 1, Item(1) ), mg ); > > In this line following is happen: > > 1. adjacency_list allocates (with new) a new > stored_vertex structure to store property > element of type ItemHolder (yes, using my initialization > value), fields to store incoming, outgoing edges and > other fields. > > 2. This pointer is cast to a void *, to be used as > the new vertex descriptor. > > 3. The void * is fed to the multi_index_container used > for vertex storage. > > 4. Now, inside ItemHolderKey, that "void *" must be converted to back > to stored_vertex type, defined in base class of adajcent_list. And > thisI find as a real threat to break everything. To my regret, I > can't spend > more > time - I have to put all that into my project. > > > Well, all in all I must say this is a glorious hack :) > > Thank you! Indeed, you did helped me. > > > Probably, the only sensible approach is to write from > > scratch a graph-compliant structure that uses > > I already did that couple of times. I do not want that anymore. > Writing, testing, documenting, helping colleques to numerous > suboptimal versions of the same component, scattered through > number of versions of different products... No, thank you. > > > That said, the thing seems to work and may suffice > > for your purposes. > > I see that as a quite general use case. > > > It'd be great if some BGL expert (Jeremy?) jumped > > in and comment on this. > > Yes, that would be great. > > Kind Regards, > Alexander > > -------------- sample code -------------- > #include <iostream> > > #include <boost/multi_index_container.hpp> > #include <boost/multi_index/ordered_index.hpp> > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/graph/adjacency_list.hpp> > > using namespace boost; > using namespace boost::multi_index; > > using namespace std; > > template<class Index> > struct MICSelector > { > typedef Index index; > }; > > struct Item > { > Item(int _a=0, int _b=0, int _c=0) > : a(_a), b(_b), c(_c) {} > > int a,b,c; > > friend std::ostream& operator<< > (std::ostream& os, const Item& item) > { > return os << " a: " << item.a << > " b: " << item.b << " c: " << > item.c << " "; > } > }; > > struct ItemHolder > { > ItemHolder(int id=0, const Item item=Item()) > : m_ID(id), m_item(item) {} > > int m_ID; > Item m_item; > > friend std::ostream& operator<< > (std::ostream& os, const ItemHolder& item) > { > return os << " ID: " << item.m_ID > << " Item( " << item.m_item << ") "; > } > }; > > struct ItemHolderKey > { > typedef int result_type; > int operator()(const ItemHolder& v) const { return v.m_ID; } > > template<class P, class Derived, class Config, class Base> > int get_int(const P& p, const adj_list_impl<Derived, Config, Base>&) > const; > > template<class P> > int operator()(const typename P& p) const; > }; The problem with your approach to implementing this oeprator() is that you've got a circular dependency between ItemHolderKey, which is nasty to say the least. Since you're hacking your way through this, I guess you won't mind relying on just another undocumented feature to solve this in a nicer manner. Reviewing the BGL source, seems like the container is not instantiated with void*s but rather with the actual stored_vertex pointer. stored_vertex must be one of the following types: boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_seq_stored_vertex ; boost::graph::detail::adj_list_gen<...>::config::rand_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_rand_stored_verte x; So you just can provide overloads for all of them and get rid of the "static MG m" dependency and the get_int() memfun: template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> int operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return p->m_property.m_value.m_ID; } //etc for the other stored_vertex types See what I mean? You can even do better and provide an adaptor that takes a general key extractor and performs the surgery: template<typename KeyExtractor> struct from_adjacency_list: private KeyExtractor { typedef KeyExtractor::result_type result_type; // we forward to KeyExtractor for the general case template<typename Value> const result_type& operator()(const Value& v) { return KeyExtractor::operator()(v); } // overloads for the various stored_vertex types template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> const result_type& operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return KeyExtractor::operator()(p->m_property.m_value); } // etc }; Now you can use this adaptor in a fairly general way: // No need to define ItemHolderKey. // No dependecies from the particular adjacency_list you're // instantiating. typedef indexed_by < sequenced<>, ordered_unique< from_adjacency_list<member<ItemHolder,int,&ItemHolder::m_ID> > > // and other indices > Index; I haven't actually tried this, but I think it should work and provide with a much more comfortable way to define your embedded MICs. [...] > It is correct that I use undocumented features of BGL to > fuse MIC and BGL. OTOH, it is the way how std::list, > std::vector etc. are used. It would be a surprise if it > is gonna change. One could say that it is > documentation issue, rather then the code. Well, the thing should work but won't be surprised if everthing goes to heck when ugrading to Boost 1.3x. As for this being a documentation issue, I'm afraid too much detail is relied on to think realistically BGL authors will concede to open it to the public. A most viable solution (applicable not only to MIC but also to any other container) would be to have a graph class modeled after adjacency_list with the following aspect: template< typename ElementType, typename EdgeList, typename VertexList, ... > element_adjacency_list; so that it guarantees that the edge container is instantiated with elements of type ElementType*. This is not very hard to achieve if the actual stored_vertex is defined like this: template<typename ElementType> struct element_pointer { ElementType* ptr; }; template<typename ElementType,...> struct stored_vertex: public element_pointer<ElementType> { // rest of the payload (properties, pointer to edge list, etc. }; // from stored_vertex* to ElementType* stored_vertex<...>* sv; ElementType* ptr=sv->ptr; // from ElementType* to stored_vertex // this is portable! ElementType* ptr; element_pointer<ElementType>* eptr= reinterpret_cast<element_pointer<ElementType>*>( reinterpret_cast<char*>(ptr)- offsetof(element_pointer<ElementType>,ptr) ); stored_vertex<...>* sv=static_cast<stored_vertex<...>*>(eptr); Implementing this should be mostly cut&paste from the original adjacency_list, so, who knows, maybe you can convince BGL authors to do it :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-1115124 ] Diff in state of mersenne_twister gen between GCC3.41 & CW9
by SourceForge.net 03 Feb '05

03 Feb '05

Bugs item #1115124, was opened at 2005-02-02 16:08 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=1115124&group_… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morgan (toth21) Assigned to: Jens Maurer (jmaurer) Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Initial Comment: I have found a bug with the mersenne_twister random number generator class, where results when calling for a random number vary between codewarrior 9.0 and gcc 3.4.1 with boost 1.31.0. A simple example is shown below: #include <boost/random/mersenne_twister.hpp> //for mt11213b typedef boost::mt11213b base_generator_type; class foo { public: foo(const base_generator_type gen):m_gen(gen) {} ~foo(void) {} rand_type operator() ( void ) { const float x = m_gen(); return x; } private: base_generator_type m_gen; } int main(void) { base_generator_type gen( (uint32_t) 2000); //seed is not important foo f(gen); cout << "Random result is " << f() << endl; } The resulting numbers will be different between codewarrior 9.0 running on windows (xp or 2000) and gcc 3.4.1 running on Suse linux 7.3.(Hope that is enough info). I tracked the cause of the bug down to class initialization. In the case of CW9.0, the compiler when constructing a foo, will use a mersenne_twister copy ctor when initializing m_gen, while in the case of gcc 3.4.1 it will choose the following in the .hpp file template<class Generator> explicit mersenne_twister(Generator & gen) { seed (gen); } therefore using the provided generator as a seed to the new generator rather than just copying its state, even though no template parameter is provided. Anyways I will leave it up to the more informed to decide which is more desirable/proper; however, this is a fairly nasty bug at the moment as you can not reproduce results between these two platforms when using this random number generator for your random numbers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1115124&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Boost Digest, Vol 991, Issue 1
by Jared McIntyre 02 Feb '05

02 Feb '05

> Well, it doesn't look like you're inclined to give up so I guess we can't > either. Thas greatly appreciated. > Do I take this to mean that almost all the tests (200+) compiled, linked, > and executed with no error? Correct. To be exact, there were 5 skipped and 5 that failed. > General > 1) Configuration Type: Application(.exe) > 2) Use of MFC: Use Standard Windows Libraries > 3) Use of ATL: Not using ATL This project is MFC based, but I can't imagine that is causing an issue. Otherwise its the same. > C/C++ > 1) General > Additional Include Directories - the directory that contains boost > headers > 3) Preprocessor: > Preprocessor definitions - WIN32;_DEBUG;_CONSOLE > 4) Code Generation > Enable C++ Exceptions - Yes(/EHsc) > Runtime Library - Multi-threaded Debug DLL - note the DLL ! ( I > suspect this is the problem) > Enable Function-level Linking - Yes(/Gy) I prefer this myself but > not strictly necessary > 5) Language > Enable Run-Time type info - Yes (/GR) > Linker > 1) General > Additional Library Directories - <directory that contains the > serialization library here> > 2) Input > Additional Dependencies - libboost_serialization.lib This is all the same with the exception of the console part (since it is an MFC GUI app), but again, I doubt that is causing it. > I would hope that those settings should do it. To make sure its finding the > correct libboost_serialization.lib - change the name of this file. It > should come up with an error at link time - can't find file > libbost_serialization.lib. Changing this name back should make this error go > away. Check > The program should now compile !? Saddly, the problem persists. Perhaps it is something other than the library. Here are some code snippets in case there are issues there. The includes in the file that performes the save: #include <fstream> #include <boost/serialization/serialization.hpp> #include <boost/serialization/vector.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> Here is the save code: std::ofstream ofs(PCSZ_USER_TOOLS_FILE, std::ios::binary); boost::archive::text_oarchive oa(ofs); // write class state from archive oa << boost::serialization::make_nvp("UserToolList", m_UserTools); // close archive ofs.close(); m_UserTools is an instance of a typedefed vector defined as: typedef std::vector<BusUserTool*> USER_TOOL_LIST; Thanks for hanging in with me. I will probably need to change the code so I compile the serialization code into the project soon in order to meet my deadlines, but I'd like to get the library working if possible. Jared

3 2

Dimensional Analysis
by Sérgio Vale e Pace 02 Feb '05

02 Feb '05

Is the dimensional analisys code shown in the MPL tutorial, part of the mpl library ? Or any other boost library ?

9 30

1.32 intel 8.1 in windows
by Matt Hurd 02 Feb '05

02 Feb '05

Trying and failing to compile v1.32 with Intel 8.1 on windows. Seems mainly /Zm800 option is in error. Is there a quick fix for building 1.32 with this toolset? I'm simply doing this from the boost root bjam "-sTOOLS=intel-win32" "-sINTEL_BASE_MSVC_TOOLSET=vc-7_1" stage TIA, Matt. matthurd(a)acm.org

2 4

Help needed with BGL & multi_index_container
by Me here 02 Feb '05

02 Feb '05

Hi there, I need an advanced container which allows me to access my data over number of different indices. That is exactly what for boost::multi_index_container was made. But, my data items also have relationships with other data in the same container, which could be represented as directed graph. So, I have made a custom container, which aggregates multi_index_container (MIC) to store data items and a graph (BGL) to store relationships. To allow switching from MIC to walk over relationships, as an additional field of my item in MIC I store BGL vertex; as vertex property in graph I store the key of unique index in MIC. So, MIC and BGL refer to each other. But, it is difficult to have those two containers in sync. So, I made another attempt to have MIC as customized vertex storage. I succeed two write the code for it (see it below). It also compiles and links :-). Unfortunately, I can not add neither vertices not edges. If I try to add vertex as in commeted code below, an error errors that there is no convertion from vertex property to vertex descriptor (error message is below). What's wrong? My another question is: how can I get access to my MIC stored in graph? I would like to use its indices. Best wishes, Alexander --------- sample code ----------- #include <iostream> #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/graph/adjacency_list.hpp> using namespace boost; using namespace boost::multi_index; using namespace std; struct MICSelector {}; struct Item { Item(int _a=0, int _b=0, int _c=0) : a(_a), b(_b), c(_c) {} int a,b,c; }; struct ItemHolder { ItemHolder(int id=0, const Item item=Item()) : m_ID(id), m_item(item) {} int m_ID; Item m_item; }; struct ItemHolderKey { typedef int result_type; int operator()(const ItemHolder& v) const { return v.m_ID; } }; template<class ValueType> struct MICWrapper { typedef multi_index_container < ValueType, indexed_by < ordered_unique< ItemHolderKey > > > type; }; namespace boost { // the specialization for your selector template<class ValueType> struct container_gen<MICSelector, ValueType> { typedef typename MICWrapper<ValueType>::type type; }; template <> struct parallel_edge_traits<MICSelector> { typedef allow_parallel_edge_tag type; }; }; typedef adjacency_list < listS, MICSelector, bidirectionalS, ItemHolder > MG; int tmain(int argc, char* argv[]) { MG mg; /* ItemHolder IH( 1, Item(1) ); add_vertex( &IH, mg ); // add_edge( // ItemHolder( 1, Item(1) ), // ItemHolder( 2, Item(2) ), // mg ); */ cout << typeid( boost::graph_traits<MG>::vertex_descriptor ).name(); return 0; } --------- sample code ----------- ----------- error message ------------- Compiling... MIC_BGL.cpp c:\test\MIC_BGL.cpp(87) : error C2664: 'boost::add_vertex' : cannot convert parameter 1 from 'ItemHolder *__w64 ' to 'const boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_property_type &' with [ Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectionalS,ItemHolder>, VertexListS=MICSelector, OutEdgeListS=boost::listS, DirectedS=boost::bidirectionalS, VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t,ItemHolder>::type, EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type, GraphProperty=boost::no_property, EdgeListS=boost::listS ] Reason: cannot convert from 'ItemHolder *__w64 ' to 'const boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_property_type' with [ Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectionalS,ItemHolder>, VertexListS=MICSelector, OutEdgeListS=boost::listS, DirectedS=boost::bidirectionalS, VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t,ItemHolder>::type, EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type, GraphProperty=boost::no_property, EdgeListS=boost::listS ] No constructor could take the source type, or constructor overload resolution was ambiguous ----------- error message ------------- __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

6 5

[mpl]mpl::plus and non Integral Constants
by Andy Little 02 Feb '05

02 Feb '05

Reading the mpl documentation it states that boost::mpl::plus is expected to be specialised for non Integral Constants. Therefore should the following work ?: typedef boost::mpl::plus<int,int>::type int_plus_int_type; // eg int presumably OTOH it could be said that: mpl::plus<int_<1>, int_<1> >::type and mpl::plus<int,int>::type are conceptually different and that therefore mpl::plus<int,int> should be(remain) invalid. Any thoughts? regards Andy Little

3 2

Reminder: Boost Logo Contest
by Joel de Guzman 02 Feb '05

02 Feb '05

Hi Y'all, This is to remind you about the ongoing Boost Logo Contest: http://www.boost.org/more/logo_contest.htm Entries will be accepted on or before February 15, 2005. Please email all entries to me (djowel at gmail dot com). I've posted the entries submitted so far in the page above. I decided not to continue with the wiki page because of problems and difficulties with it. Some things to note: 1) I'm limiting the image size to a width of 320 pix. This is for the sake of uniformity. Images that were rescaled to fit this limit might look jagged. If you are not satisfied, please re-submit. 2) Most entries have a title (italics). To those who wish to have a title (optional), please email me. This is optional because each entry has a corresponding number anyway. 3) Some entries have an annotation relating to the artwork. This is also optional but it might help if you annotate your work. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 1

[Boost-bugs] [ boost-Bugs-1114831 ] boost 1.32 compile error with STLPort462 and boost/format
by SourceForge.net 02 Feb '05

02 Feb '05

Bugs item #1114831, was opened at 2005-02-02 16: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=1114831&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Glen Summers (glensummers) Assigned to: Nobody/Anonymous (nobody) Summary: boost 1.32 compile error with STLPort462 and boost/format Initial Comment: compile error using MSVC 7.1 STLPort4.6.2 Boost 1.32.0 Code: #include <iostream> #include <tchar.h> #include <boost/format.hpp> int _tmain(int argc, _TCHAR* argv[]) { return 0; } Fails with: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' Worked with boost 1.31.0 Regards, Glen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1114831&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[serialization]: 1.32/VC7.1:error C2039: 'serialize' : is not a member of 'std::vector<_Ty>'
by Francis ANDRE 02 Feb '05

02 Feb '05

Hi Robert I got the following error from the serialization access.cpp: : Schema.cpp c:\boost\boost\serialization\access.hpp(106) : error C2039: 'serialize' : is not a member of 'std::vector<_Ty>' with [ _Ty=GLOB::SUB::Key ] ... ... For sure, I have doubled checked that the "boost/serialization/vector.hpp" file is well included at the very beginning of Schema.cpp This error appears only with binary archive. With an XML archive, the source Schema.cpp does not produce any error. I am not able to reproduce it on a small case. Is there anyway to trace/or activate an helper that could show up be the underlying problem?? Regards Francis ANDRE

2 2

Graph_traits and Graph
by Jannel Rémi 02 Feb '05

02 Feb '05

Hello All, I started to use boost a few weeks ago and i still have got some problems with the graph_traits theory. In fact, it seems that you use a graph_traits to stock the type of the data used for the Graph (given as a template) such as vertex_descriptor or in_edge iterator. To keep this you use something like: typedef typename Graph::vertex_descriptor vertex_descriptor; which means that you get this type from Graph::vertex_descriptor. Now, if i want to wite an algorithm which will search for all the vertices for example, i'll have to use my Graph as a template and i'll get the vertex type for example using typedef typename graph_traits<Graph>::vertex_descriptor vertex_descriptor; That's why I wanted to ask you why this method is used instead of just typedef typename Graph::vertex_descriptor vertex_descriptor; used in the class graph_traits definition. I hope i made me understandable! Thanks a lot Koopajah

2 1

[Boost-bugs] [ boost-Bugs-1114732 ] boost 1.32 compile error with STLPort462 and boost/format
by SourceForge.net 02 Feb '05

02 Feb '05

Bugs item #1114732, was opened at 2005-02-02 13:37 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=1114732&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Glen Summers (glensummers) Assigned to: Nobody/Anonymous (nobody) Summary: boost 1.32 compile error with STLPort462 and boost/format Initial Comment: compile error using MSVC 7.1 STLPort4.6.2 Boost 1.32.0 Code: #include <iostream> #include <tchar.h> #include <boost/format.hpp> int _tmain(int argc, _TCHAR* argv[]) { return 0; } Fails with: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' Worked with boost 1.31.0 Regards, Glen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1114732&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Regression tests completely broken?
by Caleb Epstein 02 Feb '05

02 Feb '05

I reported an error yesterday that I thought stemmed from my trying to use a toolset variant. I changed my regression.py run to use the "stock" toolsets and I'm still getting an identical error (though now with the stock toolset name "sunpro"). Nothing is being built and no tests are being run as a result: http://article.gmane.org/gmane.comp.lib.boost.build/8071 -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Status of BOOST_ASSERT?
by Beman Dawes 02 Feb '05

02 Feb '05

BOOST_ASSERT is documented at http://www.boost.org/libs/utility/assert.html, but it isn't mentioned or linked to in the library index, programmers guidelines, or utility index. If Boost libraries are really supposed to use BOOST_ASSERT, seems like we need to better integrate it into our docs by mentioning it and linking to its docs on the above pages. I looked at the archives a bit, but didn't see any definitive answer as to whether or not we had decided to use BOOST_ASSERT rather than plain assert. Comments? --Beman

3 2

[spirit][phoenix] operator[] hack for std::map
by Ronald Garcia 02 Feb '05

02 Feb '05

Howdy, I've been working on a parser in Spirit that uses Phoenix and came across an item that I needed to support: operator[] on std::map. Perhaps I overlooked this feature somewhere, but based on the code in operators.hpp, I crafted the following code for myself: namespace phoenix { // Workaround: std::map::operator[] uses a different return type than all // other standard containers. Phoenix doesn't account for that. template <typename TK, typename T0, typename T1> struct binary_operator<index_op, std::map<TK,T0>, T1> { typedef typename std::map<TK,T0>::mapped_type& result_type; static result_type eval(std::map<TK,T0>& container, T1 const& index) { return container[index]; } }; } // namespace phoenix I suspect that it would need generalizing to be added to Phoenix as it comes with Spirit, but I thought that it would be useful to alert others of the desire for this feature, if not supply a full implementation (I really don't have the time :( ). Cheers, ron

3 2

Re:[probing interest]AssocVector (and other parts of Loki)
by ION_G_M 02 Feb '05

02 Feb '05

>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]) Yes I would be, since I'm using it in Boost Shmem. >1) Is there interest in additional interfaces(set, multiset, multimap) >described in [1] or is std::map-like container enough? I would see this also very useful, since associative containers are normally developed as a single underlying class that can be, via traits, converted into multi* or *map/set. Since assoc_vector or the new container family will be based on a vector implementation, I would suggest providing a common vector-like class that uses the following: -> No raw pointers. Uses allocator::pointer instead -> No placement news or destructors. Uses allocator::construct/destroy -> To sum up: all memory operations done using allocator interface so that for example, can be used in shared memory using relative pointers. While doing some tests, I was able to modify slightly yasli_vector to provide this (allocator/pointer) != (new(ptr)/T*) approach. Maybe it could be a good start point. For a modified SGI vector implementation using this approach, please see shmem_vector in Boost Shmem library in Files Section. shmem_assoc_vector is basically the same as Loki AssocVector. If this vector is also developed for Boost to construct the AssocVector/flat_associative containers, I would be glad to drop the shmem_vector and shmem_assoc_vector classes from Boost Shmem, since they only modify SGI implementations to use the generic allocator approach. I would also point out that apart from set/map operations, the new family should have reserve/capacity methods to optimize memory usage and avoid reallocations if the user knows the number of elements to insert. Just a call to vector::reserve/capacity I've been also talking with Daniel James, who is responsible of Boost unordered associative family and he is also generously using this allocator::pointer/construct/destroy generic approach, so we will be able to use boost unordered family in shared memory, mapped in different base addresses, using relative smart pointers. Best regards, Ion

1 0

Extension Classes and the BIL
by christopher diggins 02 Feb '05

02 Feb '05

I notice that member functions for many classes can be divided up into a minimal set, and derivable functions. For instance: class MyClass { void Fu() { cout << "fu"; } void Bar() { cout << "bar"; } void FuBar() { Fu(); Bar(); } } Clearly a minimal interface for representing FuBar would be: BOOST_IDL_BEGIN(IMyInterface) BOOST_IDL_FN0(Fu, void) BOOST_IDL_FN1(Bar, void) BOOST_IDL_END(IMyInterface) Using IMyInterface in our code instead of IMyInterface is more generic, and reduces coupling, but we lose the syntactic pleasantries of FuBar(). In order to achieve this effect I am currently using an extension class (or veneer if you prefer): template<typename Base_T> class MyClass_ext : public Base_T { MyClass_ext() : T() { }; template<typename T> MyClass_ext(const T& x) : T(x) { }; void FuBar() { T::Fu(); T::Bar(); } // ... assignment operators etc. } I can then write a new extended interface as follows: typedef MyClass_ext<IMyInterface> IMyInterface2; And of course I would also rewrite the original class, to avoid code redundancy: class MyClass_base { void Fu() { cout << "fu"; } void Bar() { cout << "bar"; } } typedef MyClass_ext<MyClass_base> MyClass; I don't how solid this technique is for real code. My terminology and naming convention also leaves me disatisfied. Any comments or suggestions? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

RE: [boost] More on Serialization Link Issue
by Jared McIntyre 02 Feb '05

02 Feb '05

> This is almost surely an issue of the library build settings out of sync > with the program build settings. The included VC7 IDE projects might be out > of sync with the bjam builds. here are some other things to try > > a) from with in the serialization/test directory, invoke the batch file with > the argument vc-7_1 . This should build all the libraries, demos and tests > for the serialization libary with a consistent set of settings. > b) If the above works, move the libraries from where they are build > boostdir/bin/... etc to you favorite local spot and alter thid IDE projects > to point to them. > c) Note that I have found that the IDE projects with the VC 7.1 IDE often > report a non-sensical error when I try to bring them up. This can be fixed > by going to the build menu item and selecting configuration setup and > explictly selectinga configureuation. The problem then goes away for a > while. Its an VC IDE thing. I built out everything in test as suggested (there were a few that failed, but don't appear to be related). I then took the library built in libs\serialization\build\libboost_serialization.lib\vc-7_1\debug\threading-multi and moved it to my build location. I ended up getting the same failure. To make sure that my build was picking up the library at link, I added it as a resource to the project, and it continued to have the failure (so I'm sure my project is linking to the library). Is there any more information I could give you about my setup that might help? Jared

2 1

Re: [boost] Status of BOOST_ASSERT?
by JOAQUIN LOPEZ MU?Z 01 Feb '05

01 Feb '05

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Martes, Febrero 1, 2005 11:36 pm Asunto: [boost] Status of BOOST_ASSERT? > BOOST_ASSERT is documented at > http://www.boost.org/libs/utility/assert.html, but it isn't > mentioned or > linked to in the library index, programmers guidelines, or utility > index. > If Boost libraries are really supposed to use BOOST_ASSERT, seems > like we > need to better integrate it into our docs by mentioning it and > linking to > its docs on the above pages. The utility section is kinda messed up. Some utilities like enable_if are included by boost/utility.hpp yet they're documented separately. Others, like result_of, are *not* included by boost/utility.hpp, though the docs seem to imply it is. in_place_factory has its own docs, but it lives in boost/utility. compare_pointees seem to be in a limbo, and so does aligned_storage... As for BOOST_ASSERT, I guess there is no objection against using it (at least, I hope there isn't --I'm using it :) It is just that somehow the docs got unlinked. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > I looked at the archives a bit, but didn't see any definitive > answer as to > whether or not we had decided to use BOOST_ASSERT rather than > plain assert. > > Comments? > > --Beman > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Threads in xcode
by Benjohn 01 Feb '05

01 Feb '05

We're building a multithreaded OS X application with xcode, that uses cocoa, objective c++, and makes a lot of use of shared_ptr and other parts of Boost. We're currently using boost 1_32_0 (I've just upgraded from boost-1.30.2). We're getting some crashes, and I've started to suspect that <boost/shared_ptr.hpp> isn't being compiled with multithread awareness. Acting on this hunch, if <boost/requires_threads.hpp> is included, it generates the compilation error: "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" ...which seems to suggest that shared_ptrs (if they use the same config info) wouldn't be compiling in thread support. Are application also makes use of the pthread API, and cocoa's threads class, and these both seem to be working as expected. We've had a look at xcode's options, but have found no way to explicitly turn on thread support. Specifically, adding -pthread or -pthreads causes the compiler to issue an error. We have also looked for a configure script in the boost distribution, but can find nothing (except for the one in libs/config/ which doesn't seem to work, but I personally think we're using it wrong). If someone could suggest what we may be missing, I'd be terribly grateful. Thanks very much, and thanks for a great library! Cheers, Benjohn

1 0

[type_traits][documentation]no <A name="example"></A>
by Larry Evans 01 Feb '05

01 Feb '05

http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/type_traits/index.ht… Contains: <H2>Example code</H2> But it should have: <H2><A name="example"></A>Example code</H2> in order for TOC at top to work.

3 2

Re: Boost Digest, Vol 990, Issue 1
by Jared McIntyre 01 Feb '05

01 Feb '05

> Normally this shouldn't be a problem. So > > a) what os are you using? > b) what compiler are you using? > c) have you been able to build the libraries using bjam? > d) have you been able to build any of the demos? > e) what methods of building have you tried? Bjam, IDE, command line, or ? > > Robert Ramey Windows 2000 & XP Visual Studio 7.1 I did an inital build of everything using bjam, and that worked fine, however, bjam appears to build the libraries linking to the static multithreaded C runtime, I had to rebuild them from the VC7 project included with a change to link to the multithreaded dll of the runtime (or I run into a lot of duplicate function definitions at link). Otherwise, it built fine on bjam. Is there a way to build with bjam so that it uses the dll version of the multithreaded runtime? I'm now doing some tests with building everything from the delivered VC7 project, demos and all, and the demos are failing mostly with msvcrt linking issues. I haven't tried that before. Jared

2 1

[Boost-bugs] [ boost-Support Requests-1114084 ] program_options bug?
by SourceForge.net 01 Feb '05

01 Feb '05

Support Requests item #1114084, was opened at 2005-02-01 08:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1114084&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: program_options bug? Initial Comment: I use Borland C++ 6 under Windows and I am trying to use program_options library. It seems that if I add a nonhandled parameter to command line the program hangs. For example using first.cpp and adding --unhandled to command line. in parsers.hpp: template<class charT> basic_parsed_options<charT> basic_command_line_parser<charT>::run() const { // Presense of parsed_options -> wparsed_options conversion // does the trick. ==== HERE! ===> return basic_parsed_options<charT>( common_command_line_parser::run()); } thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1114084&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 2

Problem with Intel 8.1 Linux regression tests
by Joaquín Mª López Muñoz 01 Feb '05

01 Feb '05

Seems like some stdlib headers are missing: http://tinyurl.com/4pkjh The same error happens accross multiple tests of different libraries. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[iostreams] [regression] iostreams added to CVS
by Jonathan Turkanis 01 Feb '05

01 Feb '05

Dear all, The iostreams library has been added to CVS. I've also added a line to boost-root/status/Jamfile. Is this enough to have the library included in the regression tests, or is something more required? Jonathan

4 8

lexical_cast: Needing to work for MSVC 6 (and similar)?
by Terje Slettebø 01 Feb '05

01 Feb '05

Hi. When testing it, I've found that the CVS version of lexical_cast apparently doesn't work for MSVC 6 (at least with my setup). I get the following errors when running the unit test: boost/lexical_cast.hpp(178) : error C2059: syntax error : '<' boost/lexical_cast.hpp(180) : see reference to class template instantiation 'boost::detail::lexical_stream<Target,Source>' being compiled boost/lexical_cast.hpp(178) : error C2238: unexpected token(s) preceding ';' boost/lexical_cast.hpp(180) : see reference to class template instantiation 'boost::detail::lexical_stream<Target,Source>' being compiled boost/test/utils/basic_cstring/bcs_char_traits.hpp(120) : error C2143: syntax error : missing ',' before '<' boost/test/utils/basic_cstring/bcs_char_traits.hpp(120) : error C2059: syntax error : '<' boost/test/utils/basic_cstring/bcs_char_traits.hpp(120) : fatal error C1903: unable to recover from previous error(s); stopping compilation I also see that the current regression test doesn't include MSVC 6 (http://www.meta-comm.com/engineering/boost-regression/developer/conversion. html). Because of this, Kevlin Henney and I was wondering whether or not MSVC 6 support for this component (and components in Boost in general) is no longer demanded, or in general, what the required conformance level is? If MSVC 6 support is still needed, I guess the above problems should be fixed. It seems to crash out in Boost.Test, as well. I see there are a few other failures in the regression test for more conformant compilers, though, and I'll look into these. Regards, Terje

3 2

Re: shared_ptr inheritance query
by Dave Handley 01 Feb '05

01 Feb '05

Peter Dimov wrote: > Can you separate the interface and implementation parts of the policy into > two classes, then inherit publicly from policy_interface and privately > from > policy_implementation? Unfortunately not, the policy has to be able to generate shared pointers from itself - hence it needs access to shared_from_this. If I used a multiple inheritance solution, I would be forced to dynamic_cast across to the enable_shared_from_this class, which I don't want to do. Dave Handley

2 1

g++ 4.0 and typeof/operator overloading based metaprogramming
by Daniel James 01 Feb '05

01 Feb '05

Hello everyone, I've been trying out a pre-release of g++ 4.0, and its typeof now works a lot better than the older versions. This allows it to be used for metaprogramming. As an example, I've attached a compile time factorial implemented mainly using operator overloads (it's not commented at all, but should be pretty easy to understand for most people on this list). I think it would be possible to write a metaprogramming library which would have much nicer syntax (borrowing techniques from lamba & phoenix), and integrate well with mpl. I suppose that since such a library would only work on gcc for now (or do any other compilers have a good enough typeof?), it might not be appropriate for boost, but I thought this might be of interest here anyway. Daniel

2 2

Wave C++ preprocessor - Boost Review
by Tom Brinkman 01 Feb '05

01 Feb '05

I would like to start the boost wave review in the next couple of days. If you would like to volunteer to be the review manager for this very intersting library, please contact me. Tom Brinkman at reportbase(a)yahoo.com Boost Review Wizard A short description of the library follows: The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It is not a monolitic application, it's rather a modular library, which exposes mainly a context object and an iterator interface. The context object helps to configure the actual preprocessing process (as search path's, predefined macros, etc.). The exposed iterators are generated by this context object too. Iterating over the sequence defined by the two iterators will return the preprocessed tokens, which are to be built on the fly from the given input stream. The C++ preprocessor iterator itself is fed by a C++ lexer iterator, which implements an abstract interface. The C++ lexers packaged with the Wave library may be used standalone, too, and are not tied to the C++ preprocessor iterator at all. The flexible interface exposed by the library makes it usable in a variety of applications ranging from simple lexing (tokenising) a C99/C++ input stream to complex preprocessing with fine control over the details of the macro expansion process. For instance it's very simple to inject your own #pragma handling into the preprocessing, allowing to expand it in virtually unlimited ways. The Wave C++ preprocessor library is known to be compilable on VC7.1, Intel7.1 and 8.0, gcc 3.2.x and 3.3.x. Work is currently underway to make it usable with VC6.5 as well. The library contains samples, which show different ways of it's usage. A full blown preprocessing command line oriented driver application is included in the Boost tools section as well. The review candidate version of Wave is accessible here: http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip additionally it is included in the Boost-sandbox CVS. If you're interested in what's new or changed since the last releases, please refer to the enclosed documentation or the changelog file contained inside the archive. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

protection from unintended ADL
by Gennadiy Rozental 01 Feb '05

01 Feb '05

I noticed that in some places we are using extra namespace for protection from unintended ADL. Is there any rationale for: 1. Why we need that? 2. Why namely this solution is prefered? 3. In which case we need to do so? Gennadiy

2 1

iostreams stdio_filter motivating example
by christopher diggins 01 Feb '05

01 Feb '05

I may finally have a good motivating example for stdio_filter: Consider the roman_numerals.cpp example from the Boost spirit library at http://tinyurl.com/3qw4k If I make a couple of minor modifications exclusively to the main, such as remove the superflous user prompting and rename it to something legal, i.e.: int RomanNumeralParse() { string str; while (getline(cin, str)) { if (str[0] == 'q' || str[0] == 'Q') break; unsigned n = 0; roman roman_p(n); if (parse(str.c_str(), roman_p).full) { cout << n << endl; } else { cerr << "parsing failure" << endl; return 1; } } return 0; } Using my current version of my filters library (not available online yet) I can now reuse the entire program from another, such as the following: void RomanNumeralParserTest() { stringstream sIn("MCMLXXIV"), sOut; sIn > SimpleMainFilter(RomanNumeralParse) > sOut; int n; sOut >> n; TEST(n == 1974); } Many examples from the Spirit examples, can be refactored in this manner, to become reusable with relatively little effort. I suppose one of the calculators would be even more interesting. Is this a good motivating example for introducing a stdio_filter into boost::iostreams? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 2

Money/Currency uploaded to Sandbox
by Daniel Frey 31 Jan '05

31 Jan '05

Hi, just a quick note that I uploaded the money/currency-stuff to the sandbox files section. I also moved some stuff from the Yahoo-Files and I added two techniques in case someone is interested. The overload_literal_zero-technique is used in the money class, too. You can find the files here: <http://tinyurl.com/6prl6> = <http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di…> The money/currency-framework is seriously cut down. I lacks support for nan/infinity, swap(), etc. - it's just meant as a starter for more discussion, it's main point is to illustrate what I think should be allowed and what shouldn't wrt operators. Example: money / money -> decimal, exception on currency mismatch money / decimal -> money decimal / money -> compile time error Hope someone can make any use of it :o) Regards, Daniel

1 0

More on Serialization Link Issue
by Jared McIntyre 31 Jan '05

31 Jan '05

I'm still trying to track down the serialization link issue I'm having. I've tried using different archivers (text, etc), and the save and load for each _impl isn't in the libboost_serialization.lib. Is there something I need to be doing to force these to be built in my own code (since they are publicly defined in the boost includes), or should the impls be in the library? Jared

2 1

New Logging Library
by John Eddy 31 Jan '05

31 Jan '05

In response to a number of great suggestions and interesting examples, I have made some more changes to the logging library that I would like to make Boost-worthy. I still have some changes to make and am mulling over the way I would like to go about making them. At last posting, I had made a policy of the logging levels and they can now be user specified with my levels being the default (Thanks to Jason Hise for the suggestion). Since then, I have separated the management of a log from the log itself. the log itself is a very simple thing and implements whatever means of storage, display, etc. that it wishes (inspired by the suggestions and mantra example of Preston Elder). A couple examples I have created so far are a simple_log which keeps a list of entries for retrieval (by predicate for example), an ostream_log which immediately writes entries to a supplied ostream, a file_log which immediately writes entries into a file with a specified name. I have created these as examples but I don't see any reason why implementations for just about anything could not be created. I have implemented a callback system for log entries. A boost::function can be mapped to a logging level as a callback in case of an entry at the specified level. For example, this allows a user to catch what they consider to be a "fatal" error and act on it. (Thanks again to Preston Elder for the suggestion). I have implemented a means of converting from levels to string representations of those levels. This must also be carried out by the same policy class that defines the levels. It requires the implementation of a single, simple method in the class accepting a level and an ostream and writing the appropriate text into the ostream. I have implemented a means of customizing the format by which entries are written (Thanks to Preston Elder and Caleb Epstein for the suggestion). Again, it requires a policy class. This class must have a method that accepts an entry and writes it to a supplied stream. Of course, there is a null version for use in the case where you want to have specific logs do all the writing themselves. If you want to have custom formats for the entries, the only possibilities at this point are to log them all anonymously with a completely formatted message and use the text only entry writer or to implement some sort of logic in your logger/writer to distinquish the entries and format them accordingly. I am considering an ostream style message writing functionality as well. Something I plan to do but have not yet done is change from a char specific implementation (Thanks to Preston Elder for the suggestion) to one that's non-char specific. The code in it's current state is available for simple download from www.eng.buffalo.edu/~johneddy. It is not well Boost-ified yet but the directory structure is in place and some example files are available. Everything is implemented in header files at this point so no library need be built. There was a question of thread safety. The library is threadsafe if BOOST_LOGGING_THREADSAFE is defined. It currently depends on date_time and if thread safe, the thread library. Thanks for all your help, John

1 0

Re: shared_ptr inheritance query
by Dave Handley 31 Jan '05

31 Jan '05

Jonathan Wakely wrote: > > http://boost.org/libs/smart_ptr/enable_shared_from_this.html says: > > Requires: > enable_shared_from_this<T> must be an accessible base class of T. I've seen this - but even if I make the inheritance protected, VC++7.1 balks at it complaining that a conversion from the type T to enable_shared_from_this is available but inaccessible. > > Obviously using public inheritance works, but you might also be able to > make it work by making shared_ptr<T> a friend of policy<T> so it can do > the conversion. You'll also need to disable the BOOST_ASSERTs in > enable_shared_from_this.hpp by defining BOOST_DISABLE_ASSERTS or by > copying enable_shared_from_this.hpp and re-implementing the class > without the assertions. I have no idea if this is supposed to work, nor > if it will still work if the internals of shared_ptr or > enable_shared_from_this change. Caveat emptor. > I've tried friendship as you recommend, between shared_ptr<T> and policy<T>, but again without success. Interestingly, I actually get the error from a construction of a standard shared_ptr, without even using shared_from_this. I've gone as far as commenting out every call to shared_from_this in my code. If I inherit from enable_shared_from_this, the compiler complains on construction of a shared_ptr in the detail::sp_enable_shared_from_this line in the code below. If I also comment out enable_shared_from_this, everything compiles okay. template<class Y> explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete { detail::sp_enable_shared_from_this(p, p, pn); } This is remarkably frustrating, since there are a large number of implementation details in my policy class that I am keen to hide from the API, and the API works fine for all my other policies, it is just the shared_ptr policy that is collapsing. Dave

2 1

custom iterator comparisons (gcc 3.4.2)
by Gennadiy Rozental 31 Jan '05

31 Jan '05

I am getting following error while compiling my test with gcc 3.4.2 on Linux: gcc-C++-action ../../../bin/boost/libs/test/test/ifstream_line_iterator_test.test/gcc-3.4.2 /debug/ifstream_line_iterator_test.o /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/bits/ios_base.h: In copy constructor `std::basic_ios<char, std::char_traits<char> >::basic_ios(const std::basic_ios<char, std::char_traits<char> >&)': /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/bits/ios_base.h:738: error: `std::ios_base::ios_base(const std::ios_base&)' is private ../../../libs/test/test/ifstream_line_iterator_test.cpp:28: error: within this context /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/streambuf: In copy constructor `std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf(const std::basic_filebuf<char, std::char_traits<char> >&)': /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/streambuf:769: error: `std::basic_streambuf<_CharT, _Traits>::basic_streambuf(const std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits = std::char_traits<char>]' is private ../../../libs/test/test/ifstream_line_iterator_test.cpp:28: error: within this context An error occured in line performing comparison: 26: ifstream_line_iterator it( "abc" ); 27: 28: BOOST_CHECK( it != ifstream_line_iterator() ); Looks like compiler end up generating copy constructor. Why did this happend? Is there workaround? Gennadiy

1 0

std::string construction/assignment
by Gennadiy Rozental 31 Jan '05

31 Jan '05

Hi, One of my unit tests is failing because following code throw an exception (gcc 3.2.3 linux): #include <list> #include <string> int main() { std::list<char> l; l.push_back( 'a' ); l.push_back( 'b' ); l.push_back( 'c' ); std::string( l.begin(), l.end() ); return 0; } Does it supposed to work? Is there workarounds? Gennadiy

2 1

shared_ptr inheritance query
by Dave Handley 31 Jan '05

31 Jan '05

I wonder if anyone could help me with a particular problem I'm having with shared_ptr. I'm working on a policy template, and I want the policy template to both privately inherit, and inject enable_shared_from_this - but the 2 things seem to be mutually exclusive. Let me give you an idea of what I'm trying to do (with some gross simplification to make the code a little simpler): template <class T> class policy : public enable_shared_from_this<T> { }; template <class T> class base : private policy<T> { public: shared_ptr<T> get_ptr() { return shared_from_this(); } }; class MyClass : public base<MyClass> { }; test() { shared_ptr<MyClass> obj( new MyClass ); shared_ptr<MyClass> obj1 = obj->get_ptr(); } If you run this you get a "conversion from MyClass* to boost::enable_shared_from_this<T> * exists, but is inaccessible" error (on VC++7.1). The same is true with protected inheritance. Is there any way around this? Thanks Dave Handley

2 1

[Boost.Test] Failure building regression tools.
by Martin Wille 31 Jan '05

31 Jan '05

Hi, I can't build the regression test helper programs anymore: In file included from /boost/head-regression/boost/boost/test/included/prg_exec_monitor.hpp:20, from ../../../tools/regression/compiler_status.cpp:749: /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:59: error: syntax error before `(' token /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:68: error: parse error before `try' /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: ISO C++ forbids declaration of `result' with no type /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: redefinition of `int result' Looks like Boost.Test is the culprit. Regards, m

1 0

Re: Fw: [boost] Re: Complex type failure with boost::lexical_cast
by Kevlin Henney 31 Jan '05

31 Jan '05

In message <000c01c506b9$fed670b0$0300000a@pc>, Terje Slettebø <tslettebo(a)broadpark.no> writes >----- Original Message ----- >From: "Preston A. Elder" <prez(a)neuromancy.net> >To: <boost(a)lists.boost.org> >Sent: Sunday, January 30, 2005 4:56 AM >Subject: [boost] Re: Complex type failure with boost::lexical_cast > >I am of the opinion we should follow the standard (ie. STL) in this one. >The STL would accept both, and since we rely on operator>>, so should we. Technically, the _STL_ doesn't do anything about spaces because it doesn't do anything with I/O ;-) However, given that I/O streams handle spaces inconsistently wrt what we think of as the representation of a type, it does not seem the best example to follow -- people prefer something that works consistently. >I mean, if you're going to be anal about spaces, be completely anal about >them, but I don't think we should be, I think accepting whitespace before >and after is correct, just as the stringstream operator>> does by default. And that is where the problems begin. The older versions of lexical_cast had problems because they behaved like the other types that work with I/O streams... but since the other types don't work consistently or sensibly with I/O streams, this causes problems. For example, if we do as the standard does, then lexical_cast will not work when reading a single whitespace character and it will pick out the first space-separated sequence from a string. It is unlikely anyone would consider this desirable. So, if you're going to deal with spaces, deal with them consistently and avoid surprises. And over time this is what lexical_cast has been converging on. This latest bug is one that will be fixed, continuing the trend towards total consumption of the input representation -- we thought we had it, but this corner case was missed and fixing it will improve coverage. Reverting to inconsistent behaviour is not an attractive option. Hope that clarifies the rationale! Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

2 1

[mpl][range_c][doc]integral_rank requirement not mentioned
by Larry Evans 31 Jan '05

31 Jan '05

Apparently, the T in: range_c<T,n,m> on page: http://www.boost.org/libs/mpl/doc/refmanual/range-c.html requires a specialization of integral_rank<T> to compile. Otherwise, I'm getting error: intel-linux.compile.c++ ../../../../bin.v2/lje/libs/indexed_types/test/range_c_enum_test.test/intel-linux/debug/range_c_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/largest_int.hpp(48): error: incomplete type is not allowed ( integral_rank<T1>::value >= integral_rank<T2>::value ) ^ However, this requirement is not mentioned on the range-c.html page. Shouldn't it be?

1 1

C++ standards committee meetings
by Beman Dawes 30 Jan '05

30 Jan '05

The schedule for C++ standards committee meetings can be found at http://www.open-std.org/jtc1/sc22/wg21/docs/meetings The next two meetings are scheduled for: April 11-15, 2005, in Lillehammer, Norway October 3-7, 2005, in Mont Tremblant, Canada Information about the Lillehammer meeting is available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1707.htm There is a FAQ for Boost members who might want to attend a committee meeting. See http://www.boost.org/more/cpp_committee_meetings.html --Beman

1 0

boost:::iterator (1_32_0) and sunpro
by Tim Van Epps 30 Jan '05

30 Jan '05

I'm trying to use boost::tokenizer with the sunpro compiler and encountering an error in the boost interator. Sunpro compiler: CC: Sun C++ 5.5 Patch 113817-10 2004/10/05 boost 1_32_0 program that demonstrates the error: #include <boost/tokenizer.hpp> using namespace boost; int main(int argc, char ** argv) { std::string ret; char_separator<char> sep("\r\n"); tokenizer<char_separator<char> > tok(ret, sep); for(tokenizer<char_separator<char> >::iterator i =tok.begin(); i != tok.end(); ++i) {} } the output from CC -I$D/src/vendor/incl -o bug bug.C: "/usr/local/dailyLibraryBuild/src/vendor/incl/boost/iterator/iterator_facade.hpp", line 837: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core_access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). 1 Error(s) detected. I've seen variations on this issue discussed on the boost mailing lists, but I'm not sure I've seen a definitive answer. Does anybody have one? -- Tim Van Epps Archelon 312.788.6328

3 2

overloads: request for discussion
by Alexander Nasonov 30 Jan '05

30 Jan '05

An overload set can be represented as a class with _numbered_ call operators: struct has_intersection { bool operator()(id<1>, Circle&, Circle& ) const; bool operator()(id<2>, Circle&, Rectangle&) const; bool operator()(id<3>, Rectangle&, Circle& ) const; bool operator()(id<4>, Rectangle&, Rectangle&) const; }; I wonder how to pass it to different kind of algorithms. Here's my brain dump of the topic: 1. Pass an overload set, MPL sequence of positions and a predicate find_if< has_intersection , range_c<int,1,5> , is_same<first_arg<_>, Circle&> > The find_if algorithm works with mpl sequence of positions, that is, it takes positions and return an iterator to first found position. Unlike mpl::find_if, the predicate takes a signature, not a position. I used it till recently. But it's not quite an OverloadSet concept. 2. MPL-like sequence would be nice to have. Something similar to: mpl::vector< bool(Circle&, Circle& ) , bool(Circle&, Rectangle&) , bool(Rectangle&, Circle& ) , bool(Rectangle&, Rectangle&) > or mpl::set< bool(Circle&, Circle& ) , bool(Circle&, Rectangle&) , bool(Rectangle&, Circle& ) , bool(Rectangle&, Rectangle&) > Unfortunately, if typeof is not available, deref and some other operations work only in deduced context (that is, inside special function). Presumably that sequence should store pairs of id and a signature in deduced context or id and unknown otherwise: pair<id<1>, bool(Circle&,Circle&) > // deduced context pair<id<1>, unknown> // non-deduced context (This reminds me of mpl::map but I'm not sure about keys and values: id -> signature or signature -> id?) Algorithms that accept boolean predicates will be using deduced context (this can be extended to predicates that return integral constants in limited range). Question about whether to implement other algorithms is open. This approach has an advantage on a long run. When typeof becomes standartized, everything can be switched to the first case. To summarize, I see it being as close to MPL sequence (I don't know to which one, though) as possible typedef overload_set<has_intersection, range_c<int,1,5> > seq; but not closer. For example, overload_set is extensible only in a limited way: you can't insert new overload but you can restore an overload removed by previous algorithm or a filter. This means, in particular, that sort should work because it only changes an order of elements. Note that sorting by id or signature is less important then sorting by return or argument type and then applying unique algorithm. At best, sorting of huge overload set can be avoided. MPL has a trick for this: mpl::copy<from, inserter<set<>, insert<_1,_2> > > Something similar can be done for overload_set. Otherwise, new algorithm should be introduced because of its high importance. It has to be very fast at compile-time to deal efficiently with huge overload sets. (This algorithm exists already under name "unique"). 3. Fusion-like interface. Overload sets are not pure compile-time entities as shown in this example: tuple< bool (has_intersection::*)(id<1>, Circle&, Circle& ) const, bool (has_intersection::*)(id<2>, Circle&, Rectangle&) const, bool (has_intersection::*)(id<3>, Rectangle&, Circle& ) const, bool (has_intersection::*)(id<4>, Rectangle&, Rectangle&) const > t( &has_intersection::operator(), &has_intersection::operator(), &has_intersection::operator(), &has_intersection::operator() ); Something like that would be great addition for overloads library. The library is available at cpp-experiment.sf.net (please, use CVS). -- Alexander Nasonov

2 12

Iterator lib tests broken
by John Maddock 30 Jan '05

30 Jan '05

Guys, The Jamfile for the iterator tests is currently rather badly broken: don't know how to make <@boost!libs!iterator!test>../../utility/iterator_traits_test.cpp don't know how to make <@boost!libs!iterator!test>../../utility/transform_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/reverse_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/projection_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/indirect_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/fun_out_iter_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/filter_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/counting_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/iterator_adaptor_examples.cpp and so on. Any chance of a fix? Thanks! John.

3 4

Type traits change alert
by John Maddock 30 Jan '05

30 Jan '05

Hi folks, Its that time of year again when type traits gets a bit of maintenance, and as some of you will know, almost any change is guaranteed to break something, so here are the changes just in case: 1) The existing traits classes have been modified to inherit from boost::integral_constant, as per TR1. I've done everything I can to retain MPL compatibility, and tested every way I can think of, but you never know something may go wrong somewhere... I've also had to defer this change for VC6 in one case (couldn't get variant to compile unless alignment_of inherited from mpl::size_t; even using mpl::integral_c as a base just made VC6 ICE all the time). 2) The addition of true_type/false_type meant a minor change to boost/pending/ct_if.hpp. 3) New traits classes added: aligned_storage, extent, has_virtual_destructor, is_member_object_pointer, is_signed, is_unsigned, rank, remove_all_extents, all as per the TR. There is just about an outside chance that old and broken compilers will be unable to parse one of these when including boost/type_traits.hpp, but it's pretty unlikely. 4) Renamed: remove_bounds -> remove_extent is_base_and_derived -> is_base_of is_float -> is_floating_point To bring those names into line with the TR, the old names all remain as well for backwards compatibility. 5) Docs: these really need rewriting (Boostbook?), will do when I get a chance. Regards, John Maddock.

1 0

[range] patch to fix begin() and end()
by Eric Niebler 30 Jan '05

30 Jan '05

The following trivial use of Boost.Range fails to compile: #include <boost/range/begin.hpp> template<class Rng> void foo(Rng const& rng) { boost::begin(rng); } int main() { char* sz = "hello"; foo( sz ); } With g++, I get: $ g++ -I$BOOST_ROOT test.cpp /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp: In function `typename boost::range_const_iterator<C>::type boost::range_detail::begin(const C&) [with C = char*]': /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp:162: instantiated from `typename boost ::range_const_iterator<C>::type boost::begin(const T&) [with T = char*]' test.cpp:6: instantiated from `void foo(const Rng&) [with Rng = char*]' test.cpp:12: instantiated from here /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp:40: error: request for member `begin' in `c', which is of non-aggregate type `char* const' The attached patch fixes the problem for both boost::begin() and boost::end(). I have verified that the range tests pass with this change. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: begin.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/begin.hpp,v retrieving revision 1.11 diff -b -d -u -r1.11 begin.hpp --- begin.hpp 5 Jan 2005 18:19:30 -0000 1.11 +++ begin.hpp 29 Jan 2005 00:07:13 -0000 @@ -111,20 +111,40 @@ return s; } + inline const char* begin( const char*const& s ) + { + return s; + } + inline char* begin( char*& s ) { return s; } + inline char* begin( char*const& s ) + { + return s; + } + inline const wchar_t* begin( const wchar_t*& s ) { return s; } + inline const wchar_t* begin( const wchar_t*const& s ) + { + return s; + } + inline wchar_t* begin( wchar_t*& s ) { return s; } + + inline wchar_t* begin( wchar_t*const& s ) + { + return s; + } #endif } // namespace 'range_detail' Index: end.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/end.hpp,v retrieving revision 1.14 diff -b -d -u -r1.14 end.hpp --- end.hpp 5 Jan 2005 18:19:31 -0000 1.14 +++ end.hpp 29 Jan 2005 00:07:13 -0000 @@ -111,20 +111,40 @@ return range_detail::str_end( s ); } + inline char* end( char*const& s ) + { + return range_detail::str_end( s ); + } + inline wchar_t* end( wchar_t*& s ) { return range_detail::str_end( s ); } + inline wchar_t* end( wchar_t*const& s ) + { + return range_detail::str_end( s ); + } + inline const char* end( const char*& s ) { return range_detail::str_end( s ); } + inline const char* end( const char*const& s ) + { + return range_detail::str_end( s ); + } + inline const wchar_t* end( const wchar_t*& s ) { return range_detail::str_end( s ); } + + inline const wchar_t* end( const wchar_t*const& s ) + { + return range_detail::str_end( s ); + } #endif } // namespace 'range_detail'

2 3

Re: [boost] Help needed with BGL & multi_index_container
by JOAQUIN LOPEZ MU?Z 30 Jan '05

30 Jan '05

Hi Alexander, ----- Mensaje original ----- De: Me here <rhjrjlbk2002(a)yahoo.com> Fecha: Viernes, Enero 28, 2005 5:21 pm Asunto: [boost] Help needed with BGL & multi_index_container > Hi there, > > I need an advanced container which allows me to access > my data over number of different indices. That is > exactly what for boost::multi_index_container was > made. But, my data items also have relationships with > other data in the same container, which could be > represented as directed graph. > > So, I have made a custom container, which aggregates > multi_index_container (MIC) to store data items and a > graph (BGL) to store relationships. To allow switching > from MIC to walk over relationships, as an additional > field of my item in MIC I store BGL vertex; as vertex > property in graph I store the key of unique index in > MIC. So, MIC and BGL refer to each other. But, it is > difficult to have those two containers in sync. > > So, I made another attempt to have MIC as customized > vertex storage. I succeed two write the code for it > (see it below). It also compiles and links :-). > Unfortunately, I can not add neither vertices not > edges. If I try to add vertex as in commeted code > below, an error errors that there is no convertion > from vertex property to vertex descriptor (error > message is below). > > What's wrong? Well, I'm no BGL expert, so take this with a grain of salt, but I think adjacency_list does not work the way you're assuming: it is adjacency_list that internally defines its vertex_descriptor type, and uses the container supplied to store them: so, you just cannot select what vertices actually are (like it seems you're trying with ItemHolder.) In fact, the primary API for adding vertices is add_vertex(g); which does not specify the vertex being added (it is created internally by adjacency_list). The syntax add_vertex(p,g); is shorthand for adding a vertex and attaching it a property. I'd say that, in order to blend BGL with multi_index_container, you have three options: 1. Maintain the two structures in sync, like you've done in your first approach. 2. Use multi_index_container as a property map attached to a graph. I don't know if this would work, since I'm not a BGL conoisseur. 3. Create your own data structure modeling mutable graph which internally uses multi_index_container. Besides the multi-index container, you'll need another one for storing edges, if you are to follow the way adjacency_list works. Good luck with your project, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > My another question is: how can I get access to my > MIC stored in graph? I would like to use its indices. > > Best wishes, > Alexander > > --------- sample code ----------- > #include <iostream> > > #include <boost/multi_index_container.hpp> > #include <boost/multi_index/ordered_index.hpp> > > #include <boost/graph/adjacency_list.hpp> > > using namespace boost; > using namespace boost::multi_index; > > using namespace std; > > > struct MICSelector {}; > > struct Item > { > Item(int _a=0, int _b=0, int _c=0) > : a(_a), b(_b), c(_c) {} > > int a,b,c; > }; > > struct ItemHolder > { > ItemHolder(int id=0, const Item item=Item()) > : m_ID(id), m_item(item) {} > > int m_ID; > Item m_item; > }; > > struct ItemHolderKey > { > typedef int result_type; > int operator()(const ItemHolder& v) const > { return v.m_ID; } > }; > > template<class ValueType> > struct MICWrapper > { > typedef multi_index_container > < > ValueType, > indexed_by > < > ordered_unique< ItemHolderKey > > > > > type; > }; > > namespace boost > { > // the specialization for your selector > template<class ValueType> > struct container_gen<MICSelector, ValueType> > { > typedef typename MICWrapper<ValueType>::type type; > }; > > template <> > struct parallel_edge_traits<MICSelector> { > typedef allow_parallel_edge_tag type; > }; > }; > > typedef adjacency_list > < listS, MICSelector, > bidirectionalS, ItemHolder > > MG; > > int tmain(int argc, char* argv[]) > { > > MG mg; > > /* > ItemHolder IH( 1, Item(1) ); > > add_vertex( &IH, mg ); > > // add_edge( > // ItemHolder( 1, Item(1) ), > // ItemHolder( 2, Item(2) ), > // mg ); > */ > > cout << typeid( > boost::graph_traits<MG>::vertex_descriptor ).name(); > > return 0; > } > --------- sample code ----------- > > ----------- error message ------------- > Compiling... > MIC_BGL.cpp > c:\test\MIC_BGL.cpp(87) : error C2664: > 'boost::add_vertex' : cannot convert parameter 1 from > 'ItemHolder *__w64 ' to 'const > boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,Ver texProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_proper ty_type > &' > with > [ > > Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectiona lS,ItemHolder>, > VertexListS=MICSelector, > OutEdgeListS=boost::listS, > DirectedS=boost::bidirectionalS, > > VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t ,ItemHolder>::type, > > EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boo st::no_property>::type, > GraphProperty=boost::no_property, > EdgeListS=boost::listS > ] > Reason: cannot convert from 'ItemHolder *__w64 ' to > 'const > boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,Ver texProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_proper ty_type' > with > [ > > Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectiona lS,ItemHolder>, > VertexListS=MICSelector, > OutEdgeListS=boost::listS, > DirectedS=boost::bidirectionalS, > > VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t ,ItemHolder>::type, > > EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boo st::no_property>::type, > GraphProperty=boost::no_property, > EdgeListS=boost::listS > ] > No constructor could take the source type, or > constructor overload resolution was ambiguous > ----------- error message ------------- > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced search. > http://info.mail.yahoo.com/mail_250 > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Platform independent types available in boost?
by Roland Schwarz 30 Jan '05

30 Jan '05

Sorry for my possibly ignorant question, but I couldn't find any pertinent information so far. Is there a recommended way of how to proceed when an application needs to store data in platform independent manner? Is there support in boost? Is anything planned? Thank you for any hints. Roland

4 5

boost.filesystem - rationale for copy_file
by larsbj＠gullik.net 30 Jan '05

30 Jan '05

What is the rationale for having copy_file fail if the target file exists? This is not how any cp/copy in any shell I know of works, actually quite surprising. And with boost.filesystem there is no way to avoid this, short of rewriting the function to allow it. The other way around would have been easy: fs::exists(target) || fs::copy_file(source, target) (One option is to delete the target before doing the copy, but then it is impossible to keep the same inode as before, and f.x. for backup files this is something that you want.) -- Lgb

8 17

Re: [boost] [iostreams] [regression] iostreams added to CVS
by JOAQUIN LOPEZ MU?Z 30 Jan '05

30 Jan '05

Hi, I think the note on the first page of the docs is no longer needed: Boost.Iostreams is now part of Boost. Also, don't forget to add an entry in libs/libraries.htm and in /index.htm (under the "Version 1.33.0" paragraph). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Domingo, Enero 30, 2005 0:29 am Asunto: [boost] [iostreams] [regression] iostreams added to CVS > Dear all, > > The iostreams library has been added to CVS. > > I've also added a line to boost-root/status/Jamfile. Is this > enough to have the > library included in the regression tests, or is something more > required? > Jonathan > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Composites and Visitors
by Dave Handley 30 Jan '05

30 Jan '05

Since my last post concerning my implementation of a composite and visitor framework, I have been working on a memory management policy for the composite. The new version of the code is available in the sandbox. I would like to highlight the key changes, along with a few comments from a very useful offline discussion I had with Pavel Vozenilek: 1) A few bugs have been fixed - specifically to do with memory management. I haven't written a full test suite yet (but intend to do so in the near future) so I can't guarantee any degree of robustness in the code as yet. 2) I have put in 3 memory management policies. These enable you to ignore memory management, allow the composite to be responsible for its own memory with conventional pointers, or allow the composite to be responsible for its own memory with boost smart pointers. As yet I have been unable to sort out deep copying of the tree with the smart pointer policy. One option on this may be to implement shallow copies of the tree in the copy constuctor and equals operator, and implement a separate deep_copy function. What are the general views on this? Are there any tricks with boost shared_ptrs that enable you to do deep copies of trees from the constructor? 3) I am intending to put in a policy that will allow you to select the type of container used for internal storage. Thanks to Pavel for this suggestion. 4) I know that this is not strictly a composite in the traditional GoF sense. I actually created this particular version of a composite due to the fact that it is easier to write deep iterators when every node in a composite tree knows that it is part of the tree (unlike the GoF model where only the group nodes actually know about the tree structure). My design goals for this code were: a) Create a tree where individual nodes know about their location in the tree. b) Provide various iterators for this tree. c) Provide tight integration with the visitor pattern. These design goals were specifically designed to try and reduce virtual function bloat that, in my experience, is common with composites. In discussion with Pavel, I have come up with a design that also succeeds in meeting these criteria but ensures that leaf nodes do not carry around an empty list. I am working on this at present, but it is worthy of note that the API will be slightly more complex. The files in the sandbox are now: composite_visitor.zip - contains only the composite and visitor headers and a quick instruction document. composite_visitor_tests_win32.zip - contains the win32 test program. I haven't included the vcproj or sln files, but they should be trivial to create. Dave Handley

1 0

shared_ptr doubts
by Don G 29 Jan '05

29 Jan '05

Not to be contentious, but IMHO it seems that shared_ptr's reach has exceeded its grasp. After looking thoroughly into shared_ptr, I have major doubts about what appear to be design-induced inefficiencies: 1. There is no support for "introducing" shared_ptr to a type T such that shared_ptr would use an intrusively managed count. This is just about required in my book for practicle use of reference counting in large applications. I see intrusive_ptr<>, but this would not help template code that wanted to share ownership of some type T; should it use shared_ptr<T> or intrusive_ptr<T>? Only type T knows. 2. The idea of weak_ptr seems to force external reference counting and a mutex (of some sort) to guard the counter(s). If there is a safe way to use lock-free counting and still get the assurances of weak_ptr::lock, I'm not clever enough to see it. Also, I can see no hope of tuning shared_ptr<T> for intrusive counting and keep weak_ptr. To me, this feature is worth no more than sizeof(ref_count) per object and no hidden locks, at least on platforms that support atomic integer operations. weak_ptr<T> would not be available if shared_ptr<T> was based on intrusion, again unless someone more clever than I could find a way to do so that wouldn't burden code that doesn't use weak_ptr. 3. The deleter feature also adds virtual function bloat as well as more per-object overhead. To me, this kind of overhead would preclude use of shared_ptr in all by the most trivial applications. The problem again is that this is not something that can be avoided by shunning the use of some features. For example, if the deleter where part of a shared_ptr<void> specialization or something. While I like the aesthetics of these features, I can see little practicle need for them given their cost. In other words, I would trade both of them for the knoweldge that I could "use the shared_ptr, Luke" without concern for such bloat. Herb Sutter advocated this position in a recent C++ User Journal article, which is what sparked my curiousity in the first place. Again, perhaps I've missed something profound and fundamental in the specification of shared_ptr that would allow for these features and a highly effecient implementation of basic reference counting. As I see it, I will have to keep my own counted_ptr which does "just the counting, ma'am." My $2e-02, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

mpl::set problem
by Alexander Nasonov 29 Jan '05

29 Jan '05

I can't understand why derefencing begin of set<int,char> gives set2<int,char>, not char or int as one would expect. typedef set<int,char> s; typedef deref<begin<s>::type>::type e; BOOST_MPL_ASSERT(( or_<is_same<e,int>, is_same<e,char> > )); If I change s definition to typedef insert<set<int>,char>::type s; it compiles fine on gcc 3.4 and intel-linux 8.0. -- Alexander Nasonov

1 0

StringAlgo::split issue
by Dirk Gregorius 29 Jan '05

29 Jan '05

Hi, I used the split function on the following string: vector<string> tokens; string str= "( 448 448 64 ) ( 448 0 64 ) ( 0 448 64 ) name 0 0 0 0.5 0.5 0 0 0"; split( tokens, str, is_any_of( ()), token_compress_on ); // I pass 'space' , '(' and ')' into is_any_of() I was supposed to get 18 tokens. The first nine values, the string "name" and the remaining eight digits. "split" always returns a string vector containing 19 tokens, where the first element of the vector is an empty string. Why does the function insert empty strings into the collection? Can I use split to obtain the 18 wanted tokens? -Dirk

3 4

Boost Test - when you've got nothing else to do
by Robert Ramey 29 Jan '05

29 Jan '05

I find Boost Test very valuable and use on a regular basis. I think that it would be even more useful if it had the following additional features: a) automatic heap checking for memory leaks for libraries that can support it. b) the ability to create a temporary fstream with a unique name in a safe way. c) The ability to specify an execution time limit so that if the program goes off into space it doesn't waste an in ordinate amount of time. (perhaps this would be easier to include in bjam) d) The abtility to specify a maximum amount of memory to be allocated. When this allocation is passed, the program would terminate. e) Currently, all tests compiled with borland compilers fail immediatly when the program and library are built in release mode. I would like to see this fixed. I did spend a little time trying to track this down but was unsuccessful. f) A more tutorial type manual. Robert Ramey

4 7

[test] CHECK_EQUAL_COLLECTION
by Jody Hagins 29 Jan '05

29 Jan '05

I have a collection of boost:shared_ptr<>, and I want to test what they point to. CHECK_EQUAL_COLLECTION does not take a predicate, so what method do you suggest? Currently, I create "copies" of the collections with "holders" that invoke the comparison on the "pointed-to-object" but this seems a bit klunky. What is the preferred method for this type of collection?

2 1

non-member reset()
by Stefan Slapeta 28 Jan '05

28 Jan '05

Hi all, do we have a non-member reset() somewhere? Something like template <typename T> void reset(T& t) { std::swap(t, T()); } (of course to be refined...) Stefan

6 14

Meta-math
by Jason Hise 28 Jan '05

28 Jan '05

I was just playing around, trying to compute a square root at compile time. I came up with the following: template < unsigned int N, unsigned int X = 1, unsigned int X2 = ( X + N / X ) / 2 > struct Sqrt { typedef typename Sqrt < N, X2 > :: ValueHolder ValueHolder; }; template < unsigned int N, unsigned int X > struct Sqrt < N, X, X > { struct ValueHolder { enum ValueStorage { Value = X }; }; }; This works for most values, but unfortunately some ( like 80 ) end up oscillating and X never becomes equal to X2. How could I go about correcting this? -Jason

4 9

Re: [Osl-sysadmin] Re: devel ML archive stuck again
by David Abrahams 28 Jan '05

28 Jan '05

Jeff Squyres <jsquyres(a)osl.iu.edu> writes: > Dave -- > > As I have indicated before, I am not the OSL sysadmin. Please stop > telling people that I am. Sorry, I must have missed that announcement. > The OSL sysadmin is now DongInn Kim (not Larry). The > osl-sysadmin(a)osl.iu.edu address will continue to be your primary > contact address. Okay, everyone, please take note. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Multiton
by Dave Handley 28 Jan '05

28 Jan '05

Jason Hise wrote: > > I agree entirely... which is why I plan to make multiton a sibling class > instead of making the singleton support it with additional policies. It > will live in the same namespace and possibly be able to utilize some of > the same policies that the singleton does (for instance any allocator > that doesn't restrict creation to one instance) Excellent... > Almost. The key passed in to GetInst would be templated, and Child > would be the multiton itself. However, upon further meditation I wonder > if having Child a separate type would be preferable. I guess the > question at hand is how important it is to enforce that there can only > be instances that correspond to a key. With your model, anyone could > easily instantiate a Child. > What I was essentially thinking about was a class that IS actually a singleton, then a class which you inherit off to generate the "multiton" using CRTP in a similar way to the singleton. Essentially your classes would be something like (with slightly better names than my last attempt of Child and multiton): template <class M> class multiton_factory_impl : public singleton<multiton_factory_impl<M> > {}; and class my_multiton : public multiton<my_multiton> {}; template <class M> class multiton { typedef typename multiton_factory_impl<M> multiton_factory public: static M* GetInst( int number ) { return multiton_factory::GetInst()->GetInst( number ); } // All the usual private constructors to force creation through here // along with appropriate friending to support it }; This is slightly better than my last suggestions because the GetInst function is actually in the real multiton, rather than in the singleton. Anyway, I look forward to seeing your implementation. Dave Handley

2 3

Re: Problem Linking to Serialization Libs
by Jared McIntyre 28 Jan '05

28 Jan '05

> Are you including libboost-serialzation.lib (or ?) in your project? > > Robert Ramey Yes, specifically the version I built with multithreaded debug dll (otherwise there are a number of duplicate definition errors). I was trying to use the wide version of the xml archive earlier and was therefore linking to both libboost_serialization.lib and libboost_wserialization.lib, but was running into several more linking failures, so I went to the standard version in hopes of reducing some of the complexity. I forgot to mention in the previous email that these are the static library builds. Jared

1 0

Problem Linking to Serialization Libs
by Jared McIntyre 28 Jan '05

28 Jan '05

I'm having difficult linking to the serailization libraries. Here is the basic setup: Visual Studio 7.1 Boost 1.32 Aerialization libraries built using runtime library : Multithreaded Debug DLL using xml_oarchive & xml_iarchive I'm getting the following linking errors: BusBuild.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::archive::xml_oarchive_impl<class boost::archive::xml_oarchive>::save(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &)" (?save@?$xml_oarchive_impl@Vxml_oarchive@archive@boost@@@archive@boost@@QAEXABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) referenced in function "public: static void __cdecl boost::archive::save_access::save_primitive<class boost::archive::xml_oarchive,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > >(class boost::archive::xml_oarchive &,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &)" (??$save_primitive@Vxml_oarchive@archive@boost@@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@save_access@archive@boost@@SAXAAVxml_oarchive@12@ABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) BusBuild.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::archive::xml_iarchive_impl<class boost::archive::xml_iarchive>::load(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > &)" (?load@?$xml_iarchive_impl@Vxml_iarchive@archive@boost@@@archive@boost@@QAEXAAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) referenced in function "public: static void __cdecl boost::archive::load_access::load_primitive<class boost::archive::xml_iarchive,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > >(class boost::archive::xml_iarchive &,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > &)" (??$load_primitive@Vxml_iarchive@archive@boost@@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@load_access@archive@boost@@SAXAAVxml_iarchive@12@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) Any ideas of how to get around this?

2 1

devel ML archive stuck again
by Gennadiy Rozental 28 Jan '05

28 Jan '05

Is there direct mal I could use to notify when it happends? Gennadiy

2 1

serialization lib minor suggestion (to Robert Ramey)
by Sergey Skorniakov 28 Jan '05

28 Jan '05

Hello, Robert! I've got a couple of linker error with std::wostream & operator<<(std::wostream &os, const char t) and std::wostream & operator<<(std::wostream &os, const char *t) when defining custom archives and explicitly instantiating them in separate library. Can you declare these operators as inline - its would be more convenient for anyone performing same task? With best regards, Sergey.

2 3

boost::mem_fn
by John Maddock 28 Jan '05

28 Jan '05

Am I right in thinking that boost::mem_fn: 1) Does not inherit from std::unary_function or std::binary_function when it should (as per the TR)? 2) Does not support volatile qualified member functions? Many thanks, John.

4 3

Interfaces Library (structural subtyping)
by christopher diggins 28 Jan '05

28 Jan '05

Several people have told me the technique which I referred to as "retroactive polymorphism" is more correctly labelled "structual subtyping". Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

boost/bind.hpp patch (was Re: Compiling boost on tru64 (Richard Hadsell))
by Kevin Wheatley 28 Jan '05

28 Jan '05

Peter Dimov wrote: > Mark Helzer wrote: > > Kewl, that works, I got a little further down the path. Next problem: > > > > cxx: Error: /adp/local/src/boost_1_32_0/boost/bind.hpp, line 206: #266 > > "value" is ambiguous > > Can you please try adding _bi:: in front of value and see if this fixes the > problem? The following patch (against 1.32) certainly allows the MIPS Pro compiler to compile that file without the two ambiguity errors. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself | --- /tmp/bind.hpp.orig Fri Jan 28 10:56:34 2005 +++ /data/RnD/3rdPartyLibraries/www.boost.org/boost_1_32_0/boost/bind.hpp Fri Jan 28 10:55:52 2005 @@ -203,9 +203,9 @@ A1 operator[] (boost::arg<1> (*) ()) const { return a1_; } - template<class T> T & operator[] (value<T> & v) const { return v.get(); } + template<class T> T & operator[] (_bi::value<T> & v) const { return v.get(); } - template<class T> T const & operator[] (value<T> const & v) const { return v.get(); } + template<class T> T const & operator[] (_bi::value<T> const & v) const { return v.get(); } template<class T> T & operator[] (reference_wrapper<T> const & v) const { return v.get(); }

1 0

[any] ostream inserter
by Sérgio Pace 28 Jan '05

28 Jan '05

Hi, I was playing with the any.hpp library trying to add a generic inserter to an ostrem. To acomplish that I created a pure virtual method print in the placeholder: class placeholder { ... virtual void print(std::ostream& out) const = 0; ... } implemented it in the template holder template<typename ValueType> class holder : public placeholder { ... virtual void print(std::ostream& out) const { out<<held; } ... }; and last but not least I implemented the inserter i the any class: class any { ... friend std::ostream& operator<<(std::ostream& out, const any& data) { data.content->print(out); return(out); }; ... }; this was my first attempt and I expected it to work fine, but to limit the use of any to classes that implement inserters, but I had a nice surprise to find out that as long I don´t actually invoke the inserter on non inserter implementing contained objects everything work fine, at least in bcc 5.5 and gcc(mingw) 3.4.2. when I do use the inserert operator for a nom implementing contained object I get a stack overflow exception, it seens like the inserter operator call the print method and print invoke the any inserter instead of the contained object inserter. Beeing able to strem out a unknow object is a huge plus in my current project and I thing it will be a great addition to the library, but I´m wondering how portable (standard compliant?) is my solution and why this recursive call happens with non inserter objects. Sorry if my explanation was not very clear or bad english, this is my first post in this mailing list and english is not my native language. just mail any need for clarifications. Sérgio

5 8

Is this a legal approach to template definition separation
by JOAQUIN LOPEZ MU?Z 28 Jan '05

28 Jan '05

This is not strictly related to Boost, but its motivation comes from an effort to reduce compilation times for a Boost library, so I'll risk posting the question. Consider the following: // *************** some_class_template.hpp *************** #ifdef INCLUDE_DEFINITION # define BODY_INCLUDED 1 #else # define BODY_INCLUDED 0 #endif #define BODY_DEFINITION(body) BOOST_PP_IF(BODY_INCLUDED,body,;) template<typename ...> class some_template_class { ... void f(...) BODY_DEFINITION(( { // implementation of f goes here } )) ... }; // *************** foo.hpp *************** #include "some_class_template.hpp" class foo { void bar(); private: some_class_template<...> m; }; // *************** foo.cpp *************** #define INCLUDE_DEFINITION #include "user.hpp" void foo::bar() { m.f(); // f is defined, OK to use it. } Well, the idea is to generate in a simple way a declaration only header of a template class from the full definition, for those situations when the definitions are not needed. The purpose is to reduce compilation times in those translations units including foo.hpp, as they won't be using the class template directly. Other, more conventional approaches, like having the definitions of the class template out of line in a separate file, are harder to maintain and proved to be problematic with buggy compilers (MSVC++ 6.5.) Yet another alternative is to use the pimpl idiom, but this has a runtime penalty. My question is: is this ODR compliant? Anyone sees a problem with this approach? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[function] virtual function bloat
by Jonathan Turkanis 28 Jan '05

28 Jan '05

Hi, I'm writing documentation for my interface library comparing the performance of interfaces vs. base classes with virtual functions. I was going cite a reduction in code bloat caused by virtual functions, with a link to the Boost.Function docs. But when I read the function docs again I was surprised: I had thought the bloat was caused by duplicate vtables being placed in different translation units; I see instead that the bloat cited is attributes to auxiliary type-classification functions. In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out? I realize I haven't given much info about my library; I can supply more if necessary. Any insight would be greatly appreciated. Jonathan

2 2

[function] function_base.hpp comile error with bcc32-5.6.5
by Roman Morokutti 28 Jan '05

28 Jan '05

I am trying to compile the boost libraries. I encountered a compile error with bcc32: Error E2437 D:\boost\boost_1_32_0\boost/function/function_base.hpp 598(55): 'typename' should be followed by a qualified, dependent type name Can someone help? Greetings Roman

3 3

[mpl] Possible documentation bug
by Brad Austin 28 Jan '05

28 Jan '05

The MPL Reference Manual page for at_c: http://www.boost.org/libs/mpl/doc/refmanual/at-c.html Contains the following sample code: typedef range_c<long,10,50> range; BOOST_MPL_ASSERT_RELATION( (at_c< range,0 >::value), ==, 10 ); BOOST_MPL_ASSERT_RELATION( (at_c< range,10 >::value), ==, 20 ); BOOST_MPL_ASSERT_RELATION( (at_c< range,40 >::value), ==, 50 ); Does at_c<unspecified>::value exist? I get a compilation error: error: `value' is not a member of type `boost::mpl::at_c<range, 0> '

2 1

[graph] Any plans to finish implementing subgraph?
by David M. Jones 28 Jan '05

28 Jan '05

Hi, I am using the subgraph class template in my work and I have noticed a number of issues. (1) I am unable to use boost::listS as the storage type for vertices or edges. I see that this is because the association between the local and global vertices is stored (in part) in a std::vector. Is there a plan to support subgraphs of non-array-indexed graphs? (2) The remove_edge_if() and clear_vertex() functions have comments stating that they are wrong. Are the functions wrong or are the comments wrong? If the functions are wrong, is there a plan to fix them? (3) The remove_vertex() function states that it is "under construction". Who is doing the construction? Is there a time-frame for this? I am asking these questions because I don't want to work on my own fixes/implementations of these issues if someone else is already putting forth the effort. Thanks, David

2 2

Re: [boost] boost.filesystem - rationale for copy_file
by Victor A. Wagner Jr. 28 Jan '05

28 Jan '05

At Thursday 2005-01-27 14:32, you wrote: >From: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > > At Tuesday 2005-01-25 14:28, you wrote: > > > > >What is the rationale for having copy_file fail if the target file > > >exists? > > > > > >This is not how any cp/copy in any shell I know of works, actually > > >quite surprising. > > > > in windows (and every OS I've been on the writing team) the shell will at > > least _ask_ for permission to overwrite. > >*nix cp has a -i option to query you, but the default behavior is >to overwrite quietly. The shells do nothing to change that. I wasn't on the team that wrote any flavor of *nix >-- >Rob Stewart stewart(a)sig.com >Software Engineer http://www.sig.com >Susquehanna International Group, LLP using std::disclaimer; >_______________________________________________ >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

RE: cant i use mpl::contains to find members of list_c ??
by Jaap Suter 28 Jan '05

28 Jan '05

> I was trying to use mpl::contains with list_c and it always seems to > return mpl::false_. > For example > typedef mpl::list_c< int ,16,8 > mylist; > typedef mpl::contains<mylist, mpl::int_<16> >::type tt; I've run into this issue in the past as well, and I vaguely rememember seeing mpl::integral_c<long>'s being used somewhere along the way, instead of mpl::integral_c<int>'s as one would expect. I'm not sure if that is still the case, or whether I was decaffeinated, but I ended up fixing it by using the following work-around (pseudo-code): template<class Sequence, class Elem> struct contains : mpl::contains < Sequence, mpl::integral_c < mpl::front<Sequence>::value_type, Elem::value> > >{}; Which isn't pretty, but it got the job done. You basically get the value_type of the first element in the sequence, to make sure the base type of the integral_c you're looking for matches with the sequence. I'm hoping Alexsey or Dave will step in here and clarify this, as it has been a source of confusion for me as well. Regards, Jaap Suter

2 1

[ANN] Interfaces Library
by Jonathan Turkanis 27 Jan '05

27 Jan '05

I am pleased to announce the much anticipated (by me) release of a preliminary version of my interfaces library. The download page and online docs are here: http://www.kangaroologic.com/interfaces/ (For fun, click on "Online Documentation" and then on the Boost logo.) The library is an implementation of Christopher Diggins's proposal to add interfaces to C++, which was posted on comp.std.c++ early last year and later was described in the C/C++ User Journal. It provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the "dot" operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particular base class. Current applications include: * Non-intrusive dynamic polymorphism - interfaces can often be used in place of abstract base classes, and are sometimes much faster. * Dynamic inheritance - allows function calls to be forwarded automatically to an object specified at runtime. * Smart Interface Pointers - smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References - like smart interface pointers, but the managed object is accessed using the dot operator. * The Object Oriented Template Library, a project in the initial stages of development, by Christopher Diggins. Planned future applications include: * Runtime reflection - will allow an interface's functions to be enumerated and looked up by name at runtime * Aspect Oriented Programming as described in a August 2004 Dr. Dobb's Journal article by Christopher Diggins. Possible future applications include: * Integration with component architectures such as COM and CORBA. * Boost.Names - by abstracting the various uses of identifiers in C++ into preprocessor generated types called names, C++ classes and functions can be constructed in a straightforward manner using template metaprogramming. Best Regards, Jonathan

6 12

[ANN] range algorithms and adaptors
by Eric Niebler 27 Jan '05

27 Jan '05

I just uploaded to the boost-sandbox a set of range-based algorithms and adaptors. The algorithms are based on container_algo.hpp from the sequence_algo library (Thorsten Ottosen, Jeremy Siek, Vladimir Prus). I have reimplemented them on top of Boost.Range, and changed the modifying algorithms to work with ranges that are physically const but logically non-const (such as std::pair<char*,char*> const). I have also implemented range adaptors, which are built on top of Boost.Range and the iterator adaptors in Boost.Iterator. There are transform, filter, reverse and indirect range adaptors. They combine with the range algorithms and with BOOST_FOREACH. Consider the following which takes a list of Widget pointers and finds a Widget which is visible and that is named "This Widget": list<Widget*> widgets = ...; list<Widget*>::iterator = find( widgets | indirect | filter(bind(&Widget::Visible,_1)) | transform(bind(&Widget::Name,_1)) , "This widget" ).base().base().base(); And consider the following, which loops over a vector in reverse order: vector<string> strings = ...; BOOST_FOREACH( string & str, strings | reverse ) { cout << str << '\n'; } The code is in boost-sandbox at boost-sandbox/boost/range_ex. I have also put a range_ex.zip in the file vault at: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler No docs or tests yet. This is a work in progress. Feedback welcome. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

What is the status of associative vector framework?
by ION_G_M 27 Jan '05

27 Jan '05

Hello to all, While developing Boost Shmem, I needed an associative container to store data in shared memory, and the easiest one to develop was an ordered vector. For this, I'm using a slightly modified version of Loki's AssocVector (just added reserve() and capacity() members to adjust memory and boost performance in some cases). Reading Boost Files section, I've seen an associative_vector directory containing a preliminary version of this class and related mails, but I don't see any more references to this class since 2002. In the Formal Review Schedule page it is not listed but I can see some review mails googling around so I was asking if this library was abandoned for any reason. I think that this king of "flat" associative containers are very useful, since they are normally faster than std::set/map in lookups and more memory friendly, specially for small types, since normally a tree like structure imposes an overhead of 3 pointers and an integer per node. That without counting that memory allocation for a vector has far less fragmentation when using std::allocator. Is the library still alive? Is anyone insterested in these classes? What I propose is a std::set/map/multiset/multimap like interface on an ordered vector, without more advanced functions, perhaps with added reserve/capacity interface to optimize memory allocation when the number of elements is known beforehand. Best regards, /Ion ---EOF---

1 0

[Boost-bugs] [ boost-Bugs-1110443 ] boost::uniform_on_sphere in not uniform on sphere
by SourceForge.net 27 Jan '05

27 Jan '05

Bugs item #1110443, was opened at 2005-01-27 10:38 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=1110443&group_… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: USU ACM (usu_acm) Assigned to: Jens Maurer (jmaurer) Summary: boost::uniform_on_sphere in not uniform on sphere Initial Comment: It's clear that your previous (1.29) and current verisons (1.32) has no really uniform point distribution on sphere. This fact can be proved by observation that distributions of all coordinates are independent on each other. For example for 3D-sphere really uniform distribution is given by Euler angles (x, arcsin(2t - 1)), where x is uniformly distributed random value on [0..2*pi]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1110443&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Review Manager Needed - Wave Review
by Tom Brinkman 27 Jan '05

27 Jan '05

The Wave Library is ready to review by the boost group. Hartmut indicated that he would like to start around January 31, 2005. Are there any boost members that are familiar with his library and would like to volunteer to be the review manager. The library can be downloaded at: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/wave/ Contact me if you would like to volunteer. Tom Brinkman Review Wizard __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

2 1

Questions on boost::filesystem
by Ami Tavory 26 Jan '05

26 Jan '05

Hello, I have some questions encountered while attempting to extend the boost::filesystem library (BTW, thanks to all involved with this excellent library). I often need to do something with all files matching certain criteria which reside (recursively) in subdirectories matching some (probably different) criteria. E.g., I might want to list all *.hpp files in all subdirectories of 'develop', or search for the first *.cpp file in all subdirectories of "my_proj" excluding "my_proj/bin". Using the boost::iterator library (BTW, thanks to all involved with this excellent library as well), I built a recursive_directory_iterator, parameterized by a functor indicating whether to expand a subdirectory, and a filter iterator, parameterized by a functor indicating whether to retain an entry with a given path, which filters the sequence formed by some other underlying iterator (e.g., recursive_directory_iterator, in this case). This led to two questions: 1. Does the library already include similar functionality? (I couldn't find any;) If not, are there any pitfalls involved? 2. There are (at least) two ways to implement recursive_directory_iterator, which display a memory/time tradeoff: (a) using a stack of boost::filesystem::directory_iterator, and (b) using a boost::filesystem::directory_iterator (for the current subdirectory) and a boost::filesystem::path (for the (parent) subdirectory entry to which to return once the current subdirectory is exhausted). Consequently, I made this too a policy of recursive_directory_iterator. Version (b), however, throws an exception when trying to iterate over a subdirectory "foo!": specifically, I can't assign "foo!" (or any name including '!') to a boost::filesystem::path object, although it seems that my filesystem (on Windows XP) finds "foo!" an acceptable name for a subdirectory. Should I be using boost::filesystem differently? Many Thanks, Ami

1 0

[ANN] QuickBook 1.0 now in boost/tools
by Eric Niebler 26 Jan '05

26 Jan '05

Joel de Guzman and I are happy to announce the general availability of QuickBook, the mindlessly simple way to generate BoostBook-based documentation. The official home for QuickBook is now boost/tools/quickbook. <<What is QuickBook?>> QuickBook is a WikiWiki style documentation tool geared towards C++ documentation using simple rules and markup for simple formatting tasks. QuickBook extends the WikiWiki concept. Like the WikiWiki, QuickBook documents are simple text files. A single QuickBook document can generate a fully linked set of nice HTML and PostScript/PDF documents complete with images and syntax-colorized source code. Features include: * generate BoostBook xml, to generate HTML, PostScript and PDF * simple markup to link to Doxygen-generated entities * macro system for simple text substitution * simple markup for italics, bold, preformatted, blurbs, code samples, tables, URLs, anchors, images, etc. * automatic syntax coloring of code samples * CSS support For point of reference, the entire set of xpressive's documentation at: http://boost-sandbox.sf.net/libs/xpressive was generated from a the single text file: http://tinyurl.com/6h464 (full link: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost-sandbox/boost-sandbo…) Up-to-date documentation for QuickBook can be found in CVS at boost/tools/quickbook/index.html . -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Re: [boost] Re: [Serialization] of pointers into a vector
by JOAQUIN LOPEZ MU?Z 26 Jan '05

26 Jan '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Martes, Enero 25, 2005 10:33 pm Asunto: [boost] Re: [Serialization] of pointers into a vector > This is a currently known problem with the library. It only became > apparrent with the implementation of serialization for indexed set. > > The problem arises because the objects are deserialized to a temporary > variable then moved into the collection. So the pointers are not > going to > point to objects final resting place. > This can be circumvented if one's willing to accept making intrusive changes to the element type. The following is a sketch of the tecnhique (caveat, not compiled): template<typename Derived> class retrackable { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive&,const unsigned int) { // do nothing } }; class object:public retrackable<object> { ... template<class Archive> void serialize(Archive&,const unsigned int) { // serialize as usual } } class foo { private: std::vector<object> v; object* po; // po points to some element of v friend class boost::serialization::access; BOOST_SERIALIZATION_SPLIT_MEMBER() template<class Archive> void save(Archive& ar,const unsigned int version)const { ar<<v; for(std::vector<object>::const_iterator it=v.begin(),it_end=v.end(); it!=it_end;++it){ ar<<static_cast<const retrackable<object>&>(*it); } ar<<static_cast<retrackable<object>*>(po); } template<class Archive> void load(Archive& ar,const unsigned int version) { ar>>v; for(std::vector<object>::iterator it=v.begin(),it_end=v.end(); it!=it_end;++it){ ar>>static_cast<retrackable<object>&>(*it); } retrackable<object>* pro; ar>>pro; po=static_cast<object*>(pro); } }; Of course, an extension to Boost.Serialization would be better --something along a facility to instruct the serialization lib to change the tracking address of an object when this is moved around. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: Re: [Serialization] of pointers into a vector
by JOAQUIN LOPEZ MU?Z 26 Jan '05

26 Jan '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Enero 26, 2005 1:12 am Asunto: [boost] Re: Re: [Serialization] of pointers into a vector > > JOAQUIN LOPEZ MU?Z wrote: > > ----- Mensaje original ----- > > Of course, an extension to Boost.Serialization would > > be better --something along a facility to instruct > > the serialization lib to change the tracking address > > of an object when this is moved around. > > > > I don't think it will be all that hard once its apparent what the > problemis. (Of course that's what I always think - that's my problem) > > my current thinking is to implement something like > > template<class Archive, class T> > common_iarchive<Archive>::move(T & dest, T & source) > > which would do the assignment and update the tracking information. > Then use > it in the de-serializaton of all the collections. This particular interface, if I'm not wrong, is of no use for the collections case, since the assignment is done internally by the container. At least, you need a similar facility that only does the tracking thing: template<class Archive, class T> common_iarchive<Archive>::move_track(T * dest, T * source) // no assignment While we are at it, it could be good to have something along this line for a different but related situation: sometimes it can be necessary to serialize pointers to objects which are *not* serialized themselves (i.e. they are reconstructed by some other means.) This can be achieved with something like: template<class Archive, class T> common_iarchive<Archive>::set_track(T * p) which allows the object pointed by p to be tracked (that is, pointers to it can be serialized) without attempting to load/save the object itself. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

BOOST_PP_SEQ_ENUM
by Arkadiy Vertleyb 25 Jan '05

25 Jan '05

Hi all, Is BOOST_PP_SEQ_ENUM broken? I can't use it with VC71. It expands to something like: BOOST_PP_SEQ_ENUM_3[space](x)(y)(z) and stops here, probably because of the space. Shouldn't the current definition: # define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq be replaced with something like: #define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_SEQ_CAT((BOOST_PP_SEQ_ENUM_)(BOOST_PP_SEQ_SIZE(seq))(seq)) Regards, Arkadiy

2 5

[Boost-bugs] [ boost-Support Requests-1109438 ] Error: Template with C linkage
by SourceForge.net 25 Jan '05

25 Jan '05

Support Requests item #1109438, was opened at 2005-01-25 14:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1109438&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error: Template with C linkage Initial Comment: My email: valeika(a)email.unc.edu I'm a C++ noob, so thanks for looking this over. I am trying to use the boost graph library for an infection transmission project. However, I can't get the BGL to work. In even a simple program that just has: #include <boost\graph\xxxx.hpp> will not compile. I get hundreds of template with c linkage errors. I'm not sure where to go from here. I am using a Mac G5 and am using xcode to edit, build, compile and run my code. Xcode uses the gcc 3.3. Thanks, Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1109438&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

documentation bug
by Max Khesin 25 Jan '05

25 Jan '05

http://www.boost.org/libs/mpl/doc/refmanual/reverse-fold.html The example in the end should say "remove non-negative" rather then "remove negative", methinks. max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

[Serialization] of pointers into a vector
by Robert Shuchatowitz 25 Jan '05

25 Jan '05

Hi, We have a class containing a vector of objects (not pointers to them) and a member class containing a vector of pointers to a subset of those objects. We have tried to serialize the classes, but after loading the subset, we see that the pointers in the subset are not set properly. That is, they do not point to the data in the master vector. Is there a way of doing this besides using new() for the objects in the master set? Thanks, robert

2 1

[Boost-bugs] [ boost-Support Requests-1106566 ] Boost 1.31.0: Compiler erros for msvc-stlport toolset
by SourceForge.net 25 Jan '05

25 Jan '05

Support Requests item #1106566, was opened at 2005-01-21 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1106566&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: meroth (meroth) Assigned to: Nobody/Anonymous (nobody) Summary: Boost 1.31.0: Compiler erros for msvc-stlport toolset Initial Comment: I try to build boost libraries v1.32.0 on VC++ 6.0 using toolset msvc-stlport. INTERNAL COMPILER ERROR when trying to build greg_month.obj in boost_date_time.dll. Obviously more errors after that (see attached file for complete output of command line session). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1106566&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

4 3