[vtk-developers] MTime Olympics
Bill Lorensen
bill.lorensen at gmail.com
Mon Aug 15 16:14:10 EDT 2016
Will raised an interesting point regarding the typedef name.
vtkTypeMTime versus vtkMTimeType.
Most of vtk uses vtkFooType except in vtkType.h where vtkTypeFoo is preferred.
for example in vtkTypes.h
typedef unsigned char vtkTypeUInt8;
typedef signed char vtkTypeInt8;
typedef unsigned short vtkTypeUInt16;
typedef signed short vtkTypeInt16;
typedef unsigned int vtkTypeUInt16;
typedef signed int vtkTypeInt16;
typedef unsigned int vtkTypeUInt32;
typedef signed int vtkTypeInt32;
typedef unsigned long vtkTypeUInt32;
typedef signed long vtkTypeInt32;
typedef unsigned long long vtkTypeUInt64;
typedef signed long long vtkTypeInt64;
typedef unsigned long vtkTypeUInt64;
typedef signed long vtkTypeInt64;
typedef float vtkTypeFloat32;
typedef double vtkTypeFloat64;
typedef int vtkTypeBool;
typedef bool vtkTypeBool;
but
typedef long long vtkIdType;
typedef long vtkIdType;
typedef int vtkIdType;
And in the rest of VTK
+ DataSetType
+ LineType
+ DataType
+ PlotType
+ ComponentsType
+ MapType
Also, in ITK almost all typedefs are FooType, not TypeFoo.
I can easily change vtkTypeMTime to vtkMTimeType.
On Fri, Aug 12, 2016 at 4:14 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> +2 good point. Using a typedef is probably a good idea.
>
>
> On Fri, Aug 12, 2016 at 4:06 PM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>> 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
>>>
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
--
Unpaid intern in BillsBasement at noware dot com
More information about the vtk-developers
mailing list