> Hi Thomas,
> You're right, it's a pythonOCC issue. I noticed it a couple of weeks > ago. Here is the problem: the occ.GeomLProp_SurfaceTool().Bounds > method takes 4 Standard_Real passed by reference. This means under C+ > + you do: > > Standard_Real a, b, c, d; > GeomLProp_SurfaceTool.Bounds(hsrf,a,b,c,d); > > and you can access the new values of a, b, c, d. > > In Python, it's impossible (no pointers in Python)! For instance, if > you have: > a = b = c = d = 0.0 > occ.GeomLProp_SurfaceTool.Bounds(hsrf,a,b,c,d) > then a still equals 0.0, and so b, c and d. So the Python wrapper > needs to transform this function so that is returns 4 Standard_Real. > > The good solution would be (under Python): > a, b, c, d = occ.GeomLProp_SurfaceTool.Bounds(hsrf) > > SWIG can handle function transformation in a very simple way, but I > did not have time to do that for the moment. I know a few other > methods are affected by this issue (for example the > BndLib.GetBoudingBox or something like that (not sure about the > function name)). Well if you'd supply 4 float, that would still be ok ( though not pythonic, clearly ) for me, if this is easier to implement perhaps? Thanks for your comments Thomas. Actually, I'm curious, do you think ctypes can be helpful here in overcoming these limitations? You know, it can still be a couple of months before these sort of kinks are ironed out, so in that sense, if its easy to overcome such trivial issues are passing by reference, it could be interesting to look into it? What do you think? I know its very hackish, but we have to be practical ;') -jelle _______________________________________________ Minerva-pythonocc mailing list Minerva-pythonocc@gna.org https://mail.gna.org/listinfo/minerva-pythonocc
