From: Amitha P. <pe...@cs...> - 2003-11-13 04:46:57
|
Hi all Does it make sense for VXL to add compiler options to make the compiler more standards compliant? For example, adding the flag /Za to the Microsoft compiler disables MS extensions and fixes some things, like the scope of the variable in a for loop. Since VXL is meant to be in Standard C++, and given that vcl tries to fix the system standard library to be Standard, I think that we should forcefully add compiler options that make the compiler as standards compliant as possible. This should apply to the MS compiler (/Za), to the MIPSpro compiler (-Llang:std), and any other compiler. However, I think this effect will percolate to the "private" projects that use VXL. I feel that's okay, and if it causes trouble, those projects should fix their code to be C++. But I'd appreciate other opinions before I start looking into this further. Thanks, Amitha. |
From: Ian S. <ian...@st...> - 2003-11-13 09:53:54
|
Put it in as an option- default off. Have the dashboards turn it on manually. Ian. > -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > Sent: Thursday, November 13, 2003 4:47 AM > To: vxl...@li... > Subject: [Vxl-maintainers] Compiler options to force std C++? > > > Hi all > > Does it make sense for VXL to add compiler options to make the > compiler more standards compliant? > > For example, adding the flag /Za to the Microsoft compiler disables MS > extensions and fixes some things, like the scope of the variable in a > for loop. > > Since VXL is meant to be in Standard C++, and given that vcl tries to > fix the system standard library to be Standard, I think that we should > forcefully add compiler options that make the compiler as standards > compliant as possible. This should apply to the MS compiler (/Za), to > the MIPSpro compiler (-Llang:std), and any other compiler. > > However, I think this effect will percolate to the "private" projects > that use VXL. I feel that's okay, and if it causes trouble, those > projects should fix their code to be C++. But I'd appreciate other > opinions before I start looking into this further. > > Thanks, > Amitha. > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <pe...@cs...> - 2003-11-13 15:13:41
|
Ian Scott wrote: > Put it in as an option- default off. Have the dashboards turn it on > manually. Fred Wheeler wrote: > > Sounds like a fine idea to me. > > Perhaps we could start with Ian's suggestion and migrate to default-on some > time in the future. I think the dashboards must always build with the "default" options. Otherwise, the dashboards may all be green, but a poor user downloads vxl, tries to build, and *boom*, everything is broken. It is sometimes reasonable for the dashboards to do something slightly different for testing purposes---as we did for the CMake try-compile stuff---but that works when the default options are known to work. If the dashboards have the strict compliance turned on, then code like for( int i = 0; i < e; ++i ) { } class_x i; will compile on the dashboard but not on your desktop. (At least on Windows.) And that is bad. Amitha. |
From: Ian S. <ian...@st...> - 2003-11-13 15:37:52
|
> -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > > Ian Scott wrote: > > Put it in as an option- default off. Have the dashboards turn it on > > manually. > > I think the dashboards must always build with the "default" > options. Otherwise, the dashboards may all be green, but a poor user > downloads vxl, tries to build, and *boom*, everything is broken. Fair point. Solution 1: don't have the dashboards all turn this option on. Anyone who wants to test the idea can turn it on for an experimental build. Solution 2: Put it in the build by default, but be ready to take it out again if anyone raises any serious objections. I am worried that turning on strict ISO will involve a large amount of relatively unproductive work. e.g. some of the work-arounds in vcl could be illegal in strict ISO C++. I agree that running the DART builds in strict ANSI is a good idea in principle. It's the practice that scares me. A bit of testing beforehand could deal with that fear. Ian. |
From: Markus M. <me...@me...> - 2003-11-13 16:08:31
|
Am Don, den 13.11.2003 schrieb Ian Scott um 16:39: > I am worried that turning on strict ISO will involve a large amount of > relatively unproductive work. e.g. some of the work-arounds in vcl could be > illegal in strict ISO C++. > > I agree that running the DART builds in strict ANSI is a good idea in > principle. It's the practice that scares me. A bit of testing beforehand > could deal with that fear. I remember that in the past options, which make the MS C++ compiler more standards compliant, breaked a lot of Microsoft-internal things, like MFC, ATL, even Windows headers. I don't know if it's better now with VC++7. Furthermore, I can imagine that forcing users to compile their project with e.g. "/Za" can cause a lot of problems, if any third party libraries are involved. Markus |
From: William A. H. <bil...@ny...> - 2003-11-13 16:20:48
|
I think it even disables the declspec stuff required for dll's. -Bill At 11:07 AM 11/13/2003, Markus Meyer wrote: >Am Don, den 13.11.2003 schrieb Ian Scott um 16:39: >> I am worried that turning on strict ISO will involve a large amount of >> relatively unproductive work. e.g. some of the work-arounds in vcl could be >> illegal in strict ISO C++. >> >> I agree that running the DART builds in strict ANSI is a good idea in >> principle. It's the practice that scares me. A bit of testing beforehand >> could deal with that fear. > >I remember that in the past options, which make the MS C++ compiler more >standards compliant, breaked a lot of Microsoft-internal things, like >MFC, ATL, even Windows headers. I don't know if it's better now with >VC++7. > >Furthermore, I can imagine that forcing users to compile their project >with e.g. "/Za" can cause a lot of problems, if any third party >libraries are involved. > > >Markus > > > > >------------------------------------------------------- >This SF.Net email sponsored by: ApacheCon 2003, >16-19 November in Las Vegas. Learn firsthand the latest >developments in Apache, PHP, Perl, XML, Java, MySQL, >WebDAV, and more! http://www.apachecon.com/ >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Gehua Y. <ya...@rp...> - 2003-11-13 16:23:47
|
> I remember that in the past options, which make the MS C++ compiler more > standards compliant, breaked a lot of Microsoft-internal things, like > MFC, ATL, even Windows headers. I don't know if it's better now with > VC++7. > VC7 is as bad as VC6 on this aspect. Gehua |
From: Peter V. <Pet...@es...> - 2003-11-13 16:16:58
|
Anybody any idea what is going wrong here? (OSF is a 64-bit platform; compilation with static libraries; the relevant values just before the assertion failure are: nx=11, k_hi=3, k_lo=4294967293 (instead of -3)). -- Peter. ----------------------------------------------------- >8 Build Name: OSF1-V5.1-gcc-3.3 vil_test_algo_cartesian_differential_invariants Failed Execution Time 3.054711 Completion Status Completed Exit Code CHILDKILLED Exit Explanation SIGABRT Exit Value SIGABRT Test output Standard Output: ----------------------------------------------------------------------------- Start Testing test_algo_cartesian_differential_invariants: ----------------------------------------------------------------------------- Standard Error: Assertion failed: k_rbegin >= k_rend, file /vxl/core/vil/algo/vil_convolve_1d.h, line 215 ------------------------------------------------------ >8 backtrace: void vil_convolve_1d<float, float, double, double>(float const*, unsigned, long, float*, long, double const*, long, long, double, vil_convolve_boundary_option, vil_convolve_boundary_option) void vil_convolve_1d<float, float, double, double>(vil_image_view<float> const&, vil_image_view<float>&, double const*, long, long, double, vil_convolve_boundary_option, vil_convolve_boundary_option) () void vil_cartesian_differential_invariants_3_1plane<float, float>(vil_image_view<float> const&, vil_image_view<float>&, double, unsigned) () void vil_cartesian_differential_invariants_3<float, float>(vil_image_view<float> const&, vil_image_view<float>&, double, unsigned) () test_algo_cartesian_differential_invariants() () test_algo_cartesian_differential_invariants_main(int, char**) () |
From: Ian S. <ian...@st...> - 2003-11-13 16:33:56
|
Hi Peter, I think I've fixed it. The update is in the repository. Thanks for investigating that. Ian. > -----Original Message----- > From: Peter Vanroose [mailto:Pet...@es...] > Sent: Thursday, November 13, 2003 4:17 PM > To: vxl...@li... > Subject: [Vxl-maintainers] > vil_test_algo_cartesian_differential_invariants failed > > > Anybody any idea what is going wrong here? > > (OSF is a 64-bit platform; compilation with static libraries; > the relevant values just before the assertion failure are: > nx=11, k_hi=3, k_lo=4294967293 (instead of -3)). > > -- Peter. > > ----------------------------------------------------- >8 > Build Name: OSF1-V5.1-gcc-3.3 > vil_test_algo_cartesian_differential_invariants Failed > > > Execution Time 3.054711 > Completion Status Completed > Exit Code CHILDKILLED > Exit Explanation SIGABRT > Exit Value SIGABRT > > > > Test output > > > Standard Output: > -------------------------------------------------------------- > --------------- > Start Testing test_algo_cartesian_differential_invariants: > -------------------------------------------------------------- > --------------- > > Standard Error: > Assertion failed: k_rbegin >= k_rend, file > /vxl/core/vil/algo/vil_convolve_1d.h, line 215 > > ------------------------------------------------------ >8 > > backtrace: > > void vil_convolve_1d<float, float, double, double>(float > const*, unsigned, long, float*, long, double const*, long, > long, double, vil_convolve_boundary_option, > vil_convolve_boundary_option) > void vil_convolve_1d<float, float, double, > double>(vil_image_view<float> const&, vil_image_view<float>&, > double const*, long, long, double, > vil_convolve_boundary_option, vil_convolve_boundary_option) () > void vil_cartesian_differential_invariants_3_1plane<float, > float>(vil_image_view<float> const&, vil_image_view<float>&, > double, unsigned) () > void vil_cartesian_differential_invariants_3<float, > float>(vil_image_view<float> const&, vil_image_view<float>&, > double, unsigned) () > test_algo_cartesian_differential_invariants() () > test_algo_cartesian_differential_invariants_main(int, char**) () > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Peter V. <Pet...@es...> - 2003-11-13 17:10:21
|
> I think I've fixed it. The update is in the repository. That works! Thanks. |
From: Peter V. <Pet...@es...> - 2003-11-16 21:06:29
|
Dear all, In core/vgl, most classes are templated on the data type (float or double). But the vgl_polygon and the vgl_*iterator classes are not, which causes some inconvenience when using e.g. vgl_polygon together with vgl_point_2d<double>. I have now "templatised" all classes in vgl. The "diff" of vgl_fwd.h is below. This causes of course a (minor) interface incompatibility: every user will have to replace every occurrence of vgl_polygon in his private code with vgl_polygon<float> . Shall I go ahead and cvs commit my changes? -- Peter. Index: core/vgl/vgl_fwd.h =================================================================== RCS file: /cvsroot/vxl/vxl/core/vgl/vgl_fwd.h,v retrieving revision 1.6 diff -u -w -r1.6 vgl_fwd.h --- core/vgl/vgl_fwd.h 17 May 2003 14:35:15 -0000 1.6 +++ core/vgl/vgl_fwd.h 14 Nov 2003 19:51:16 -0000 @@ -21,10 +21,11 @@ template <class T> class vgl_box_2d; template <class T> class vgl_box_3d; template <class T> class vgl_conic; -class vgl_polygon; -class vgl_polygon_scan_iterator; +template <class T> class vgl_polygon; struct vgl_region_scan_iterator; -struct vgl_triangle_scan_iterator; -struct vgl_window_scan_iterator; +template <class T> class vgl_ellipse_scan_iterator; +template <class T> class vgl_polygon_scan_iterator; +template <class T> class vgl_triangle_scan_iterator; +template <class T> class vgl_window_scan_iterator; #endif // vgl_fwd_h_ |