On Sat, Oct 16, 2010 at 2:11 AM, Ben Kloosterman <[email protected]> wrote:
> > > In .NET while a char is scalar a char array is a object... > I think you are referring to the pun between System.char and char. If so, note that System.char is a descendant of System.ValueType. That is: it's a structure, not a class. No marshal tricks are required to embed it; all of that is a consequence of it being a struct. > but can with ... embed the array directly into an object ( since you know > the size before hand and strings are immuable). So new string (“x”) only > creates a single object ( Not a string and an internal array object). > This is very useful for small strings. > The same trick works with vectors. The requirement is that they be non-resizable; it has nothing to do with immutability. But in fact the specification does not guarantee this implementation, and with good reason. They were well aware that incremental real-time GC might require a chunked implementation of both vectors and characters. > I'm sorry - I'm not understanding what you are saying here. Can you expand > on this? > > > > William was suggesting you may use the type information to determine the > type of the strand on the fly eg typeof() implying the arrays are objects. > I haven't thought it through, but probably not. Strands *can't* be part of the externally visible String specification, so they aren't first-class objects. In light of which it probably makes sense to put the tag bits into the referencing pointer within the string object. > >The NoHeap issue is actually very complicated, and the current C# answer > isn't very good. One problem with stranded strings is that it's a bit > strange to ask what it means to pin them. > > > > Agree , C# has come close for the higher level GC languages but it’s a > tricky problem which MS thought too difficult hence only half hearted value > types in C# which 99.9% of C# devs struggle to use well. > Chris Brumme once told me that conventional arrays had been planned for CLR 1.0, got dropped for schedule reasons, and never got revisited. > Why is pinning them strange ? > Because one has to pin multiple objects. Granted they are primitive, but it's a special case. > Especially for a compacting collector basically all strands are pinned... > What! Not at all. For any relocating collector strands are relocatable like anything else in the heap. That's the *problem*. P/Invoke itself wasn't bad. What got added to deal with the COM object model was a nightmare, and in my opinion not well thought out. OTOH, COM support was likely to be a nightmare no matter what one did. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
