From a code perspective, I absolutely agree that size_t is the way to go. I wish to exercise caution, however, when implementing the binary I/O side of things. A frequent problem I run into is sharing binary files written out with vsl between 32 and 64 bit platforms. While using size_t for everything presents a clean code API it becomes problematic for binary IO as one platform writes it as a uint32 for size_t while another tries to decode a uint64 size_t, which obviously doesn't work. I would suggest that for binary serialization purposes, that lengths and indexes and things of that nature always get written in uint64 while the api keeps the size_t.


Chuck Atkins
R&D Engineer, Kitware, Inc.
(518) 371-3971 x603

-- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos

On Fri, Dec 3, 2010 at 6:00 PM, Paul Smyth <> wrote:

Hi all,

Were increasingly using vxl (mostly vnl/vil) in a 64 bit Windows and Linux environment, and are repeatedly running into problems associated with the use of unsigned int rather than size_t for indexing into matrices, vectors, images etc., as this produces warnings absolutely everywhere we have used size_t as an indexing type (it is the type of std::vector<T>::size() ), and then use that to then index into a vnl/vil type.

Would it be unreasonable if we ported at least vnl & vil to use size_t in place of unsigned int?

Additionally, there are quite a few situations where (signed) int is used for indexing, in which case more care is required porting to size_t, as there is the possibility of the signed-ness being used: e.g. for(int i = v.size()-1; i >= 0; --i) {lookup v[i] } // loop through vector in reverse.

Wed like to sort out as many of those as possible, without causing too much risk. Opinions?

Cheers, Paul Smyth.

Vicon Motion Systems Ltd.

This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system.

What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more.
Vxl-maintainers mailing list