Le 27/01/2010 17:34, David Abrahams a écrit :
I'm not sure exactly what "enable the unit tests" means in this case.
Can you be explicit and/or preferably provide an illustrative patch?
As I'm a complete bjam noob, I made an attempt that is certainly clumsy
and/or inelegant.
The idea would
Microsoft calling
conventions. Did you consider that point ?
Best regards,
Nicolas.
Le 24/01/2010 03:10, David Abrahams a écrit :
At Fri, 15 Jan 2010 18:09:36 +0100,
Nicolas Lelong wrote:
My previous mail once again got lost, gotta be more careful...
Changes (by
IMO, the easiest route would be to wrap the member functions :
namespace {
std::string video_getDeviceName_wrapped(int deviceID)
{
char* name = videoInput::getDeviceName(devideID);
std::string result(name);
// free 'name' memory if needed
return result;
}
}
and then ::
using namespace
> Please file a trac ticket at svn.boost.org so that this does not get
lost.
OK Ravi, thanks for the pointer, I should have known
I submitted ticket #3833 (https://svn.boost.org/trac/boost/ticket/3833),
and will be happy to have feedback about it !
Cheers,
Nicolas.
_
My previous mail once again got lost, gotta be more careful...
Changes (by dave):
This looks terrific! I'll try to get it applied ASAP. Please poke me if
you don't see it in trunk by the end of the week.
Thanks ! As I didn't see the batch in trunk today, I poke you :)
> Please file a t
Simon,
it seems that I wrapped the same videoinput library you're using.
I wrapped the getPixels the following way : python script is responsible
of the memory allocation for pixels buffer (in a correctly sized string).
The getPixels function is wrapped as follows :
namespace {
bool video
Sending
again, as my original reply apparently got lost, sorry if it didn't.
IMO, the easiest route would be to wrap the member functions :
namespace {
std::string video_getDeviceName_wrapped(int deviceID)
{
char* name = videoInput::getDeviceName(devideID);
std::string result(name);
> 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.
;, &X::g1)
+.def("f2", &X::f2)
+.def("g2", &X::g2)
+.def("f3", &X::f3)
+.def("g3", &X::g3)
+.def("f4", &X::f4)
+.def("g4", &X::g4)
+.def("f5", &X::f5)
+.def("g5", &X::g
David wrote:
- I'm using a std::map that will be filled with more than 1 entries:
it's a private member of the class in the first case and a global in the
second case
That may be dumb, but are you sure that you reset your global data
structures before or after your free function call. When
You may disambiguate by using a cast inside .def(), such as
.def("getA", (A*(B::*)())B::getA);
Whether that's actually more readable is arguable, however.
IMHO, this is quite dangerous as the explicit cast prevents the compiler to
give you a proper error if the signature of B::getA changes
FWIW, it seems I can't reproduce the problem with current boost svn trunk code,
the problem still existed in boost_1_37_0 though. I could not spot the changes
made that fixed the problem.
I took a look at the shared_ptr aliasing constructor, and made a patch to my
boost_1_37_0 that solves the p
at could be applied in client code and/or in shared_ptr ?
Thanks for your time,
best regards,
Nicolas Lelong
mgdesign
Followed by Peter's answer that lead to Trac ticket #2584 :
Yes, I am aware of this problem. It is possible today to emulate the
proposed functionality by using t
13 matches
Mail list logo
