From: Wheeler, F. W \(Research\) <wh...@cr...> - 2005-08-17 17:38:00
|
BCC provides, int64 atoi64(const char * s); while other compilers provide something like, long long strtoll (const char *S, char **PTR, int BASE); The additional functionality that comes from the 2 extra arguments is = not offered by BCC, and it is this 3 argument signature that will likely = be part of the standard. Providing vcl_strtoll in vcl makes sense to = me, since we can see it on the standards horizon. However, putting it = in vcl now would require implementing a more fully functional version = for BCC. Sooner or later, Borland will release another version of their free = compiler, or bcc 5.5.1 will be abandoned by VXL. We could wait for = either of those events and leave a few #ifdefs in nitf2* files. Fred Wheeler > -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > Sent: Wednesday, August 17, 2005 12:35 PM > To: p.v...@ie... > Cc: Wheeler, Frederick W (Research); Rob Radtke; VXL Maintainers List > (E-mail) > Subject: Re: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build >=20 >=20 > On Wed 17 Aug 2005, Peter Vanroose wrote: > > If ::strtoll indeed belongs in <cstdlib> according to the=20 > standard, the > > file vcl/generic/vcl_cstdlib.hhh must be adapted accordingly. >=20 > strtoll is not part of the current C++ standard (C++98), since it is > not in the C89 standard. The latest C standard, C99, introduces > strtoll, along with type "long long". It is likely that the next C++ > standard (C++0x) will also introduce it. >=20 > Only the latest versions of the compilers are C99 compatible. >=20 > Amitha. >=20 |
From: Wheeler, F. W \(Research\) <wh...@cr...> - 2005-08-19 19:22:38
|
Rob, Amitha Perera and I were just looking at this. We notice that when this = "using" line is commented out, bcc gets past the point where it has a = fatal error presently. It has a fatal error later, this time at = vil_nitf2_typed_array_field.h:81. And of course, this might lead to = link troubles. // partially overridden value method //using vil_nitf2_scalar_field::value; // COMMENT OUT virtual bool value(T& out_value) const { out_value =3D m_value; return true; } It is not clear to Amitha whether over-riding a non-templated base-class = member with a member of a templated sub-class is allowed by the = standard. Do you know for sure? In either case, bcc is not happy with = it. How difficult is it to restructure the code to avoid this = situation? We notice that there are further bcc internal compiler = errors under similar circumstances with using, and overriding one of = several virtual members (read/write in vil_nitf2_typed_array_field.h). Installing bcc is fast and easy and doesn't screw up anything else that = I've seen. Here are my notes on how I did it, in case you want to try = it out yourself. Borland C++ Compiler -------------------- # downloaded version 5.5.1 from http://altd.borland.com/hold/download/bcppbuilder/freecommandLinetools.ex= e ftp://ftpd.borland.com/hold/download/bcppbuilder/freecommandLinetools.exe= # very simple install process cygstart ~/hold/download/freecommandLinetools.exe - install to default location # The Borland readme.txt says to put these config files in # /cygdrive/c/Borland/BCC55, but that does not work and this does. cd /cygdrive/c/Borland/BCC55/Bin rm -f bcc32.cfg cat > bcc32.cfg <<EOF -I"c:\Borland\Bcc55\include" -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" EOF rm -f ilink32.cfg cat > ilink32.cfg <<EOF -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" EOF Fred Wheeler > -----Original Message----- > From: Rob Radtke [mailto:ro...@st...] > Sent: Thursday, August 18, 2005 12:09 PM > To: Wheeler, Frederick W (Research) > Subject: RE: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build >=20 >=20 > ->Sooner or later, Borland will release another version of their free > ->compiler, or bcc 5.5.1 will be abandoned by VXL. We could=20 > wait for either > ->of those events and leave a few #ifdefs in nitf2* files. >=20 > This sounds reasonable to me. I especially like it because it doesn't > require any immediate action j/k. On another note, I'm=20 > currently seeing > internal compiler errors from bcc when compiling a vil_nitf2=20 > file. Does > anyone have any clues as to what might be wrong there? >=20 > Rob >=20 >=20 >=20 |
From: Harry L. V. <hl...@st...> - 2005-08-19 22:36:12
|
Hi Fred, I'm actually the one responsible for the obscure partially overloaded methods, and don't know whether overriding a non-templated base class = member with a templated subclass is allowed by the standard. I just removed the 'using' statements, which I had added a couple days = ago, to suppress some compiler warnings, but in fact they shouldn't be = needed. It's OK for vil_nitf2_scalar_type_field<T>::value() to hide the other overloads of its parent value() method. =20 What is the policy on warnings in VXL? Should we insert directives to suppress expected compiler-specific warnings? I also renamed a pair of the read() and write() methods on vil_nitf2_field_formatter to eliminate some overload problems there. I'm hoping this will eliminate the errors. I'll be leaving on vacation shortly, so I won't have a chance to download and try bcc. I'll try to = check back later tonight to see if the compilers like the new code better. A = more complicatd workaround may need to wait until Rob gets back on Tuesday. Harry Voorhees | -----Original Message----- | From: vxl...@li...=20 | [mailto:vxl...@li...] On=20 | Behalf Of Wheeler, Frederick W (Research) | Sent: Friday, August 19, 2005 3:21 PM | To: Rob Radtke | Cc: VXL Maintainers List (E-mail); Perera, Amitha (Research) | Subject: RE: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build |=20 |=20 | Rob, |=20 | Amitha Perera and I were just looking at this. We notice=20 | that when this "using" line is commented out, bcc gets past=20 | the point where it has a fatal error presently. It has a=20 | fatal error later, this time at=20 | vil_nitf2_typed_array_field.h:81. And of course, this might=20 | lead to link troubles. |=20 | // partially overridden value method | //using vil_nitf2_scalar_field::value; // COMMENT OUT |=20 | virtual bool value(T& out_value) const { | out_value =3D m_value; | return true; | } |=20 | It is not clear to Amitha whether over-riding a non-templated=20 | base-class member with a member of a templated sub-class is=20 | allowed by the standard. Do you know for sure? In either=20 | case, bcc is not happy with it. How difficult is it to=20 | restructure the code to avoid this situation? We notice that=20 | there are further bcc internal compiler errors under similar=20 | circumstances with using, and overriding one of several=20 | virtual members (read/write in vil_nitf2_typed_array_field.h). |=20 | Installing bcc is fast and easy and doesn't screw up anything=20 | else that I've seen. Here are my notes on how I did it, in=20 | case you want to try it out yourself. |=20 | Borland C++ Compiler | -------------------- |=20 | # downloaded version 5.5.1 from | http://altd.borland.com/hold/download/bcppbuilder/freecommandL | inetools.exe | ftp://ftpd.borland.com/hold/download/bcppbuilder/freecommandLi | netools.exe |=20 | # very simple install process | cygstart ~/hold/download/freecommandLinetools.exe | - install to default location |=20 | # The Borland readme.txt says to put these config files in | # /cygdrive/c/Borland/BCC55, but that does not work and this does. |=20 | cd /cygdrive/c/Borland/BCC55/Bin |=20 | rm -f bcc32.cfg | cat > bcc32.cfg <<EOF | -I"c:\Borland\Bcc55\include" | -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" | EOF |=20 | rm -f ilink32.cfg | cat > ilink32.cfg <<EOF | -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" | EOF |=20 |=20 | Fred Wheeler |=20 |=20 |=20 | > -----Original Message----- | > From: Rob Radtke [mailto:ro...@st...] | > Sent: Thursday, August 18, 2005 12:09 PM | > To: Wheeler, Frederick W (Research) | > Subject: RE: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build | >=20 | >=20 | > ->Sooner or later, Borland will release another version of=20 | their free | > ->compiler, or bcc 5.5.1 will be abandoned by VXL. We could=20 | > wait for either | > ->of those events and leave a few #ifdefs in nitf2* files. | >=20 | > This sounds reasonable to me. I especially like it because=20 | it doesn't | > require any immediate action j/k. On another note, I'm=20 | > currently seeing | > internal compiler errors from bcc when compiling a vil_nitf2=20 | > file. Does | > anyone have any clues as to what might be wrong there? | >=20 | > Rob | >=20 | >=20 | >=20 |=20 |=20 | ------------------------------------------------------- | SF.Net email is Sponsored by the Better Software Conference & EXPO | September 19-22, 2005 * San Francisco, CA * Development=20 | Lifecycle Practices | Agile & Plan-Driven Development * Managing Projects & Teams *=20 | Testing & QA | Security * Process Improvement & Measurement *=20 | http://www.sqe.com/bsce5sf | _______________________________________________ | Vxl-maintainers mailing list | Vxl...@li... | https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |=20 |
From: Rob R. <ro...@st...> - 2005-08-23 07:32:26
|
I added code to vil_file_format so it now recognizes the new vil_nitf2_image class. I also added a number of test cases for NITF 2.x reading. The test cases cover the following items: - All four uncompressed data layouts - Band sequential (IMODE=S) - Band interleaved by block (IMODE=B) - Band interleaved by pixel (IMODE=P) - Band interleaved by row (IMODE=R) - A good sampling of data types - 8 bit unsigned int - 16 bit unsigned int - 32 bit signed int - float - double - One case where the "actual bits per pixel" is less than the "number of bits per pixel" and data is right justified - Both NITF 2.1 and 2.0 files I created all the test files myself so that they would be very small (less than 1kb each). There are a few more tests I'd like to implement, but this is a good start. Rob |
From: Wheeler, F. W \(Research\) <wh...@cr...> - 2005-08-22 13:00:44
|
Harry, It looks like the bcc build is all fixed up now. It's great to see. With regards to using directives to suppress warnings, hopefully someone = else will reply. I'm not sure whether we have a policy. There are some = warning suppression directives in VXL, but I think they are all to stop = warnings in system header files. Maybe this is moot now? It seems = there are almost no warning remaining in the nitf2 files. Thanks again for the NITF support in VXL. Regards, Fred > -----Original Message----- > From: Harry L. Voorhees [mailto:hl...@st...] > Sent: Friday, August 19, 2005 6:36 PM > To: Wheeler, Frederick W (Research); 'Rob Radtke' > Cc: 'VXL Maintainers List (E-mail)'; Perera, Amitha (Research) > Subject: RE: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build >=20 >=20 > Hi Fred, >=20 > I'm actually the one responsible for the obscure partially overloaded > methods, and don't know whether overriding a non-templated=20 > base class member > with a templated subclass is allowed by the standard. >=20 > I just removed the 'using' statements, which I had added a=20 > couple days ago, > to suppress some compiler warnings, but in fact they=20 > shouldn't be needed. > It's OK for vil_nitf2_scalar_type_field<T>::value() to hide the other > overloads of its parent value() method. =20 >=20 > What is the policy on warnings in VXL? Should we insert directives to > suppress expected compiler-specific warnings? >=20 > I also renamed a pair of the read() and write() methods on > vil_nitf2_field_formatter to eliminate some overload problems there. >=20 > I'm hoping this will eliminate the errors. I'll be leaving on vacation > shortly, so I won't have a chance to download and try bcc.=20 > I'll try to check > back later tonight to see if the compilers like the new code=20 > better. A more > complicatd workaround may need to wait until Rob gets back on Tuesday. >=20 > Harry Voorhees >=20 > | -----Original Message----- > | From: vxl...@li...=20 > | [mailto:vxl...@li...] On=20 > | Behalf Of Wheeler, Frederick W (Research) > | Sent: Friday, August 19, 2005 3:21 PM > | To: Rob Radtke > | Cc: VXL Maintainers List (E-mail); Perera, Amitha (Research) > | Subject: RE: [Vxl-maintainers] Re: Win2k_bcc-5.5.1_MinSizeRel build > |=20 > |=20 > | Rob, > |=20 > | Amitha Perera and I were just looking at this. We notice=20 > | that when this "using" line is commented out, bcc gets past=20 > | the point where it has a fatal error presently. It has a=20 > | fatal error later, this time at=20 > | vil_nitf2_typed_array_field.h:81. And of course, this might=20 > | lead to link troubles. > |=20 > | // partially overridden value method > | //using vil_nitf2_scalar_field::value; // COMMENT OUT > |=20 > | virtual bool value(T& out_value) const { > | out_value =3D m_value; > | return true; > | } > |=20 > | It is not clear to Amitha whether over-riding a non-templated=20 > | base-class member with a member of a templated sub-class is=20 > | allowed by the standard. Do you know for sure? In either=20 > | case, bcc is not happy with it. How difficult is it to=20 > | restructure the code to avoid this situation? We notice that=20 > | there are further bcc internal compiler errors under similar=20 > | circumstances with using, and overriding one of several=20 > | virtual members (read/write in vil_nitf2_typed_array_field.h). > |=20 > | Installing bcc is fast and easy and doesn't screw up anything=20 > | else that I've seen. Here are my notes on how I did it, in=20 > | case you want to try it out yourself. > |=20 > | Borland C++ Compiler > | -------------------- > |=20 > | # downloaded version 5.5.1 from > | http://altd.borland.com/hold/download/bcppbuilder/freecommandL > | inetools.exe > | ftp://ftpd.borland.com/hold/download/bcppbuilder/freecommandLi > | netools.exe > |=20 > | # very simple install process > | cygstart ~/hold/download/freecommandLinetools.exe > | - install to default location > |=20 > | # The Borland readme.txt says to put these config files in > | # /cygdrive/c/Borland/BCC55, but that does not work and this does. > |=20 > | cd /cygdrive/c/Borland/BCC55/Bin > |=20 > | rm -f bcc32.cfg > | cat > bcc32.cfg <<EOF > | -I"c:\Borland\Bcc55\include" > | -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" > | EOF > |=20 > | rm -f ilink32.cfg > | cat > ilink32.cfg <<EOF > | -L"c:\Borland\Bcc55\lib;c:\Borland\Bcc55\lib\PSDK" > | EOF > |=20 > |=20 > | Fred Wheeler > |=20 > |=20 > |=20 > | > -----Original Message----- > | > From: Rob Radtke [mailto:ro...@st...] > | > Sent: Thursday, August 18, 2005 12:09 PM > | > To: Wheeler, Frederick W (Research) > | > Subject: RE: [Vxl-maintainers] Re:=20 > Win2k_bcc-5.5.1_MinSizeRel build > | >=20 > | >=20 > | > ->Sooner or later, Borland will release another version of=20 > | their free > | > ->compiler, or bcc 5.5.1 will be abandoned by VXL. We could=20 > | > wait for either > | > ->of those events and leave a few #ifdefs in nitf2* files. > | >=20 > | > This sounds reasonable to me. I especially like it because=20 > | it doesn't > | > require any immediate action j/k. On another note, I'm=20 > | > currently seeing > | > internal compiler errors from bcc when compiling a vil_nitf2=20 > | > file. Does > | > anyone have any clues as to what might be wrong there? > | >=20 > | > Rob > | >=20 > | >=20 > | >=20 > |=20 > |=20 > | ------------------------------------------------------- > | SF.Net email is Sponsored by the Better Software Conference & EXPO > | September 19-22, 2005 * San Francisco, CA * Development=20 > | Lifecycle Practices > | Agile & Plan-Driven Development * Managing Projects & Teams *=20 > | Testing & QA > | Security * Process Improvement & Measurement *=20 > | http://www.sqe.com/bsce5sf > | _______________________________________________ > | Vxl-maintainers mailing list > | Vxl...@li... > | https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |=20 >=20 >=20 |