Scripting interface does not respect const qualifier

[tmodes]

The script interface does not respect the const qualifier to some (member) functions.
E.g. Panorama::GetImages returns a const SrcImage. In C++ you can not modify it, but it works in Python. So in the scripting interface also the const qualifier should be respected.

[KFJ (kfj)]

On 27.06.2013 21:20, Launchpad Bug Tracker wrote:
> tmodes (tmodes) has assigned this bug to you for Hugin:
>
> The script interface does not respect the const qualifier to some (member) functions.
> E.g. Panorama::GetImages returns a const SrcImage. In C++ you can not modify it, but it works in Python. So in the scripting interface also the const qualifier should be respected.
>
> ** Affects: hugin
> Importance: Undecided
> Assignee: KFJ (kfj)
> Status: Confirmed

Well, thanks for assigning me this task, but I fear I won't be able do
anything about it. Have a look at

http://www.swig.org/Doc2.0/SWIGDocumentation.html#SWIGPlus_const

I don't think making the python interface respect all uses of const is
an easy task, if at all feasible. If you look at the i-file, you'll see
that I have very rarely wrapped anything specific, but instead used the
feed-swig-the-whole-header approach. Going into the details would
require way more work.

I do think though that the complete state of the Panorama is stored
before any plugin is called, and so all changes which might lead into
trouble because const is not honoured can be undone after the plugin's
run. And if you want to be on the safe side you can always store the
panorama before the plugin is called.

Kay

[tmodes (tmodes)]

This issue can also cause trouble inside the script, if the Python script is using the Panorama object or the like in a not intended way. The const qualifier have their reason in the C++ code. If the script is first using a const object to write and then the next step will work with an undefined state of the whole object. So the script works not correctly. And in this case it does not help, if the C++ part is called later.

So please respect that and do not post code where you know that you are violating the const qualifier. This is not a help for new developer.

[KFJ (kfj)]

On 28.06.2013 18:14, tmodes wrote:
> This issue can also cause trouble inside the script, if the Python
> script is using the Panorama object or the like in a not intended way.
> The const qualifier have their reason in the C++ code. If the script is
> first using a const object to write and then the next step will work
> with an undefined state of the whole object. So the script works not
> correctly. And in this case it does not help, if the C++ part is called
> later.
>
> So please respect that and do not post code where you know that you are
> violating the const qualifier. This is not a help for new developer.

Are you referring to my posting to hugin-ptx

https://groups.google.com/forum/#!topic/hugin-ptx/G8WZwCPZo7c

If so, I think I have explicitly stated that one shouldn't do what I'm
doing in that plugin. It works, though - and it can be used standalone,
which is helpful with a workflow which uses mainly command-line tools.
When using the script standalone, I suppose all the
const-qualifier-violations are irrelevant.

I felt the chance that some people might benefit from something I made
which works for me is worth more than the violation of a rule which so
far hasn't produced any problems. So I posted it. It's not in the repo
because of your objections, and that's fair enough because I see your
point, but I can't see anything wrong in posting it on hugin-ptx.

Anyway, I don't think the python interface can feasibly be changed to
respect const qualifiers properly, so all we can do is tell hsi/hpi
users to beware and avoid modifying objects which are qualified const in
the C++ sources. Once we have a proper API the problem should disappear.

Kay