BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Fastcode Complete Boolean Eval Rule Poll Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi Language BASM View previous topic :: View next topic   Author Message Dennis Guest Posted: Sat Mar 17, 2007 9:43 pm    Post subject: Fastcode Complete Boolean Eval Rule Poll Hi Community I have made a poll with this question "Should we add this rule to our global rules? All functions must pass validation with complete boolean evaluation on/off." http://tech.groups.yahoo.com/group/fastcodeproject/surveys?id=12540249 Best regards Dennis Kjaer Christensen Back to top Dennis Guest Posted: Sat Mar 17, 2007 9:53 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi My personal opinion is that we should have it and I see it as a complement to these 3 rules "All functions must pass validation with range check on/off. All functions must pass validation with overflow check on/off. All functions must pass validation with optimization on/off." Remember that you can locally disable complete boolean eval "Functions are allowed to set compiler switches, but must reset them again. " You see all our rules here http://fastcode.sourceforge.net/challenge_content/Rules.html The rules ensure that users of our library can compile with all kinds of compiler settings and our functions still work. If we did not have the rules then it is possible to copy paste our functions into an application and have them fail if they do not work with eg. complete boolean eval on. In a function like the example below, it is clear to users that the function will not work with R+ and Q+ and why. //Reads zero terminator which causes a range check error //Negative Hex numbers writtens $F1234567 gets converted by letting the result //wrap around. To enable this overflow checking must be off {$ifopt R+} {$define RangeCheckWasOn} {$R-} {$endif} {$ifopt Q+} {$define OverflowCheckWasOn} {$Q-} {$endif} function StrToInt32_DKC_Pas_24_a(const S : string): Integer; begin ...... end; {$ifdef RangeCheckWasOff} {$R-} {$endif} {$ifdef OverflowCheckWasOff} {$Q-} {$endif} Best regards Dennis Kjaer Christensen Back to top Jouni Turunen Guest Posted: Sun Mar 18, 2007 1:26 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Dennis, Quote: My personal opinion is that we should have it and I see it as a complement to these 3 rules "All functions must pass validation with range check on/off. All functions must pass validation with overflow check on/off. All functions must pass validation with optimization on/off." My personal opinion is that because Delphi RTL isn't compiled with complete boolean evaluation, adding this rule means just more work but no gain. I voted no. Regards, Jouni -- The Fastcode Project: http://www.fastcodeproject.org/ Back to top Dennis Guest Posted: Sun Mar 18, 2007 3:46 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Jouni Quote: My personal opinion is that because Delphi RTL isn't compiled with complete boolean evaluation, adding this rule means just more work but no gain. I voted no. Bad argument. Our only customer is not the RTL. Functions will be used widely in other libraries/applications. The RTL is also compiled with O+, R- etc. Does this mean we should remove the other 3 rules? Hardly. We should always be willing do to the work needed to make the best possible quality. The work you mention is only CPU time. Best regards Dennis Kjaer Christensen Back to top Davy Landman Guest Posted: Sun Mar 18, 2007 4:37 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi I voted no because it's something different as: Quote: "All functions must pass validation with range check on/off. All functions must pass validation with overflow check on/off. These options check a function for doing "wrong things", going over the range, overflowing. Those checks I'd call safety checks. But the Boolean Evaluation I think are language (syntax) changing effects. Neither Range, Overflow, Optimization change the way the delphi works, they just do extra checks on the code. Complete boolean evaluation changes the way the language works.. I've never seen the need for the complete boolean evaluation (perhaps help branching)... Looking at other languages, C#, C, C++, Java. They have complex rules about which expresions get's evaluated first, and when the evaluation stops. Changing that sequence would destroy alot of applications.. Looking at delphi, instead of writing if (Length(AString) > 0) and (AString[1] > ' ') then // no front trim should be written as. if Length(AString) > 0 then if AString[1] > ' ' then // no front trim. If we want to check for these kind of settings, we should also check for {$T+} (typed pointers enabled) because it won't even compile with this option. But that's just why I voted No :) If it's decided that we should check for this, I will just enclude an {$B-} in my units, {$B has a local scoop anyway.. Kind Regards, Davy Landman Back to top Dennis Guest Posted: Sun Mar 18, 2007 10:09 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Davy Good arguments. Best regards Dennis Kjaer Christensen Back to top Dennis Guest Posted: Sun Mar 18, 2007 10:36 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi My only concern is that some user will copy paste some Fastcode Trim function into his application, compile with B+ and see that Fastcode Trim fails. If this is possible it will happen and Fastcode will be blamed. I aim at 100% quality, which means that functions that fail if compiled with B+, should protect themselves with B-. Adding B- at the top of our B&V units is not a good solution because it is very likely that somebody will copy paste a function and not looking 3245 lines up for that B-. Also it signals that no functions in the unit will function properly with B+, which is not true. Best regards Dennis Kjaer Christensen Back to top Anders Isaksson Guest Posted: Mon Mar 19, 2007 1:56 am    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Dennis wrote: Quote: My only concern is that some user will copy paste some Fastcode Trim function into his application, compile with B+ and see that Fastcode Trim fails. If this is possible it will happen and Fastcode will be blamed. If a Fastcode function has been made to validate under B+ by enclosing it in B- it might still fail after copy/paste, as the user might well copy it without the enclosing directives. The only way to make copy/paste-safe code is to never utilize the short-cirquit boolean evaluation at all. Do we really want to put that restriction on the code? If you copy/paste RTL code, much of it will *not* compile under B+ Davy had so good arguments that I have decided to change my vote :-) -- Anders Isaksson, Sweden BlockCAD: http://web.telia.com/~u16122508/proglego.htm Gallery: http://web.telia.com/~u16122508/gallery/index.htm Back to top Jouni Turunen Guest Posted: Mon Mar 19, 2007 8:11 am    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Dennis, Quote: My only concern is that some user will copy paste some Fastcode Trim function into his application, compile with B+ and see that Fastcode Trim fails. If this is possible it will happen and Fastcode will be blamed. I aim at 100% quality, which means that functions that fail if compiled with B+, should protect themselves with B-. Adding B- at the top of our B&V units is not a good solution because it is very likely that somebody will copy paste a function and not looking 3245 lines up for that B-. Also it signals that no functions in the unit will function properly with B+, which is not true. I don't like those defines at top of the units either for the same reason. One way to protect routines against copy-paste errors is to have all routines like this: function Trim_XXX(const S: string): string; {$ifopt B+} You forgot to copy B- define! {$endif} begin ... end; This way code doesn't compile if define line is forgotten. Opinions? Regards, Jouni -- The Fastcode Project: http://www.fastcodeproject.org/ Back to top Dennis Guest Posted: Mon Mar 19, 2007 9:58 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Anders Quote: If a Fastcode function has been made to validate under B+ by enclosing it in B- it might still fail after copy/paste, as the user might well copy it without the enclosing directives. Yes but he should be quite blind to miss them when present 1 line away - and then he is really the one to blame, not Fastcode. Quote: The only way to make copy/paste-safe code is to never utilize the short-cirquit boolean evaluation at all. Do we really want to put that restriction on the code? Nope. There is no argumentation at all pointing in that direction. Quote: If you copy/paste RTL code, much of it will *not* compile under B+ Which has nothing to do with Fastcode. Quote: Davy had so good arguments that I have decided to change my vote Yes his argumentation is quite good - I wish he was on my side :-) Best regards Dennis Kjaer Christensen Back to top Dennis Guest Posted: Mon Mar 19, 2007 10:01 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Jouni Quote: I don't like those defines at top of the units either for the same reason. One way to protect routines against copy-paste errors is to have all routines like this: function Trim_XXX(const S: string): string; {$ifopt B+} You forgot to copy B- define! {$endif} begin ... end; This is abetter way to go than having directives at the top of the unit. I however prefer setting and resetting directives around functions that need it. If somebody using our functions think it is ugly then they can remove them at their own risk. Have anybody tried compiling and validating the Fastcode library with R+/R- etc. ? Eg. are there any missing directives in it? Best regards Dennis Kjaer Christensen Back to top Davy Landman Guest Posted: Tue Mar 20, 2007 12:08 am    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Jouni, Quote: I don't like those defines at top of the units either for the same reason. One way to protect routines against copy-paste errors is to have all routines like this: I'm wondering who we are trying to protect? People who violate the license of the file by copying the function out of the unit? Or the people who copy functions from pre BV1.0.0 units? Because if that were the case, we should perhaps protect them even more.. How would a function then look? {$IFOPT B+} {$define SaveB} {$endif} {$IFOPT Q+} {$define SaveQ} {$endif} {$IFOPT R+} {$define SaveR} {$endif} {$IFOPT I+} {$define SaveI} {$endif} {$B-} {$Q-} {$R-} {$I-} function Trim_DLA_PAS_2_a(const AString: string): string; { remember to include SysUtils} { remember to copy the types PByteArray and TByteArray because the definition in SysUtils is to small..} var .... begin .... end; {$ifdef SaveB} {$B+} {$endif} {$ifdef SaveQ} {$Q+} {$endif} {$ifdef SaveR} {$R+} {$endif} {$ifdef SaveI} {$I+} {$endif} damn... that would be sucky to read... but atleast we helped those copying without reading people! Kind regards, Davy Landman Back to top Dennis Guest Posted: Tue Mar 20, 2007 10:15 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Davy Quote: I'm wondering who we are trying to protect? People who violate the license Violate which license and how? Quote: of the file by copying the function out of the unit? Ouf of which unit? Quote: Or the people who copy functions from pre BV1.0.0 units? I want max quality = max security for Fastcode functions behaving correctly in all and any circumstance. Quote: Because if that were the case, we should perhaps protect them even more.. How would a function then look? This is a very good way to do it, but only add those defines if they are needed. It is possible to write fast code that does not need all those protections. Quote: damn... that would be sucky to read... but atleast we helped those copying without reading people! Yes and nobody have to read it. If they think it looks ugly then they can strip it of and their own risk. Perhaps we should abandon BASM and machinecode because it sucks even more to read ? ;-) I think you should all focus 100% on quality and speed and forget about the rest. It is not a beaty contest. People have no need to read or understand our functions. I would not like them to modify any of our functions either. They should have the best we can make and then just use it. Remember the Fastcode mantra: 100% quality, max speed. Quality above speed = no dirty shortcuts. Validation, validation and strict rules => QUALITY. Best regards Dennis Kjaer Christensen Back to top Davy Landman Guest Posted: Fri Mar 23, 2007 1:14 am    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Dennis Quote: Violate which license and how? Your right, sorry went on a little bit there Quote: of the file by copying the function out of the unit? Ouf of which unit? I meant a FastCodeLibrary or something like that Thus copying it out of it's place holder..... Quote: I want max quality = max security for Fastcode functions behaving correctly in all and any circumstance. I understand, but when you're using a beta product... you know it has faults, and you know there are parts which will not work when taken away from the product... (using a beta dll from a beta product in your own product spells bad news!) I agree then when the winner functions are joined to a nice unit, they should be protected in a extensive way, but I wonder who we are trying to protect and if that doesn't impose alot of overhead in the units? Quote: This is a very good way to do it, but only add those defines if they are needed. It is possible to write fast code that does not need all those protections. I know Quote: Yes and nobody have to read it. If they think it looks ugly then they can strip it of and their own risk. Correct. Quote: Perhaps we should abandon BASM and machinecode because it sucks even more to read ? That would sure improve my chances for winning at least in pascal I have a small chance ;-) I'm wondering what the other core fastcode members think about that.. Quote: Remember the Fastcode mantra: 100% quality, max speed. Quality above speed = no dirty shortcuts. Validation, validation and strict rules => QUALITY. First time I heard that.. But that doesn't say a thing... So concluding, I think this threads now holds two discussions. 1. Should we validate for Complete boolean evaluation, I still think No. 2. Should we protect every function from copying out of the unit? I'm not sure. So, what do the others think? Kind regards, Davy Landman Back to top Dennis Guest Posted: Sun Mar 25, 2007 1:52 pm    Post subject: Re: Fastcode Complete Boolean Eval Rule Poll Hi Davy Quote: Violate which license and how? Your right, sorry went on a little bit there OK ;-) Quote: of the file by copying the function out of the unit? Ouf of which unit? I meant a FastCodeLibrary or something like that Thus copying it out of it's place holder..... Anybody can copy our functions from anywhere they like. Quote: I want max quality = max security for Fastcode functions behaving correctly in all and any circumstance. I understand, but when you're using a beta product... you know it has faults, and you know there are parts which will not work when taken away from the product... We are not making beta products! All our releases are meant to be as high quality as possible. We are not making anything low quality on purpose and then try hiding behind a Beta release tag. Quote: (using a beta dll from a beta product in your own product spells bad news!) I agree then when the winner functions are joined to a nice unit, they should be protected in a extensive way, but I wonder who we are trying to protect and if that doesn't impose alot of overhead in the units? Overhead ? There is no runtime overhead at all. Just a few lines extra to copy and paste and people can do it or not. Only Michael is forced to do it. I volunteer to pay for the extra load on his electricity bill ) You are trying to get around some the burden of making high quality functions and pushing the work on to Michael Halabos and any other user of our functions. This is wrong. The function writer knows which compiler switches his function will work under and he has to document why he disables some swiches. Quote: This is a very good way to do it, but only add those defines if they are needed. It is possible to write fast code that does not need all those protections. I know :-) Yes and nobody have to read it. If they think it looks ugly then they can strip it of and their own risk. Correct. Perhaps we should abandon BASM and machinecode because it sucks even more to read ? That would sure improve my chances for winning at least in pascal I have a small chance Your Trim functions look very good ;-) Quote: I'm wondering what the other core fastcode members think about that.. Just a joke :-) Quote: Remember the Fastcode mantra: 100% quality, max speed. Quality above speed = no dirty shortcuts. Validation, validation and strict rules => QUALITY. First time I heard that. It has been said 100 times probably just before you joined us. <. But that doesn't say a thing... ????? Quote: So concluding, I think this threads now holds two discussions. 1. Should we validate for Complete boolean evaluation, I still think No. Fine. I see the Complete boolean evaluation question being important for Trim, but there is a reason that we have made functions for 4,5 years without having the discussion. The other compiler switches we are validating against are much more important. Quote: 2. Should we protect every function from copying out of the unit? I'm not sure. I am. This is the way all our functions are used. I want to maximize chances that they are used correctly. Quote: So, what do the others think? The poll will say. I really hope we will get many votes. Best Regards Dennis Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi Language BASM All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.