Classes or stucts :: Newbie

Jonathan M Davis jmdavisProg at gmx.com
Mon Dec 20 10:19:41 PST 2010


On Monday, December 20, 2010 03:19:48 bearophile wrote:
> Jonathan M Davis:
> > So, putting classes on the stack kind of negates the whole point of
> > having both structs and classes in the first place.
> 
> Where you put the instance is mostly a matter of implementation. This is
> why a smart JavaVM is able to perform escape analysis and choose where to
> allocate the class instance.
> 
> Keep in mind that if you allocate a class on the stack or in-place inside
> another class, you don't turn it into a value, because beside the class
> instance you reserve space for its reference too (this reference may even
> be immutable, if you want).
> 
> > scoped classes are definitely not in SafeD.
> 
> Well implemented scoped classes are safe enough (compared to the other
> things). The compiler may perform escape analysis of all the aliases of a
> scoped object and statically raise an error if a reference escapes. This
> isn't 100% safe in a language that has all kind of casts and low-level
> features, but it's often safe enough, compared to other things. And those
> casts and low level features that can fool the escape analysis can be
> disabled statically (with something like @safe), this makes scoped classes
> 100% safe, probably safer than heap allocations.
> 
> >The whole point of "safe" when talking about safe in D is memory saftey.
> 
> I know, but some people (including me) think that "safe D" is a misleading
> name because it just means "memory safe D".

Talking about SafeD meaning memory safety makes the meaning of safety clear. If 
you try and make the term safety encompass more than that, it takes very little 
for "safety" to become subjective. Regardless of whether it would be nice if 
SafeD gave types of safety other than memory safety, when D documentation and 
any of the main D devs talk about safety, it is memory safety which is being 
referred to. Trying to expand the meaning beyond that will just cause confusion 
regardless of whether the non-memory safety being discussed is desirable or not.

> >If the compiler can determine that a particular class object can be put on
> >the stack and optimize it that way. Fine, but it's pretty rare that it
> >can do that - essentially only in cases where you don't pass it to
> >_anything_ except for pure functions (including calls to member
> >functions).
> 
> I don't agree that it's rare. If a function that allocates an object calls
> a function (or member function) that's present in the same compilation
> unit (this more or less means same module), then the compiler is able to
> continue the escape analysis and determine if the called function escapes
> the reference. If this doesn't happen, then the class instance is free to
> be scoped. This situation is common enough.
> 
> >And if the compiler can do that, then it there's no need for the
> >programmer to use scope explicitly.<
> 
> I don't agree. An annotation like "@scope" is a contract between the
> programmer and the compiler. It means that if the compiler sees a
> reference escape, then it stops the compilation.
> 
> >And no, a compiler _can't_ do pure optimizations on its own,
> >generally-speaking, because that would require looking not only at the
> >body of the function that's being called but at the function bodies of
> >any functions that it calls. D is not designed in a way that the compiler
> >even necessarily has _access_ to a function's body when compiling, and
> >you can't generally look at a function's body when doing optimizations
> >when calling that function. So, _some_ pure optimizations could be done,
> >but most couldn't. This is not the case with scoped classes, because
> >purity already gives you the information that you need.<
> 
> Quite often a function calls another function in thee same compilation
> unit, in this case the analysis is possible. So you limit the
> optimizations to this common but limited case.
> 
> And LDC compiler and in future GDC too, have link-time optimization, this
> means the compiler packs or sees the program code code in a single
> compilation unit. In this case it's able to perform a more complete
> analysis (including de-virtualization of some virtual functions).

It's trivial to get a reference or pointer to escape and make undetectable to 
the compiler. Some escape analysis can be and is done, but all it takes is 
passing a pointer or a reference to another function and the compiler can't 
determine it anymore unless it has access to the called functions body, and 
perhaps the bodies of functions that that function calls. And if the compiler 
can't be 100% correct with escape analysis, then any feature that requires it is 
not safe.

And as great as fancier optimizations such as link-time optimizations may be, 
the existence of dynamic libraries eliminates any and all guarantees that such 
optimizations would be able to make if they had all of the source to look at. 
So, you can't rely on them. They help, and they're great, but no feature can 
require them. They're optimizations only.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list