Hi Gehua,

 

I should have maybe been a little more clear in my motivations. The main practical reason is that in our codebase we have for some time built with warnings as errors, and usually try to avoid making frequent lossy casting. We made the decision ourselves to move to size_t for all indexing, as a knock-on effect of its use throughout the STL. So when this ‘policy’ collides with VXL, we have a few choices:

1)      Cast from size_t to unsigned int wherever we interact with VXL. Tedious.

2)      Somehow ‘accept’ these warnings by marking these as specifically tolerated. Dangerous, as our own code may be more likely to be 64-bit unsafe.

3)      Help VXL to move in-line with the STL by porting the code that we use most frequently (vnl/vil). A moderate amount of work, and maybe with small sizeof(vnl_vector) cost on 64-bit platforms only, but hopefully the right thing to do (tm).

The issue I believe is a little less to do with the actual storage capabilities of vnl/vil types, although it’s not completely impossible that it might arise.

Does that make anything at all clearer?

 

Cheers, Paul.

 

From: Gehua Yang [mailto:yanggehua@gmail.com]
Sent: Monday, December 06, 2010 7:10 PM
To: Paul Smyth
Cc: vxl-maintainers@lists.sourceforge.net; vxl-users@lists.sourceforge.net
Subject: Re: [Vxl-maintainers] unsigned int -> size_t for indexing

 

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,

We’re 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.

We’d 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.
________________________________________________________________________