<!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>Brad et al.,<BR>
<BR>
I'm seeing some warnings on Windows about inconsistent<BR>
DLL linkage. Right now vtkInformation looks like:<BR>
<BR>
class VTK_COMMON_EXPORT vtkInformation : public vtkObject<BR>
{<BR>
// ...<BR>
void MethodInCommon();<BR>
void MethodInFiltering();<BR>
};<BR>
<BR>
I'm not familiar with Windows import/export behavior. Should<BR>
I change it to<BR>
<BR>
class VTK_COMMON_EXPORT vtkInformation : public vtkObject<BR>
{<BR>
// ...<BR>
void MethodInCommon();<BR>
VTK_FILTERING_EXPORT void MethodInFiltering();<BR>
};<BR>
<BR>
or<BR>
<BR>
class vtkInformation : public vtkObject<BR>
{<BR>
// ...<BR>
VTK_COMMON_EXPORT void MethodInCommon();<BR>
VTK_FILTERING_EXPORT void MethodInFiltering();<BR>
};<BR>
<BR>
or something else entirely?<BR>
<BR>
Thanks,<BR>
David<BR>
<BR>
-----Original Message-----<BR>
From: Brad King [<A HREF="mailto:brad.king@kitware.com">mailto:brad.king@kitware.com</A>]<BR>
Sent: Fri 10/19/2007 8:43 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>
Thompson, David C wrote:<BR>
> OK, I'll get this checked in today.<BR>
<BR>
Great. Please also move the corresponding information key classes back<BR>
to filtering. Just leave the forward declarations in vtkInformation.h.<BR>
<BR>
We should also consider marking these methods as legacy so that this<BR>
problem can be removed after the next release. Since all of them are<BR>
just forwarding calls to methods defined on the executive-related<BR>
information key types it should be easy to replace all the calls to them<BR>
in VTK itself.<BR>
<BR>
Thanks,<BR>
-Brad<BR>
<BR>
> -----Original Message-----<BR>
> From: vtk-developers-bounces+dcthomp=sandia.gov@vtk.org on behalf of<BR>
> 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:<BR>
> vtkInformationExecutivePortVectorKey and vtkExecutive link error in<BR>
> 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>
><BR>
> ------------------------------------------------------------------------<BR>
><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>
<BR>
</FONT>
</P>
</BODY>
</HTML>