From: Paul S. <pau...@vi...> - 2010-12-03 23:19:44
|
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. ________________________________________________________________________ |
From: Joseph M. <mu...@le...> - 2010-12-06 11:26:23
|
Dear Paul, This sounds like a great idea to me. Joe Mundy Brown University From: Paul Smyth [mailto:pau...@vi...] Sent: Friday, December 03, 2010 6:01 PM To: vxl...@li...; vxl...@li... Subject: [Vxl-maintainers] unsigned int -> size_t for indexing 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. ________________________________________________________________________ |
From: Gehua Y. <yan...@gm...> - 2010-12-06 19:10:38
|
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...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Paul S. <pau...@vi...> - 2010-12-06 20:50:16
|
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:yan...@gm...] Sent: Monday, December 06, 2010 7:10 PM To: Paul Smyth Cc: vxl...@li...; vxl...@li... 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...@li... 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. ________________________________________________________________________ |
From: Paul S. <pau...@vi...> - 2010-12-06 23:45:51
|
Hi Stefan, The changes more-or-less amount to: T & operator[](unsigned int index) -> T & operator[](size_t index), and unsigned int size() const -> size_t size() const In a codebase that uses unsigned int for indexing, doing a lookup with an unsigned int will be fine, but calling size() and storing that as an unsigned int will require a lossy cast. But that will be the only warning-causing problem. I think the basic 'rightness' of size_t (uint32 on 32-bit, uint64 on 64-bit) still makes a lot of sense, especially as unsigned int is the current type. I agree that any conversion of signed->unsigned is a much bigger deal, which was why I think it's a separate and less clear-cut choice. I certainly don't agree that going from unsigned int -> ptrdiff_t (signed int32 on 32-bit and signed int64 on 64-bit) makes any sense, as introducing signedness where there was none is unnecessary. Will vxl eventually be expected to support >32-bit length vnl_vectors, or > 32 bit area vnl_matrices? I'd imagine so, in which case the bullet needs to be bitten. Cheers, Paul. -----Original Message----- From: Stefan Atev [mailto:ste...@gm...] Sent: 06 December 2010 21:03 To: Paul Smyth Cc: Gehua Yang; vxl...@li...; vxl...@li... Subject: Re: [Vxl-users] [Vxl-maintainers] unsigned int -> size_t for indexing I can feel your pain with unnecessary casts, but if and when you change the public api to use size_t, you will make life painfull for all those of us that decided to use unsigned ints in the parts of our codebase that does use vnl and vil. In my opinion, such warnings are not an adequate reason to change the API of a widely used project. Having gone through one conversion like that (which was worse because it went from signed int to size_t), I can tell you that you will have lingering bugs for a long time, precisely of the sort that was mentioned initially. The choice of size_t in STL is, if anything, annoying as hell - ptrdiff_t would have been so much kinder to the users. There is no reason to copy that decision, especially for image and matrix dimensions. Stefan On Mon, Dec 6, 2010 at 2:24 PM, Paul Smyth <pau...@vi...> wrote: > 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:yan...@gm...] > Sent: Monday, December 06, 2010 7:10 PM > To: Paul Smyth > Cc: vxl...@li...; vxl...@li... > 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...@li... > 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. > ________________________________________________________________________ > > ------------------------------------------------------------------------------ > 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-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > > ________________________________________________________________________ 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. ________________________________________________________________________ |
From: Ian S. <sc...@im...> - 2010-12-07 10:11:20
|
Can we keep this discussion on just vxl-maintainers only please. There is no need to bore vxl-users with the details. Ian. On 06/12/2010 23:19, Paul Smyth wrote: > Hi Stefan, > > The changes more-or-less amount to: > T& operator[](unsigned int index) -> T& operator[](size_t index), and > unsigned int size() const -> size_t size() const > > In a codebase that uses unsigned int for indexing, doing a lookup with an unsigned int will be fine, but calling size() and storing that as an unsigned int will require a lossy cast. But that will be the only warning-causing problem. > > I think the basic 'rightness' of size_t (uint32 on 32-bit, uint64 on 64-bit) still makes a lot of sense, especially as unsigned int is the current type. I agree that any conversion of signed->unsigned is a much bigger deal, which was why I think it's a separate and less clear-cut choice. I certainly don't agree that going from unsigned int -> ptrdiff_t (signed int32 on 32-bit and signed int64 on 64-bit) makes any sense, as introducing signedness where there was none is unnecessary. > > Will vxl eventually be expected to support>32-bit length vnl_vectors, or> 32 bit area vnl_matrices? I'd imagine so, in which case the bullet needs to be bitten. > > Cheers, Paul. > > -----Original Message----- > From: Stefan Atev [mailto:ste...@gm...] > Sent: 06 December 2010 21:03 > To: Paul Smyth > Cc: Gehua Yang; vxl...@li...; vxl...@li... > Subject: Re: [Vxl-users] [Vxl-maintainers] unsigned int -> size_t for indexing > > I can feel your pain with unnecessary casts, but if and when you > change the public api to use size_t, you will make life painfull for > all those of us that decided to use unsigned ints in the parts of our > codebase that does use vnl and vil. > > In my opinion, such warnings are not an adequate reason to change the > API of a widely used project. > > Having gone through one conversion like that (which was worse because > it went from signed int to size_t), I can tell you that you will have > lingering bugs for a long time, precisely of the sort that was > mentioned initially. > > The choice of size_t in STL is, if anything, annoying as hell - > ptrdiff_t would have been so much kinder to the users. There is no > reason to copy that decision, especially for image and matrix > dimensions. > > Stefan > > > On Mon, Dec 6, 2010 at 2:24 PM, Paul Smyth<pau...@vi...> wrote: >> 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:yan...@gm...] >> Sent: Monday, December 06, 2010 7:10 PM >> To: Paul Smyth >> Cc: vxl...@li...; vxl...@li... >> 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...@li... >> 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. >> ________________________________________________________________________ >> >> ------------------------------------------------------------------------------ >> 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-users mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-users >> >> > > ________________________________________________________________________ > 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-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > > |
From: Paul S. <pau...@vi...> - 2010-12-06 21:46:00
|
Hi Check, I completely agree that retaining BW compatibility of IO is essential. What's the view of FW compatibility - i.e. loading a file saved post- this change into an older version. I'd guess it's not a big deal if that breaks? Thanks, Paul. From: Chuck Atkins [mailto:chu...@ki...] Sent: 06 December 2010 20:48 To: Paul Smyth Cc: vxl...@li...; vxl...@li... 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 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Fri, Dec 3, 2010 at 6:00 PM, Paul Smyth <pau...@vi...> 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...@li... 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. ________________________________________________________________________ |
From: Markus M. <Mar...@es...> - 2010-12-06 22:14:58
|
Hi On Mon, 6 Dec 2010 21:42:10 -0000, "Paul Smyth" <pau...@vi...> wrote: > I completely agree that retaining BW compatibility of IO is essential. > What's the view of FW compatibility - i.e. loading a file saved post- > this change into an older version. I'd guess it's not a big deal if that > breaks? [...] > From: Chuck Atkins [mailto:chu...@ki...] [...] > Paul, > >>From a code perspective, I absolutely agree that size_t is the way to > go. Actually I think that Paul's assumption is flawed. The return type of std::vector<T>::size isn't necessarily size_t, it's an unspecified unsigned integral type (std::vector<T>::size_type). What's worse, that type can be different for different T. So even when porting everything to size_t (which might still be reasonable), user code would still have to deal with casting things explicitly to avoid warnings. Markus |
From: Paul S. <pau...@vi...> - 2010-12-06 23:19:18
|
Hi Markus, Obviously it isn't a perfect assumption in that std::vector<T>::size_type is not actually defined to be size_t, but in practice it is the most likely decision of an STL library writer. So while having a global index type in one's codebase may be technically problematic, I'd hope that in practice it isn't. Paul. -----Original Message----- From: Markus Moll [mailto:Mar...@es...] Sent: 06 December 2010 22:15 To: Paul Smyth Cc: Chuck Atkins; vxl...@li...; vxl...@li... Subject: Re: [Vxl-users] [Vxl-maintainers] unsigned int -> size_t for indexing Hi On Mon, 6 Dec 2010 21:42:10 -0000, "Paul Smyth" <pau...@vi...> wrote: > I completely agree that retaining BW compatibility of IO is essential. > What's the view of FW compatibility - i.e. loading a file saved post- > this change into an older version. I'd guess it's not a big deal if that > breaks? [...] > From: Chuck Atkins [mailto:chu...@ki...] [...] > Paul, > >>From a code perspective, I absolutely agree that size_t is the way to > go. Actually I think that Paul's assumption is flawed. The return type of std::vector<T>::size isn't necessarily size_t, it's an unspecified unsigned integral type (std::vector<T>::size_type). What's worse, that type can be different for different T. So even when porting everything to size_t (which might still be reasonable), user code would still have to deal with casting things explicitly to avoid warnings. Markus ________________________________________________________________________ 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. ________________________________________________________________________ |