[M3devel] STL algorithms? sort/unique?

Rodney M. Bates rodney_bates at lcwb.coop
Thu Oct 4 03:40:57 CEST 2012



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
>
>
>



More information about the M3devel mailing list