From: Roy S. <roy...@ic...> - 2011-06-24 20:25:17
|
Any preference for what we should name a macro whose behavior is essentially "do what libmesh_assert() does even when NDEBUG is defined"? I'm not sure when we'd get around to using such a thing in the library (maybe sparingly in the MeshInput subclasses?), but in application code at least there's a definite need to always run certain sanity checks on input files and input options; the users who provide invalid input aren't always going to be kind enough to provide it to a devel-mode program. --- Roy |
From: John P. <jwp...@gm...> - 2011-06-24 20:47:03
|
On Fri, Jun 24, 2011 at 2:25 PM, Roy Stogner <roy...@ic...> wrote: > > Any preference for what we should name a macro whose behavior is > essentially "do what libmesh_assert() does even when NDEBUG is > defined"? I think this is called an "if test", right? > I'm not sure when we'd get around to using such a thing in the library > (maybe sparingly in the MeshInput subclasses?), but in application > code at least there's a definite need to always run certain sanity > checks on input files and input options; the users who provide invalid > input aren't always going to be kind enough to provide it to a > devel-mode program. Sorry, I actually don't understand why you need a macro for code that should essentially always execute? -- John |
From: Roy S. <roy...@ic...> - 2011-06-24 20:56:10
|
On Fri, 24 Jun 2011, John Peterson wrote: > On Fri, Jun 24, 2011 at 2:25 PM, Roy Stogner <roy...@ic...> wrote: >> >> Any preference for what we should name a macro whose behavior is >> essentially "do what libmesh_assert() does even when NDEBUG is >> defined"? > > I think this is called an "if test", right? Heh, zing! Yeah, it'd basically be to replace if (!test) { print "`test' failed"; libmesh_error(); } >> I'm not sure when we'd get around to using such a thing in the library >> (maybe sparingly in the MeshInput subclasses?), but in application >> code at least there's a definite need to always run certain sanity >> checks on input files and input options; the users who provide invalid >> input aren't always going to be kind enough to provide it to a >> devel-mode program. > > Sorry, I actually don't understand why you need a macro for code that > should essentially always execute? Mostly to turn a bunch of instances of the 3-5 lines above into one-liners. Using a macro or function prevents having to retype "test" (which can be a long complicated expression returning bool), using a macro keeps the libmesh_here() working right. --- Roy |
From: Derek G. <fri...@gm...> - 2011-06-24 21:04:34
|
On Jun 24, 2011, at 2:46 PM, John Peterson wrote: > On Fri, Jun 24, 2011 at 2:25 PM, Roy Stogner <roy...@ic...> wrote: >> >> Any preference for what we should name a macro whose behavior is >> essentially "do what libmesh_assert() does even when NDEBUG is >> defined"? > > I think this is called an "if test", right? I'm with John. Although, in MOOSE we have taken one shortcut so we can do: if(test) mooseError("message"); That way all of our error messages are formatted the same (and it saves some typing). But ultimately I don't see the need for a libmesh_really_assert,_seriously() ;-) Derek |