<div dir="ltr">I tend to like that simpler solution as well.  The change is easy to explain, the compiler identifies the issues, and fixing them is easy.  Should the user want to support multiple versions of VTK on Windows (the change is a noop on Linux OSX IIRC), an ifdef can be used in the places where they override GetMTime to provide the old signature.<div><br></div><div>Ken</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 3, 2016 at 8:13 PM, David Cole <span dir="ltr"><<a href="mailto:DLRdave@aol.com" target="_blank">DLRdave@aol.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Berk: personally, I would prefer a simple change to the signature of GetMTime. Dealing with a documented method signature change when upgrading to a new version of VTK is less annoying than learning a new method name, even a similar one, and partially invalidating years of mailing list discussions about GetMTime (by changing its name)...<div><br></div><div>Again: not a strong preference, though, and will GLADLY use whatever is put into VTK. We have an app that can hit the overflow condition within about 45 minutes when running at full speed, and having a solution where we don't have to have a heavily patched VTK will be awesome.</div><div><br></div><div>Thanks, Ken, for working on this.</div><div><br></div><div><br></div><div>David C.</div><div><br></div><div><br><div><br></div><div><br>On Wednesday, August 3, 2016, Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Wouldn't it be better to just change the signature of GetMTime() to return a 64 bit int? Only subclasses would fail to compile. They should be very easy to fix. Any user of the GetMTime() method would cause a warning that can be safely ignored by the users of VTK. My personal preference would be to do that than to cause all users to switch to a new method (over time). Not a strong preference though.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin <span dir="ltr"><<a>ken.martin@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I am looking for some feedback here. We have a problem in VTK that on Windows unsigned long GetMTime is limited to 32 bits due to the type of unsigned long (even on 64 bit builds). This problem creeps up for any VTK application that runs for a long time (say 4 hours or more depending on what the application is doing). I feel like we need to fix this but from what I can see there is no trivially easy fix. Changing the signature of GetMTime would break external code that overrides GetMTime. So my thought is to add a new method called GetModifiedTime that returns a 64 bit unsigned int. Convert VTK to use this method and provide backwards compatibility support for external code to still compile/link/and work. </div><div><br></div><div>I have created a sample topic here <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/1724" target="_blank">https://gitlab.kitware.<wbr>com/vtk/vtk/merge_requests/<wbr>1724</a> that shows the basic idea.  In that topic I have not converted over all the other GetMTime calls in the VTK tree which I would want to do, rather it is just a topic to show the idea behind the change. I believe it handles the common cases properly with only one failure case I know of so far (documented in the comments for that topic).</div><div><br></div><div>If we went with such a change I believe existing code would still work unchanged (aside from a warning)</div><div><br></div><div>This change would allow external code to have both GetMTime and GetModifiedTime so that the external code would work with both old and new versions of VTK.</div><div><br></div><div>This change will cause some performance issues if VTK_LEGACY_GETMTIME is left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost but require external codes to be updated to GetModifiedTime.</div><div><br></div><div>It would be nice if I was missing some easy pain free solution here so please holler if you see something, have thoughts, etc.</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>Ken</div><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">Ken Martin PhD<div>Chairman & CFO<br>Kitware Inc.<br>28 Corporate Drive<br>Clifton Park NY 12065<br><a href="tel:518%20371%203971" value="+15183713971" target="_blank">518 371 3971</a><div><br></div><div><span style="font-size:10pt;font-family:Tahoma,sans-serif">This communication,
including all attachments, contains confidential and legally privileged
information, and it is intended only for the use of the addressee.  Access to this email by anyone else is
unauthorized. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken in reliance on it is prohibited and may be
unlawful. If you received this communication in error please notify us
immediately and destroy the original message. 
Thank you.</span></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/vtk-<wbr>developers</a><br>
<br>
<br></blockquote></div><br></div>
</blockquote></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Ken Martin PhD<div>Chairman & CFO<br>Kitware Inc.<br>28 Corporate Drive<br>Clifton Park NY 12065<br>518 371 3971<div><br></div><div><span style="font-size:10pt;font-family:Tahoma,sans-serif">This communication,
including all attachments, contains confidential and legally privileged
information, and it is intended only for the use of the addressee.  Access to this email by anyone else is
unauthorized. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken in reliance on it is prohibited and may be
unlawful. If you received this communication in error please notify us
immediately and destroy the original message. 
Thank you.</span></div></div></div>
</div>