On 11/14/2013 09:28 PM, Sieghard wrote: > It might not be very neccessary if these types aren't compatible among each > other. Range checking has to be done only on coercion then, i.e. when > assigning a value cast from a - any - different type. I understand that Martin is (IMHO) correctly assuming that range restricted numerical types (only) make sense if you do realtime range checking on them. > You won't usually even realize that it's been done. It would be noticably > only under very specific circumstances, such as a loop with many deeply > nested calculations using a lot of different variables of such type, > running over a large range of the controlling variable, i.e. "a long time", > or very often. Martin explicitly stated that compile and execution speed is one of the reasons that nudged him to start the mseLang project. So this should not be invalidated by not having the possibility to use bitsize restricted (but not explicitly range restricted) variables without realtime range checking.
>> "simulated bit fields" this is not at all what I would want. > Typical C attitude - no checking, please, I want to shoot me in the foot > silently! ;-> Yep. It should be possible to decide if I want the fastest or the most secure code. > You wouldn't be satisfied by a compiler directive, like Delphi, FPC > and most others do it? Even C has the "pragma" statement for such > puposes, and gcc extends its syntax quite far to achieve similar things. First I ask for a syntax that frees me from manually calculating the range that is imposed by a bit count: with 1 Bits "-1..0" means the same as "signed and "0...1" means the same as "unsigned". with 2 Bits "-2..1" means the same as "signed and "0...3" means the same as "unsigned". with 3 Bits "-4..4" means the same as "signed and "0...7" means the same as "unsigned". with n Bits "-(2^(n-1))..(2^(n-1)-1)" means the same as "signed and "0...(2^n-1)" means the same as "unsigned". on top of that this syntax _might_ decide whether or not range checking is imposed. This of course might be decided by another keyword. but I don't think this is necessary. A compiler option is not a good Idea, as with same you can't define the range checking separately for each type. Her I feel that it's really logical to define that range checking is imposed exactly when the programmer explicitly defines a range. -Michael ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
