- Boost - lists.boost.org

[RFC] Alternative any design
by Pablo Aguilar 12 Aug '05

12 Aug '05

Hi, First of all, thanks to everyone who's commented on the proposed any alternative. Given that the alignment issue doesn't seem to be easy to solve, I'm thinking of giving up on trying to align correctly, and just skip the "in place storing of value" optimization when it might be an issue. So I'm wondering, is the following a proper way to detect alignment problems? <code> typedef void* any_buffer_base_type; // could be customized int const ANY_BUFFER_SIZE = sizeof(any_buffer_base_type); union object_holder { char buffer[ANY_BUFFER_SIZE]; void* pointer; any_buffer_base_type alignment_dummy_; }; template<typename T> struct optimize { enum { T_size_ = sizeof(T) , base_size_ = sizeof(any_buffer_base_type) , size_ok_ = (T_size_ <= base_size_) , T_align_ = alignment_of<T>::value , base_align_= alignment_of<any_buffer_base_type>::value , align_ok_ = ((base_align_ % T_align_) == 0) , value = size_ok_ && align_ok_ }; }; </code> I looked at Optional's alignment tecnique, and couldn't come up with how to use it, given that the stored type for any changes at runtime. If there's something I missed about this, any help would be welcome. My current solution is to use the above shown code (assuming it works, of course!), and fall back on heap based storage when optimization is deemed not possible. The 2nd question I had to ask is, how should any's alignment type be specified, with a configuration macro or through a template parameter? I haven't posted an updated version, given that there's some issues (other than alignment) still requiring attention. Thanks in advance for any help you might provide, Pablo Aguilar

1 0

[wave] No dynamic lib?
by Neal Becker 12 Aug '05

12 Aug '05

I notice that 1.33.0-rc2 doesn't build dynamic libs for wave. Is this intentional?

2 3

Re: [boost] [thread] assertion error when exiting app
by Sean Huang 11 Aug '05

11 Aug '05

> I didnt understand your solution... > You call on_thread_exit in the end of the threads that are created > with boost::thread ? Even if there are, possibly, other(COM) threads > running? It has nothing to do with boost::thread. I call on_thread_exit on any threads that use boost::thread_specific_ptr. on_thread_exit can be called multiple times so this workaround works with boost::thread too. One thing important is you cannot use boost::thread_specific_ptr after the call. I would consider this as a hack not a solution. Sean

1 0

archive stuck?
by Gennadiy Rozental 11 Aug '05

11 Aug '05

I don't see this month messages here: http://lists.boost.org/boost/2005/08/date.php Gennadiy

3 4

Linker Error During Compilation of Function
by Mottengte, Rajeev Kumar 11 Aug '05

11 Aug '05

Hi I am getting linker errors during compilation of functions which is returning object of class boost::archive::text_iarchive. The error is "In Copy constructor 'boost::archive::basic_text_iprimitive<> ..... boost::scoped_ptr<T> is private. So I changed the scoped_ptr to public manually in the scoped_ptr.hpp file. After that I am getting an error undefined reference to boost::scoped_ptr<std::locale>. Can any body tell me how to resolve this problem. Rgds Rajeev

1 0

Re: [boost] alignment problem in proposed any alternative
by Martin Bonner 11 Aug '05

11 Aug '05

----Original Message---- From: christopher diggins [mailto:cdiggins@videotron.ca] Sent: 11 August 2005 14:00 To: boost(a)lists.boost.org Subject: Re: [boost] alignment problem in proposed any alternative [snip] > 3.9(2) says: > For any complete POD object type T, whether or not the object holds a > valid value of type T, the underlying > bytes (1.7) making up the object can be copied into an array of char > or unsigned char.36) If the content of the array of char or unsigned > char is copied back into the object, the object shall subsequently > hold its original value. > > This has nothing to do with void* and char*, but rather with all > POD's. > > This clearly implies char arrays are stringently aligned. Err, no it doesn't. It says that you can store the bits of a POD object into a char array, and then load the bits back into the same (correctly aligned) POD object. It does *NOT* say that you can use the address of the char array as if it were the address of the POD object. For example: #include <assert.h> int main() { long pod = 3141L; char pad; char c[sizeof(pod)]; memcpy( c, &pod, sizeof(pod) ); pod = 42L; memcpy( &pod, c, sizeof(pod) ); assert (pod == 3141L); // 3.9(2) requires this assert to pass. // nothing requires THIS assert to pass, and on some systems it fail // because c is not suitable aligned. assert ( *reinterpret_cast<long*>(&c[0]) == 3141L ); return 0; } -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 3

thread library mutexes in Windows 95
by Jorge Lodos 11 Aug '05

11 Aug '05

Hi I'm trying to use the the boost::thread::mutex class in a Windows 95 project. Since the generated .lib files for the thread library include InterlockedCompareExchange (used in try_mutex::call_once) I was left with the option of adding the mutex.cpp and the exceptions.cpp files to my project and compiling them separately. Building the program included at the end, MSCV 7.1 gives the following linker errors: Compiling... Mutex.cpp Linking... mutex1.obj : error LNK2019: unresolved external symbol "void __cdecl boost::call_once(void (__cdecl*)(void),long &)" (?call_once@boost@@YAXP6AXXZAAJ@Z) referenced in function "bool __cdecl `anonymous namespace'::has_TryEnterCriticalSection(void)" (?has_TryEnterCriticalSection@?A0x5deb84cd@@YA_NXZ) mutex1.obj : error LNK2019: unresolved external symbol "int __cdecl boost::xtime_get(struct boost::xtime *,int)" (?xtime_get@boost@@YAHPAUxtime@1@H@Z) referenced in function "private: bool __thiscall boost::timed_mutex::do_timedlock(struct boost::xtime const &)" (?do_timedlock@timed_mutex@boost@@AAE_NABUxtime@2@@Z) Debug/Mutex.exe : fatal error LNK1120: 2 unresolved externals call_once is called in try_mutex constructor, while xtime_get is called in timed_mutex::do_timedlock. Nor try_mutex or timed_mutex are used at all. This was confirmed by commenting out the whole implementation for both in mutex.cpp, in which case the program links without problems. Just commenting out the lines m_critical_section = has_TryEnterCriticalSection(); in the try_mutex constructor and boost::xtime_get(&cur, boost::TIME_UTC); in timed_mutex::do_timedlock makes the program link. I originally expected the linker will remove all try_mutex and timed_muted implementation but it does not. Can someone give any ideas on how to use boost::mutex in a MSCV 7.1 project for Windows 95 without having to modify the original files? Is there a reason for the linker not to remove all the code for try_mutex and timed_mutex? Thanks in advance. Best regards Jorge #define BOOST_THREAD_NO_LIB #include <boost/thread/mutex.hpp> // mutex.cpp and exceptions.cpp compiled with // BOOST_THREAD_NO_LIB preprocessor option. // This must be enforced, since they both #include // <boost/thread/detail/config.hpp> int main(int argc, char *argv[ ]) { boost::mutex mymutex; boost::mutex::scoped_lock scoped_lock(mymutex); }

1 0

Boost regression notification (2005-08-11)
by Douglas Gregor 11 Aug '05

11 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-11T14:40:23Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

[1.33 RC2/serialization] New failures on Intel 8.1
by Stefan Slapeta 11 Aug '05

11 Aug '05

Hi, the latest changes seem to cause new failures on Intel 8.1 ("internal failure...") that are once again related to the buggy debug info generation in this compiler version. After investigating, I'm afraid I can't offer anything but to mark them as expected :-( Stefan

2 1

Re: [boost] alignment problem in proposed any alternative
by felipe 11 Aug '05

11 Aug '05

> Date: Thu, 11 Aug 2005 09:00:20 -0400 > From: christopher diggins <cdiggins(a)videotron.ca> > Subject: Re: [boost] alignment problem in proposed any alternative > To: boost(a)lists.boost.org > Message-ID: <004c01c59e74$a17a7800$2b792518@heronnest> > Content-Type: text/plain; format=flowed; charset=iso-8859-1; > reply-type=original > ----- Original Message ----- > From: "felipe" <pbr(a)taric.es> > To: <boost(a)lists.boost.org> > Sent: Thursday, August 11, 2005 4:09 AM > Subject: Re: [boost] alignment problem in proposed any alternative > >> Nope, this is totally wrong! chars and arrays of type char are >> generally >> the least aligned objects. You can demonstrate that this doesn't work >> with something like this: >> >> void blah() >> { >> char c[/* some number */]; >> any<8> a((double)1.0); >> std::cout << &a << std::endl; >> } > That code is completely misleading, yhe question is not what the address > of > a is! > Well, let me clarify: /*############ BEGIN ########*/ #include <iostream> #include <boost/type_traits.hpp> template<int buffer_size> struct any { char c; // this offsets buffer by one-byte.. because for the // compiler, chars only need byte alignment char buffer[buffer_size]; // ... template<typename T> any(const T& x) { if (boost::is_pod<T>::value && (sizeof(T) <= buffer_size)) { memcpy(buffer, &x, sizeof(T)); } else { // new and stuff } } }; int main(int argc, char **argv) { any<8> blah((double)1.0); std::cout << (void *)&blah.buffer << std::endl; return 0; } /*##### END ########*/ Output of the program on Pentium/Win2k/Visual C++ 6.0: 0x22ef01 This is obviously NOT a good place for a double, unless you are going to memcpy everything, which would be a needlessly inefficient design. Right, the Pentium lets me slide (with some extra instructions to keep away idle cycles), but don't try it on an Alpha! Have you not read the articles by Alexandrescu in CUJ? These are pretty old and yet they explore all of this stuff. What you should do is make the buffer a union of a minimal size object (e.g. your char array) and a minimum alignment object (e.g. a double in the example above). The compiler then adjusts alignment for the latter, while guaranteeing space for the former. Another thing, your proposal shies away from objects with constructors, etc. Why? You can use the placement new operator and get a much cleaner implementation. You know, something like this: template<typename T> any(const T& x) { .. new(&buffer[0]) T(x); // instead of memcpy hope this helps -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0