Hi Paul and others, 

I have taken one small step before towards this direction: vbl_array_2d<T> and vbl_array_3d<T> had been fixed with size_t as the indexing type. 

However, as I started to think about what needs to be done inside vil and vnl, the answer is unclear to me.  I am going to take vil_image_view<T>  as an example and hope it would open up the discussion. 


Inside vil_image_view<T>,  I believe the top_left_ pointer, vil_memory_chunk, and the steps are all properly typed on 64 bit systems.   Only the indices to i, j and plane are currently 32-bit unsigned integers and may need a "upgrade". 

Is it worthy to have the indices "upgraded" to 64-bit integers?  On one hand,  such a change does not seem to bring forth any practical advantages.  Or at least I am unaware of it.  Unlike std::vector<T> which may contain more than 4 billion (roughly 2^32) elements,  I have not yet seen any images that have billion of pixels per dimension.  The number is at most millions, which is far below the limit of a 32-bit unsigned integer. (I would like to stress this is per dimension measurement.  The whole image may contain billions of pixels or beyond).  

If we "upgrade" the indices to 64-bit unsigned integers, we effectively waste some space (but it may not be a serious problem on 64-bit systems).  If we do not "upgrade", we save the space but may pay a small penalty for accessing a pixel as it converts 32-bit integer to 64-bit one each time. 
  
I am okay with either solution. I just think the community shall be aware of the problem, make a decision and then move forth.

Best regards,
Gehua Yang
DualAlign LLC
  



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