[vtk-developers] VTK CVS broken: vtkInformationExecutivePortVectorKey and vtkExecutive link error in Debug only

[Brad King]

Thompson, David C wrote:
> OK, I'll get this checked in today.

Great.  Please also move the corresponding information key classes back
to filtering.  Just leave the forward declarations in vtkInformation.h.

We should also consider marking these methods as legacy so that this
problem can be removed after the next release.  Since all of them are
just forwarding calls to methods defined on the executive-related
information key types it should be easy to replace all the calls to them
in VTK itself.

Thanks,
-Brad

> -----Original Message-----
> From: vtk-developers-bounces+dcthomp=sandia.gov at vtk.org on behalf of
> Brad King
> Sent: Fri 10/19/2007 8:30 AM
> To: Thompson, David C
> Cc: vtk-developers at vtk.org; Berk Geveci
> Subject: Re: [vtk-developers] VTK CVS broken:
> vtkInformationExecutivePortVectorKey and vtkExecutive link error in
> Debug only
> 
> David C Thompson wrote:
>> On Thu, 2007-10-18 at 16:05 -0400, Brad King wrote:
>>> The correct split would be to leave "vtkInformation" in Common, and then
>>> create a "vtkPipelineInformation" in Filtering that derives from
>>> vtkInformation ...
>>> this will break way too much code.  I think renaming the class in Common
>>> to vtkInformationBase and then leaving vtkInformation in Filtering will
>>> work.  ...
>>>
>>> I propose the following (radical) solution.  Instead of splitting the
>>> *interface* we should split the *implementation*.  All of the offending
>>> methods are non-virtual, so they will only be needed by the linker if
>>> someone calls them.  Code that links to vtkCommon only cannot possibly
>>> need information about vtkExecutive and therefore will not be calling
>>> the methods.  So what we need to do is take the implementation of
>>> executive-related vtkInformation methods and move it out of
>>> Common/vtkInformation.cxx and put it in a new
>>> Filtering/vtkInformation.cxx file.  The filtering version of the file
>>> would contain something like
>>
>> I would much prefer this to having vtkInformationBase. However, I the
>> Python/Tcl/Java wrappers would probably then be broken since there isn't
>> a way to split the wrapper code across libraries.
> 
> We'll just have to BTX/ETX the offending methods.  From wrapper
> languages the convenience methods do not add that much convenience
> anyway.  The key types can be directly used to extract information about
> executives.  Also, I don't think code using the wrapper languages would
> ever have to look at these keys.
> 
>> Also, I was under the impression that some linkers complain (fail?) when
>> some functions (not necessarily just virtual ones) are not implemented.
> 
> I don't think so.  Most VTK classes have copy constructors and
> assignment operators declared but purposely not implemented.  The linker
> will complain only if someone calls the method.
> 
> -Brad
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers