You can write a memory manager in safe code and possibly nearly all of
a runtime but it would be very tricky. Is the benefit worth it for
the sake of a few unsafe calls ?
Nearly all the unsafe code I have seen ( and im speaking of C# unsafe
here in normal apps + Singularity) has to do with
- Escaping the type system eg casting or creating types from data
( eg IPC , reflection)
- Interop with native routines eg for intrinsic or stack
manipulation ( pinvoke and extern are both unsafe since they call
unsafe code)
- Escaping memory safety / GC often for performance , especially
the write barrer / card deck and array length checks. but sometimes
to do lots of manual allocations where it would be stupid to involve
a GC ( eg a cache ) .
Im still curious how BITc would have gone for stack / static types
which are a pain in C# ( eg I bet on a generic array of ints writes to
the value type fields still incur the GC write barrier or at least
some escape condition) . The support of explicit boxing . non nullable
types and immutable types would have greatly assisted the runtime
here.. ( and perhaps also some indicator that a type contains no
references so the GC and card table don't need to do anything)
Bitc seemed to get lost in inheritance/type classes and trying to make
a better C++ but most system programming is still in C not C++..and
to me bitc as a language seemed better than C (or say javascript when
released. ) . Memory and type safety even on top of C structs and case
statements would have been a great test to see how far you can go with
type/memory safety on static/ stack allocated data types.
Regards,
Ben
On Thu, May 17, 2012 at 11:03 AM, Jonathan S. Shapiro <[email protected]> wrote:
> On Tue, May 15, 2012 at 8:31 PM, David Jeske <[email protected]> wrote:
>>
>> On Tue, May 15, 2012 at 11:56 AM, Jonathan S. Shapiro <[email protected]>
>> wrote:
>>>
>>> Every other use of unsafe code that I have seen exists to correct a
>>> deficiency of the language design, most commonly in the area of arrays vs.
>>> vectors or in the area of low-level I/O. There are known strongly-typed
>>> solutions for both cases.
>>
>>
>> - Implementing thunks to primitive shared-libraries or kernel calls .... I
>> much prefer the PInvoke/unsafe model over having to code all of these things
>> in external unsafe languages.
>>
>
> OK. That is certainly a good one, though I tend to think of that code as (a)
> something that should be generated by a language support tool, and therefore
> (b) part of the runtime.
>
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
