September 2006 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Writing a more readable code
by Nat Goodspeed 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of me22 > Sent: Friday, September 15, 2006 2:55 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Writing a more readable code > > use an iterator adapter that returns base_itr->second when > dereferenced. I hear that it's simple to make one with > Boost.Iterator. > > You'd then just do > std::for_each( seconder(a.begin()), seconder(a.end()), boost::bind(f,_1) > ); [Nat] The need to adapt each of a.begin() and a.end() bothers me. (I've dealt with similar but more complex situations.) Is there a nice way to combine Boost.Iterator adaptors with Boost.Range to express this less redundantly?

1 0

Re: [Boost-users] Comments / Advice on using Boost Test Library
by Sohail Somani 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Dave Steffen > > This is permissable in unit tests, I would think. > > Yes, this is one of the alternate approaches I've been considering. > We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is > out there somewhere... :-) I'm pretty sure those are the only approaches, but I'd be glad to find a more obvious way that isn't intrusive.

1 0

Re: [Boost-users] [serialization] serialization of pointers toprimitive types?
by JOAQUIN LOPEZ MU?Z 15 Sep '06

15 Sep '06

Hi Volodya ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Viernes, Septiembre 15, 2006 6:19 pm Asunto: Re: [Boost-users] [serialization] serialization of pointers toprimitive types? > Joaquín Mª López Muñoz wrote: > > > The following test program: > > > > #include <boost/archive/text_oarchive.hpp> > > #include <sstream> > > > > int main() > > { > > int x=0; > > int* const px=&x; > > std::ostringstream oss; > > boost::archive::text_oarchive oa(oss); > > oa<<px; > > > > return 0; > > } > .... > > I've checked the same snippet against Boost 1.33.1, CVS HEAD and > > RC_1_34_0, using other primitive types like std::string, same > > problem always. Same problem also for the loading counterpart. > > When the pointed-to type is not primitive, though, everything > > works fine, regardless of whether the type has intrusive or non > > intrusive serialization support. > > > > I am sure I'm doing something really stupid here, but I've been > > banging my head against this several hours. Some clue greatly > > appreciated. > > This never worked, I think. The problem is that if you're saving > pointers,you need to check if you've already saved that pointer, > so that on loading, > you don't get two pointers to to ints, as opposed to two pointers > to a > single int, as it should be. > > This "tracking" requires runtime map, and I believe Robert decided > thatmaintaining such map for primitive type can be too expensive. > I'm not sure > how valid that point it, not how many hidden stones there are in > enablingprimitive types to be tracked. I know primitive types are not tracked, but I take that to mean that multiple pointers to the same object will result in duplicated copies in the archive, *not* that serializing a pointer will result in a compile error. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[shmem] leaving shared objects in memory
by Pataki Szilard 15 Sep '06

15 Sep '06

Hello! Can anybody tell me how can I make the shared memory segment (together with the objects constructed in it) remain in memory AFTER the process which created it terminates? E.g. Proc1 creates the segment and the objects in it. Proc2 accesses the segment and operates on the shared objects. Proc1 might get killed and I don't want this event to affect in any way Proc2. Thanks and regards, Szilard

2 1

shared_ptr without rtti
by Michael Marcin 15 Sep '06

15 Sep '06

Using WinARM version 20060606 (gcc 4.1.1) compiling with -fno-rtti gives: 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp: In member function 'virtual void* boost::detail::sp_counted_impl_pd<P, D>::get_deleter(const std::type_info&)': 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp(150): error: cannot use typeid with -fno-rtti 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp: In member function 'virtual void* boost::detail::sp_counted_impl_pda<P, D, A>::get_deleter(const std::type_info&)': 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp(220): error: cannot use typeid with -fno-rtti 1>..\..\sdk\boost\inc/boost/shared_ptr.hpp: In function 'D* boost::get_deleter(const boost::shared_ptr<U>&)': 1>..\..\sdk\boost\inc/boost/shared_ptr.hpp(540): error: cannot use typeid with -fno-rtti I thought typeid can work at compile-time without rtti (seems to for msvc8) but I guess not. Any ideas? -- Michael Marcin Method Solutions, Programmer

2 4

boost.crc
by renjh 15 Sep '06

15 Sep '06

My truncated polynominal has 83 bits, does boost.crc support it? I hope to get an example for that.

1 0

Boost::signals MT question
by Mark Wilson 14 Sep '06

14 Sep '06

Does the fact that bjam builds a "*-mt*" version of signals indicate that signals is now thread-safe? If it isn't, why is the "*-mt*" version built? Thanks, Mark

2 1

best of both worlds: ptr_vector and multi_array
by Levent Yilmaz 14 Sep '06

14 Sep '06

This question is perhaps, rather a feature request from multi_array: ptr_vector (of pointer container library) is nice but it is not multi dimensional, multi_array is nice but it is not, well, ptr_multi_array. For any single dimensional random access array there is multi_array_ref: /**/ boost::array<size_t,2> shape = {4,4}; std::vector<int> v(16); boost::multi_array_ref<int,2> mav(&v[0],shape); /**/ But, this (&v[0]) wouldn't work with ptr_vector, due to the indirected interface of pointer containers. I was thinking, one way of achieving this is to have multi_array_ref work with any random access container, rather than just plain C array. The above example would be: /**/ boost::array<size_t,2> shape = {4,4}; std::vector<int> v(16); boost::multi_array_ref< std::vector<int>, 2 > mav(v,shape); /**/ Note the change of the first template parameter of multi_array_ref from the element type to, container type. This way, it would similarly be possible to use it with ptr_vector, or any other random access container for that matter: /**/ class foo; boost::array<size_t,2> shape = {4,4}; boost::ptr_vector<foo> v(16); boost::multi_array_ref< boost::ptr_vector<foo>, 2 > mav(v,shape); /**/ The thing is, I am not sure if this can be done with the multi_array library. Or, what other ways are there to get a multi dimenstional pointer container? thanks - Levent.

1 0

Re: [Boost-users] [program_options] Linker error with MSVS 7.1
by Scott 14 Sep '06

14 Sep '06

As a follow up to my previous email regarding UNICODE problems, I tried the following on a whim: int _tmain(int argc, _TCHAR* argv[]) { try { static char* argvv[] = { "help" }; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("set,s", po::value< std::vector<std::string> >(), "Set one or more node values, overriding stored value in config file") ; po::variables_map vm; po::store(po::parse_command_line(argc, argvv, desc), vm); The program above compiles. If I switch from argvv (ANSI) to argv (UNICODE) in parse_command_line(), I get all those linker errors. The docs seem to indicate that UNICODE parsing is supported, so what am I missing? Thanks, Scott

1 0

[program_options] Linker error with MSVS 7.1
by Scott 14 Sep '06

14 Sep '06

I'm trying to link a win32 console app using program options. I have previously build boost with bjam using MSVS 7.1. My program, which is pretty basic and taken from first.cpp looks something like this: int _tmain(int argc, _TCHAR* argv[]) { try { po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("set,s", po::value< std::vector<std::string> >(), "Set one or more node values, overriding stored value in config file") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help")) { std::cout << desc << "\n"; } [snip] The program is compiled as _UNICODE. It seems to compile ok, though I get the following warnings: ..\API\inc\boost\program_options\errors.hpp(21) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::program_options::error' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' ..\API\inc\boost\program_options\errors.hpp(21) : see declaration of 'boost::program_options::error' ..\API\inc\boost\program_options\variables_map.hpp(130) : warning C4273: 'boost::program_options::store' : inconsistent dll linkage ..\API\inc\boost\program_options\variables_map.hpp(138) : warning C4273: 'boost::program_options::store' : inconsistent dll linkage But then I get linker errors, like this: NwEngine.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::program_options::basic_parsed_options<unsigned short>::~basic_parsed_options<unsigned short>(void)" (__imp_??1?$basic_parsed_options@G@program_options@boost@@QAE@XZ) referenced in function _wmain I have the following lib files in my lib path: boost_program_options-vc71-mt-1_33_1.lib boost_program_options-vc71-mt-gd-1_33_1.lib libboost_program_options-vc71-mt-1_33_1.lib libboost_program_options-vc71-mt-gd-1_33_1.lib libboost_program_options-vc71-mt-s-1_33_1.lib libboost_program_options-vc71-mt-sgd-1_33_1.lib Am I supposed to do something special to link to them? I was under the impression that it worked similar to boost regex and auto-linked. Thanks, Scott

1 0