- Boost - lists.boost.org

Re: [boost] [1.34.0] Re: State of regression tests
by Vladimir Prus 25 Jan '07

25 Jan '07

Thomas Witt wrote: >> Can we all agree on the following: >> >> 1. No commits to libraries code on RC branch whatsoever. >> >> 2. All patches to regression testing tools and Boost.Build >> code on RC should be posted to main boost mailing list, so >> that everybody knows what's being changed. > > Please add a cc to the testing list. But also please post to main boost list, so that there's one list where all changes go. >> 3. No changes in tester's configurations whatsoever, unless >> explicitly asked for. > > Vladimir are you going to be the person in charge of this? I.e. *no* > changes unless you ask for them? I think it's important that there is > one person. Yes, I think I can do it. >> 4. No new testers whatsoever. >> >> I think that with those agreements, it would take me >> less than a week to stabilize regression results from >> Martin Wille (who is historically known to have no >> local misconfigurations), and knowing that regression system >> itself works, we can effectively decide what to do with >> other issues -- including those showing up in configurations that >> were not previously tested. > > If it's not clear by now I completely agree with this strategy. Great. As outlined above, I'll try to sort Martin's results first. - Volodya

1 0

Variant/Any and the never-empty guarantee
by Mathias Gaunard 25 Jan '07

25 Jan '07

I am currently writing an object container similar to boost.any but with an allocator template parameter. That allocator is of a custom type that allows efficient stack allocation like boost.variant. While looking at variant's documentation, I became aware of the problem with operator= and the never-empty guarantee. http://boost.org/doc/html/variant/design.html#variant.design.never-empty However, I think none of the solutions is really satisfying, especially in my case where the allocator is generic and provided by the user and where the types that are to be put in the container aren't known until runtime. Lots of versions would need to be made, indicating whether one or another option is nothrow for the object or the allocator, providing fallback allocators etc. Do you think it is reasonable to simply require a nothrow move constructor for the types which are to be put into my container? I cannot think of a case where move constructors would really want to throw, and swap functions which are similar are usually no-throw. There is also the 'false hopes' solution, which is said to not be allowed by the standard. But realistically, that solution shouldn't cause any problem, since I always see moving as a simple bitwise copy ; unless the object references itself, which would be solved by moving it back anyway. I welcome any critics, ideas and advices about moving, exceptions, and bitwise copy.

1 0

[Parameter] bug with 1.33.1 and vc7.1 ?
by Paul Rose 25 Jan '07

25 Jan '07

In the process of getting familiar with Boost.Parameter I created the following simple example: #include <iostream> #include <boost/parameter/keyword.hpp> namespace Foo{ BOOST_PARAMETER_KEYWORD(tag, touch) BOOST_PARAMETER_KEYWORD(tag, taste) BOOST_PARAMETER_KEYWORD(tag, smell) BOOST_PARAMETER_KEYWORD(tag, sight) BOOST_PARAMETER_KEYWORD(tag, hearing) template<class ArgumentPack> void senses(ArgumentPack const &args){ std::cout << "touch: " << args[touch|"soft"] << std::endl; std::cout << "taste: " << args[taste|"bitter"] << std::endl; std::cout << "smell: " << args[smell|"foul"] << std::endl; std::cout << "sight: " << args[sight|"bright"] << std::endl; std::cout << "hearing: " << args[hearing|"loud"] << std::endl; } } int main(){ using namespace Foo; senses((sight="dim",hearing="quiet",taste="sweet",touch="rough",smell="s tinky")); return 0; } I expected the following output: touch: rough taste: sweet smell: stinky sight: dim hearing: quiet But when compiling with VC7.1 (cl.exe version 13.10.6030) and Boost 1.33.1 I get the following touch: rough taste: sweet smell: foul sight: bright hearing: loud Note the "hearing: loud" instead of "hearing: quiet". I get the expected results under gcc 3.3.5 using the same Boost 1.33.1. Is this a known issue? Is there a work around? Thanks, Paul Rose

1 0

GIL Review Comments
by Tom Brinkman 25 Jan '07

25 Jan '07

I'm finishing up a small project using GIL and I appreciate GIL even more -- I now have a very good feel for the basic functionality of the library. I'll post my sample project and some impressions of my experience here when I'm done. I'm still trying to learn the more advanced features of GIL -- my difficulty with the advanced functionality has nothing to do with GIL, but more my own deficiencies in understanding color theory. There are two things that I would absolutely must have if I was to completely switch over to GIL: 1) freetype - for text rendering I've started to write a freetype class for GIL that may be of interest. I'll send that to Lubomir it on when I'm done. 2) antaialias lines - for smooth line rendering Anatialias lines are more difficult, particularly connecting end points. I wonder what lubomir's plans are for this important functionality. I'm thinking something like this: for_each_line(lines.begin(), lines.end(), draw_antialised()); <or> for_each_point(points.begin(), points.end(), draw_antialiased());

7 9

[filesystem] invalid pointer 0x91d4a98
by prateek khanna 25 Jan '07

25 Jan '07

Whenever i try to perform any filesystem library operation in Linux i get following message at runtime. I written following code int SystemCall::Remove(std::string strAbsFilename) { fs::path del_path ( fs::initial_path() ); del_path = fs::system_complete( fs::path( strAbsFilename, fs::native ) ); if(fs::exists( del_path )) { int i = fs::remove(del_path); cout << i << "\n"; } else { cout << strAbsFilename.c_str() << " not found."; return 0; } cout << "\nSuccessfully deleted."; return 1; } This code deleted the file passed to it as an argument. But give runtime message "free(): invalid pointer 0x91d5638! ". 1) Is it a memory leak ? 2) Can this lead to a bigger problem. Because my code works perfectly fine except this message.? -- Thanks & Regards: Prateek Khanna Software Developer Baysquare Technologies

1 0

Re: [boost] [pool] object_pool::destroy_all? (from users)
by Steven Watanabe 25 Jan '07

25 Jan '07

AMDG Michael Marcin wrote: > >> I started using object_pool recently to solve a problem. I have lots of >> objects being created and destroyed frequently and stored in a >> collection. Every so often an event happens which triggers destroying >> all the objects. >> >> Essentially I have: >> >> boost::object_pool<Object> m_object_pool; >> std::vector<Object*> m_objects; >> >> >> Then I have a function >> >> void DestroyAllObjects() >> { >> std::vector<Object*>::iterator it, iend = m_objects.end(); >> for( it = m_objects.begin(); it != iend; ++it ) >> { >> m_object_pool.destroy(*it); >> } >> m_objects.clear(); >> } >> >> It seems like there should be a better way of doing this... i.e. >> >> void DestroyAllObjects() >> { >> m_object_pool.destroy_all(); >> m_objects.clear(); >> } >> >> Also it might be nice to iterate over all the objects in the pool (in >> which case I wouldn't even need the m_objects vector. >> >> Perhaps there is a better way to solve the problem? >> >> > > I didn't get an answer on users so I thought I'd ping here. > > Thanks, > > Michael Marcin Iteration seems like a good solution. #include <iterator> class object_pool { //... public: class iterator; friend class iterator; class iterator { friend class object_pool; public: typedef T value_type; typedef T* pointer; typedef T& reference; typedef typename object_pool::difference_type difference_type; typedef std::forward_iterator_tag iterator_category; iterator& operator++() { while(true) { i += increment; if(i == end) { iter = iter.next(); if(iter.valid()) { i = iter.begin(); end = iter.end(); } else { i = 0; } break; } if(i != freed_iter) break; freed_iter = object_pool<T, UserAllocator>::nextof(freed_iter); } return(*this); } iterator operator++(int) { iterator result(*this); ++*this; return(result); } reference operator*() const { return(*static_cast<T*>(static_cast<void*>(i))); } friend bool operator==(const iterator& self, const iterator& other) { return(self.i == other.i); } friend bool operator!=(const iterator& self, const iterator& other) { return(self.i != other.i); } private: size_type increment; details::PODptr<size_type> iter; void* freed_iter; char* i; char* end; }; iterator begin() { iterator result; if(this->list.valid()) { result.increment = this->alloc_size(); result.iter = this->list; result.freed_iter = this->first; result.i = this->list.begin(); result.end = this->list.end(); } else { result.i = 0; } return(result); } iterator end() { iterator result; result.i = 0; return(result); } class const_iterator; friend class const_iterator; class const_iterator { friend class object_pool; public: typedef T value_type; typedef const T* pointer; typedef const T& reference; typedef typename object_pool::difference_type difference_type; typedef std::forward_iterator_tag iterator_category; const_iterator() {} const_iterator(const iterator& other) : increment(other.increment), iter(other.iter), freed_iter(other.freed_iter), i(other.i), end(other.end) {} const_iterator& operator++() { while(true) { i += increment; if(i == end) { iter = iter.next(); if(iter.valid()) { i = iter.begin(); end = iter.end(); } else { i = 0; } break; } if(i != freed_iter) break; freed_iter = object_pool<T, UserAllocator>::nextof(freed_iter); } return(*this); } const_iterator operator++(int) { const_iterator result(*this); ++*this; return(result); } reference operator*() const { return(*static_cast<const T*>(static_cast<const void*>(i))); } friend bool operator==(const const_iterator& self, const const_iterator& other) { return(self.i == other.i); } friend bool operator!=(const const_iterator& self, const const_iterator& other) { return(self.i != other.i); } private: size_type increment; details::PODptr<size_type> iter; void* freed_iter; char* i; char* end; }; const_iterator begin() const { const_iterator result; if(this->list.valid()) { result.increment = this->alloc_size(); result.iter = this->list; result.freed_iter = this->first; result.i = this->list.begin(); result.end = this->list.end(); } else { result.i = 0; } return(result); } const_iterator end() const { const_iterator result; result.i = 0; return(result); } }; In Christ, Steven Watanabe

2 2

Re: [boost] program_options: Why it throw ambiguous_option?
by Sohail Somani 25 Jan '07

25 Jan '07

Well maybe as of a few days ago, but yes. Anyway, you should try to debug it. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Peng Yu > Sent: Wednesday, January 24, 2007 6:45 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] program_options: Why it throw ambiguous_option? > > Hi, > > Are you talking about CVS described at > http://www.boost.org/more/getting_started.html#CVS > > The boost in CVS should make the following code work, right? > > Thanks, > Peng > > On 1/24/07, Sohail Somani <s.somani(a)fincad.com> wrote: > > This works for me in CVS. > > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org on behalf of Peng Yu > > Sent: Tue 1/23/2007 8:33 PM > > To: boost(a)lists.boost.org > > Subject: [boost] program_options: Why it throw ambiguous_option? > > > > Hi, > > > > I got the following error for the program list below. Where > > program_options considers "help" and "help_abc" as ambiguous? > > > > $ ./main --help > > terminate called after throwing an instance of > > 'boost::program_options::ambiguous_option' > > what(): ambiguous option help > > Aborted > > > > > > Thanks, > > Peng > > > > > > #include <boost/program_options.hpp> > > namespace po = boost::program_options; > > > > int main(int ac, char* av[]) > > { > > po::options_description desc("Allowed options"); > > desc.add_options() > > ("help", "produce help message") > > ("help_abc", po::value<int>(), "set compression level") > > ; > > > > po::variables_map vm; > > po::store(po::parse_command_line(ac, av, desc), vm); > > po::notify(vm); > > > > return 0; > > } > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] [pool] object_pool::destroy_all? (from users)
by Steven Watanabe 24 Jan '07

24 Jan '07

AMDG gchen wrote: > Michael Marcin wrote: > >>> It seems like there should be a better way of doing this... i.e. >>> >>> void DestroyAllObjects() >>> { >>> m_object_pool.destroy_all(); >>> m_objects.clear(); >>> } >>> >>> Also it might be nice to iterate over all the objects in the pool (in >>> which case I wouldn't even need the m_objects vector. >>> >>> Perhaps there is a better way to solve the problem? >>> >>> > > It seems that pool::release_memory or purge_memory can do this. > > Regards > cg > 1) They don't call the destructors. 2) object_pool does not expose these members. In Christ, Steven Watanabe

3 2

[pool] object_pool::destroy_all? (from users)
by Michael Marcin 24 Jan '07

24 Jan '07

Michael Marcin wrote: > I started using object_pool recently to solve a problem. I have lots of > objects being created and destroyed frequently and stored in a > collection. Every so often an event happens which triggers destroying > all the objects. > > Essentially I have: > > boost::object_pool<Object> m_object_pool; > std::vector<Object*> m_objects; > > > Then I have a function > > void DestroyAllObjects() > { > std::vector<Object*>::iterator it, iend = m_objects.end(); > for( it = m_objects.begin(); it != iend; ++it ) > { > m_object_pool.destroy(*it); > } > m_objects.clear(); > } > > It seems like there should be a better way of doing this... i.e. > > void DestroyAllObjects() > { > m_object_pool.destroy_all(); > m_objects.clear(); > } > > Also it might be nice to iterate over all the objects in the pool (in > which case I wouldn't even need the m_objects vector. > > Perhaps there is a better way to solve the problem? > I didn't get an answer on users so I thought I'd ping here. Thanks, Michael Marcin

2 1

program_options: Why it throw ambiguous_option?
by Peng Yu 24 Jan '07

24 Jan '07

Hi, I got the following error for the program list below. Where program_options considers "help" and "help_abc" as ambiguous? $ ./main --help terminate called after throwing an instance of 'boost::program_options::ambiguous_option' what(): ambiguous option help Aborted Thanks, Peng #include <boost/program_options.hpp> namespace po = boost::program_options; int main(int ac, char* av[]) { po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("help_abc", po::value<int>(), "set compression level") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); return 0; }

2 2