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

Alex Rønne Petersen xtzgzorex at gmail.com
Fri Feb 3 03:14:19 PST 2012


On 03-02-2012 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)
>
> artur

Well, you would have to mark methods as scope too, as they could be 
passing off 'this' as well.

It's probably doable that way, but explicit annotations kind of suck. :(

--
- Alex


More information about the Digitalmars-d-learn mailing list