Re: [C++-sig] Avoid Implicitly conversion for non direct conversion
On Dienstag 05 Januar 2010, Renato Araujo wrote: > I would like to know if is possible to avoid this level of conversion > and tell to boost.python only try the direct conversion, Not as far as I know. > because this > make the functions call slower then normal calls, But only if you pass objects that need to be converted, right? > and some times cause > a lot of problems in my classes. Details? You might have problems with overloaded functions, in which case Troy's recently suggested BPL extension would most likely help. (I am looking forward to its integration). Ciao, / /.o. /--/ ..o / / ANS ooo signature.asc Description: This is a digitally signed message part. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost 1.41 and autolink (maybe the wrong list)
Hello Terry, Try this: .sconf_temp\conftest_4.cpp: #define BOOST_PYTHON_DYN_LINK #include "boost/python.hpp" This will make boost look for shared library in the autolink feature Si On 06/01/2010 06:50, [email protected] wrote: I have compiled boost, and now want to use it in my python app but I am having trouble with autolink.hpp in my c++ files. C:\source\esys13>cl /Fo.sconf_temp\conftest_4.obj /c .sconf_temp\conftest_4.cpp /TP /nologo /IC:\python26\include "/IC: \source\boost_1_41_0" conftest_4.cpp C:\source\boost_1_41_0\boost/config/auto_link.hpp(297) : fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." I haven't done any linking at this point -- I am just trying to compile. Here is my test file. .sconf_temp\conftest_4.cpp: #include "boost/python.hpp" Yep -- just the include and thats it. VS2008, and python 2.6 Any ideas what I am doing wrong? Terry Rankine ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Avoid Implicitly conversion for non direct conversion
Hi thanks for you help, On Wed, Jan 6, 2010 at 4:59 AM, Hans Meine wrote: > On Dienstag 05 Januar 2010, Renato Araujo wrote: >> I would like to know if is possible to avoid this level of conversion >> and tell to boost.python only try the direct conversion, > > Not as far as I know. > >> because this >> make the functions call slower then normal calls, > > But only if you pass objects that need to be converted, right? Yes but this is the user level I would like to avoid this. > >> and some times cause >> a lot of problems in my classes. > > Details? I'm working on PySide (python bindings for Qt), and I have a lot of classes and a lot of implicitly conversions. Example: I have a class QVariant (Docs: http://doc.trolltech.com/4.6/qvariant.html) with many constructos, adn each type has your implicitly conversion rule. One example is QCorlor (Docs: http://doc.trolltech.com/4.6/qcolor.html) this is implicitly conversible from "int". Then when I create a QVariant(1) (passing int as argument) boost.python call the QVariant(QColor) constructor. I think this happening because boost.python try the implicitly conversion before verify the other basics signatures. This is one of the case I have a lot of others because I have more then 100 classes and more then 200 implicitly conversions rules, it's almost impossible to me, manager this if the conversion can happen in every class level. > > You might have problems with overloaded functions, in which case Troy's > recently suggested BPL extension would most likely help. (I am looking > forward to its integration). Where I can get more info about this I searched in ML but I did not find any info related. > > Ciao, / / .o. > /--/ ..o > / / ANS ooo Thanks ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Avoid Implicitly conversion for non direct conversion
Renato Araujo wrote:
Hi guys,
I'm trying use the "implicitly_convertible" to specify to boost.python
the possible conversions for every type, but I start get some errors
in my functions call because, the boost.python accept conversions in
more then one level. Like in this code:
The boost.python allow me to call the function "value" passing "int"
as argument type. Because "int" is implicitly convertible to "X" and
"X" is implicitly convertible to "Y".
This make a mess in my functions because boost try converter the
values before try other functions and call the wrong functions.
I would like to know if is possible to avoid this level of conversion
and tell to boost.python only try the direct conversion, because this
make the functions call slower then normal calls, and some times cause
a lot of problems in my classes.
---
#include
#include
#include
#include
using namespace boost::python;
struct X
{
X(int x) : v(x) {}
int v;
};
struct Y
{
Y(const X& w) : v(w.v) {}
int v;
};
int value(Y const& x)
{
return x.v;
}
BOOST_PYTHON_MODULE(implicit_ext)
{
def("value", value);
class_("X",
init())
;
class_("Y",
init())
;
implicitly_convertible();
implicitly_convertible();
}
---
Hi,
I'm in a rather elliptical orbit at the moment but should be coming back
around soon. I'll have a look at this: if we're going to attempt to
fix overloading, we might as well try to make boost.python obey the c++
rule of 'no more than 1 user-defined conversion in a row'.
Renato, the overloading stuff mentioned by Hans is in a thread titled
"Implementation of proper overload resolution" on this list.
-t
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] function types as user-defined converters
Ravi wrote:
On Friday 06 November 2009 14:52:49 troy d. straszheim wrote:
Currently, the converter type still leaks out to python in the signature:
class S(Boost.Python.instance)
| add(...)
| add( (S)arg1, (object)arg2) -> None :
|
| C++ signature :
| void add(S*,to_optional
(*)(boost::python::api::object))
converters won't nest:
def("foo", as(&somefn)); // nah
I dont have a mechanism for hooking a user defined converter into the
return type. I'm going to have to think about that one a bit more.
Did you have any ideas on this, Troy? This is the last bit I think I'd need in
order to replace my code with yours.
Hi Ravi,
I haven't looked, I got pulled away. I hope to be back to this soon though.
-t
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Avoid Implicitly conversion for non direct conversion
Am Mittwoch, 06. Januar 2010 14:10:02 schrieb Renato Araujo: > On Wed, Jan 6, 2010 at 4:59 AM, Hans Meine wrote: > > But only if you pass objects that need to be converted, right? > > Yes but this is the user level I would like to avoid this. Ah, you fear users saying "PySide is slow" because they're unknowingly using implicit conversions? How slow is this really? IMO BPL method calls are not blazingly fast anyway, since there is a lot of stuff happening at runtime, so one should not try to call millions of methods in the first place. I am not convinced there's a problem, so maybe you could try to ignore it for now. > I have a class QVariant (Docs: > http://doc.trolltech.com/4.6/qvariant.html) with many constructos, adn > each type has your implicitly conversion rule. > One example is QCorlor (Docs: > http://doc.trolltech.com/4.6/qcolor.html) this is implicitly > conversible from "int". > > Then when I create a QVariant(1) (passing int as argument) > boost.python call the QVariant(QColor) constructor. I think this > happening because boost.python try the implicitly conversion before > verify the other basics signatures. Yes, but here the implicit conversion is not the problem IMO, but the fact that BPL tries the overloaded functions one-by-one and uses the first matching, instead of the "best" one. > This is one of the case I have a > lot of others because I have more then 100 classes and more then 200 > implicitly conversions rules, it's almost impossible to me, manager > this if the conversion can happen in every class level. I see, this is exactly the problem that I had in mind when I wrote about the overloading problem. (Without overloading, implicit conversion should not bug you, right?) > > You might have problems with overloaded functions, in which case Troy's > > recently suggested BPL extension would most likely help. (I am looking > > forward to its integration). > > Where I can get more info about this I searched in ML but I did not > find any info related. Cf. recent thread "Implementation of proper overload resolution". HTH, Hans ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Implementation of proper overload resolution
This is great, I will try this, but I'm afraid about the size, because my main problem with boost.python is the library size compared to others c++ python bindings, my current library has 16 MB compared to 5 MB from SIP, and in my bindings I have a lot of overload functions and this solution can produce some new bytes. :( Renato Araujo Oliveira Filho On Tue, Dec 22, 2009 at 12:42 AM, Troy D. Straszheim wrote: > Dane Springmeyer writes: > >> Troy, >> >> Incidentally, do you know the proper way (or is there a proper way?) >> to support None type keyword arguments? >> >> Cheers, >> >> Dane >> > > Could you elaborate? What're you trying to do? > > -t > > > ___ > Cplusplus-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/cplusplus-sig > ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost 1.41 and autolink (maybe the wrong list)
> I haven’t done any linking at this point – I am just trying to compile. Yep, but the compiler has predefined macros defined, and the auto_link header tries to prevent linking / crashing problems. You should try to compile using an addition /MD switch to use the dynamically linked C-runtime. see http://msdn.microsoft.com/fr-fr/library/cc438633(VS.71).aspx HTH, Nicolas Here is my test file. .sconf_temp\conftest_4.cpp: #include "boost/python.hpp" Yep – just the include and thats it. VS2008, and python 2.6 Any ideas what I am doing wrong? Terry Rankine ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Boost-python wrapping a vector of vectors?
I'm trying to boost-python a vector-of-vectors, like
class A
{
public
A(const std::vector>& my_array);
};
and would intuitively write the wrapper:
BOOST_PYTHON_MODULE(foo)
{
using namespace boost::python
class_("A")
.def(init(std::vector >())
;
but get the error "a call to a constructor cannot appear in a constant
expression"
Can anyone supply any guidance as to how to wrap this? Thanks
Tim
Dr Tim Couper
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost-python wrapping a vector of vectors?
Tim Couper wrote:
I'm trying to boost-python a vector-of-vectors, like
class A
{
public
A(const std::vector>& my_array);
};
and would intuitively write the wrapper:
BOOST_PYTHON_MODULE(foo)
{
using namespace boost::python
class_("A")
.def(init(std::vector >())
;
but get the error "a call to a constructor cannot appear in a constant
expression"
Syntax error, init takes a type argument: init()
-t
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
