<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [vtk-developers] VTK CVS broken: vtkInformationExecutivePortVectorKey and vtkExecutive link error in Debug only</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

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

</BODY>
</HTML>