From: Amitha P. <pe...@cs...> - 2002-10-03 13:57:15
|
"Ian Scott" <ian...@st...> writes: > add vxl_byte: > typedeffed to unsigned char 8-bit char platforms. ^^^^^^^^ > vil2 will use this instead of vil2_byte. > > add vxl_ubyte: > typedeffed to signed char 8-bit char platforms. ^^^^^^ > > remove vxl_int_8, vxl_sint_8, vxl_uint_8: > (As Peter pointed out) these are normally defined > to be char so > vcl_cout << (vxl_int_8)(65) << vcl_endl; > displays 'A' not 65. This is not int behaviour. > Use vxl_byte and vxl_ubyte instead. IMO, the (mis)behaviour when output is not enough to warrant the inconsistency created by the name change. I'll advocate instead that vil_byte be removed. To me, the key is the intended use of the type. All the vxl_int_* are being used as integers. That they are not all output as numbers is a minor nuisance. (If you have to code around for vxl_byte, you can code around for vxl_uint_8.) That said, since "byte" is not a C++ type, and since "byte" is widely understood to be 8-bits, I guess this is somewhat okay. A minor quibble is that I understand "byte" to be 8-bit unsigned, not 8-bit signed. If there is consensus on this, I would suggest that vxl_*_8 be deprecated and left around for a while. Some code (mine!) uses vxl_*_8... > remove vxl_sint_16, vxl_sint_32, vxl_sint_64. > These are defined by the C++ standard to > be equivalent to vxl_int_16, vxl_int_32, vxl_int_64. > Lets not have both. Agreed. > > If no-one objects I'll commit this change to the repository in a few days. > > Ian. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |