Re: [C++-sig] Subset of default python library
Mark Chandler wrote: Is there a small subset of the default python library that i can use for our embedded instance. Since this is part of a larger app that doesnt expect to have python installed thus we are including it with the program data. How ever there is alot of stuff in there that we are not going to use (all the server stuff) and dont want clients using as well. Have you looked at the distutils tools? I know there's functionality to start from a "root set" of referenced Python library modules and produce an exhaustive list of recursively-referenced modules. I haven't directly used those tools myself because my experience is more with py2exe and py2app: http://www.py2exe.org/ http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html In our case, instead of embedding the Python interpreter into our C++ application, we started with a Python main program and wrapped our C++ code as extension modules. This structure works well with py2exe and py2app. Both tools package the minimum subset of the Python standard library needed for your specific application, and that functionality is available via distutils. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Conversion from Python to C++
Michele De Stefano wrote: I'd like to write a custom from_python converter, but the point is that I've not understood how it works. Did you see Austin Bingham's recent post on another thread? If it's any help, I wrote a small bit on the details of writing converters. It might help clarify some of the mechanics which, I agree, are a bit mysterious: http://misspent.wordpress.com/2009/09/27/how-to-write-boost-python-converters/ ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] How to install extensions using bjam(?)
Amos Anderson wrote: I'm working on a project which is mixed C++/Python, and we use Boost functionality in our C++, and we've set up bjam to compile our project (on OSX). Everything seems to be working quite well. 2) It looks like python's distutils is supposed to be able to help, but it seems like a waste of time to figure out how to get distutils to compile my code when I already have bjam pretty much figured out. First, I assume that distutils can put my libraries on an automatic DYLD_LIBRARY_PATH path that python knows about, because if it can't then there's no point. But assuming that's not a problem, I can't figure out how to tell distutils about Extensions that it shouldn't try to build... In a previous project I've had success with py2app: http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html We had a number of extensions we built ourselves (not with distutils or py2app itself) and it happily packaged them into a working app bundle. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] boost::shared_ptr casting
peoro wrote: Ok, it does work as expected if class Base has got at least one virtual member: ...What if I cannot add a virtual function to the class Base? If your C++ base class has no virtual methods, even pure C++ can't dynamic_cast<> it. Put differently -- you've been asking Python to determine the runtime type of a class for which C++ maintains no runtime type. It's the presence of at least one virtual method that forces C++ to start tracking the runtime type of a class hierarchy. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] boost::shared_ptr casting
peoro wrote: There should be no need of dynamic_cast or any kind of run time type checking since the program has got static knowledge of types: The C++ program may have that knowledge. All I'm saying is that your original issue concerned Python determining the runtime type (leaf class) of each object. managed to get around the problem with a simple hack: prior to pass a shared_ptr to Python for the first time, I just pass it to Python casted to its most-derived class. I'm glad you've got a solution that works for you. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] When not to use static boost python library
Mr Kun Hong wrote: The lines in the documentation is: ''' It might be appropriate to use the static Boost.Python library in any of the following cases: * You are extending python and the types exposed in your dynamically-loaded extension module don't need to be used by any other Boost.Python extension modules, and you don't care if the core library code is duplicated among them. > ... ''' I guess what the problem is should be that: another python extension, written in boost python, cannot access the types and functions exposed in my current extension. I am not clear why is it so, becaused it is exposed to the python interpreter already. If there are two python extensions, both written in pure C, can't they access each other's type and functions? Suppose you develop two different Python extensions, each statically linked with Boost.Python. The situation looks like this: Ext1 | Boost.Python / Python interpreter \ Ext2 | Boost.Python You have two different copies of Boost.Python in memory at the same time. Presumably Boost.Python contains certain static data used to manage registering types to the Python interpreter. I guess the documentation is saying that if Ext2 tries to reference types defined in Ext1, it might confuse Boost.Python's static data. Contrast with dynamic linking: Ext1 /\ Python Boost.Python interpreter / \/ Ext2 Having a single copy of the Boost.Python static data eliminates the potential for confusion. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] interfacing headle binary file library, raw pointer and buffer
[email protected] wrote: I am trying to interface a binary file library using py++. There is a function in the library like int read(void* buffer, size_t len) which is hard to wrap. It read a piece (size len) of the file, and store it in buffer, and then return the buffer length (most likely equal to len). You want to write a C++ wrapper function something like this: std::string wrapped_read(size_t len) { // manually allocate buffer of size 'len', // e.g. by using std::vector int bytes_read = read(buffer, len); return std::string(buffer, bytes_read); // If you literally used 'new' or 'malloc' to obtain your 'buffer', // rather than a type such as std::vector which will release // its dynamic memory automatically, of course the 'return' // above would leak 'buffer'. In that case you'd have to declare // std::string result(buffer, bytes_read); // ...manually release 'buffer'... // return result; } Then wrap the C++ function wrapped_read() as the Python function "read". Boost.Python is very happy passing std::string in either direction. Trying to directly use char* or void* buffers is perilous and will, as you remark, make the consumers of your library unhappy. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Calling a C++ function with arguments by reference (lvalues)
Oded Padon wrote:
The C++ code is:
void add(int const a, int const b, int const& c)
{
c = a + b;
}
This doesn't even compile under g++ 4.0.1 (Mac):
error: assignment of read-only reference 'c'
I hope you're not using a compiler that accepts such code as legal?
I must emphasize that I wish to have functions that get arguments
> by reference and change them. Returning the values using the return
> mechanism isn't what I want to do (I have functions that get and set
> many many arguments, and I hardly wish to rewrite them).
Many moons ago I had the dubious pleasure of using a FORTRAN compiler
that was old and dumb even for the time. With this compiler, all
parameters were passed by non-const reference. One of my team was
delegated to write a subroutine that accepted certain parameters. There
was miscommunication about the expected parameter order, and the calling
code ended up passing the integer literal '5' in the parameter slot to
which the subroutine stored its result.
From that point on, everywhere the literal '5' appeared in the source,
the executable was instead referencing the result of some computation.
Merriment ensued as the program confounded all attempts to predict its
behavior.
You are proposing to do the same to the Python interpreter. It's
appropriate for Boost.Python to try to make that difficult.
Suppose you were writing this code from scratch in pure Python. How
would you approach the problem? This won't work:
def add(a, b, c):
c = a + b
def caller():
c = 0
add(1, 2, c)
assert c == 3 # FAIL
One way would be to keep some set of working variables in an object, and
pass that object into the function that wants to modify them:
class Vars(object):
def __init__(self):
self.a = 0
self.b = 0
self.c = 0
def add(a, b, vars):
vars.c = a + b
def caller():
v = Vars()
add(1, 2, v)
assert v.c == 3
Or you could keep working values in a dict, if you prefer dict lookup to
attribute references.
You can code your C++ add() function to accept its 'vars' parameter as a
boost::python::object. If you pass a class object, you can reference
vars.attr("c"). If you pass a dict, you can reference vars["c"].
See also:
http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/embedding.html#python.using_the_interpreter
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Calling a C++ function with arguments by reference (lvalues)
Oded Padon wrote:
There is another reason why I think this has to be possible.
> It is possible using ctypes. Using ctypes with the same C++
> code written above (except for extern "C"), the following python code:
import ctypes;
lib_cpp = ctypes.CDLL('./test_cpp.so')
result = ctypes.c_int(0);
lib_cpp.add(1, 2, ctypes.byref(result));
print result;
prints: "c_long(3)"
Yes. In this case, you allocated and passed a specific ctypes object
guaranteed to be compatible with a C++ int.
I still stand by my earlier point. Python doesn't recognize the concept
of 'const'. All int values are equally immutable. If Boost.Python were
to allow usage like this:
result = int()
cppmodule.add(1, 2, result)
assert result == 3
then what should happen in this innocent-looking case?
result = int()
cppmodule.add(result, 1, 2)
Or consider this. In recent versions of the Python interpreter, if you
assign (say) 5 to a variable and then double it enough times, you will
eventually produce a value larger than a C++ int. Unlike C++, Python
will grow the storage associated with that variable to be able to
represent the value exactly.
What should happen when you try to pass *that* value to a C++ int&
parameter?
If you're happy with the ctypes approach, you could easily introduce a
convention like this:
class RefInt(object):
def __init__(self, value=int()):
self.value = value
def __int__(self):
return self.value
# ...other operations as desired for convenience...
Now, assuming you've coded your C++ add() function to accept a RefInt,
you can write:
result = RefInt(0)
cppmodule.add(1, 2, result)
assert int(result) == 3
which is just as facile as the ctypes code you cited.
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Linking issues with Boost.Python
David Aldrich wrote: I would strongly recommend that you use something more modern than GNU make. Boost's build system is much better. The one I use is scons (http://www.scons.org/) whose only main fault is O(N^2) scaling to source file number, a problem they are in the process of fixing. Should one consider bjam? That's what Niall meant by "Boost's build system." Boost.Build uses bjam as its engine, with substantial work around that. I've always found bjam syntax a bit off-putting, and I've never read the available Boost.Build documentation, which is probably superb. So in fairness to the work of many others, I'll only note that many of the questions on the boost-users mailing list seem to be from people confused by proper use of '--' on the bjam command line, proper placement of spaces and commas in the configuration files, etc. I really want to like scons: I see no need to invent a whole new language for a build engine. That said, our organization presently uses CMake. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost.Python: Callbacks to class functions
On Aug 1, 2011, at 10:50 AM, diego_pmc wrote: > How should I capture Python function objects such > that I won't increase their reference count? I only need a weak reference to > the objects. http://docs.python.org/library/weakref.html#module-weakref I don't know how to access a Python weakref from Boost.Python. > ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] failed to install boost.python on Lion
On Oct 26, 2011, at 9:54 AM, Liguo Kong wrote: > I am trying to install boost.python on Mac Lion OS. I used python 2.6 > installed by default and > built boost.build with ./bootstrap.sh --set-toolset=gcc and then ./b2 install > --prefix=~/workspace/boost_build. Uh, maybe toolset=darwin?___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Fwd: Passing Python-derived class back into a native C++ class doesn't match the C++ signature
On Nov 12, 2011, at 11:34 AM, Adam Preble wrote: > I am seeing this come up in many variations, with people doing slightly > different things. I have no direct experience with this issue myself, but I can parrot a bit of advice I've read here before. > In Python: > class DerivedTest(BaseTest): > def __init__(self): BaseTest.__init__(self) > pass > > def GimmeNumber(self): > return 100 ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Fwd: Passing Python-derived class back into a native C++ class doesn't match the C++ signature
On Nov 12, 2011, at 2:25 PM, Jim Bosch wrote: > On 11/12/2011 02:12 PM, Adam Preble wrote: >> Woooah that looks like it does work, although I had to interpret it like so: >> >> class DerivedTest(BaseTest): >> def __init__(self): >> BaseTest.__init__(self) Yes, sorry the email quoting confused my intended indentation. >> Is this kind of the normal rigors when subclassing in Python >> normally, or is this something I must particularly pay attention to when >> using Boost? > > Calling the base class __init__ is less important in pure Python (i.e. > sometimes it's not necessary), but it's still definitely good practice; it > depends on whether the base class __init__ does anything important. Python > does not ever call it automatically, and in Boost.Python it definitely does > something important. That's right: this is NOT specific to Boost.Python. If your Python subclass constructor doesn't explicitly call the base-class constructor, the base class remains uninitialized. As Jim says, with Boost.Python the bad effect of an uninitialized base can include that type recognition failure. fwiw, if the only logic in your subclass constructor is to forward all the same arguments to the base-class constructor, you could omit it entirely and just let Python implicitly call the inherited base-class constructor. I only define a subclass constructor when it must perform additional logic beyond initializing the base class. Again, that's a general rule in Python rather than anything specific to Boost.Python. > ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python support Python Version.
On Jul 22, 2012, at 4:20 AM, Harkirat Singh wrote: > My target system uses python2.4.4. > I have even tried swig, but it seems there isnt full support for python2.4. > It uses some python c++ API not supported in > python2.4.4. My advice would be to update your Python version. Quite aside from the mere age of Python 2.4, many useful features have been added to the language since then - perhaps most notably in Python 2.5. But why not use 2.7? ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] V2 windows build problems update
On Sat, Oct 19, 2013 at 4:50 AM, Nitas Aeter wrote: fatal error LNK1104: can not open “libmmdd.lib” > > Can you help me ? > Wow, that's really not a lot to go on. Usually the mailing list would at least want to know what you're trying to do, what versions of the OS and compiler you're using and what specific command lines you executed -- plus a small, self-contained source file that demonstrates the problem. I have just one thing to say about LNK1104. While building our own software, I have encountered so many spurious LNK1104 errors that I've concluded it must be primarily due to Windows 7 failing to release file locks soon enough after program termination. I finally got fed up and coded a retry loop into the script with which I run builds. When the failure output contains "LNK1104," my script emits a message and reruns the build command line. Usually that succeeds. I may have an unusual Windows development environment. Certainly the scripts we run on our build farm don't include automated retries, and yet somehow we manage to produce Windows executables. I do have the impression that our buildmeister manually reruns many Windows builds; I couldn't tell you whether LNK1104 is the chief culprit. So in the complete absence of any other actionable information, my only advice is: try running your build again. ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] sharing code between different python extensions
On Oct 22, 2014, at 8:08 AM, "Wintersberger, Eugen"
wrote:
> I have a little problem with two Python extensions (C++ with
> boost::python) where share code.
>
> I have to Python extensions ('a' and 'b') each of them exporting two
> functions. What I want is to use a function exported by 'a' in the code
> of 'b'. Though the package compiles I get an unresolved symbol error
> when trying to load 'b'.
If I were faced with this situation either in pure Python, or pure C++, I would
probably break out module 'c' with functions consumed by both 'a' and 'b'.
Could this work in your situation?
>
___
Cplusplus-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] formatting str of exposed type
On Thu, Sep 17, 2015 at 5:41 PM, Daniel Brake wrote:
> I would like a C++ class which I am exposing through Boost.Python
> (initially,the boost::multiprecision::mpfr_float, with expression templates
> turned off -- eventually a whole pile of types depending on mpfr_float) to
> be able to respond to the %precision n command, for example, from ipython.
> Additionally, I would like to be able to use a format spec such as
>
> print('{0:.40}'.format(b))
>
> to print a variable b with 40 digits of precision. Even better, I would
> like to be able to put a standard formatting letter in the format string
> preceding the .format call.
>
> My best guess would be to def("format",...) as a free function for my
> class_, but I also guess that this is a standard operation, and I would
> rather use a standard solution. Parsing the formatting string myself
> doesn't sound like much fun, and am hoping for a little insight from the
> mailing list.
What if you provide a __format__ function, as described in PEP 3101:
https://www.python.org/dev/peps/pep-3101/
(section "Controlling Formatting on a Per-Type Basis")?
___
Cplusplus-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cplusplus-sig
