- Boost-users - lists.boost.org

Python/C PyRun_String
by Venkatraman S 29 Mar '08

29 Mar '08

Hi All, Am using Pythong/C API for embedding. I have written a small-simple wrapper that does the low level functions and exposes the functionalities in a c++ style(i.,e the application layer doensnt use 'PyObject'). I am reading the contents of a file(Python script) and am running the same using PyRun_String; the script setups some variables in the Main Dict which i access it using the PyArg_Parse...etc etc(the standard way). This keeps running in a loop - i.,e it needs to be processed for every transaction - hence the Python wrapper is a singleton which preserves the main dict. Am stumbling on a problem wherein when i try to access a variable in Python from C as a string - this variable in python was constructed by concatenating a float with a string(using 'str'), and hence the resulting python variable is also a string. If i comment out the variable , then the program runs fine; else it(C program) throws out a segmentation fault. A clueless as to how to debug this and suitable hints would be immense help. (If required , i can share the code for this - i just didnt want to send it here) Secondly, can anyone point me to the Boost::python way of embedding - basically, i would like to know how to build/compile the program without using bjam. Regards, -- Venkat Blog @ http://blizzardzblogs.blogspot.com

1 0

boost.program_options or boost bjam build issue
by Dan Pieczynski 28 Mar '08

28 Mar '08

I had rebuilt my library using bjam because I needed a 32 bit Linux build(while on a 64 bit machine). I built the libraries and linked them into my project. I was attempting to use my local boost files, but I get an error referring to another boost include directory which is a different version. I don't specify the path being referred to in my link steps anywhere, so I'm assuming my build with bjam didn't specify a necessary define. The error I see is: main.o(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcEC1EiPPc+0x53): In function `boost::program_options::basic_command_line_parser<char>::basic_command_line_parser(int, char**)': /usr/include/boost/program_options/detail/parsers.hpp:42: undefined reference to `boost::program_options::common_command_line_parser::common_command_line_parser(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)' Where it refers to /usr/include/boost/program_options/detail/parsers.hpp while my intent was to use BOOST_ROOT=/home/dpieczynski/opt/libs/BOOST/boost_1_34_1/lib32 To build the library I defined BOOST_ROOT, then ran "./configure -prefix=lib32 -includedir=/home/dpieczynski/opt/libs/BOOST/boost_1_34_1" The library was then built with: bjam cxxflags=-m32 linkflags=-m32 cflags=-m32 architecture=x86 address-model=32 -d2 link=shared --prefix=lib32 threading=multi debug install -a What needs to be done to prevent the reference to /usr/include/boost? Thanks for your time and help. Dan Pieczynski _______________________________________________________ The information in this email or in any file attached hereto is intended only for the personal and confiden- tial use of the individual or entity to which it is addressed and may contain information that is propri- etary and confidential. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communica- tion is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product. Email trans- mission cannot be guaranteed to be secure or error- free. P6070214

2 2

variant comparison operators
by Jiri Palecek 28 Mar '08

28 Mar '08

Hello, is there some deep reason why comparing variant to a nonvariant is disabled? For example: variant<int, string> v=1; assert(v==1); // doesn't compile The problem is that there are overloads for anything else than a variant, which explicitely fail to compile (via static_assert and other means). If they weren't there, everything would work (the comparison would invoke conversion constructor, and then normal variant/variant comparison. Another problem is that variant includes the == operator, but not !=, even though this could be easily achieved with boost::operators. I can send patches if that would help. Regards Jiri Palecek

2 1

Asio deadline_timer does not work when io_service::run is called from a Python thread.
by Eric Newhuis 28 Mar '08

28 Mar '08

Dr. Egon Spengler: There's something very important I forgot to tell you. Dr. Peter Venkman: What? Dr. Egon Spengler: Don't cross the streams. Apparently my deadline_timers don't work when I call io_service::run from python on Linux. Has anyone encountered this and worked around the problem?

1 1

Re: [Boost-users] nondynamic: A utility class that promotes safe programming
by Daniel Lidström 28 Mar '08

28 Mar '08

Ovanes wrote: [snip] > What do you think how this allocator will allocate the number > of these element? Actually in any possible way. > It can use new[] or new char[sizeof(T)*NumElems] or use an > own mem-manager. And the worse thing you can't make > allocator friend of your class, since users of containers can > pass their own allocators. > And despite all enumerated facts you will fail to compile, > since the function address will fail to return the pointer to > x, because it is prohibited in your case. Yes, well boost::noncopyable also prohibits something :-) The whole intent of nondynamic is to prohibit (or make difficult) dynamic allocation/pointer usage. Do you think boost::noncopyable has a valid purpose, but nondynamic is less useful? -- Daniel

4 3

Re: [Boost-users] nondynamic: A utility class that promotes safe programming
by Daniel Lidström 28 Mar '08

28 Mar '08

Hello Ovanes, Ovanes wrote: > Hello Daniel, > > I thought about such a class as well. The main disadvantage of it > is that it is impossible to use with standard containers. :( > Standard containers (e.g. std::vector) pre-allocate space for > some number of instances and use the placement new operator to > place items in the pre-allocated memory and when deriving form > nondynamic makes it impossible. As I understand it, the standard containers use the global placement new, which cannot be overridden. These lines are actually ok to do it seems: char dataIOBuffer[sizeof(DataIO)] = {0}; DataIO* inplaceCreated = ::new(dataIOBuffer)DataIO(IDataIOPtr()); Regardless of where I place (no pun intended) the placement new operator in nondynamic. -- Daniel

3 2

Re: [Boost-users] object relational mapping library
by Pavlo Korzhyk 28 Mar '08

28 Mar '08

> Very cool indeed! > > However, from a quick glance at your tutorial, it seems you could have > folded this back into Boost.Serialization by writing a sqlite3 archive. > Is there some reason you chose not to do this? The main reason is the difference between "serialization" and "persistence". Boost.Serialization is not designed for "random access" to the data files. Consider a situation when you store several structs in one XML file. Serialization doesn't provide you any means to edit or at least extract only one specific element. All you can do is load the whole file, update some entries and write the whole set back to disc. You can build your own persistence solution on top of Boost.Serialization, but you have to do it yourself. And hiberlite is a persistene library - the main idea is to provide the smart pointers to objects inside the SQLite database. We really need some sort of SQL support in Serialization, but I don't see any good way to integrate features like primary keys, queries, tables metamodel, etc. So simply adding some sqlite output will look like a new file format, and that's not what RDBMS software is built for. But I agree, an idea of sqlite3_archive is very attractive, and also very challenging. http://code.google.com/p/hiberlite/ Yours sincerely, Pavlo Korzhyk ICQ#155870780

1 0

Need help with boost.variant and apply_visitor method overloading.
by Kevin Scarr 28 Mar '08

28 Mar '08

Hi I am trying to implement a system for ensuring producers and consumers agree on the data type they are exchanging. However, I also have "general" containers which can send or receive anything (mainly routing components). Anyway, I have tried to setup the following code to implement this scheme, however When I compile code (on MSVC 2005), I see the following error: Error 1 error C3066: there are multiple ways that an object of this type can be called with these arguments; unable to recover from previous error(s); stopping compilation c:\boost-1_34_1\boost\variant\detail\apply_visitor_binary.hpp 63 I have tracked it down to the first two overloads where I am trying to connect a consumer/producer of a specific type to a general producer/consumer. What am I doing wrong? The compiler obviously thinks that it can cast a (for example) G2Consumer<t1>* into a G2Consumer<DataTypes>*, so it cannot resolve which overload to use. How can I tell it not to cast?? Thanks for your help, Kevin typedef boost::variant<t1*,t2*,t3*> DataTypes; typedef boost::variant< G2Consumer<t1>*, G2Consumer<t2>*, G2Consumer<t3>*, G2Consumer<DataTypes>* > G2ConsumerTypes; typedef boost::variant< G2Producer<t1>*, G2Producer<t2>*, G2Producer<t3>*, G2Producer<DataTypes>* > G2ProducerTypes; class doConnectConsumerToProducer : public static_visitor<> { public: template<typename T> void operator() ( G2Consumer<DataTypes>* consumer, G2Producer<T>* producer ) const { consumer->RegisterAsConsumer( *producer ); } template<typename T> void operator() ( G2Consumer<T>* consumer, G2Producer<DataTypes>* producer ) const { consumer->RegisterAsConsumer( *producer ); } template<typename T> void operator() ( G2Consumer<T>* consumer, G2Producer<T>* producer ) const { consumer->RegisterAsConsumer( *producer ); } template<typename C, typename P> void operator() ( G2Consumer<C>* consumer, G2Producer<P>* producer ) const { G2Base* c = dynamic_cast<G2Base*>(consumer); G2Base* p = dynamic_cast<G2Base*>(producer); std::ostringstream msg; msg << "Incompatible consumer(" << typeid(*c).name() << ") and producer(" << typeid(*p).name() << ") types" << std::ends; throw G2::exception( msg.str().c_str() ); } }; // Helper function to drive this above. void connectConsumerToProducer( G2ConsumerTypes& c, G2ProducerTypes& p ) { apply_visitor( doConnectConsumerToProducer(), c, p ); }

2 1

variant cast operators?
by Daniel Oberhoff 28 Mar '08

28 Mar '08

Hi, I am playing with boost::variant to introduce a more elegant property system into my current project. I was wondering why there are no cast operatorst defined for the variant types, to avoid having to type get<>: boost::variant<double,int,string> v; string s = v; is there a basic reason why this is not possible? Best Daniel

2 1

[statechart] post_event() and Boost.Bind
by Commander Pirx 28 Mar '08

28 Mar '08

Currently I don't understand why the following code dosn't compile (with VC 8.0). I simply try to bind the post_event() method from the state_machine to a function object. To illustrate the problem I've added the following code to the Camera.hpp file of the Camera example from the Statechart library: #include <boost/function.hpp> #include <boost/bind.hpp> <snip> struct Camera : sc::state_machine< Camera, NotShooting > { // @test start typedef boost::function< void( const event_base_type& ) >process_event_fun; typedef boost::function< void( const event_base_type& ) > post_event_fun; process_event_fun process_event_fun_; post_event_fun post_event_fun_; Camera() { process_event_fun_ = boost::bind( &Camera::process_event, boost::ref( *this ), _1 ); // the following line doesn't compile with VC 8.0 // post_event_fun_ = boost::bind( &Camera::post_event, boost::ref( *this ), _1 ); } // @test end bool IsMemoryAvailable() const { return true; } bool IsBatteryLow() const { return false; } }; After uncommenting the marked line the compiler produce more than 200 error messages: A function template has too few arguments. But the line above compiles very well and the process_event() method has the same signature. The post_event() method is polymorphic. But this shouldn't be a problem. Should it?

2 2