# size\_t and vtkIdType (aka int, long or long long)

**URL:** <https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062>\
**Category:** Development\
**Created:** [April 15, 2020, 7:00pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062 "2020-04-15T19:00:21Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ron84](https://discourse.vtk.org/user_avatar/discourse.vtk.org/ron84/32/630_2.png) [@Ron84](https://discourse.vtk.org/u/Ron84)\
**Post date:** [April 15, 2020, 7:00pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/1 "2020-04-15T19:00:22Z")

</div>

What’s your opinion about the use of size\_t for arguments in VTK that are defined as vtkIdType? Look at this:

```auto
// p is a vector
std::size_t i, num = p.size();

vtkIdList *cell = vtkIdList::New();
cell->SetNumberOfIds(num); // what happens if num is bigger than int?

for (i = 0; i < num; i++) {
    cell->SetId(i, p[i]); // also here
}

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [April 15, 2020, 7:35pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/2 "2020-04-15T19:35:15Z")

</div>

`size_t` isn’t viable because the fact that `vtkIdType` is signed is important. The other is that 64-bit builds with 32-bit ID types are still useful (decent memory savings).

Usually we just `static_cast` the warnings away though proper checks should actually be done.

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [April 15, 2020, 8:01pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/3 "2020-04-15T20:01:06Z")

</div>

Python and Java do not have native unsigned integer types, so it’s good to limit the use of unsigned types in the VTK API. But I agree that vtkIDType is inconvenient when working with STL.

---

<div class="post-metadata">

**Author:** ![Ron84](https://discourse.vtk.org/user_avatar/discourse.vtk.org/ron84/32/630_2.png) [@Ron84](https://discourse.vtk.org/u/Ron84)\
**Post date:** [April 15, 2020, 8:03pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/4 "2020-04-15T20:03:04Z")

</div>

What’s a good practice? The compiler does not print any warning.

---

<div class="post-metadata">

**Author:** ![seanm](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/s/a88e4f/32.png) [@seanm](https://discourse.vtk.org/u/seanm)\
**Post date:** [April 15, 2020, 8:12pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/5 "2020-04-15T20:12:58Z")

</div>

It may also come to pass that C++ STL changes from using unsigned to signed size types.

[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r2.html](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r2.html)

Ronald, -Wconversion should be able to warn.

---

<div class="post-metadata">

**Author:** ![Ron84](https://discourse.vtk.org/user_avatar/discourse.vtk.org/ron84/32/630_2.png) [@Ron84](https://discourse.vtk.org/u/Ron84)\
**Post date:** [April 15, 2020, 8:34pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/6 "2020-04-15T20:34:44Z")

</div>

> [@seanm](#):
>
> -Wconversion

This is a very bad idea 🤣 😂 🤪

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [April 15, 2020, 8:41pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/7 "2020-04-15T20:41:29Z")

</div>

MSVC does it by default, so usually we fix the warnings from that compiler. Doesn’t make them not bugs in the other compilers.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [April 15, 2020, 8:44pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/8 "2020-04-15T20:44:09Z")

</div>

> [@seanm](#):
>
> It may also come to pass that C++ STL changes from using unsigned to signed size types.

I think the most we can expect is an `ssize()` method (though not even that; seems we get `std::ssize(container)` instead). Hopefully these have assertions or something internally if the size does grow beyond `std::ssize_t`.

---

<div class="post-metadata">

**Author:** ![Ron84](https://discourse.vtk.org/user_avatar/discourse.vtk.org/ron84/32/630_2.png) [@Ron84](https://discourse.vtk.org/u/Ron84)\
**Post date:** [April 15, 2020, 8:48pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/9 "2020-04-15T20:48:54Z")

</div>

But the signed/unsigned is not the problem. It’s the range of both types.

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [April 15, 2020, 9:28pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/10 "2020-04-15T21:28:21Z")

</div>

By default, vtkIdType is configured to have the same width as size\_t. The only time you will see a 32-bit vtkIdType with a 64-bit size\_t is if you build VTK with VTK\_USE\_64BIT\_IDS=OFF.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [April 15, 2020, 9:34pm UTC](https://discourse.vtk.org/t/size-t-and-vtkidtype-aka-int-long-or-long-long/3062/11 "2020-04-15T21:34:21Z")

</div>

Signed vs. unsigned is _a_ problem. This code can be optimized much more easily in C or C++:

```auto
for (int i = 0; i <= N; ++i)
    do_something(i);

```

_because_ signed overflow is UB. Because it is UB, the compiler can assume it doesn’t happen and can unroll your loop. Change `int` to unsigned, and if the compiler can’t prove N isn’t `UINT_MAX`, it has to pessimize.

In any case, `.size()` on containers will be unsigned forever and it looks like `std::ssize(container)` will be the C++20 solution for these things.

But `vtkIdType` can be 32-bit even on 64-bit platforms, so range checking is actually always needed.