[postgis-devel] size_t: width and signedness of counters

Mateusz Loskot mateusz at loskot.net
Tue Jan 9 10:17:22 PST 2018


On 9 Jan 2018 6:31 pm, "Sandro Santilli" <strk at kbt.io> wrote:

On Tue, Jan 09, 2018 at 06:57:00AM -0800, Paul Ramsey wrote:
> On Sun, Dec 31, 2017 at 1:55 AM, Sandro Santilli <strk at kbt.io> wrote:
> > On Sat, Dec 30, 2017 at 12:53:26PM -0800, Paul Norman wrote:
> >>
> >> I've been in the habit of using size_t from C++, where it's what all
the STL
> >> size-related operators use, and thus what you get when you use auto.
> >
> > In C++ size_t is usually typedef'ed per-class, as if you could for
> > example define POINTARRAY::size_t to be == uint32_t
>
> Re-upping this, I don't have any objection to changing our counters
> (npoints, ngeoms) to uint32_t globally, if someone is willing to do
> all the grooming and cleaning that will imply.
> (referencing https://github.com/postgis/postgis/pull/183)
> I'm definitely not interested in going to size_t, cute though that is.

I'd note that Daniel Baston suggestion of npoints_t, ngeoms_t typedefs
is very similar to the C++ per-class typedef.



I'd note there are no per-class size_t aliases.
There is T::size_type however it is an old convention. These days memory
sizes in at library are guaranteed to be specified in std::size_t
(std::vector::size_type is std::size_t as is value returned by sizeof
operator or std::size() and similar functions).


Mateusz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180109/4e158967/attachment.html>


More information about the postgis-devel mailing list