- Boost-users - lists.boost.org

Select outer face for "Chrobak-Payne Straight Line Drawing"
by jakob brandt 19 Apr '11

19 Apr '11

Hello, I'm a boost-newbie and don't know excactly where to post my question - not only because I have some trouble with my English… sorry for that. My Problem is: I have builded some graphs which always can be drawn with an outer face consisting of 3 certain vertices. Now I am trying to find out if it is possible to select the vertices for the outer face in the Chrobak-Payne Straight Line Drawing. Because if I dont, the drawing-algorithm finds other vertices to set the outer face. Could someone tell me if this was possible without a hugh affort and maybe help me with it? (My cpp-skills arent the best :( … to play things down) I would be very thankfull and happy for any advise or help. Best wishes Jakob

1 0

[system] Dynamic error message with context (like MySQL client API)
by Lian Cheng 19 Apr '11

19 Apr '11

Hi, everyone, I'm writing a MySQL client API wrapper with Boost.Asio and Boost.System. And I want to encapsulate all MySQL error codes with boost::system::error_code. But I found out that error messages corresponding to a specified error code value is designed to be unique within Boost.System, which retrieves the error message from the `message()' method of corresponding boost::system::error_category subclass. MySQL provides an API mysql_error, which accepts a connection handle and returns the error message of the last error on this connection. Also, the content of the error message is dynamic. So here is my question: is there any way to provide context related rather than static error messages with Boost.System? Any reply would be appreciated! Cheers Lian

1 0

Creating interprocess::shared_ptr across processes
by GxL 18 Apr '11

18 Apr '11

Hi all, I've been looking into the "boost::interprocess" library to use shared memory the resides in a non-paged physical memory facilitated by RTX (Real-time Windows extension). According to my understanding it's best to use "managed_external_buffer". I have managed to create the shared memory and create and share objects using raw pointers. I would however prefer using smart_ptr that is offered by the boost::interprocess. The problem I'm having is that I can create the shared pointer for any shared object in one process but when I want to create it's counter-part in the other process, it does not share the "share_count" with the original shared_ptr in the first process. For instance I tried to share a list of integers. So I used the interprocess::list as "named" object and once I crated it (following that "interprocess" documentation) I placed that pointer into a interprocess::shared ptr that I created using the helper function "make_managed_shared_ptr". Now in another process I am able to get hold of the raw pointer to that same list by looking up by the name but cant figure out (did lots of searches about this to no avail) how to instantiate an interprocess::shared_ptr such that it would get the same shared_count object. When I use the "make_managed_shared_ptr" and pass in the raw pointer to the shared object it will create one but with a new "shared_count" which is obviously bad. First I thought that the "make_managed_shared_ptr" is able to resolve and find the already existing "shared_count" and link to that but figured it wasn't the case. Then I thought maybe I need to instantiate the shared_ptr as a named object and then retrieve the same object in another process but can't see the "make_managed_shared_ptr" would support such concept. Then I thought maybe the pre-implemented interprocess shareable types (e.g. vector, list, etc.) derive from "enable_shared_from_this" so I could just call the shared_from_this on the retrieved raw pointer to retrieve the shared_ptr that will be guaranteed to share the "shared_count". None of the above yielded the desired results. I didn't find (by googling) anybody talking about the process of creating a shared_ptr (using the helper method of "make_managed_shared_ptr") across the process so I assume that probably is clear and is able to achieve the mentioned results and I must be missing something awfully obvious. Can somebody please advise on how to achieve this? I am loath to just jump and implement my version of "make_managed_shared_ptr" unless I really have to and I'm sure it's designed to work across the processes. Thanks a in advance for help and guidance. Kind regards gxl

2 2

Re: [Boost-users] [filesystem] std::bad_alloc during dll initialization when migrating to filesystem v3
by Richard Ulrich 18 Apr '11

18 Apr '11

I can not reproduce the behavior with a toy project containing 3 dlls that all use boost::filesystem. It might be some incompatibility with another library. But with filesystem v2 it works. So, what should I look for. I searched google extensively for std::bad_alloc during dll initialization, but found no solution so far. Rgds Richard > Date: Wed, 13 Apr 2011 16:51:41 +0200 > From: Richard Ulrich <richi(a)paraeasy.ch> > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [filesystem] std::bad_alloc during dll > initialization when migrating to filesystem v3 > Message-ID: <1302706301.2665.13.camel@one> > Content-Type: text/plain; charset="us-ascii" > > Hi Guys, > > I'm currently migrating our system consisting of multiple dll's and and > executable to filesystem v3. > The first two dll's that use boost::filesystem load ok, but the third > fails with std::bad_alloc in the locale copy constructor called from > default_locale during the construction of dot_path. > > I don't know if it's relevant, but we usually work with char while > filesystem uses wchar_t for BOOST_WINDOWS_API > > Rgds > Richard

3 3

[Serialization] creating an archive fails under GCC-4.6.0
by doug livesey 18 Apr '11

18 Apr '11

Hi -- I have some code that runs when compiled with GCC-4.2 (on OSX Snow Leopard), but that throws the following error with my fresh compile of 4.6.0: run_features(2872) malloc: *** error for object 0x100502060: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug The line that creates this error is here, on line 24: https://gist.github.com/923262 (Apologies for any egregious code abuses in there, I'm just learning!) In the debugger, it lets me step from that line to the constructor of xml_oarchive (line 114 of xml_oarchive.hpp), and when I try to step any further, I get this: run_features(2885) malloc: *** error for object 0x100501b00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT, Aborted. 0x00007fff871a95d6 in __kill () Could anyone advise me on what I could do to fix this? I really want to be working with GCC 4.6.0 and the boost serialisation libraries. Incidentally, I reinstalled boost after I installed the latest GCC (with homebrew), and I'd set cc, gcc, and g++ symlinks to GCC-4.6.0 before I did that, so boost should be compiled with the latest. Thanks very much for any & all assistance. Doug.

3 3

Boost asio lib question: async_accept and EBADF
by olegb＠it-forces.com 18 Apr '11

18 Apr '11

Cheers, I have a question regarding handling error bad file descriptor in asio async_accept. Standard example doesn't expose whether it's fatal or not. If I understand correctly bad_descriptor error is not fatal here, like it would be for usual POSIX accept() call, and we should continue accepting new incoming calls, no? void handle_accept(tcp_connection::pointer new_connection, const boost::system::error_code& error) { if (!error) { new_connection->start(); start_accept(); } } e.g. if (!error) { new_connection->start(); start_accept(); } else if (error == bad_descriptor) { start_accept(); } -- King regards, Oleh

1 0

Pimpl framework comments/suggestions
by Clinton Mead 18 Apr '11

18 Apr '11

Hi All I've been experimenting with pimpl recently. What I've seen written about the pimpl idiom is that you have an interface class and an implementation class, and in the interface class you put some kind of pointer to the implementation. However, I thought, sometimes you might want that to be a shared pointer. Or an intrusive pointer. Or unique pointer. Or maybe sometimes you might decide not to use pimpl at all. I thought it was a bit silly that you had to make these decisions at the time you create the interface class. I thought it would be nice if you could write the interface independent of how it was going to be connected to the implementation, and then hook them together however you like. So this is what I've done. Basically I've broke things up into three separate parts: (1) Interface (2) Implementation (3) What joins them together (i've created unique_pimpl and shared_pimpl as examples) I've implemented a unique_ptr and shared_ptr pimpl implementations as examples. The idea is that you can basically do this: unique_pimpl<interface, impl>::create(...) or shared_pimpl<interface, impl>::create(...) make_your_own<interface, impl>::create(...) for any interface and implementation you choose. I've included all the code in a question at http://stackoverflow.com/questions/5666442 but it doesn't seem to be getting much attention there, so I thought I'd bring it up on this list. If something like this isn't in Boost, and people like it, with a bit of help I'd be happy to work on it to get it into Boost. Alternatively I'm happy for someone else to Boostify this. I've used a bit of c++0x in the code, gcc 4.4.5 will compile it though. However if I'm just (badly) reinventing the wheel, if someone could direct me to where this has already been done that would be good to. Thanks Clinton

2 5

filesystem v3, unicode and std::codecvt linker error
by archie14 18 Apr '11

18 Apr '11

I am porting the code from (boost44, msvc2008, Qt, unicode support) to (boost46, msvc2010, Qt, unicode support). I am getting following linker error: error LNK2001: unresolved external symbol "private: static class std::codecvt<unsigned short,char,int> const * & __cdecl boost::filesystem3::path::wchar_t_codecvt_facet(void)" (? wchar_t_codecvt_facet@path@filesystem3@boost@@CAAAPBV?$codecvt@GDH@std@@XZ) I found that std::codecvt defined in <xlocale>. May be the filesystem lib should be built in certain way to support widestrings? Any advise/help will be greatly appreciated.

1 1

[system] static linking + static member in y a dynamic design
by Amoriello Hutti 17 Apr '11

17 Apr '11

Hi everyone, I am facing a "design" issue while sharing error_codes across modules boundaries. Has I understand the design, error_categories like "generic_error_category" are static (maybe to provide unique way to represent error_category, avoiding error_category ID confilct, and allowing users to extend with there own categories). The question is : How can we share error_code across modules (A and B), when these modules are both statically linked with there own boost::system library (same version)? Under Windows operating system, both static version of boost::system library co-exist in the same process address space (that contains module A and module B), they do not share code or static data members. Comparison between error_code is made by looking error_value and error_category, but error_categroy doesn't has the same "static" address, causing comparison to fail, even when the semantic is respected (because of the co-existing static error_category with different address). sharing the boost::system has a unique shared library used by both module A and B could solve this issue, but this solution is not suitable for certain needs. Thanks for your help! -- Amoriello Hutti

1 0

[phoenix][accumulators] Is is possible to use phoenix v3 and accumulators in parallel?
by alfC 17 Apr '11

17 Apr '11

Hi, Last week I started a thread called "[Boost-users] [phoenix][spirit] Is is possible to use phoenix v3 and spirit in parallel? " . While that issue seems under control, now I found a compatibility problem between accumulators and phoenix 3. #include <boost/phoenix/phoenix.hpp> //#include <boost/spirit/home/ phoenix.hpp> #include<boost/accumulators/accumulators.hpp> #include<boost/accumulators/statistics/min.hpp> int main(){ return 0; } gives an error boost/accumulators/numeric/detail/function_n.hpp:83:1: error: ‘apply12’ in namespace ‘boost::mpl’ does not name a type I tried predefining certain macros but it didn't work: #define BOOST_SPIRIT_USE_PHOENIX_V3 #define BOOST_PROTO_MAX_ARITY 11 #define BOOST_PROTO_MAX_LOGICAL_ARITY 11 #define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 12 Is there a workaround? Thank you, Alfredo

1 0