April 2004 - Boost - lists.preview.boost.org

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

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

16 Apr '04

> > 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. > > A bold prediction in the face of contradictory evidence. Can you elaborate? You may have no problems understanding the library, but the first time I tried to bind with a reference, I ran into the same confusion. I am speaking from my own limited experience with the library. I've read the documentation: // Start of docs The arguments that bind takes are copied and held internally by the returned function object. For example, in the following code: int i = 5; bind(f, i, _1); a copy of the value of i is stored into the function object. boost::ref and boost::cref can be used to make the function object store a reference to an object, rather than a copy: int i = 5; bind(f, ref(i), _1); // End of docs I know this makes it explicit that you need a ref or cref to have bind store a reference to an object, but there is no reasoning behind this design decision in the documentation, or that I can find in the implementation and I've not stumbled across it in the mail archives. Best, John

4 3

[serialization] register_type and dll/so module
by Li Lirong 16 Apr '04

16 Apr '04

Hi, 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? Best regards, Lirong

2 3

[serialization] + [boost.python] serialization of python object
by Li Lirong 16 Apr '04

16 Apr '04

Dear All, 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? Thanks and best regards, Lirong

1 0