[vtk-developers] VTK CVS broken: vtkInformationExecutivePortVectorKey and vtkExecutive link error in Debug only
Thompson, David C
dcthomp at sandia.gov
Fri Oct 19 11:37:44 EDT 2007
OK, I'll get this checked in today.
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.
vtk-developers mailing list
vtk-developers at vtk.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vtk-developers