From: Peter V. <pet...@ya...> - 2012-11-15 16:22:37
|
There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* #defines. Currently, these backward compatibility defines are unconditionally visible. Objections? -- Peter. Matt McCormick <mat...@ki...> wrote: A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the CMakeLists.txt: option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." OFF) mark_as_advanced(VXL_LEGACY_REMOVE) In core/vxl_config.h.in #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern <Phi...@ma...> wrote: > I can confirm that adding the following macros directly to vnl_math.h work (at least under Visual Studio 2005): > > #define vnl_math_isnan vnl_math::isnan > #define vnl_math_isinf vnl_math::isinf > #define vnl_math_isfinite vnl_math::isfinite > #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven > #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup > #define vnl_math_rnd vnl_math::rnd > #define vnl_math_floor vnl_math::floor > #define vnl_math_ceil vnl_math::ceil > #define vnl_math_abs vnl_math::abs > #define vnl_math_max vnl_math::max > #define vnl_math_min vnl_math::min > #define vnl_math_sqr vnl_math::sqr > #define vnl_math_cube vnl_math::cube > #define vnl_math_sgn vnl_math::sgn > #define vnl_math_sgn0 vnl_math::sgn0 > #define vnl_math_squared_magnitude vnl_math::squared_magnitude > #define vnl_math_cuberoot vnl_math::cuberoot > #define vnl_math_hypot vnl_math::hypot > > If the aim is to minimize disruption, this would be my recommendation; if the aim is to persuade all users to migrate to the namespace version, however, then an '#if legacy' or separate include file might give them the nudge they require. > > Phil. > >> -----Original Message----- >> From: Peter Vanroose [mailto:pet...@ya...] >> Sent: 14 November 2012 08:27 >> To: Matt McCormick; Johnson, Hans J >> Cc: vxl...@li...; Bill Lorensen; ITK >> Subject: Re: [Vxl-users] API change of vnl_math to namespace >> >> >> >> Matt McCormick wrote: >> > Would it be possible to get backwards-compatibility macros like >> > #define vnl_math_abs vnl_math::abs ? >> >> Yes, of course. Good idea. >> I suppose this can go in core/vnl_math.h Or would a kind of "#if legacy..." >> switch be the preferred way? Or maybe a separate include file, say >> vnl_math_oldstyle.h ? >> >> -- Peter. -- |
From: Johnson, H. J <han...@ui...> - 2012-11-15 16:33:27
|
that sounds like a great plan. Hans ================================================================= Hans J. Johnson, Ph.D. Assistant Professor, Department of Psychiatry Mailing Address: W274 GH Email: han...@ui...<mailto:han...@ui...> 200 Hawkins Drive Phone: (319) 353 8587 The University of Iowa Iowa City, IA 52242 From: Peter Vanroose <pet...@ya...<mailto:pet...@ya...>> Reply-To: Peter Vanroose <pe...@va...<mailto:pe...@va...>> Date: Thursday, November 15, 2012 10:22 AM To: "\"Matt McCormick\"" <mat...@ki...<mailto:mat...@ki...>> Cc: "\"Philip Tresadern\"" <Phi...@ma...<mailto:Phi...@ma...>>, Hans Johnson <han...@ui...<mailto:han...@ui...>>, Bill Lorensen <bil...@gm...<mailto:bil...@gm...>>, vxl maintainers <vxl...@li...<mailto:vxl...@li...>> Subject: Re: API change of vnl_math to namespace There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* #defines. Currently, these backward compatibility defines are unconditionally visible. Objections? -- Peter. Matt McCormick <mat...@ki...<mailto:mat...@ki...>> wrote: A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the CMakeLists.txt: option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." OFF) mark_as_advanced(VXL_LEGACY_REMOVE) In core/vxl_config.h.in #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern <Phi...@ma...<mailto:Phi...@ma...>> wrote: > I can confirm that adding the following macros directly to vnl_math.h work (at least under Visual Studio 2005): > > #define vnl_math_isnan vnl_math::isnan > #define vnl_math_isinf vnl_math::isinf > #define vnl_math_isfinite vnl_math::isfinite > #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven > #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup > #define vnl_math_rnd vnl_math::rnd > #define vnl_math_floor vnl_math::floor > #define vnl_math_ceil vnl_math::ceil > #define vnl_math_abs vnl_math::abs > #define vnl_math_max vnl_math::max > #define vnl_math_min vnl_math::min > #define vnl_math_sqr vnl_math::sqr > #define vnl_math_cube vnl_math::cube > #define vnl_math_sgn vnl_math::sgn > #define vnl_math_sgn0 vnl_math::sgn0 > #define vnl_math_squared_magnitude vnl_math::squared_magnitude > #define vnl_math_cuberoot vnl_math::cuberoot > #define vnl_math_hypot vnl_math::hypot > > If the aim is to minimize disruption, this would be my recommendation; if the aim is to persuade all users to migrate to the namespace version, however, then an '#if legacy' or separate include file might give them the nudge they require. > > Phil. > >> -----Original Message----- >> From: Peter Vanroose [mailto:pet...@ya...<mailto:pet...@ya...>] >> Sent: 14 November 2012 08:27 >> To: Matt McCormick; Johnson, Hans J >> Cc: vxl...@li...<mailto:vxl...@li...>; Bill Lorensen; ITK >> Subject: Re: [Vxl-users] API change of vnl_math to namespace >> >> >> >> Matt McCormick wrote: >> > Would it be possible to get backwards-compatibility macros like >> > #define vnl_math_abs vnl_math::abs ? >> >> Yes, of course. Good idea. >> I suppose this can go in core/vnl_math.h Or would a kind of "#if legacy..." >> switch be the preferred way? Or maybe a separate include file, say >> vnl_math_oldstyle.h ? >> >> -- Peter. -- ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ |
From: Matt M. <mat...@ki...> - 2012-11-15 16:34:14
|
On Thu, Nov 15, 2012 at 4:33 PM, Johnson, Hans J <han...@ui...> wrote: > that sounds like a great plan. +1 Thanks, Matt > > Hans > > ================================================================= > Hans J. Johnson, Ph.D. > Assistant Professor, Department of Psychiatry > > Mailing Address: > W274 GH Email: han...@ui... > 200 Hawkins Drive Phone: (319) 353 8587 > The University of Iowa > Iowa City, IA 52242 > > From: Peter Vanroose <pet...@ya...> > Reply-To: Peter Vanroose <pe...@va...> > Date: Thursday, November 15, 2012 10:22 AM > To: "\"Matt McCormick\"" <mat...@ki...> > Cc: "\"Philip Tresadern\"" <Phi...@ma...>, Hans Johnson > <han...@ui...>, Bill Lorensen <bil...@gm...>, vxl > maintainers <vxl...@li...> > Subject: Re: API change of vnl_math to namespace > > There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; > I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* > #defines. > Currently, these backward compatibility defines are unconditionally visible. > > Objections? > > -- Peter. > > > > > Matt McCormick <mat...@ki...> wrote: > > A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the > CMakeLists.txt: > > option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." > OFF) > mark_as_advanced(VXL_LEGACY_REMOVE) > > In core/vxl_config.h.in > > #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ > > and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". > > On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern > <Phi...@ma...> wrote: >> I can confirm that adding the following macros directly to vnl_math.h work >> (at least under Visual Studio 2005): >> >> #define vnl_math_isnan vnl_math::isnan >> #define vnl_math_isinf vnl_math::isinf >> #define vnl_math_isfinite vnl_math::isfinite >> #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven >> #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup >> #define vnl_math_rnd vnl_math::rnd >> #define vnl_math_floor vnl_math::floor >> #define vnl_math_ceil vnl_math::ceil >> #define vnl_math_abs vnl_math::abs >> #define vnl_math_max vnl_math::max >> #define vnl_math_min vnl_math::min >> #define vnl_math_sqr vnl_math::sqr >> #define vnl_math_cube vnl_math::cube >> #define vnl_math_sgn vnl_math::sgn >> #define vnl_math_sgn0 vnl_math::sgn0 >> #define vnl_math_squared_magnitude vnl_math::squared_magnitude >> #define vnl_math_cuberoot vnl_math::cuberoot >> #define vnl_math_hypot vnl_math::hypot >> >> If the aim is to minimize disruption, this would be my recommendation; if > the aim is to persuade all users to migrate to the namespace version, > however, then an '#if legacy' or separate include file might give them the > nudge they require. >> >> Phil. >> >>> -----Original Message----- >>> From: Peter Vanroose [mailto:pet...@ya...] >>> Sent: 14 November 2012 08:27 >>> To: Matt McCormick; Johnson, Hans J >>> Cc: vxl...@li...; Bill Lorensen; ITK >>> Subject: Re: [Vxl-users] API change of vnl_math to namespace >>> >>> >>> >>> Matt McCormick wrote: >>> > Would it be possible to get backwards-compatibility macros like >>> > #define vnl_math_abs vnl_math::abs ? >>> >>> Yes, of course. Good idea. >>> I suppose this can go in core/vnl_math.h Or would a kind of "#if >>> legacy..." >>> switch be the preferred way? Or maybe a separate include file, say >>> vnl_math_oldstyle.h ? >>> >>> -- Peter. > > > > > > > > > -- > > > ________________________________ > Notice: This UI Health Care e-mail (including attachments) is covered by the > Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential > and may be legally privileged. If you are not the intended recipient, you > are hereby notified that any retention, dissemination, distribution, or > copying of this communication is strictly prohibited. Please reply to the > sender that you have received the message in error, then delete it. Thank > you. > ________________________________ |