On 09/30/2012 01:06 AM, Jay K wrote:
> I believe opinion remains strongly mixed on garbage collection / "managed"
> etc. There is a lot of "managed" code. There is a lot of "native" code.
> We all use a lot of both every day.
>
>
> Modula-3 is actually pretty unusual in being native code and having garbage collection.
> It is pretty unusual in having optional garbage collection.
> It is pretty unusual in having optional safety.
> C# allows some safety relaxation within "unsafe" blocks.
> Like pointer manipulation.
>
> It pains me slightly in Modula-3 to write e.g.
>
> RTIO.PutText("foo " & Fmt.Int(123) & "bar");
> I've created at least two pieces of garbage.
> In C++ any temporary strings would be cleaned up
> right away at a deterministic time.
>
>
> I'm really torn.
> C# seems to be a highly "productive" "environment" (the language,
> the libraries, possibly the IDEs). Perhaps far more than any C++ or Modula-3.
> I know people who work on kernel drivers. They still use C.
>
>
> I don't just want UNTRACED OBJECT.
> I also want stack allocated objects.
> C++ has them.
>
This idea has never made any sense to me at all:
1) No OOP advocate would let you get away with calling it OOP without
having dispatching methods. (This despite the fact that the great
majority of OO examples don't actually use them, and thus are really
ADT programming.)
2) You can't actually use dispatching unless your variable can dynamically
be assigned values of different subclasses at different times. Degenerately
using a linguistic mechanism that dispatches, but the algorithm ensures it
is always to the same place, does not count.
3) If a stack object is to be dynamically assignable to values of different
subclasses, the compiler is going to have to allocate space for the
largest of these. That can be declared anywhere, in a place unknown
to exist, at the point where the variable is declared. I think I can
see a way this could be implemented with whole-program techniques, but
it still won't work with dynamically linked libraries, which rules out
a major part of what the staunch OOP advocates advocate. And it creates
a new kind of space waste.
4) Alternatively, a compiler could actually hiddenly allocate the
objects in the heap and put a pointer on the stack. But now any real
or imagined performance gains from on-stack objects are gone. Moreover,
there will be reference assignment vs. value assignment semantic
distinctions that violate what local variables are expected to do,
with sometimes big bugs as consequence.
5) A compiler could fix this by simulating the correct value assignment
semantics, making heap copies whenever necessary. This makes it
effectively a functional language, which certainly would require a GC
and greatly increases the volume of allocated and collected heap
objects.
6) Or, a programmer could explicitly take pointers to stack objects of
various subclasses and assign them to the same variable at different
times. I guess this is what is done in C++. This amounts to enticing
the naive to try dancing on a tight-wire over Dangling Pointer Abyss.
Which would justify Stroustrup's comment.
7) Finally, a programmer diligent and skillful enough to pull this off
would be extremely hard pressed to find an application where the
actual stack lifetimes of the different subclass objects had any
significant correlation to the real lifetimes of their usefulness
to the program.
> class C
> {
> void F1();
> virtual void F2();
> };
>
> void F3()
> {
> C c;
> }
>
>
> I think the nearest equivalent in Modula-3 is a stack allocated RECORD
> with function pointers.
>
>
> - Jay
>
>
>