- Boost-users - lists.boost.org

[Multi-Array] Coercion to multi_array_ref from array_view?
by Jason Sewall 21 Sep '12

21 Sep '12

I'd like to have functions that can be passed references to arrays of a given storage type and rank. Take a look at the following code: template <class A> void foo_duck(A ma) { ma[0][1] = 1.0; } typedef boost::multi_array_ref<double, 2> ref_array_2d; void foo_ref(ref_array_2d ma) { ma[0][1] = 1.0; } int main() { typedef boost::multi_array<double, 3> array_3d; typedef boost::multi_array_types::index_range range; array_3d A(boost::extents[3][4][4]); array_3d::array_view<2>::type slice = A[boost::indices[1][range()][range()]]; foo_duck(slice); foo_ref(slice); return 0; } foo_duck works fine, but foo_ref does not; I get a compiler error (gcc 4.6.3, boost 1.47) like so: "error: could not convert ‘slice’ from ‘boost::multi_array<double, 3ul>::array_view<2ul>::type {aka boost::detail::multi_array::multi_array_view<double, 2ul>}’ to ‘ref_array_2d {aka boost::multi_array_ref<double, 2ul>}’" I suspect, without having looked at the code itself, that multi_array_ref was never designed to be coerced from array_view, but I don't understand why. Is there a solution to my foo_ref problem that doesn't involve moving all such functions to headers and templating them? Cheers, Jason

3 2

[Context] Building 32-bit Context?
by Nat Linden 21 Sep '12

21 Sep '12

Our product uses many third-party libraries, all built for 32 bits. On a couple platforms we still support users with 32-bit systems. We build our Boost libraries with address-model=32, which has so far worked (for the subset of libraries we use) even on 64-bit build systems. Now we would like to introduce Boost.Context. However, address-model=32 --with-context causes the Boost build to break on Mac OS X. Indeed, the Requirements page [0] for Boost.Context says: "Please note that address-model=64 must be given to bjam command line on 64bit Windows (boost-build issue)." Does the same boost-build issue affect Mac OS X? Is there a workaround for this boost-build issue? I don't think we can integrate Boost.Context any time soon if it would require converting everything to 64 bits. [0] http://www.boost.org/doc/libs/1_51_0/libs/context/doc/html/context/requirem…

2 9

Xcode 4.5 and boost 1.51.0 semantic issues with implicit conversions long to int
by Graham Reitz 20 Sep '12

20 Sep '12

Recently upgraded to Xcode 4.5 and boost 1.51 and started getting a pile of: /Users/grahamreitz/Development/src/libs/boost_1_51_0/boost/asio/detail/impl/socket_ops.ipp:952:20: Implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' ...warnings I'm guessing this is a 64 bit/32 bit issue. Should I be seeing these warnings out of the box?

1 0

[boost.org] Getting Started list of built libraries
by Nat Linden 20 Sep '12

20 Sep '12

Both Getting Started pages [0], [1] list libraries that must be built separately. With Boost 1.51, Boost.Context should be added to those lists. [0] http://www.boost.org/doc/libs/1_51_0/more/getting_started/windows.html#head… [1] http://www.boost.org/doc/libs/1_51_0/more/getting_started/unix-variants.htm…

1 0

[filesystem] using locales on Solaris with GCC
by JonathonS 20 Sep '12

20 Sep '12

Hi, I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem. Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :( This is very unfortunate because after looking through the boost filesystem code (boost/libs/filesystem/src/path.cpp), I found out that it creates a default locale by invoking std::locale("") (boost/libs/filesystem/src/path.cpp @ line 911) . Therefore, if my client sets the locale to anything but "C" or "POSIX", when it tries to create the default locale object via std::locale(""), it throws a runtime exception which crashes my program. So, my question is whether anyone knows of a work-around for this? I came up with one idea, but it seems very hackish. I can try to construct a boost::filesystem::path object and try to catch the exception thrown by std::locale(""). If the exception is thrown, I can set the environment variable to "C" or "POSIX" and continue with the program. My other idea is to manually patch boost::filesystem::path to use the following code to create the default locale. (again line 911 in path.hpp) try { use std::locale("") as the default locale; } catch ( std::runtime_error& ) { // We were unable to construct a locale, now use the global locale. use std::locale() as the default locale; } using std::locale() as the default will *always* succeed since it will just use whatever the current global locale is. My concern with this, is that I'll have to manually patch boost for this. Thanks, J

3 4

[boost.build] Problems getting PDB files withs DLLs
by Jonathan Jones 19 Sep '12

19 Sep '12

Hi all, I'm having problems getting PDB files built with the DLLs using Boost 1.49 and Visual Studio 2010. I have both debug-symbols=on and debug-store=database specified, but the PDB files are never built. Am I missing something? Thanks, Jon

1 1

(newbie) is_regular_file vs. symlinks in boost::filesystem ?
by Christian Convey 18 Sep '12

18 Sep '12

I'm writing code that takes a file pathname as a command-line argument. My program doesn't care whether the pathname is for a regular file, or if it's a symlink that ultimately leads to a regular file. This seems like such a common usage pattern that I would have expected Boost to have a built-in solution to this problem. But I don't see one. At the moment it looks like I'll have to write code like this: my_path = argv[1]; while (my_path is a symlink) { set my_path to the target of the symlink; error out of a cycle or excessive indirection is detected; } if (! is_regualr_file( my_path )) { tell user there's a problem; } Do I really need to write code like this?

2 3

using boost shared memory
by Dave Dyer 18 Sep '12

18 Sep '12

I'm contemplating using boost to implement inter process communication between a 32 bit process and a 64 bit process. I'm pretty sure there will be no problem at the raw bits level, but I suspect that if I attempt to use any of the higher order constructs, such as allocators or message queues, the disparate size of pointers will make hash of it. Does anyone have any experience (or advice) ?

1 0

Crash in boost::function destructor in my thread pool implementation
by Marcin Adamski 18 Sep '12

18 Sep '12

Hi I am trying to implement thread pool in C++ using pthread and boost::function as a wrapper for any function that client would like to call in the worker thread. I want to encapsulate logic related to threads management in one object which is taking ownership of these threads. That means whenever this object is destroyed, threads must be stopped and cleaned up. I've been testing my code and it turns out that I get segmentation fault when I destroy WorkerThreadManager object while there is boost::function processed in worker thread. See the code in attachment and backtrace from GDB below. I don't really understand why it happens, as far as I know boost::function is copyable, so once I get a copy of it from the queue, I can pop() it and even destroy whole queue (I prooved that in some small test) and then call the function's copy. So why is destruction of std::queue< boost::function<void() > causing problems? Or maybe it is something else. (gdb) bt #0 0xb7ad33a0 in ?? () from /lib/i386-linux-gnu/libc.so.6 #1 0x0807d3a7 in boost::function0<void>::clear (this=0x858db48) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:856 #2 0x0807d17b in boost::function0<void>::~function0 (this=0x858db48, __in_chrg=<optimized out>) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:752 #3 0x0807cec5 in boost::function<void()>::~function(void) (this=0x858db48, __in_chrg=<optimized out>) at /home/marcin/intel_build/boost_1_42_0/boost/function/function_template.hpp:1043 #4 0x0807ced8 in std::_Destroy<boost::function<void ()> >(boost::function<void ()>*) (__pointer=0x858db48) at /usr/include/c++/4.6/bits/stl_construct.h:94 #5 0x0807c868 in std::_Destroy_aux<false>::__destroy<boost::function<void ()>*>(boost::function<void ()>*, boost::function<void ()>*) (__first=0x858db48, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:104 #6 0x0807bd05 in std::_Destroy<boost::function<void ()>*>(boost::function<void ()>*, boost::function<void ()>*) (__first=0x858d938, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:127 #7 0x0807af23 in std::_Destroy<boost::function<void ()>*, boost::function<void ()> >(boost::function<void ()>*, boost::function<void ()>*, std::allocator<boost::function<void ()> >&) (__first=0x858d938, __last=0x858d928) at /usr/include/c++/4.6/bits/stl_construct.h:153 #8 0x0807a037 in std::deque<boost::function<void ()>, std::allocator<boost::function<void ()> > >::_M_destroy_data_aux(std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>) (this=0x858beec, __first=..., __last=...) at /usr/include/c++/4.6/bits/deque.tcc:795 #9 0x08076153 in std::deque<boost::function<void ()>, std::allocator<boost::function<void ()> > >::_M_destroy_data(std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::_Deque_iterator<boost::function<void ()>, boost::function<void ()>&, boost::function<void ()>*>, std::allocator<boost::function<void ()> > const&) (this=0x858beec, __first=..., __last=...) at /usr/include/c++/4.6/bits/stl_deque.h:1816 #10 0x08073411 in std::deque<boost::function<void()>, std::allocator<boost::function<void()> > >::~deque(void) (this=0x858beec, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_deque.h:898 #11 0x0806a355 in std::queue<boost::function<void()>, std::deque<boost::function<void()>, std::allocator<boost::function<void()> > > >::~queue(void) (this=0x858beec, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_queue.h:92 #12 0x0815a054 in WorkerThreadManager::~WorkerThreadManager (this=0x858be98, __in_chrg=<optimized out>) at WorkerThreadManager.cpp:42 #13 0x0815a1e3 in WorkerThreadManager::~WorkerThreadManager (this=0x858be98, __in_chrg=<optimized out>) at WorkerThreadManager.cpp:56 #14 0x080c6c51 in std::auto_ptr<WorkerThreadManager>::reset (this=0x85463e4, __p=0x0) at /usr/include/c++/4.6/backward/auto_ptr.h:244 #15 0x080604a9 in main () Regards Marcin Adamski

2 2

[ANN] ODB C++ ORM 2.1.0 released, adds support for Uuid, Multi-Index
by Boris Kolpackov 18 Sep '12

18 Sep '12

Hi, I am pleased to announce the release of ODB 2.1.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. Major new features in this release: * Ability to use accessor/modifier functions and expressions to access data members. In most cases ODB is capable of discovering suitable accessor/modifier functions automatically. * Support for virtual (imaginary) data members that can be used to handle the C++ pimpl idiom as well as aggregate or dis-aggregate real data members. * Ability to define database indexes on data members. Multi-member indexes as well as indexes with database-specific index types, methods, and options are supported. * Support for mapping extended database types, such as geospatial types, user-defined types, collections (arrays, table types, etc.), key-value stores, XML, JSON, etc., to suitable C++ types. * The Boost profile library now provides persistence support for the Uuid and Multi-Index container libraries. * The Qt profile library now provides persistence support for the QUuid type. * Support for generating single (combined) database schema file from multiple C++ header files. This release also adds support for Visual Studio 2012 and Clang 3.1. Specifically, all the runtime libraries, examples, and tests now come with project/solution files for Visual Studio 2012 in addition to 2010 and 2008. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/09/18/odb-2-1-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000018.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12, and Clang 3.1. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0