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:stefan.atev@...]
Sent: 06 December 2010 21:03
To: Paul Smyth
Cc: Gehua Yang; vxl-users@...; vxl-maintainers@...
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 <paul.smyth@...> 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:yanggehua@...]
> Sent: Monday, December 06, 2010 7:10 PM
> To: Paul Smyth
> Cc: vxl-maintainers@...; vxl-users@...
> 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.
>
> http://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@...
> 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-users@...
> 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.
________________________________________________________________________

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:Markus.Moll@...]
Sent: 06 December 2010 22:15
To: Paul Smyth
Cc: Chuck Atkins; vxl-users@...; vxl-maintainers@...
Subject: Re: [Vxl-users] [Vxl-maintainers] unsigned int -> size_t for indexing
Hi
On Mon, 6 Dec 2010 21:42:10 -0000, "Paul Smyth" <paul.smyth@...>
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:chuck.atkins@...]
[...]
> 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.
________________________________________________________________________

Hi
On Mon, 6 Dec 2010 21:42:10 -0000, "Paul Smyth" <paul.smyth@...>
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:chuck.atkins@...]
[...]
> 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

Problem solved. For others who, like me, might come across this issue,
here's the problem.
The main page for the VXL project (http://vxl.sourceforge.net/) states:
"Each core library is lightweight, and can be used without reference to the
other core libraries. Similarly, the non-core libraries don't depend on more
than absolutely necessary, so you can compile and link just the libraries
you really need."
In short, I found that this is not true, at least for my build system
(Visual Studio 2010). Based on the simple example shown
http://public.kitware.com/vxl/doc/release/books/core/book_2.html, I figured
that I needed to link with just the vil.lib and vcl.lib files. As it turns
out, those files depend on additional libraries (ws2_32.lib, geotiff.lib,
jpeg.lib, png.lib, tiff.lib), which depend on further libraries (z.lib). In
fact, it was hint on
http://public.kitware.com/vxl/doc/release/books/core/book_16.html about the
ws2_32.lib that tipped me off to this solution.
On Mon, Dec 6, 2010 at 2:06 PM, Michael Repucci <michael@...> wrote:
> I tried the latest development version of VXL from the SVN trunk, and had
> the same problem. I also tried building VXL with VC++ 2008 Express Edition,
> which I'd rather not use, but had even more warnings and errors.
>
> Any ideas? Thanks!
>
>
> On Fri, Dec 3, 2010 at 4:39 PM, Michael Repucci <michael@...>wrote:
>
>> Well, my little hack worked in so far as the vil project compiles, but the
>> vil.lib has 75 unresolved external symbols that turn up when I try to use it
>> in a project. For example:
>>
>> vil.lib(vil_png.obj) : error LNK2019: unresolved external symbol
>> _png_destroy_read_struct referenced in function "public: __thiscall
>> vil_png_structures::vil_png_structures(bool)" (??0vil_png_structures@
>> @QAE@...@Z)
>>
>> which is indicating some problem with libpng. I'm rather at a loss of how
>> to proceed. Any help would be greatly appreciated. Thank you in advance!
>>
>>
>> On Fri, Dec 3, 2010 at 3:09 PM, Michael Repucci <
>> michael.repucci@...> wrote:
>>
>>> Hi Everyone, I'm new to VXL, and relatively new to CMake, so it's
>>> possible that my problem stems from a simple configuration setting of which
>>> I am unaware. I think I could hack together a solution to my problem, but I
>>> suspect that there is a better way.
>>>
>>> First some background. I'm using Visual Studio 2010 on Windows XP 64-bit
>>> (but compiling VXL for 32-bit). I downloaded VXL 1.14 and updated to CMake
>>> 2.8.3. With the CMake GUI I accepted the default configuration, and hit
>>> configure. Upon hitting configure for the second and third times, I get a
>>> large number of Windows error boxes (starting shortly after the "Looking for
>>> MFC - found" message appears) with the following information:
>>>
>>> Title: Windows - No Disk
>>> Message: Exception Processing Message c0000013 Parameters 7c7df5f8
>>> 96cfc118 7c7df5f8 7c7df5f8
>>> Buttons: Cancel, Try Again, Continue
>>>
>>> I can eventually continue past this stage, and generate the build files,
>>> which open successfully in Visual Studio 2010.
>>>
>>> But when I build the vil project I get hundreds of warnings, such as:
>>>
>>> .\..\..\v3p\zlib\gzio.c(106): warning C4996: 'strcpy': This function or
>>> variable may be unsafe. Consider using strcpy_s instead. To disable
>>> deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
>>> C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\include\string.h(105) : see declaration of 'strcpy'
>>>
>>> ..\..\..\v3p\tiff\tif_stream.cxx(62): warning C4244: 'return' :
>>> conversion from 'std::streamsize' to 'tsize_t', possible loss of data
>>>
>>> ..\..\..\v3p\geotiff\cpl_csv.c(139): warning C4996: 'stricmp': The POSIX
>>> name for this item is deprecated. Instead, use the ISO C++ conformant name:
>>> _stricmp. See online help for details.
>>> C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\include\string.h(246) : see declaration of 'stricmp'
>>>
>>> c:\mrepucci\c3vision\libs\vxl\core\vil\vil_rgb.h(80): warning C4800:
>>> 'int' : forcing value to bool 'true' or 'false' (performance warning)
>>>
>>> and eventually the error:
>>>
>>> ..\..\..\core\vil\vil_stream_url.cxx(234): error C2039: 'snprintf' : is
>>> not a member of 'std'
>>>
>>> where line 234 reads:
>>>
>>> vcl_snprintf(buffer, 4090, "GET /%s / HTTP/1.1\r\n", path.c_str());
>>>
>>> So I tracked down the definition of vcl_snprintf to vcl/vcl_cstdio.h.
>>> Since I'm running Visual Studio 2010, I believe that VCL_VC_10 is defined,
>>> which means that vcl_snprintf doesn't get defined to _snprintf as it does
>>> for earlier versions of Visual Studio (see line 28), which means that it
>>> gets the default from vcl/generic/vcl_cstdio.h line 162 as
>>> vcl_generic_cstdio_STD :: snprintf, where vcl_generic_cstdio_STD is defined
>>> as std in vcl/iso/vcl_cstdio.h. And hence the error.
>>>
>>> Now I'm tempted to just hack away and add VCL_VC_10 to line 28 of
>>> vcl/vcl_cstdio.h, but I can't be the only person running this type of
>>> system, so I'm guessing that there's a better solution. Any thoughts or
>>> suggestions?
>>>
>>
>>
>

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:chuck.atkins@...]
Sent: 06 December 2010 20:48
To: Paul Smyth
Cc: vxl-maintainers@...;
vxl-users@...
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@...
-- "Mathematicians are tools for turning coffee grounds into formulas.",
Paul Erdos
On Fri, Dec 3, 2010 at 6:00 PM, Paul Smyth <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.
http://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@...
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.
________________________________________________________________________

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@...]
Sent: Monday, December 06, 2010 7:10 PM
To: Paul Smyth
Cc: vxl-maintainers@...;
vxl-users@...
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.
http://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@...
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.
________________________________________________________________________

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.
> http://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@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

I tried the latest development version of VXL from the SVN trunk, and had
the same problem. I also tried building VXL with VC++ 2008 Express Edition,
which I'd rather not use, but had even more warnings and errors.
Any ideas? Thanks!
On Fri, Dec 3, 2010 at 4:39 PM, Michael Repucci <michael@...> wrote:
> Well, my little hack worked in so far as the vil project compiles, but the
> vil.lib has 75 unresolved external symbols that turn up when I try to use it
> in a project. For example:
>
> vil.lib(vil_png.obj) : error LNK2019: unresolved external symbol
> _png_destroy_read_struct referenced in function "public: __thiscall
> vil_png_structures::vil_png_structures(bool)" (??0vil_png_structures@@QAE@
> _N@...)
>
> which is indicating some problem with libpng. I'm rather at a loss of how
> to proceed. Any help would be greatly appreciated. Thank you in advance!
>
>
> On Fri, Dec 3, 2010 at 3:09 PM, Michael Repucci <michael.repucci@...
> > wrote:
>
>> Hi Everyone, I'm new to VXL, and relatively new to CMake, so it's possible
>> that my problem stems from a simple configuration setting of which I am
>> unaware. I think I could hack together a solution to my problem, but I
>> suspect that there is a better way.
>>
>> First some background. I'm using Visual Studio 2010 on Windows XP 64-bit
>> (but compiling VXL for 32-bit). I downloaded VXL 1.14 and updated to CMake
>> 2.8.3. With the CMake GUI I accepted the default configuration, and hit
>> configure. Upon hitting configure for the second and third times, I get a
>> large number of Windows error boxes (starting shortly after the "Looking for
>> MFC - found" message appears) with the following information:
>>
>> Title: Windows - No Disk
>> Message: Exception Processing Message c0000013 Parameters 7c7df5f8
>> 96cfc118 7c7df5f8 7c7df5f8
>> Buttons: Cancel, Try Again, Continue
>>
>> I can eventually continue past this stage, and generate the build files,
>> which open successfully in Visual Studio 2010.
>>
>> But when I build the vil project I get hundreds of warnings, such as:
>>
>> .\..\..\v3p\zlib\gzio.c(106): warning C4996: 'strcpy': This function or
>> variable may be unsafe. Consider using strcpy_s instead. To disable
>> deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
>> C:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\include\string.h(105) : see declaration of 'strcpy'
>>
>> ..\..\..\v3p\tiff\tif_stream.cxx(62): warning C4244: 'return' : conversion
>> from 'std::streamsize' to 'tsize_t', possible loss of data
>>
>> ..\..\..\v3p\geotiff\cpl_csv.c(139): warning C4996: 'stricmp': The POSIX
>> name for this item is deprecated. Instead, use the ISO C++ conformant name:
>> _stricmp. See online help for details.
>> C:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\include\string.h(246) : see declaration of 'stricmp'
>>
>> c:\mrepucci\c3vision\libs\vxl\core\vil\vil_rgb.h(80): warning C4800: 'int'
>> : forcing value to bool 'true' or 'false' (performance warning)
>>
>> and eventually the error:
>>
>> ..\..\..\core\vil\vil_stream_url.cxx(234): error C2039: 'snprintf' : is
>> not a member of 'std'
>>
>> where line 234 reads:
>>
>> vcl_snprintf(buffer, 4090, "GET /%s / HTTP/1.1\r\n", path.c_str());
>>
>> So I tracked down the definition of vcl_snprintf to vcl/vcl_cstdio.h.
>> Since I'm running Visual Studio 2010, I believe that VCL_VC_10 is defined,
>> which means that vcl_snprintf doesn't get defined to _snprintf as it does
>> for earlier versions of Visual Studio (see line 28), which means that it
>> gets the default from vcl/generic/vcl_cstdio.h line 162 as
>> vcl_generic_cstdio_STD :: snprintf, where vcl_generic_cstdio_STD is defined
>> as std in vcl/iso/vcl_cstdio.h. And hence the error.
>>
>> Now I'm tempted to just hack away and add VCL_VC_10 to line 28 of
>> vcl/vcl_cstdio.h, but I can't be the only person running this type of
>> system, so I'm guessing that there's a better solution. Any thoughts or
>> suggestions?
>>
>
>

Dear Paul,
This sounds like a great idea to me.
Joe Mundy
Brown University
From: Paul Smyth [mailto:paul.smyth@...]
Sent: Friday, December 03, 2010 6:01 PM
To: vxl-maintainers@...; vxl-users@...
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.
http://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.
________________________________________________________________________