Re: Using C++ and ctypes together: a vast conspiracy? ;)
Joseph Garvin schrieb: On Thu, Jun 4, 2009 at 3:23 PM, Brian brian.min...@colorado.edu wrote: What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? I can't speak for others but the reason I was asking is because it's nice to be able to define bindings from within python. At a minimum, compiling bindings means a little extra complexity to address with whatever build tools you're using. AFAIU, pybindgen takes this approach. And, AFAIK, pygccxml can generate pybindgen code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Requiring that the C++ compiler used to make the dll's/so's to be the same one Python is compiled with wouldn't be too burdensome would it? Scott And what gave you then impression that Python is compiled with a Scott C++ compiler? I don't think it's too much to expect that a C++ compiler be available for the configure step if Python is being built in a C++ shop. The C compiler used to build Python proper should be compatible with the C++ compiler available to build C++ extension modules or C++ libraries dynamically linked into Python. If there is no C++ compiler available then the proposed layout sniffing just wouldn't be done and either a configure error would be emitted or a run-time exception raised if a program attempted to use that feature. (Or the sniffing could be explicitly enabled/disabled by a configure flag.) -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ America's vaunted free press notwithstanding, story ideas that expose the unseemly side of actual or potential advertisers tend to fall by the wayside. Not quite sure why. -- Jim Thornton -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
s...@pobox.com schrieb: Requiring that the C++ compiler used to make the dll's/so's to be the same one Python is compiled with wouldn't be too burdensome would it? Scott And what gave you then impression that Python is compiled with a Scott C++ compiler? I don't think it's too much to expect that a C++ compiler be available for the configure step if Python is being built in a C++ shop. The C compiler used to build Python proper should be compatible with the C++ compiler available to build C++ extension modules or C++ libraries dynamically linked into Python. If there is no C++ compiler available then the proposed layout sniffing just wouldn't be done and either a configure error would be emitted or a run-time exception raised if a program attempted to use that feature. (Or the sniffing could be explicitly enabled/disabled by a configure flag.) Hm, on Linux, gccxml (if its version is compatible with that of the C++ compiler) can probably help a lot. At runtime, no configure step needed. Unfortunately not on Windows. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Jun 5, 2009, at 10:13 AM, Thomas Heller wrote: s...@pobox.com schrieb: If there is no C++ compiler available then the proposed layout sniffing just wouldn't be done and either a configure error would be emitted or a run-time exception raised if a program attempted to use that feature. (Or the sniffing could be explicitly enabled/disabled by a configure flag.) Hm, on Linux, gccxml (if its version is compatible with that of the C ++ compiler) can probably help a lot. At runtime, no configure step needed. Unfortunately not on Windows. I'm not a gccxml user, but its install page has a section for Windows: http://www.gccxml.org/HTML/Install.html HTH P -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Philip Semanchuk schrieb: On Jun 5, 2009, at 10:13 AM, Thomas Heller wrote: s...@pobox.com schrieb: If there is no C++ compiler available then the proposed layout sniffing just wouldn't be done and either a configure error would be emitted or a run-time exception raised if a program attempted to use that feature. (Or the sniffing could be explicitly enabled/disabled by a configure flag.) Hm, on Linux, gccxml (if its version is compatible with that of the C ++ compiler) can probably help a lot. At runtime, no configure step needed. Unfortunately not on Windows. I'm not a gccxml user, but its install page has a section for Windows: http://www.gccxml.org/HTML/Install.html Yes, it runs on Windows (*). However, there are two problems: 1. gccxml refuses to parse quite some include files from the Window SDK. That's probably not the fault of gccxml but MS using non-standard C++ constructs. (There is a workaround inside gccxml: it installs patched Windows header files, but the patches must be created first by someone) 2. You cannot expect gccxml (which is mostly GCC inside) to use the MSVC algorithm for C++ object layout, so unfortuately it does not help in the most important use-case. Thomas (*) And there is even use for it on Windows to parse C header files and generate ctypes wrappers, in the ctypeslib project. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
[Please keep the discussion on the list] Joseph Garvin schrieb: On Thu, Jun 4, 2009 at 3:43 AM, Thomas Heller thel...@python.net wrote: There have been some attempts to use ctypes to access C++ objects. We (Roman Yakovenko and myself) made some progress. We were able to handle C++ name mangling, the special C++ calling convention, access virtual, non-virtual, overloaded functions, but finally gave up because the binary layout (function tables, member variables, and so on) of C++ objects is way too complicated and undocumented. Have you read the book Inside The C++ Object Model?: I haven't, but considered to buy it ;-) http://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp/0201834545/ref=sr_1_1?ie=UTF8s=booksqid=1244139929sr=8-1 It's probably out of date now, but I'm about halfway through it and it documents a ton of the little unexpected optimizations and such that cause the binary layout to be complex. How did you get as far as you did without having figured out the layout? (e.g. if you could access virtual functions you must have known how to get at the virtual table) I found a lot of material on the web, also I used the (very good) visual studio debugger, and finally I did a lot of experimentation. We were only able to access some very simple C++ objects. There is also a patent or patents from MS about the vtable. All in all, as I said, IMO it is too complicated to figure out the binary layout of the C++ objects (without using a C++ compiler), also there are quite some Python packages for accessing them. -- Thanks, Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Jun 4, 2009, at 3:35 PM, Thomas Heller wrote: [Please keep the discussion on the list] Joseph Garvin schrieb: On Thu, Jun 4, 2009 at 3:43 AM, Thomas Heller thel...@python.net wrote: There have been some attempts to use ctypes to access C++ objects. We (Roman Yakovenko and myself) made some progress. We were able to handle C++ name mangling, the special C++ calling convention, access virtual, non-virtual, overloaded functions, but finally gave up because the binary layout (function tables, member variables, and so on) of C++ objects is way too complicated and undocumented. Have you read the book Inside The C++ Object Model?: It's probably out of date now, but I'm about halfway through it and it documents a ton of the little unexpected optimizations and such that cause the binary layout to be complex. How did you get as far as you did without having figured out the layout? (e.g. if you could access virtual functions you must have known how to get at the virtual table) I found a lot of material on the web, also I used the (very good) visual studio debugger, and finally I did a lot of experimentation. We were only able to access some very simple C++ objects. There is also a patent or patents from MS about the vtable. All in all, as I said, IMO it is too complicated to figure out the binary layout of the C++ objects (without using a C++ compiler), also there are quite some Python packages for accessing them. Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Thanks Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Philip Semanchuk schrieb: Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I haven't used any of them myself. A common suggestion is SIP, less known are pybindgen and Robin. But there may be many more, and others with more experience might have much more to say about them. Also there is Roman Yokavenko's pygccxml which has a lot of stuff. I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Unfortunately there is no solution in sight, with ctypes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? Boost has published a variety of libraries that will be included into the next c++ standard. It's hard to imagine a better designed python/c++ interface library than Boost.Python. Further, pygccxml is amazing with regards to scanning your source code using gcc itself and then using that xml representation to write out the Boost.Python code. What more do people in this conversation want? On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller thel...@python.net wrote: Philip Semanchuk schrieb: Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I haven't used any of them myself. A common suggestion is SIP, less known are pybindgen and Robin. But there may be many more, and others with more experience might have much more to say about them. Also there is Roman Yokavenko's pygccxml which has a lot of stuff. I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Unfortunately there is no solution in sight, with ctypes. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Jun 4, 2009, at 4:23 PM, Brian wrote: What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? Boost has published a variety of libraries that will be included into the next c++ standard. It's hard to imagine a better designed python/c++ interface library than Boost.Python. Further, pygccxml is amazing with regards to scanning your source code using gcc itself and then using that xml representation to write out the Boost.Python code. What more do people in this conversation want? Hi Brian, I've only experimented with SWIG (and ctypes for wrapping a C library). We're not yet sold on using SWIG to wrap our C++ libraries and so we're exploring alternatives. Before I started with SWIG, I did some research to see what other folks were using. The arguments I recall reading that swayed me to try SWIG before Boost were -- - Boost involves more magic than SWIG which means it does a bit more work for you, but when things go wrong (i.e. interface won't compile or doesn't work as expected) it is very difficult to debug. - Boost-ed code requires a Boost runtime library. This isn't a showstopper problem, obviously, but it's a mark against since it adds yet another prerequisite to our install process. - Boost's generated code can take a long time to compile. I don't know what pygccxml adds to the equation, so perhaps some of those disadvantages disappear with Boost.Python + pygccxml versus just plain Boost.Python. If you'd like to expound on this, feel free. I'd appreciate the education. I don't know about what Boost (or any other tool) generates, but the interface I got out of SWIG was not pretty. That's no knock on SWIG -- I'm amazed at what it can do. Nevertheless the generated interface has all the charm of a Babelfish translation. I imagine lots of autogenerated code looks babelfish-ed: meaning is preserved, albeit crudely, but all the idioms are lost and it's eminently clear that it was not created by a native speaker. Until there's an interface generation tool that can build an interface that makes the wrapped library look completely Pythonic, then choosing a tool will be a matter of choosing which compromises you want to make. As long as that's true, I think there's room for multiple library-wrapping packages, just like there's room for more than one programming language in the world. Cheers Philip On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller thel...@python.net wrote: Philip Semanchuk schrieb: Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I haven't used any of them myself. A common suggestion is SIP, less known are pybindgen and Robin. But there may be many more, and others with more experience might have much more to say about them. Also there is Roman Yokavenko's pygccxml which has a lot of stuff. I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Unfortunately there is no solution in sight, with ctypes. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Well you'll just have to try Boost.Python. There is a pygccxml gui gets you started in about 15 minutes. You'll be able to see how well it groks your code and what that generated code is. Boost is the best. People complain about it because they don't understand C++ templates and they don't realize how incredibly well designed it is. If you don't know the basics it's this: Boost.Python uses meta template programming. This allows it to use the C++ preprocessor for what other binding systems generally write a custom tool for. Long compile times are not a real problem for anyone - it's easy to set up a compile farm and the benefit is that your runtime code is blazing fast. In my opinion Boost is more sophisticated, SWIG, etc.. is more of a hack. Of course they all help you get the job done. On Thu, Jun 4, 2009 at 2:54 PM, Philip Semanchuk phi...@semanchuk.comwrote: On Jun 4, 2009, at 4:23 PM, Brian wrote: What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? Boost has published a variety of libraries that will be included into the next c++ standard. It's hard to imagine a better designed python/c++ interface library than Boost.Python. Further, pygccxml is amazing with regards to scanning your source code using gcc itself and then using that xml representation to write out the Boost.Python code. What more do people in this conversation want? Hi Brian, I've only experimented with SWIG (and ctypes for wrapping a C library). We're not yet sold on using SWIG to wrap our C++ libraries and so we're exploring alternatives. Before I started with SWIG, I did some research to see what other folks were using. The arguments I recall reading that swayed me to try SWIG before Boost were -- - Boost involves more magic than SWIG which means it does a bit more work for you, but when things go wrong (i.e. interface won't compile or doesn't work as expected) it is very difficult to debug. - Boost-ed code requires a Boost runtime library. This isn't a showstopper problem, obviously, but it's a mark against since it adds yet another prerequisite to our install process. - Boost's generated code can take a long time to compile. I don't know what pygccxml adds to the equation, so perhaps some of those disadvantages disappear with Boost.Python + pygccxml versus just plain Boost.Python. If you'd like to expound on this, feel free. I'd appreciate the education. I don't know about what Boost (or any other tool) generates, but the interface I got out of SWIG was not pretty. That's no knock on SWIG -- I'm amazed at what it can do. Nevertheless the generated interface has all the charm of a Babelfish translation. I imagine lots of autogenerated code looks babelfish-ed: meaning is preserved, albeit crudely, but all the idioms are lost and it's eminently clear that it was not created by a native speaker. Until there's an interface generation tool that can build an interface that makes the wrapped library look completely Pythonic, then choosing a tool will be a matter of choosing which compromises you want to make. As long as that's true, I think there's room for multiple library-wrapping packages, just like there's room for more than one programming language in the world. Cheers Philip On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller thel...@python.net wrote: Philip Semanchuk schrieb: Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I haven't used any of them myself. A common suggestion is SIP, less known are pybindgen and Robin. But there may be many more, and others with more experience might have much more to say about them. Also there is Roman Yokavenko's pygccxml which has a lot of stuff. I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Unfortunately there is no solution in sight, with ctypes. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Just to expound a bit on pygccxml, which really makes boost worth it. pygccxml enables you to do all of your binding work from within Python. It calls gccxml, which is an xml backend to gcc that outputs the parse tree in an xml format. Pygccxml provides a very high level interface between the gcc xml representation and the pygccxml boost code generator. It's really a great thing. You just have to learn to read the code that pygccxml outputs for boost, and then go back to python and use the high level interface to modify the code that it outputs. It has all sorts of selectors so you can operate on all code that has certain arbitrary properties all at the same time. Play with it before deciding on swig. It's frikkin' cool :) On Thu, Jun 4, 2009 at 3:01 PM, Brian brian.min...@colorado.edu wrote: Well you'll just have to try Boost.Python. There is a pygccxml gui gets you started in about 15 minutes. You'll be able to see how well it groks your code and what that generated code is. Boost is the best. People complain about it because they don't understand C++ templates and they don't realize how incredibly well designed it is. If you don't know the basics it's this: Boost.Python uses meta template programming. This allows it to use the C++ preprocessor for what other binding systems generally write a custom tool for. Long compile times are not a real problem for anyone - it's easy to set up a compile farm and the benefit is that your runtime code is blazing fast. In my opinion Boost is more sophisticated, SWIG, etc.. is more of a hack. Of course they all help you get the job done. On Thu, Jun 4, 2009 at 2:54 PM, Philip Semanchuk phi...@semanchuk.comwrote: On Jun 4, 2009, at 4:23 PM, Brian wrote: What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? Boost has published a variety of libraries that will be included into the next c++ standard. It's hard to imagine a better designed python/c++ interface library than Boost.Python. Further, pygccxml is amazing with regards to scanning your source code using gcc itself and then using that xml representation to write out the Boost.Python code. What more do people in this conversation want? Hi Brian, I've only experimented with SWIG (and ctypes for wrapping a C library). We're not yet sold on using SWIG to wrap our C++ libraries and so we're exploring alternatives. Before I started with SWIG, I did some research to see what other folks were using. The arguments I recall reading that swayed me to try SWIG before Boost were -- - Boost involves more magic than SWIG which means it does a bit more work for you, but when things go wrong (i.e. interface won't compile or doesn't work as expected) it is very difficult to debug. - Boost-ed code requires a Boost runtime library. This isn't a showstopper problem, obviously, but it's a mark against since it adds yet another prerequisite to our install process. - Boost's generated code can take a long time to compile. I don't know what pygccxml adds to the equation, so perhaps some of those disadvantages disappear with Boost.Python + pygccxml versus just plain Boost.Python. If you'd like to expound on this, feel free. I'd appreciate the education. I don't know about what Boost (or any other tool) generates, but the interface I got out of SWIG was not pretty. That's no knock on SWIG -- I'm amazed at what it can do. Nevertheless the generated interface has all the charm of a Babelfish translation. I imagine lots of autogenerated code looks babelfish-ed: meaning is preserved, albeit crudely, but all the idioms are lost and it's eminently clear that it was not created by a native speaker. Until there's an interface generation tool that can build an interface that makes the wrapped library look completely Pythonic, then choosing a tool will be a matter of choosing which compromises you want to make. As long as that's true, I think there's room for multiple library-wrapping packages, just like there's room for more than one programming language in the world. Cheers Philip On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller thel...@python.net wrote: Philip Semanchuk schrieb: Hi Thomas, We're weighing options for accessing C++ objects via Python. I know of SIWG and Boost; are there others that you think deserve consideration? I haven't used any of them myself. A common suggestion is SIP, less known are pybindgen and Robin. But there may be many more, and others with more experience might have much more to say about them. Also there is Roman Yokavenko's pygccxml which has a lot of stuff. I've been happy with ctypes in my limited exposure to it and would love to find a way to make that work. This thread has been very interesting to me. Unfortunately there is no solution in sight, with ctypes. -- http://mail.python.org/mailman/listinfo/python-list --
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Thu, Jun 4, 2009 at 3:23 PM, Brian brian.min...@colorado.edu wrote: What is the goal of this conversation that goes above and beyond what Boost.Python + pygccxml achieve? I can't speak for others but the reason I was asking is because it's nice to be able to define bindings from within python. At a minimum, compiling bindings means a little extra complexity to address with whatever build tools you're using. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Thu, Jun 4, 2009 at 2:35 PM, Thomas Heller thel...@ctypes.org wrote: [Please keep the discussion on the list] All in all, as I said, IMO it is too complicated to figure out the binary layout of the C++ objects (without using a C++ compiler), also there are quite some Python packages for accessing them. Requiring that the C++ compiler used to make the dll's/so's to be the same one Python is compiled with wouldn't be too burdensome would it? Because then you could have it run a bunch of configure tests to determine information exposing the layout. I don't know if everything is testable, but you can for example (I learned this from the object model book btw) write a C++ program that determines whether the virtual function table is stored at the beginning or the end of an object by comparing the address of an object with a virtual function to the address of its first data member. If they're different, it's because the vptr is stored there, otherwise it's on the end (theoretically it could be in the middle but there's no reason for compiler writers to do that). cpptypes could then use information generated by tests like this that are run when the interpreter is compiled. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Joseph Garvin wrote: On Thu, Jun 4, 2009 at 2:35 PM, Thomas Heller thel...@ctypes.org wrote: [Please keep the discussion on the list] All in all, as I said, IMO it is too complicated to figure out the binary layout of the C++ objects (without using a C++ compiler), also there are quite some Python packages for accessing them. Requiring that the C++ compiler used to make the dll's/so's to be the same one Python is compiled with wouldn't be too burdensome would it? And what gave you then impression that Python is compiled with a C++ compiler? --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
A. Cavallo schrieb: Mmmm, not really a conspiracy but it is not that trivial In wrapping c++ you might find useful the commands nm with c++filt although they work under linux there is the same pair for every platform (under windows I remember there is objdump): they should only you need to wrap a c++ library. I've been wrapping in the past c++ using boost and it was trivial although I haven't tried enough to break it. swig, in older versions, is really bad: I can't comment on newer versions but I'd have a look to the generated code before using it. sip it looks quite difficult to use, but is well maintained. I don't think it's (more) difficult. It's just stripping down the c++-header-file for the easy cases,providing explicit type-marshalling code for complex arguments, and potentially writing explicit method/function-bodies for certain hard cases. All of this is done pretty much alike in boost. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In message ad634d5d-
c0e4-479a-85ed-91c26d3bf...@c36g2000yqn.googlegroups.com, Kay Schluehr
wrote:
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern
C clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies
madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL?
What does the STL offer that Python doesn't already do more flexibly and
more simply?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
No wonder, you have never actually used C++ with C types. An extern
C clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively
you're calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies
madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL?
What does the STL offer that Python doesn't already do more flexibly and
more simply?
Couldn't agree more:)
The following is the STL equivalent of:
print [ x*2 for range(10) in data if (x%2 == 0) ]
It will take more than digging into the STL documentation.
#include iostream
#include vector
#include iterator
#include algorithm
#include functional
#include ext/functional
using __gnu_cxx::compose1;
class Range
{
public:
Range(int start=0) : m_start(start) {}
virtual ~Range() {}
int operator()() { return m_start++; }
private:
int m_start;
};
class Times
{
public:
Times(int val) : m_val(val) {}
int operator()(int x) const { return x*m_val; }
private:
int m_val;
};
int main(int argc, char * argv[])
{
std::vectorint data(10);
std::generate(data.begin(), data.end(), Range(0));
std::vectorint::iterator new_end = std::remove_if(data.begin(),
data.end(), compose1(std::bind2nd(std::equal_toint(), 0),
std::bind2nd(std::modulusint(), 2)));
data.erase(new_end, data.end());
std::transform(data.begin(), data.end(), data.begin(), Times(2));
std::copy(data.begin(), data.end(), std::ostream_iteratorint(std::cout,
\n));
return 0;
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On 3 Jun., 11:13, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message ad634d5d-
c0e4-479a-85ed-91c26d3bf...@c36g2000yqn.googlegroups.com, Kay Schluehr
wrote:
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern
C clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies
madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL?
What does the STL offer that Python doesn't already do more flexibly and
more simply?
I do not quite understand your concern? Wasn't the whole point of
Josephs post that he intended to create C++ bindings effectively s.t.
ctypes can be used?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In article mailman.1046.1244023834.8015.python-l...@python.org,
A. Cavallo a.cava...@mailsnare.com wrote:
The following is the STL equivalent of:
print [ x*2 for range(10) in data if (x%2 == 0) ]
Are you sure about that? I haven't tested the following code, but I
believe it is a much more direct match the the behavior of your Python code
(at least on Python 2.5.1).
#include iostream
int main(int argc, char * argv[])
{
std::cout SyntaxError: can't assign to function call;
std::cout endl;
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Wednesday 03 June 2009 14:05:35 Roy Smith wrote:
In article mailman.1046.1244023834.8015.python-l...@python.org,
A. Cavallo a.cava...@mailsnare.com wrote:
The following is the STL equivalent of:
print [ x*2 for range(10) in data if (x%2 == 0) ]
Are you sure about that? I haven't tested the following code, but I
believe it is a much more direct match the the behavior of your Python code
(at least on Python 2.5.1).
#include iostream
int main(int argc, char * argv[])
{
std::cout SyntaxError: can't assign to function call;
std::cout endl;
}
Ahahaha you're right!
print [ x*2 for range(10) in data if (x%2 == 0) ] and it should work just
fine: I've still left 9 minutes to match what I've spent in order to write the
C++ version including wandering through the STL docs, compiling, fix the
syntax errors, finding the gnu STL hasn't compose1 in the expected header
file
Regards,
Antonio
btw.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Wednesday 03 June 2009 14:05:35 Roy Smith wrote:
#include iostream
int main(int argc, char * argv[])
{
std::cout SyntaxError: can't assign to function call;
std::cout endl;
}
Ops,
I've forgotten
a.cpp: In function ‘int main(int, char**)’:
a.cpp:5: error: ‘endl’ was not declared in this scope
Oh C++ joy!
Regards,
Antonio
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In article h04s0s$7g...@lust.ihug.co.nz,
Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern C
clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies madness.
Agreed. I've done this several times and it works fine. Once I'm in C
I'm really in C++ and can use all my C++ code and libraries. Not a big
problem really. But maybe I'm missing something.
--
-- Lou Pecora
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
A. Cavallo wrote: print [ x*2 for range(10) in data if (x%2 == 0) ] I hope you meant print [ x*2 for x in range(10) if (x%2 == 0) ] -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Jun 3, 2:13 am, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message ad634d5d-
c0e4-479a-85ed-91c26d3bf...@c36g2000yqn.googlegroups.com, Kay Schluehr
wrote:
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern
C clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies
madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL?
What does the STL offer that Python doesn't already do more flexibly and
more simply?
The opportunity to type several lines of ASCII line noise just to do
something really simple like iterate through a vector.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In article mailman.1055.1244038474.8015.python-l...@python.org,
A. Cavallo a.cava...@mailsnare.com wrote:
On Wednesday 03 June 2009 14:05:35 Roy Smith wrote:
#include iostream
int main(int argc, char * argv[])
{
std::cout SyntaxError: can't assign to function call;
std::cout endl;
}
Ops,
I've forgotten
a.cpp: In function âint main(int, char**)â:
a.cpp:5: error: âendlâ was not declared in this scope
Oh C++ joy!
I suppose I *did* deserve that :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Joseph Garvin schrieb: So I was curious whether it's possible to use the ctypes module with C++ and if so how difficult it is. I figure in principal it's possible if ctypes knows about each compiler's name mangling scheme. So I searched for ctypes c++ on Google. The third link will be Using ctypes to Wrap C++ Libraries. If you follow the link, it's broken. If you view the cache of the link, it's someone pointing to another blog, retrograde-orbit.blogspot.com, saying they discovered a way to do it easily. If you follow that link, you get taken a page does not exist error. Clearly there's some way to use ctypes with C++ and there's a vast conspiracy preventing it from reaching the masses ;) What's even stranger is that this link, despite being broken, has seemingly been near the top of google's results for these terms for a couple weeks (that's when I last tried), as if there were some underground group of rebels trying to hint the truth to us... ;) More seriously -- how difficult is it to use ctypes instead of saying, boost::python, and why isn't this in a FAQ somewhere? ;) Because it's much more needed than name-mangling. Name mangling is (amongst other things) one thing to prevent C++-inter-compiler-interoperability which results from differing C++ ABIs. I'm not an expert on this, but AFAIK no common ABI exists, especially not amongst VC++ G++. Which means that to work for C++, ctypes would need to know about the internals of both compilers, potentially in several versions, and possibly without prior notice to changes. Instead of dealing with this truly daunting task, tools such as SIP and SWIG or boost::python deal with this by utilizing the one tool that really knows about the ABI in use - the compiler itself. So while I'd loved to be proven wrong, I fear your curiosity won't be satisfied - or at least not in the positive sense you certainly envisioned. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Diez B. Roggisch de...@nospam.web.de wrote:
Joseph Garvin schrieb:
So I was curious whether it's possible to use the ctypes module with
C++ and if so how difficult it is. I figure in principal it's possible
if ctypes knows about each compiler's name mangling scheme. So I
searched for ctypes c++ on Google.
[snip]
More seriously -- how difficult is it to use ctypes instead of saying,
boost::python, and why isn't this in a FAQ somewhere? ;)
Because it's much more needed than name-mangling. Name mangling is
(amongst other things) one thing to prevent
C++-inter-compiler-interoperability which results from differing C++ ABIs.
I'm not an expert on this, but AFAIK no common ABI exists, especially
not amongst VC++ G++. Which means that to work for C++, ctypes would
need to know about the internals of both compilers, potentially in
several versions, and possibly without prior notice to changes.
Probably depends on how far you want to dig into C++. I'm sure it
will work fine for simple function calls, passing classes as anonymous
pointers etc. If you want to dig into virtual classes with multiple
bases or the STL then you are probably into the territory you
describe.
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
--
Nick Craig-Wood n...@craig-wood.com -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Mmmm, not really a conspiracy but it is not that trivial In wrapping c++ you might find useful the commands nm with c++filt although they work under linux there is the same pair for every platform (under windows I remember there is objdump): they should only you need to wrap a c++ library. I've been wrapping in the past c++ using boost and it was trivial although I haven't tried enough to break it. swig, in older versions, is really bad: I can't comment on newer versions but I'd have a look to the generated code before using it. sip it looks quite difficult to use, but is well maintained. If you have a moderate control on the library design the ctype is the best approach IMHO. Regards, Antonio On Tuesday 02 June 2009 21:50:24 Joseph Garvin wrote: So I was curious whether it's possible to use the ctypes module with C++ and if so how difficult it is. I figure in principal it's possible if ctypes knows about each compiler's name mangling scheme. So I searched for ctypes c++ on Google. The third link will be Using ctypes to Wrap C++ Libraries. If you follow the link, it's broken. If you view the cache of the link, it's someone pointing to another blog, retrograde-orbit.blogspot.com, saying they discovered a way to do it easily. If you follow that link, you get taken a page does not exist error. Clearly there's some way to use ctypes with C++ and there's a vast conspiracy preventing it from reaching the masses ;) What's even stranger is that this link, despite being broken, has seemingly been near the top of google's results for these terms for a couple weeks (that's when I last tried), as if there were some underground group of rebels trying to hint the truth to us... ;) More seriously -- how difficult is it to use ctypes instead of saying, boost::python, and why isn't this in a FAQ somewhere? ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
Diez B. Roggisch de...@nospam.web.de wrote:
Joseph Garvin schrieb:
So I was curious whether it's possible to use the ctypes module with
C++ and if so how difficult it is. I figure in principal it's possible
if ctypes knows about each compiler's name mangling scheme. So I
searched for ctypes c++ on Google.
[snip]
More seriously -- how difficult is it to use ctypes instead of saying,
boost::python, and why isn't this in a FAQ somewhere? ;)
Because it's much more needed than name-mangling. Name mangling is
(amongst other things) one thing to prevent
C++-inter-compiler-interoperability which results from differing C++
ABIs.
I'm not an expert on this, but AFAIK no common ABI exists, especially
not amongst VC++ G++. Which means that to work for C++, ctypes would
need to know about the internals of both compilers, potentially in
several versions, and possibly without prior notice to changes.
Probably depends on how far you want to dig into C++. I'm sure it
will work fine for simple function calls, passing classes as anonymous
pointers etc. If you want to dig into virtual classes with multiple
bases or the STL then you are probably into the territory you
describe.
Name mangeling starts with namespaces, and namespaces are a thing often seen
in well-designed C++-libraries. So even a simple C++-function call could
become rather difficult to do using ctypes ...
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern C
clause tells the compiler to generate C functions (more precisely, functions
that conform to the C ABI conventions), so effectively you're calling into
C, not into C++.
--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
Joseph Garvin wrote: So I was curious whether it's possible to use the ctypes module with C++ and if so how difficult it is. I figure in principal it's possible if ctypes knows about each compiler's name mangling scheme. So I searched for ctypes c++ on Google. The third link will be Using ctypes to Wrap C++ Libraries. If you follow the link, it's broken. If you view the cache of the link, it's someone pointing to another blog, retrograde-orbit.blogspot.com, saying they discovered a way to do it easily. If you follow that link, you get taken a page does not exist error. Clearly there's some way to use ctypes with C++ and there's a vast conspiracy preventing it from reaching the masses ;) What's even stranger is that this link, despite being broken, has seemingly been near the top of google's results for these terms for a couple weeks (that's when I last tried), as if there were some underground group of rebels trying to hint the truth to us... ;) More seriously -- how difficult is it to use ctypes instead of saying, boost::python, and why isn't this in a FAQ somewhere? ;) There are two possibilities here. You might have an existing DLL, written entirely in C++, with thoroughly mangled exports. Or you might have a body of code, to which you're willing to make modifications for the interface. It's only the second I would attack with ctypes. In fact, the name mangling itself varies between versions of the same compiler, never mind between different brands. You should be able to export a class factory, defined as an extern(c), and use that to get into the DLL. Once you have that, you can call any virtual functions of the class without any additional exports or name mangling needed. As long as the methods you're using are virtual, and singly inherited, it's just a question of walking the vtable. So you should be able to build wrappers, using ctypes, for each of those methods. Note: I haven't actually done it, as the machine with the C++ compiler installed as been down for longer than I've had Python, and I haven't wanted C++ enough to want to install it on my notebook computer. But this is the approach I'd try. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In article 78lit5f1mvib...@mid.uni-berlin.de, Diez B. Roggisch de...@nospam.web.de wrote: More seriously -- how difficult is it to use ctypes instead of saying, boost::python, and why isn't this in a FAQ somewhere? ;) Because it's much more needed than name-mangling. Name mangling is (amongst other things) one thing to prevent C++-inter-compiler-interoperability which results from differing C++ ABIs. Indeed. Name mangling is the most trivial way in which different C++ compilers do not interoperate. Some other thorny issues include exception handling, template instantiation, physical layout of struct and class elements (i.e. padding/alignment), and how references are returned (i.e. Return Value Optimization). I'm sure I've left out several critical items. It's an ugly world out there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern C
clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies madness.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern C
clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL? I suspect one ends up in
creating a variant of SWIG and I wonder if it's not a good idea to
just use SWIG then.
--
http://mail.python.org/mailman/listinfo/python-list
