Preprocessor commands in template arguments

Started by
12 comments, last by iMalc 19 years, 8 months ago
I am having another problem with my Assert Macro. I am not sure if I should start a new thread or not, please just let me know.

Basically, I would like to make the boolean test variable also a template paramter. The boolean type that is. The reason for this is that I would like for my Assert function to return the condition so it can be used as parameter for another function.

Example:

Assert<0>(SomeObj.GetHammerPtr(), "Data Pointer was invalid")->UseHammer;


This way, I don't have to retrieve the the hammer pointer twice. Or is it just as fast to send the point to a temporary variable?

Thanks!

Dwiel
Advertisement
Quote:Original post by Tazzel3D
I am tring to write an Assert type function where the coder can set which level of errors should get through.

This might not sound very helpful but the idea of the assert is that something that should NEVER happen HAS happened. i.e. a bug HAS been found. Given that, a "level of errors" for an assert does not really make sense. All assert failures are errors.

The only reason to turn off some asserts would be because they are in your innermost loops and slow down your debug builds horribly.

Maybe the name assert isn't quite what you're meaning here as you sound like you're using asserts for things which might knowingly fail.

All the best with whatever you're trying to achieve though :-)
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Thanks for the info. The other type of things that I was planning on using assert for was for say, out of bounds checking comming in from the script that I use. Most of the time, I can simply clamp the value into the desired range instead of killing the program. It seems to require a less dramatic error than assert, but the word makes sence to me when I assert that a value should be in a given range. Now that I am thinking about it, maybe I should just pass the Assert a function, which it tries to call to fix the problem... Does this usage where I have a condition that must be true, but might have a means for recovering still seem OK, or does it sound like I should be using something else.

Thanks!

Dwiel
Ok sure, I see.
User input checking is the kind of usage for what you are describing.

Perhaps a good name might be 'Verify', or 'ScriptVerify'?

Sorry if I sounded pedantic before! Actually I'm surprised I'm the only one so far who said what I did above.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

This topic is closed to new replies.

Advertisement