[vtk-developers] Add GetModifiedTime deprecate GetMTime

Ken Martin ken.martin at kitware.com
Tue Aug 9 14:18:42 EDT 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160809/d975a294/attachment.html>


More information about the vtk-developers mailing list