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

[Thompson, David C]

OK, I'll get this checked in today.

    David

-----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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20071019/ebfd2bc2/attachment.html>