<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>std::vector<int> vi;<br>vi.push_back(1);<br>vi.push_back(2);<br>
vi.push_back(3);<br>
<br>vs.<br>VAR s := NEW(IntSeq.T).init();<br>s.addhi(1);<br>s.addhi(2);<br>
s.addhi(3);<br>
<br><br>vector<int> is small, contains 3 pointers.<br>And one level of indirection for accessing the data.<br>printf("%d\n", vi[0]); has one level of indirection and will be inlined in any decent compiler.<br><br><br><br>IntSeq.T is one pointer, and probably contains also approximately 3 pointers.<br>The Modula-3 has an extra level of indirection.<br>
<br><br>Not every function should be "virtual".<br>"object.method" is useful syntax for statically typed "object".<br>s.get(0) probably involves like 3 pointer derefences.<br><br><br><br>Somewhat this is a "standard library" matter.<br>But I think the language is probably slightly lacking too.<br><br><br>I understand that if the "virtual-ness" is part of the interface..you could have:<br>si: IntSeq.T; <br><br><br>IntSeq.push_back(si, 1); (* static non-virtual dispatch *) <br>IntSeq.push_back(si, 2);<br>
IntSeq.push_back(si, 3);<br>
si.data[0]; (* public data *)<br><br><br>This is good and bad.<br>It is both better and worse to have the "virtual-ness" affect the public interface.<br>Exposing data like that, well, that's kind of a quality of implementation matter.<br>I could have it be.<br>IntSeq.get(si, 0);<br><br><br>and leave it up to the compiler to inline..<br><br><br>I have to go...<br> - Jay<br><br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Wed, 3 Oct 2012 20:40:57 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] STL algorithms? sort/unique?<br>> <br>> <br>> <br>> On 09/30/2012 01:06 AM, Jay K wrote:<br>> > I believe opinion remains strongly mixed on garbage collection / "managed"<br>> > etc. There is a lot of "managed" code. There is a lot of "native" code.<br>> > We all use a lot of both every day.<br>> ><br>> ><br>> > Modula-3 is actually pretty unusual in being native code and having garbage collection.<br>> > It is pretty unusual in having optional garbage collection.<br>> > It is pretty unusual in having optional safety.<br>> > C# allows some safety relaxation within "unsafe" blocks.<br>> > Like pointer manipulation.<br>> ><br>> > It pains me slightly in Modula-3 to write e.g.<br>> ><br>> > RTIO.PutText("foo " & Fmt.Int(123) & "bar");<br>> > I've created at least two pieces of garbage.<br>> > In C++ any temporary strings would be cleaned up<br>> > right away at a deterministic time.<br>> ><br>> ><br>> > I'm really torn.<br>> > C# seems to be a highly "productive" "environment" (the language,<br>> > the libraries, possibly the IDEs). Perhaps far more than any C++ or Modula-3.<br>> > I know people who work on kernel drivers. They still use C.<br>> ><br>> ><br>> > I don't just want UNTRACED OBJECT.<br>> > I also want stack allocated objects.<br>> > C++ has them.<br>> ><br>> <br>> This idea has never made any sense to me at all:<br>> <br>> 1) No OOP advocate would let you get away with calling it OOP without<br>> having dispatching methods. (This despite the fact that the great<br>> majority of OO examples don't actually use them, and thus are really<br>> ADT programming.)<br>> <br>> 2) You can't actually use dispatching unless your variable can dynamically<br>> be assigned values of different subclasses at different times. Degenerately<br>> using a linguistic mechanism that dispatches, but the algorithm ensures it<br>> is always to the same place, does not count.<br>> <br>> 3) If a stack object is to be dynamically assignable to values of different<br>> subclasses, the compiler is going to have to allocate space for the<br>> largest of these. That can be declared anywhere, in a place unknown<br>> to exist, at the point where the variable is declared. I think I can<br>> see a way this could be implemented with whole-program techniques, but<br>> it still won't work with dynamically linked libraries, which rules out<br>> a major part of what the staunch OOP advocates advocate. And it creates<br>> a new kind of space waste.<br>> <br>> 4) Alternatively, a compiler could actually hiddenly allocate the<br>> objects in the heap and put a pointer on the stack. But now any real<br>> or imagined performance gains from on-stack objects are gone. Moreover,<br>> there will be reference assignment vs. value assignment semantic<br>> distinctions that violate what local variables are expected to do,<br>> with sometimes big bugs as consequence.<br>> <br>> 5) A compiler could fix this by simulating the correct value assignment<br>> semantics, making heap copies whenever necessary. This makes it<br>> effectively a functional language, which certainly would require a GC<br>> and greatly increases the volume of allocated and collected heap<br>> objects.<br>> <br>> 6) Or, a programmer could explicitly take pointers to stack objects of<br>> various subclasses and assign them to the same variable at different<br>> times. I guess this is what is done in C++. This amounts to enticing<br>> the naive to try dancing on a tight-wire over Dangling Pointer Abyss.<br>> Which would justify Stroustrup's comment.<br>> <br>> 7) Finally, a programmer diligent and skillful enough to pull this off<br>> would be extremely hard pressed to find an application where the<br>> actual stack lifetimes of the different subclass objects had any<br>> significant correlation to the real lifetimes of their usefulness<br>> to the program.<br>> <br>> > class C<br>> > {<br>> > void F1();<br>> > virtual void F2();<br>> > };<br>> ><br>> > void F3()<br>> > {<br>> > C c;<br>> > }<br>> ><br>> ><br>> > I think the nearest equivalent in Modula-3 is a stack allocated RECORD<br>> > with function pointers.<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br></div> </div></body>
</html>