Segment violation (was Re: Why I could not cast string to int?)

Artur Skawina art.08.09 at gmail.com
Fri Feb 3 03:14:42 PST 2012


On 02/03/12 11:41, Artur Skawina wrote:
> On 02/03/12 11:21, Alex Rønne Petersen wrote:
>> On 03-02-2012 11:08, Artur Skawina wrote:
>>> On 02/03/12 00:20, Jonathan M Davis wrote:
>>>> in is pointless on value types. All it does is make the function parameter
>>>> const, which really doesn't do much for you, and in some instances, is really
>>>> annoying. Personally, I see no point in using in unless the parameter is a
>>>> reference type, and even then, it's often a bad idea with reference types,
>>>> because in is really const scope, and the scope is problematic if you want to
>>>> return anything from that variable. It's particularly problematic with arrays,
>>>> since it's frequently desirable to return slices of them, and scope (and
>>>> therefore in) would prevent that. It's useful in some instances (particularly
>>>> with delegates), but I'd use in _very_ sparingly. It's almost always more
>>>> trouble than it's worth IMHO.
>>>
>>> BTW, scope should have been the default for *all* reference type function
>>> arguments, with an explicit modifier, say "esc", required to let the thing
>>> escape. It's an all-or-nothing thing, just like immutable strings - not using
>>> it everywhere is painful, but once you switch everything over you get the
>>> benefits.
>>>
>>> If it isn't obvious why - GC. The compiler can optimize the cases where it
>>> knows a newly allocated object can't escape and reduce or omit the GC overhead.
>>> And yes, it can also do this automatically - but that requires analyzing the
>>> whole call chain, which is a) not always possible and b) much more expensive.
>>>
>>> artur
>>
>> It is not that simple.
>>
>> If the class's constructor passes 'this' off to some arbitrary code, this optimization breaks completely. You would need whole-program analysis to have the slightest hope of doing this optimization correctly.
> 
> It's about enabling the optimization for as much code as possible. And probably
> the most interesting cases are strings/arrays - the GC overhead can be huge if
> you do a lot of concatenation etc.
> 
> Would marking the ctor as "scope" (similarly to "const" or "pure") work for your
> case? (it is reasonable to expect that the compiler checks this by itself; it's
> per-type, so not nearly as expensive as analyzing the flow)

Actually, passing 'this' to some "some arbitrary code" isn't a problem, unless
the code in question has the "esc" annotation, in which case you need to mark
the ctor (or any other method) as "esq" too; that will turn off the optimization,
for this struct/class, obviously. 
That's why "scope" needs to be the default - mixing it with code that does not
guarantee that the object does not escape does not really work - you cannot call
anything not marked with "scope" with an already scoped object. Which means you
need to mark practically every function argument as scope - this doesn't scale well.

artur


More information about the Digitalmars-d-learn mailing list