- Boost - lists.boost.org

intrusive_ptr doc bug?
by Andreas Huber 16 Apr '04

16 Apr '04

Hi there >From intrusive_ptr.html: <quote> Every new intrusive_ptr instance increments the reference count by using an unqualified call to the function intrusive_ptr_add_ref, passing it the pointer as an argument. Similarly, when an intrusive_ptr is destroyed, it calls intrusive_ptr_release; this function is responsible for destroying the object when its reference count drops to zero. The user is expected to provide suitable definitions of these two functions. On compilers that support argument-dependent lookup, intrusive_ptr_add_ref and intrusive_ptr_release should be defined in the namespace that corresponds to their parameter; otherwise, the definitions need to go in namespace boost. </quote> It's the last 8 words that don't make much sense to me. That would force some libraries using intrusive_ptr to make using declarations or directives in headers. IMHO there's no other choice but to put the two functions in the global namespace for compilers that do not support ADL. What am I missing? Thanks & Regards, Andreas

2 2

Re: Re: Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

"Peter Dimov" > The types in l_ are always add_value processed, the types in the other listN > that stores references to the arguments at the call site are not. In > > bind(f, a1, a2)(b1, b2); > > bind(f, a1, a2) creates a list2 that holds the values of a1 and a2, > add_value-processed. The call (b1, b2) creates a list2<B1&, B2&> that holds > references to b1 and b2. > > These are all implementation details. I don't see why you seem so worried > about them. In particular, add_value is only present because of the need to > support MSVC 6. On a compiler that supports partial specialization, it's > possible to use an unadorned list2<A1, A2> as l_. Many other implementation > variations are also possible. Okay, now that I know add_value is a workaround, that clears up a bit of my confusion. I'm working on a typelist variety of bind that works with Loki typelist defined functors. My apologies for my wording of my initial confusion with the bind library. I should have thought about asking why bind was designed thus in a less arrogant way than I initially asked. Hopefully bad first impressions on boost are forgotten faster than bad first impressions with parents. Best, John

1 0

Re:[boost] Re: [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > Thanks for the link. However, the current BOOST_CLASS_EXPORT mechanism > will not work with DLLs. That's because global/static variable (the > extended_type_info_typeid instance) is not shared by DLLs. > I guess we may have to make the serialization library a dll and export > the extended_type_info_typeid instance as a global variable. Clearly you understand the main issue here. I believe its fixable although I'm not sure that making the library a DLL in itself will addresse it. Basically we have to find the tweak so that there is one and only one type table be it in the main program or in the DLL of the library. I'm sure it will require a subtle adjustment in the library. If you managed to figure this out let me know. I'll also take a look at it. Robert Ramey

1 0

Re: [boost] [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > In the serialization library, when classes are never serialized directly > but rather through a pointer to the base class, the user need to call > register_type so that the archive contains information about the derived > classes. > However, sometimes those derived classes are implemented in another > dynamic loaded (dll/so) module. The type of the derived classes will > not be known at compile time. How can cope with this? Does the library > provide any facilities to help the user in this situation? This is still under consideration. Right now its not clear what the best way to handle this is. The package contains demo_pimpl and I have a demo_plugin example on my desk - but I don't think I'm ready to give a good answer to this question. Just going into speculation mode I would consider: a) build the library as a DLL. b) build the serialization of another type as another DLL c) use BOOST_CLASS_EXPORT for the ser d) pray that the type registration maintains a single type/key table in the main program or library DLL data space. So clearly we're into new territory here. Your questions suggest that you're taking the serialization library to places were no one has gone before. Just out of curiosity, what is the application you're working on? Robert Ramey

1 0

[serialization] + [boost.python] serialization of python object
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > According to the documentation of boost.python, > one can derive from c++ base class in Python and override the virtual > functions in Python. However, is it possible to serialize the objects > of the python class using the serialization library? I think we're a little ways off from that. If you want to get started now take a look Plugin Archive Adaptor in the manual section "Future Directions" Robert Ramey

4 3

Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> So e.g. list1 is always instantiated with a reference type, to what? the original type, or the add_value processed type? > and thus it > also stores the arguments > as references. I still think that those types are processed by add_value before being used. The bind_t L template parameter is instantiated with a list of add_value modified types through list_av_N in the bind calls, which leads me to believe that the listN represented by l_ object in bind_t has types of either value<T>, reference_wrapper<T>, or other bind_t structures. So are the types stored in listN (A1, A2, ... ) ever the original type or the original reference type? Or are they always add_value<T> processed? Many thanks 4 your time, John

2 1

gcc34 , boost::random problem
by Neal D. Becker 16 Apr '04

16 Apr '04

In file included from /usr/include/boost/random.hpp:46, from TestPn.cc:1: /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::init_modulus()': /usr/include/boost/random/lagged_fibonacci.hpp:276: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::seed(It&, It)': /usr/include/boost/random/lagged_fibonacci.hpp:309: error: `std::fmod' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp:310: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::lagged_fibonacci_01<RealType, w, p, q>&)': /usr/include/boost/random/lagged_fibonacci.hpp:357: error: `std::pow' has not been declared In file included from /usr/include/boost/random/ranlux.hpp:25, from /usr/include/boost/random.hpp:47, from TestPn.cc:1: /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::init_modulus()': /usr/include/boost/random/subtract_with_carry.hpp:268: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(uint32_t)': /usr/include/boost/random/subtract_with_carry.hpp:280: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(It&, It)': /usr/include/boost/random/subtract_with_carry.hpp:295: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp:296: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::subtract_with_carry_01<RealType, w, s, r, val>&)': /usr/include/boost/random/subtract_with_carry.hpp:351: error: `std::pow' has not been declared

1 0

reference binding
by Dill, John 16 Apr '04

16 Apr '04

> > Its learning curve is > > inherently steep and more importantly, it simply cannot be flattened by > > making bind less useful. > > I guess the current design gives maximal power; so it it seems ok. Requering > that the > user calls > > bind( f, local_copy( i ) ) > > would document that the programmer knows that f takes a reference, but that > it > can act on a copy. However, once you know the mechanism, you would be > irritated by such constraints. > > Thorsten I agree with Thorsten's point. The first inclination when binding a function with a reference is that the arguments passed to that bind functor is actually passed by reference. That is what you are actually saying in your bind statement. While having pass-by-value may be more convenient and occur more often, the counter-intuitiveness of the semantics will lead to subtle bugs in people's code who misunderstand or forget bind's behavior in this area. It is not a matter of reducing the power of bind or "hand-holding" as has been said, but enforcing the semantics of what the programmer is actually saying. If you are binding to a reference argument, you should not need a ref( arg ) to say that the argument really is a reference. If you are binding to a reference, and want to pass by value, let the programmer type the extra 5-10 characters and explicitly say that he's changing the semantics of the bind. I personally like "bind( f, value( i ) )" myself. All that would need to be done is to introduce a argument_traits type class that will wrap references with a reference_wrapper, and also provide a value() wrapper. If you are binding often to a reference and want to pass-by-value, you might need to re-evaluate your interface. Just my 2 cents. Best, John

4 3

RE: [boost] library for managing a large number of FILE objects
by Michiel Salters 16 Apr '04

16 Apr '04

I'm wondering whether this can be generalized. Basically, I imagine a class "virtually" holding objects of some type T, with the restriction that it may not hold more than N actual objects of type T, and holds data<T> objects to create the other objects. You'd have a policy<T> which would create a T from a data<T> and later destroy it. The assumption is that a data<T> would be a lot cheaper than an actual T. Your case would be a specialization with T==FILE* and data<T> being just the file name. The policy<FILE*>::create(data<FILE*>) method would call fopen, the policy<FILE*>::destroy() would fclose it. The default policy<T>::create( data<T> data_T ) can probably call new T( data_T ) and return that. Regards, Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jody Hagins > Sent: vrijdag 16 april 2004 1:57 > To: boost(a)lists.boost.org > Subject: [boost] library for managing a large number of FILE objects > > > > I know that C++ IOStreams are supposed to take over the world, and > cstdio with FILE is considered taboo by some C++ > efficionados. However, > due to many reasons, lots of code still uses cstdio FILE I/O. > One issue > that comes up from time to time is the need to manage more files than > the OS will allow a single process to have open simultaneously. I > process tons of data, and this is an issue for me. I have developed a > small library that provides on-demand caching of FILE > pointers, so that > an application can "open" as many FILEs as necessary, and use them as > normal. A simple LRU eviction algorithm is used to reclaim FILEs when > "all" have been used. > > I was discussing this library with another developer, and he > said he has > seen several questions recently about a similar issue, and he > advised me > to ask if there was interest here. This library, however, > does not seem > "on the edge" enough though... > > A very simple example of how you can use the library (of course there > are better ways to do the following, but it is meant to be a > small easy > to use example). > > > // Open 10,000 FILEs > wjh::file_cache file_cache; > std::vector<wjh::cached_fptr> fp; > for (int i = 0; i < 10000; ++i) > { > std::stringstream strm; > strm << "FILE_" << i; > wjh::cached_fptr fptr = file_cache.open(strm.str().c_str(), "w"); > if (!fptr) > { > std::cerr << strm.str() << ": " << strerror(errno) << std::endl; > break; > } > fp.push_back(fptr); > } > > // Randomly write to a particular file. > for (int i = 0; i < 200000; ++i) > { > int x = rand() % fp.size(); > fprintf(fp[x], "file %d, iteration %d\n", x, i); > } > > > Is it something useful for more than just me (and the pitiful > souls who > work for me and must use it) on this list? > > Is it something worth posting here? > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > 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

RE: [boost] Re: boost on HP-UX 11i
by DY, JERRY U (SBCSI) 16 Apr '04

16 Apr '04

Dave, >> I would be very surprised if nobody has tried before since HP is a >> top-tier vendor > >I have tried, but not in the last 9 months. HP may be "top-tier" but >if so their compilers have not proven to be of the same caliber as the >rest of the company, at least when it comes to compiling Boost code. >The number and severity of the compiler bugs, and the poor quality of >the error messages, made the job infeasibly hard. If you have notes that might be useful or helpful for me (to save me time), I would appreciate it. I have been quite successful in porting code over to aC++ over the years and have reported several compiler/linker/debugger bugs to the HP response center and worked with them to fix problems or find workarounds. The last one I helped fix was the ANTLR parser generator. I'm frantically reading the documentation ... the more I read, the more I like it. A lot of code that we have already written definitely would be better if we had boost years ago. Thanks! -Jerry

3 2