- Boost - lists.boost.org

stack-allocated STL-containers
by Stefan Strasser 13 Aug '09

13 Aug '09

I recently ran into the problem that a local container on the stack, which was likely to be very small, but its size was still not known at compile-time, consumed a considerable amount of runtime because of allocation/deallocation. e.g. void do(istream &i){ vector<int> vec; vec.reserve(20); while(...){ int tmp; i >> tmp; vec.push_back(tmp); } } so I wrote an allocator that I think is generally useful and could be added e.g. to Boost.Array: void do(int n){ int buffer[20]; stack_allocator<int,20> alloc(buffer); vector<int,stack_allocator<int,20> > vec(alloc); vec.reserve(alloc.max_stack_size()); while(...){ int tmp; i >> tmp; vec.push_back(tmp); } } the vector operates on the stack as long as there is enough space, and moves to the heap afterwards. in most cases there is no dynamic allocation. here's the source: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=stack_… it uses the simple_seq_fit allocation algorithm described here: http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/allocators_conta…

4 5

Generic copy-on-write infrastructure in boost?
by Jason Dictos 13 Aug '09

13 Aug '09

Hi, I'm looking for a way to implement a project using some copy-on-write feature, similar to how STL strings use reference counters to prevent needles copying of data. Is there anything in boost to help me out with this? -Jason ---------------------------------- Check out the Barracuda Spam & Virus Firewall - offering the fastest virus & malware protection in the industry: www.barracudanetworks.com/spam

5 7

[Serialization] Bizarre bug
by Jarl Lindrud 12 Aug '09

12 Aug '09

There is a rather bizarre bug in Boost.Serialization, that was reported on this list three years ago: http://article.gmane.org/gmane.comp.lib.boost.devel/147010/match=serializat… +bizarre+bug To sum up, a piece of code that is never even executed, is causing a serialization error in a different part of the program. Unfortunately it seems that this bug was never fixed - I just tried it on Boost 1.39.0, and the bug is still there. Any chance something can be done about it? For reference, here is the sample program that reproduces the issue: #include <sstream> #include <string> #include <vector> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/vector.hpp> template<typename Archive> struct X { template<typename T> void operator<<(const T &t) { Archive &archive = (*(Archive *) NULL); archive << t; } }; void dummy() { typedef boost::archive::text_oarchive Archive; X<Archive> &x = * (X<Archive> *) NULL; std::vector<char> *pt = NULL; // uncomment this line to cause the test in main() to fail //x << pt; } int main(int argc, char* argv[]) { std::vector<char> v0(25, '%'); std::vector<char> v1; std::ostringstream ostr; boost::archive::text_oarchive(ostr) & v0; std::istringstream istr(ostr.str()); boost::archive::text_iarchive(istr) & v1; bool ok = (v0 == v1); return 0; }

7 35

[mpl] strange vector_c and integral_c construction
by Maxim Yanchenko 12 Aug '09

12 Aug '09

Hi all, > Probably this is well-known and I just failed to find it in the docs and mailing list. According to the docs (http://www.boost.org/doc/libs/1_39_0/libs/mpl/doc/refmanual/integral-sequen…) typedef seq_c<T,c1,c2,... cn> s; Semantics: s is a sequence seq of integral constant wrappers integral_c<T,c1>, integral_c<T,c2>, ... integral_c<T,cn>. Consider the following example: const int64_t max_int = integer_traits<int>::const_max; const int64_t max_int_plus_1 = max_int + 1; BOOST_MPL_ASSERT(( equal< vector_c< int64_t, 1 > , vector< integral_c< int64_t, 1 > > > )); BOOST_MPL_ASSERT(( equal< vector_c< int64_t, max_int > , vector< integral_c< int64_t, max_int > > > )); BOOST_MPL_ASSERT(( equal< vector_c< int64_t, max_int_plus_1 > , vector< integral_c< int64_t, max_int_plus_1 > > > )); The first assert passes, while the second and third fail with the following error messages (removed repetition of 2147483647l for readability): test.h:149: error: ************mpl::equal<mpl::vector_c<int64_t, 2147483647l, 2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t, 2147483647>>, is_same<true> >::************' test.h:153: error: ************mpl::equal<mpl::vector_c<int64_t, -0x00000000080000000l, 2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t, 2147483648ll>>, is_same<true> >::************' I consider these errors as a contradiction to the docs statement. Probably, I configured MPL wrong, as I see in the preprocessed code, where long is used (boost/mpl/aux_/preprocessed/gcc/vector_c.hpp) template< typename T, long C0 = LONG_MAX, long C1 = LONG_MAX, long C2 = LONG_MAX , long C3 = LONG_MAX, long C4 = LONG_MAX, long C5 = LONG_MAX , long C6 = LONG_MAX, long C7 = LONG_MAX, long C8 = LONG_MAX , long C9 = LONG_MAX, long C10 = LONG_MAX, long C11 = LONG_MAX , long C12 = LONG_MAX, long C13 = LONG_MAX, long C14 = LONG_MAX , long C15 = LONG_MAX, long C16 = LONG_MAX, long C17 = LONG_MAX , long C18 = LONG_MAX, long C19 = LONG_MAX > struct vector_c; I'm using GCC 3.4.6, on Linux-64, compiling 32-bit binary (so int and long are of same size, and boost::int64_t is bigger than long). Thanks, Maxim (to reply in private, please use FirstName.LastName at gmail.com)

4 4

Microsoft Security Bulletin MS09-03: Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution (969706)
by Christian Eckstein 12 Aug '09

12 Aug '09

Hi, I need to know the impact of the following security bulletin on Boost: Microsoft Security Bulletin MS09-03: Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution (969706). I found usage of ATL only in the range and regex libraries and it seems that only string and array classes are used. None of the problematic methods seem to be used that are described in the checklist at http://msdn.microsoft.com/en-us/visualc/ee309358.aspx. - No class implements IUnknown so there is no ActiveX control. - No PROP_* macros are used - VT_* is not used - ReadFromStream is not used I think no modification of Boost and no recompilation of the Boost binaries is needed. I would be very happy if somebody could confirm this. Kind regards, Christian

2 1

persistence library proposal (with prototype implementation)
by Stefan Strasser 12 Aug '09

12 Aug '09

Is there any interest to include a persistence library in boost, built upon the boost serialization library? the basic idea is: transaction tx; change_objects(); tx.commit(); all changes made by change_objects() should be undone if tx is destroyed without calling commit(), e.g. because of an exception thrown by change_objects(). the library should provide ACID transaction properties, so that multiple transactions (in different threads) can work on the same objects and conflicts are discovered by the library. further, an application crash should be recovered, with the changes made by a transaction either committed as a whole or undone. to partition your object model into many different objects, which can be saved to disk and loaded back on demand, there is a new smart pointer introduced, which behaves like smart_ptr and is convertible to smart_ptr. objects that are handled by this smart pointer and are no longer used in memory are not destroyed but saved to disk. only objects which are no longer in use either in memory or on disk are destroyed. the only requirement on persistent objects would be to model the concept "Serializable" as defined by boost serialization. e.g. a linked list, whose elements are loaded from disk on demand could look like: struct node{ db_ptr<node> next; private: //Serializable requirements }; void traverse(){ while(current) current=current->next; //operator-> loads the next node } prototype implementation --- i've attached a test case using the current implementation. it demonstrates multiple concurrent transactions.running isolated from each other. it models a bank, with multiple threads constantly withdrawing from one (random) bank account and depositing the amount on another. when two threads are using the same bank account at the same time, resulting in money being lost, an isolation_exception is thrown in one of the threads and the transaction can be restarted. there is no manual thread synchronization involved. the current implementation uses an optimistic multiversion approach, meaning that each transaction running concurrently is working on its own copy of an object. when the transaction is committed conflicts are discovered and an isolation_exception is thrown. several things like reference counting on disk and the recovery process after a crash aren't implemented yet, but the basics are in place and should give you an idea of what kind of a library I'm proposing.

4 12

different matrix library?
by DE 12 Aug '09

12 Aug '09

hi i'm new to boost so please don't blame me the question is do you need a matrix library which allows you to write clear, human readable code like dV = (1/m)*force + transpose(A)*g - cross_product(omega, V) //here dV is a derivative of velocity, m is (scalar) mass //A is transition matrix and //g is gravity acceleration vector //omega is angular velocity and V is velocity vector itself //force is defined in body space (e.g. aerodynamics and thrust) that is an expression of newton's 2nd law (or if you like 'change in momentum' law: d(m*V)/dt = d_local(m*V)/dt + (omega)x(m*V) = sum_of(forces) as you can see so far i'm a math nerd) of course it must be implemented through lazy evaluation technique (which immediately implies expression templates) ps i looked at uBLAS and the design seemed obsolete to me so i thought there could be a better approach then blindly following blas design pps thanks for reading til here and forgive for (possibly) wasting your time

9 39

[Interprocess] Possible bug in shared memory on FreeBSD 8.0
by Manish Vachharajani 11 Aug '09

11 Aug '09

I've been happily using Boost.Interprocess to create shared memory regions under FreeBSD 7.2, however, I am having issues on FreeBSD 8.0 pre-release. I can reproduce the problem with Boost 1.39.0 and the svn trunk. The source of the problem appears to be that Boost.Interprocess calls lseek on a file descriptor returned by shm_open, but the results of such an lseek are undefined. Below, I explain further how I came to this conclusion. If you run the program I've appended to the end of this email, the constructor for managed_shared_memory throws an interprocess_exception with error code 29 which is Illegal Seek on FreeBSD. A little bit of system call tracing and debugging reveals that the offending seek is in mapped_region.h:447 (in svn revision 55512). However, digging around, it appears that lseek's behavior on file descriptors for shared memory regions is undefined (See http://www.opengroup.org/onlinepubs/000095399/functions/lseek.html for what IEEE 1003.1 standard has to say about this.) I've confirmed that FreeBSD 7.2 allowed such seeks but 8.0 does not by looking at the kernel source code. For what it's worth AIX 6.1 does not allow such seeks either (see http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.a…) Could someone advise me on what the correct fix for this bug is? I'd be glad to implement it, but I'm not sure what the right fix ought to be. #include <iostream> #include <string> #include <exception> #include <boost/interprocess/managed_shared_memory.hpp> namespace bip = boost::interprocess; int main(const int argc, const char *argv[]) { bool error = true; std::string shmName("testShmRegion"); bip::shared_memory_object::remove(shmName.c_str()); try { std::auto_ptr<bip::managed_shared_memory> segment(new bip::managed_shared_memory(bip::create_only, shmName.c_str(), 12345)); error = false; } catch(const std::exception &e) { std::cerr << "Error: " << e.what() << std::endl; } if(!error) { std::cout << "Shm allocated successfully." << std::endl; } return 0; } Manish

3 9

[asio] very confusing title
by DE 11 Aug '09

11 Aug '09

when i personally see 'asio' i immediately think about steinberg technology asio which stands for 'audio stream i/o' so it's up to you of course just want you to know

4 3

Vault access for Boost.Debug
by Zachary Turner 11 Aug '09

11 Aug '09

Hello, I'd like to request access to the vault. I'm going to upload a proof-of-concept of some of the things I mentioned earlier in my thread about Boost.Debug. This early version gives simple stack traces in limited scenarios, only supports Windows, and isn't designed very well. Here's an example of a program using it in its current form: void test_func(int argc, int argc2, char* argv[]) { stack_trace trace(10); //Maximum depth of 10 levels std::cout << trace.string() << std::endl; } int main(int argc, char* argv[]) { test_func(argc, argc, argv); return 0; } and an example of the stack trace printed as a result of this program: void test_func(int, int, char**) [f:/dev/stack_trace/main.cpp:10] int main(int, char**) [f:/dev/stack_trace/main.cpp:23] int __tmainCRTStartup() [f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:406] int mainCRTStartup() [f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:389] It also currently supports printing the names of all the arguments, but it was hackish and I left it out until it undergoes some redesign. There is currently no documentation, but as this is just a proof of concept I'm currently only looking for people to help out with actual code and/or provide input, so I think that's ok for now. Thanks

5 6