Yeah, I saw your other question about it. There's nothing in boost that
I know of to achieve that. The only thing I'd know to suggest is what
others have already suggested - encapsulate it in another class and pass
that in. But it wouldn't be converted to a python string that way.
My question is whether or not you may be trying to optimize prematurely.
If your performance needs are strict enough that you need to pass your
string as a pointer, might it be better to write your application in C++
entirely, or prototype in python and then convert to C++?
You might try passing it as a reference instead of a pointer. I don't
know if that'll work or not. But, try having a regular std::string
instead of a std::string* and send it using ref(str) (the same way that
I suggested you send things using ptr() in your earlier question).
Again, I don't know if it'll work, but it might be worth a try.
If it's a return value, returning a ref() would cause a local variable
to go out of scope. You could try passing the desired string as a
reference parameter, rather than trying to return it. Again, I'm not
sure if this will work or not, as I've never tried it.
If neither of those work, I'd have to play around with it some to see if
I could come up with anything else.
On 12/23/2012 11:41 PM, simon zhang wrote:
Jaedyn.
I would like to discuss another issue, what is a good way to avoid
deep copy.There may be a few big data.From c++ to python and from
python to c++.Similar from c + + return std::string* to python and
python pass the std::string* parameter to c + + function.Maybe it
should be similar to smart pointers.Do you have any good suggestions
in there?
2012/12/23 Jaedyn K. Draper <jaedyn.cpp...@jaedyn.co
<mailto:jaedyn.cpp...@jaedyn.co>>
I was at least half right, then. Python was eating the signals. :)
As an alternative, to prevent yourself from having to do this in
every loop in your code, you might try this on the python side:
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
That'll stop Python from catching SIGINT globally and will always
send the SIGINT down to the C++ and terminate.
Of course, that may or may not be an option depending on your
specific needs.
On 12/23/2012 3:02 AM, simon zhang wrote:
This is the answer from the stackoverflow.
| while (true) { //endless loop
++it;
std::cout<< it<<std::endl;
sleep(3);
if(PyErr_CheckSignals() == -1) {
exit(1);
}
}|
2012/12/23 Jaedyn K. Draper <jaedyn.cpp...@jaedyn.co
<mailto:jaedyn.cpp...@jaedyn.co>>
Oh, my mistake. Not sure then, I've only embedded, never
extended. Maybe someone else can help. :(
On 12/23/2012 1:59 AM, simon zhang wrote:
But I don't call Py_Initialize().I call C++ code in
Python.Don't embed the Python to C++...
2012/12/23 Jaedyn K. Draper <jaedyn.cpp...@jaedyn.co
<mailto:jaedyn.cpp...@jaedyn.co>>
Instead of Py_Initialize() (wherever it is you call it),
try calling Py_InitializeEx(0). Py_Initialize() (or
Py_InitializeEx(1)) binds signal handlers (including
SIGINT) to send python exceptions instead of killing the
process. This may be what's hitting you.
On 12/23/2012 1:44 AM, simon zhang wrote:
I have make a boost.python module with an endless
loop.But I can't kill the process by ctrl-c.The
following is an example.
C++
|#include <boost/python.hpp>
#include <boost/python.
module.hpp>
#include <boost/python.
def.hpp>
#include <iostream>
usringnamespace boost::python;
void foo() {
int it=0;
while (true) { //endless loop
++it;
std::cout<< it<<std::endl;
sleep(3);
}
}
BOOST_PYTHON_MODULE(ctopy)
{
def("foo",foo);
}|
python:
|import ctopy
ctopy.foo()|
result:
|1
2
3
4
.....................|
I can't kill the foreground process by Ctrl-c.why the
module don't accept signal "SIGINT" that was sent by
Ctrl-c.How to make it work.
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org <mailto:Cplusplus-sig@python.org>
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
