This presents an interesting issue though. For compatibility, the binary I/O should be using uint32 then. However, does it make sense to have the data type present it's self as having 64 bit int dimensions when you can only serialize / deserialize it with 32 bit dimensions? Or are we okay with breaking backwards compatibility for writing by forcing uint64 for I/O (not reading though of course)? I.E. old vsl files can be read by new vsl code by but new vsl files can't be read by old vsl code?

My vote is for incrementing the I/O version number and always writing size elements as uint64. This would need to be done for every type that gets converted.

Does anybody have issue with incrementing the version number for I/O and always writing uint64 for sizes? Or perhaps there's a better way to adress the issue?


Chuck Atkins
R&D Engineer, Kitware, Inc.
(518) 371-3971 x603
chuck.atkins@kitware.com

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


On Mon, Dec 6, 2010 at 4:42 PM, Paul Smyth <paul.smyth@vicon.com> wrote:

Hi Check,

I completely agree that retaining BW compatibility of IO is essential. Whats the view of FW compatibility i.e. loading a file saved post- this change into an older version. Id guess its not a big deal if that breaks?

Thanks, Paul.

From: Chuck Atkins [mailto:chuck.atkins@kitware.com]
Sent: 06 December 2010 20:48


To: Paul Smyth
Cc: vxl-maintainers@lists.sourceforge.net; vxl-users@lists.sourceforge.net
Subject: Re: [Vxl-maintainers] unsigned int -> size_t for indexing

Paul,



>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.

Thoughts?


Chuck Atkins
R&D Engineer, Kitware, Inc.
(518) 371-3971 x603
chuck.atkins@kitware.com

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

On Fri, Dec 3, 2010 at 6:00 PM, Paul Smyth <paul.smyth@vicon.com> 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.

www.vicon.com


________________________________________________________________________
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 Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Vxl-maintainers mailing list
Vxl-maintainers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers


________________________________________________________________________
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.
________________________________________________________________________