Hallo Michael,
Du schriebst am Fri, 15 Nov 2013 09:33:32 +0100:
> > It might not be very neccessary if these types aren't compatible among
^^^^^^^^^^^^^^^^^^^^^^^
> I understand that Martin is (IMHO) correctly assuming that range
> restricted numerical types (only) make sense if you do realtime range
> checking on them.
If you do calculations on them and possibly define some compatibility
relations as well, this will be neccessary (assuming you meant to say
"_runtime_ range checking" above).
> > You won't usually even realize that it's been done. It would be
...
> be invalidated by not having the possibility to use bitsize restricted
> (but not explicitly range restricted) variables without realtime range
> checking.
There's no problem with me - I just wouldn't like being deprived of the
possibility do include such checking. There aren't so many programs that
need utmost speed without concern to other things - any software that's
mostly interacting with a user won't be noticeably slowed down by range
checking, e.g. Even database software won't be affected much, as most of
its processing is command interpretation, data selection and mass storage
accesses. There's not much that's adversely affected at all, at least not
on your average PC, which will be the carrier for MSElang software, in
general. It _might_ be different with embedded systems, but even there
it's rather an exception than the rule.
> >> "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.
Just state clearly that it's from you, and I will avoid to use it.
Isn't software already bad enough as it is?
> > You wouldn't be satisfied by a compiler directive, like Delphi, FPC
...
> First I ask for a syntax that frees me from manually calculating the
> range that is imposed by a bit count:
That's a different topic from range checking. So I assume, you _would_ be
satisfied by a compiler directive. Now on this one:
> with 1 Bits "-1..0" means the same as "signed and "0...1" means the same
> as "unsigned".
I.e. there's no difference, you say? No, there's just no space for a sign
bit, and thus there's _no_ signed type of that size at all.
> with 2 Bits "-2..1" means the same as "signed and "0...3" means the same
> as "unsigned".
Even "-1..1" would have to be taken as signed, and "1..3" 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".
Well, yes, thes are the usual ranges for fully populated sets of number of
a given bit count.
> on top of that this syntax _might_ decide whether or not range checking
The _syntax_ _never_ can "decide" anything. Either the implementor decides
what his software does on behalf of the prospective user, or he lets the
user decide, giving him a means to turn on the desired behaviour.
The syntax just might provide access to such a mechanism, or it could be
decided through external data provided to the compiler.
> is imposed. This of course might be decided by another keyword. but I
> don't think this is necessary.
You think of something like
TYPE
MyByte: -256..255 unchecked;
?
Well... no, unwieldy, as you cannot just turn on range checking for
invetigating some problem. Better use a compiler directive, or even better,
use a compiler command switch.
> A compiler option is not a good Idea, as with same you can't define the
> range checking separately for each type.
Why shouldn't it be possible to add a paramter to the option stateing which
type you want to check? It _is_ possible, to any degree of detail, althoguh
possibly somewhat cumbersome for the compiler writer...
> 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.
If you turn _off_ range checking for some type you defined, why'd you
_define_ that type in the first place? The definition won't give you any
benefit - it does _exactly_ _nothing_. The only effect might be undetected
range overflows leading to unexpected program behaviour.
Good luck tracing them down.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
------------------------------------------------------------------------------
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
