[M3devel] STL algorithms? sort/unique?

[Jay K]

std::vector<int> vi;
vi.push_back(1);
vi.push_back(2);

vi.push_back(3);


vs.
VAR s := NEW(IntSeq.T).init();
s.addhi(1);
s.addhi(2);

s.addhi(3);



vector<int> is small, contains 3 pointers.
And one level of indirection for accessing the data.
printf("%d\n", vi[0]); has one level of indirection and will be inlined in any decent compiler.



IntSeq.T is one pointer, and probably contains also approximately 3 pointers.
The Modula-3 has an extra level of indirection.



Not every function should be "virtual".
"object.method" is useful syntax for statically typed "object".
s.get(0) probably involves like 3 pointer derefences.



Somewhat this is a "standard library" matter.
But I think the language is probably slightly lacking too.


I understand that if the "virtual-ness" is part of the interface..you could have:
si: IntSeq.T; 


IntSeq.push_back(si, 1); (* static non-virtual dispatch *) 
IntSeq.push_back(si, 2);

IntSeq.push_back(si, 3);

si.data[0]; (* public data *)


This is good and bad.
It is both better and worse to have the "virtual-ness" affect the public interface.
Exposing data like that, well, that's kind of a quality of implementation matter.
I could have it be.
IntSeq.get(si, 0);


and leave it up to the compiler to inline..


I have to go...
 - Jay


> Date: Wed, 3 Oct 2012 20:40:57 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] STL algorithms? sort/unique?
> 
> 
> 
> 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
> >
> >
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121004/336ce5f7/attachment-0002.html>