Briman wrote:
Well It is called REALbasic not REALC++
It also not called... - REALCute - REALStupid - REALSmart - REALorNoReal - REALSexy (I want that compiler if you know what I mean) - REALdoughnut (Krispy Kreme Doughnuts) - REALtor (Move over Godzilla) and my favorite... - the REALdeal ;) In terms of asserts what we need is the capability as stated by Andy Dent in the feedback report. In the feedback report Andy Dent wrote:
Most importantly, as per assert macros in c and I think the new assert in Java, when NOT in debug mode, the arguments to the assert should NOT BE COMPILED.
The only revision I would make to what Andy wrote in the feedback report is that it should not be limited to just debug or not debug mode, but it should be completely independent. Asserts should have there own pragma target that we can independently turn on or off. Also we need a way to turn them on and off in a global manner (see feedback report "edcqqqlj"--setting global pragmas). The reason for this is because sometimes it is desirable to release compiled programs with asserts turned on for debugging purposes. When you are done with beta testing with your customers, you want to be able to turn off the asserts for the final release build so the program runs at maximum speed. In the past, certain RS employees proposed that it is desirable to leave asserts turned on all the time and the C macro method of compiling them out based on a compile flag was not desirable (better to trigger the assert than have a hard crash according to them). According to this view of things, then asserts are not asserts any more, but real error checks. In general, asserts are for checking things that should not happen. They help you catch logic problems when you modify a system because they catch misusage of the modified system that may go undetected in subtle ways. They are traps to tell you that you just messed up and you need to look at how you are using this code. At the crux of the assert argument is that asserts impose an overhead and will slow things down and that is not a desirable quality for the final build. I must qualify this statement because someone out there will go off and say you will never notice the difference in the compiled program, so why not leave them there in the compiled object code. The response to that is to say that it is context sensitive, the code in question has a context from which it is called. So for example, if we are in a tight loop doing image bit twiddling the cost of those asserts become very expensive. If a method is called just once then the cost of the assert in terms of time is miniscule and not worth bothering over. The bottom line is what is needed is the ability to compile in or out the assert statements at the developer's "discretion"!!! _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
