[Insight-developers] Swig Wrapping Warnings.

[Luis Ibanez]

Hi Hans,

As a suggestion...

I found useful to separate the Wrapping build from the
standard ITK build in terminus.kitware.  That is, there
is a normal build and there is a separate build only for
  wrapping which has C++_TEST disabled.  In that way you
can manage to have a high level of warnings for the
standard build and then a more relaxed setup for the
wrapping build.

My 2 cents,

   Luis


----------------------
Hans J. Johnson wrote:

> Bill,
> 
> OK.  I'll turn these off again.  About 2 weeks ago on the ITK
> teleconference call it was requested that these compiler flags be tuned
> on so that an attempt to fix this could be made.
> 
> This means that I'll have to turn the warning flags off for all of ITK,
> and not just the wrapped part.
> 
> Regards,
> Hans
> 
> 
> On Mon, 2004-04-05 at 11:00, William A. Hoffman wrote:
> 
>>Since swig is a moving target, and we do updates from time to time, it may
>>be best to try and turn off warning checking for the generated code.  The
>>code is either correct or it is not, fixing warnings is not really a productive
>>exercise for swig generated wrappers.  Many times the problems show
>>up because C++ use const much more than C, swig generated code usually has
>>to be able to be compiled by an ANSI C compiler, and many of the warning fixes
>>break in C, but work in C++.
>>
>>-Bill
>>
>>
>>At 11:33 AM 4/5/2004, Hans J. Johnson wrote:
>>
>>>Hello Wrapping Experts,
>>>
>>>I've been attempting to get rid of compiler warnings from CableSwig tcl
>>>wrapped code.  The first set of changes were relativly easy to make, and
>>>eliminated about 7000 warnings.  Unfortunatly there are still about 5000
>>>warnings left to go.
>>>
>>>I beleive that one fix in cable swig will get rid of them, but I've been
>>>unable to successfully figure out how to do it.  The problem is that
>>>Swig chops off all const qualifiers for any local variable that will be
>>>an lvalue.  This is OK for non-pointer (non-reference) types, because
>>>the behavior does not affect the safety of the code, or it's use.  This,
>>>however, is not the case for pointers where the const is specified
>>>before the '*'.  
>>>
>>>e.g.
>>>===================================================================================================================
>>>static int
>>>_wrap_itkLightObject_GetNameOfClass(ClientData clientData, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[]) {
>>>   (void)clientData; (void)interp; (void)objc; (void)objv;
>>>   itk::LightObject *arg1 = (itk::LightObject *) 0 ;
>>>   char *result;
>>>
>>>   if (SWIG_GetArgs(interp, objc, objv,"o:itkLightObject_GetNameOfClass self ",0) == TCL_ERROR) SWIG_fail;
>>>   if ((SWIG_ConvertPtr(objv[1], (void **) &arg1, SWIGTYPE_p_itk__LightObject,SWIG_POINTER_EXCEPTION | 0) != TCL_OK)) SWIG_fail;
>>>   try {
>>>       result = (char *)((itk::LightObject const *)arg1)->GetNameOfClass();
>>>   }
>>>   catch(std::exception &_e) {
>>>       {
>>>           SWIG_exception(SWIG_RuntimeError, const_cast<char*>(_e.what()));
>>>       }
>>>   }
>>>   Tcl_SetObjResult(interp,Tcl_NewStringObj(result,-1));
>>>   return TCL_OK;
>>>   fail:
>>>   return TCL_ERROR;
>>>}
>>>===================================================================================================================
>>>Two changes could remove the compiler warnings in the previous code snip are: 
>>>(a) change the type of result to "const char * reusult;" and change/remove the type casting in the try block.
>>>(b) use a const_cast<char *>() in the try block instead of the c-style (char *)---(const char *) may also work.
>>>
>>>I've spent a few days trying to learn the swig wrapping mechanism well enough to make these changes, but have not
>>>found a complete working solution and have not been confident that the partial solutions would not break other 
>>>wrappings.  A patch that does the first 1/2 of option (a) is attached to this e-mail.  I could not track down where
>>>the second part was being constucted.
>>>
>>>I will not be able to devote any more time to this.
>>>
>>>Sorry,
>>>Hans J. Johnson
>>>hans-johnson at uiowa.edu
>>>
>>>
>>>
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>