[vtk-developers] MTime Olympics

[Shawn Waldon]

On Fri, Aug 12, 2016 at 4:03 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> +2 Dave
>
> I wonder if we will need to change in the future...
>

When we drop support for pre-C++11 compilers, we should probably change to
use the new uint64_t everywhere regardless of the size of long.

>
>
> On Fri, Aug 12, 2016 at 3:50 PM, David Cole <DLRdave at aol.com> wrote:
> > Think of how easy this fix would have been if vtkTypeMTime had already
> > existed .....
> >
> >
> >
> > On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> >> One advantage of naming a type is for backward compatibility:
> >> // Select an unsigned 64-bit integer type for use in MTime values.
> >> // If possible, use 'unsigned long' as we have historically.
> >> #if VTK_SIZEOF_LONG == 8
> >> typedef unsigned long vtkTypeMTime;
> >> #else
> >> typedef vtkTypeUInt64 vtkTypeMTime;
> >> #endif
> >>
> >> also for apps that need to support old and new versions of VTK:
> >> // Provide this define to facilitate apps that need to support older
> >> // versions that do not have vtkTypeMTime
> >> #ifndef VTK_HAS_TYPE_MTIME
> >> #if VTK_SIZEOF_LONG == 8
> >> typedef unsigned long vtkTypeMTime;
> >> #else
> >> typedef vtkTypeUInt64 vtkTypeMTime;
> >> #endif
> >> #endif
> >>
> >>
> >> On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> >>> I also prefer vtkTypeUInt64 but not a strong preference. Both look
> good to
> >>> me.
> >>>
> >>> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin <ken.martin at kitware.com>
> wrote:
> >>>>
> >>>> Oh, I am fine with the approach you took Bill and so haven't pushed
> the
> >>>> other changes I have locally. I just want the 32bit issue fixed as I
> think
> >>>> that is really important. I am flexible on how it gets fixed.
> >>>>
> >>>> I am not a fan of introducing another typedef as I feel it makes the
> code
> >>>> harder to understand, but that is a really small issue and I can
> definitely
> >>>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So
> once
> >>>> your topic is baked let's get it committed.
> >>>>
> >>>> Ken
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen <
> bill.lorensen at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Folks,
> >>>>>
> >>>>> We have two topics that fix the Windows mtime overflow issue for
> >>>>> Windows. This seems like a critical issue for Windows apps that run
> >>>>> for a long time (e.g. surgical applications).
> >>>>>
> >>>>> Topic 1:
> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724
> >>>>> Files changed: 376
> >>>>>
> >>>>> Topic 2:
> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790
> >>>>> Files changed: 471
> >>>>>
> >>>>> The major difference is that topic 1 defines MTime as an unsigned
> long
> >>>>> and topic 2 introduces a new type vtkTypeMTime.
> >>>>>
> >>>>> Topic 2 could be easily changed to use unsigned long for the mtime.
> >>>>>
> >>>>> Please take some time to review these topics. I suspect that some
> >>>>> combination of the two will help solve the problem.
> >>>>>
> >>>>> Bill
> >>>>> _______________________________________________
> >>>>> 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.
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
>
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160812/de679ef1/attachment-0001.html>