[vtk-developers] Add GetModifiedTime deprecate GetMTime

[David Cole]

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

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.

Thanks, Ken, for working on this.


David C.




On Wednesday, August 3, 2016, Berk Geveci <berk.geveci at kitware.com> wrote:

> 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.
>
> On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin <ken.martin at kitware.com
> <javascript:_e(%7B%7D,'cvml','ken.martin at kitware.com');>> wrote:
>
>>
>> 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.
>>
>> I have created a sample topic here
>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 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).
>>
>> If we went with such a change I believe existing code would still work
>> unchanged (aside from a warning)
>>
>> 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.
>>
>> 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.
>>
>> It would be nice if I was missing some easy pain free solution here so
>> please holler if you see something, have thoughts, etc.
>>
>> Thanks
>> Ken
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> 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.
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160803/50003caa/attachment-0001.html>