[vtk-developers] Add GetModifiedTime deprecate GetMTime

Tue Aug 9 14:20:19 EDT 2016

My topic has 447 changed files. I'll be pushing it soon...

On Tue, Aug 9, 2016 at 2:18 PM, Ken Martin <ken.martin at kitware.com> wrote:
> Sounds good, my topic is missing one or two (hundred) changes :-) Have to
> force the compiler to error on possible overflow.
>
>
> On Tue, Aug 9, 2016 at 1:47 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> There are some advantages to a new typedef.
>>
>> 1) In the future, a more sophisticated type might be needed.
>> 2) To see if all unsigned long's have been changed, the typedef can be
>> changed to something like "double" and detect missing conversions.
>>
>> I'll post a topic soon that defines a new typedef and we can see which
>> topic make sense. Since I've used 2), I can always change vtkTypeMTime
>> to vtkTypeUInt64...
>>
>>
>> On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin <ken.martin at kitware.com>
>> wrote:
>> > I feel the additional typedef makes it more confusing as you do not know
>> > what the type is. vtkTypeUInt64 I can understand from its name. If
>> > everyone
>> > wants a new typedef I can certainly live with it though but I would
>> > still
>> > rather it be consistent on unix and windows, so that people can fix the
>> > issue on Unix and have some confidence it will work/compile on Windows.
>> >
>> > I have an updated topic here
>> >
>> > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724
>> >
>> >
>> >
>> > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> > wrote:
>> >>
>> >> Why not in vtkType.h
>> >> #if defined(WIN32)
>> >> typedef vtkTypeUInt64 vtkTypeMTime;
>> >> #else
>> >> typedef unsigned long vtkTypeMTime;
>> >> #endif
>> >>
>> >> In vtkObject.h and other GetMTimes'
>> >>   virtual vtkTypeMTime GetMTime();
>> >>
>> >> Windows apps will have to change their GetMTimes' in their VTK derived
>> >> subclasses.
>> >>
>> >>
>> >>
>> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard
>> >> <robert.maynard at kitware.com> wrote:
>> >> > I agree with David. I prefer correctness to full backwards
>> >> > compatibility, especially so with something like consistently having
>> >> > 64bit MTimes on all platforms.
>> >> >
>> >> > Personally I don't see the value in having the return type as a
>> >> > typedef compared to having the caller do a static cast ( which is
>> >> > what
>> >> > MTime would have to do internally ).
>> >> >
>> >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers
>> >> > <vtk-developers at vtk.org> wrote:
>> >> >> Except.... I think fixing the overflow bug on Windows is more
>> >> >> important than full source compatibility. A default build (no need
>> >> >> to
>> >> >> set anything in CMake) of the new version of VTK on Windows with
>> >> >> this
>> >> >> capability should result in 64-bit MTime values and avoid the
>> >> >> overflow
>> >> >> condition.
>> >> >>
>> >> >> I prefer correctness to full/100% backwards compatibility.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride
>> >> >> <sean at rogue-research.com>
>> >> >> wrote:
>> >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers
>> >> >>> said:
>> >> >>>
>> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a
>> >> >>>>type for the return value of GetMTime, and then allow for user
>> >> >>>>definition of that type. Default to uint64_t, but allow for user
>> >> >>>>definition.
>> >> >>>
>> >> >>> Was just going to suggest that.  It could be typedefed to exactly
>> >> >>> what
>> >> >>> it is today, giving full source compatibility; and then if you
>> >> >>> build with
>> >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64
>> >> >>> bit type.
>> >> >>>
>> >> >>> Cheers,
>> >> >>>
>> >> >>> --
>> >> >>> ____________________________________________________________
>> >> >>> Sean McBride, B. Eng                 sean at rogue-research.com
>> >> >>> Rogue Research                        www.rogue-research.com
>> >> >>> Mac Software Developer              Montréal, Québec, Canada
>> >> >>>
>> >> >>>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >>
>> >> > _______________________________________________
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Unpaid intern in BillsBasement at noware dot com
>> >> _______________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --
>> > 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.
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
> --
> 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.

-- 
Unpaid intern in BillsBasement at noware dot com