<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2013 04:57, Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/19/13 19:13 , Eliot Miranda wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would argue that in fact the best way to deal with differing UNIX<br>
implementations is this approach. For example, ioctl defines, socket<br>
constant defines, struct layouts, etc, etc all differ markedly between<br>
UNIX implementations, and hence one easy way to extract exact<br>
information is to generate, compile and either run or load a program<br>
that reveals the implementation details.<br>
</blockquote>
<br></div>
It's not clear to me how an arbitrary interpretation mechanism would reveal what function to call to invoke e.g. malloc(), assuming that's all there is to it. The mechanism would have to deal with arbitrary macro code expansion, arbitrary code without source code provided by the compiler itself, and on some platforms such as OS X the behavior of malloc() could depend on the value of environment variables at the time the binary is loaded (as opposed to the time when the interpretation mechanism looks at said variables). Similarly, it's unclear what that interpretation mechanism would do in the general presence of things like<br>
<br>
#if defined(FOO)<br>
...<br>
#endif<br>
<br>
To me, avoiding writing a few lines of C does not justify the effort of correctly rewriting and maintaining (parts of) a C compiler in Smalltalk.<br>
<br>
Generally, I agree that one could carefully and consciously write comparatively small primitives and/or plugins. Then, one could compile those with a C compiler in a compilation environment compatible with that of the VM. And then, one could call those primitives and/or plugins from the image with the expectation (within reason) that they should work.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">But you forgot to mention, that while writing plugin, or trying to dynamically link with some external library,<br> an author must deal with tons of those #ifdefs as well.. <br>
</div><div class="gmail_extra"><br>IMO, macros is the worst thing invented for C. <br>Having 10+ years of Pascal experience, i cannot really understand why it left behind by industry: 10/100 times faster compilation times, no crazy modularity problems,<br>
</div><div class="gmail_extra">same (or even better code performance), but what's most important is that you get what you see in code.<br></div><div class="gmail_extra"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>