On processors for D ~ decoupling

[kris]

Walter Bright wrote:
> kris wrote:
 >> Why do you think Ares exists anyway?

 > I'm trying to understand.

Ah. That makes some sense now ~ so, you're saying you don't see any need 
for a better library? That you're trying to understand what such a need 
might be?


> Here's the issue I have - postings that adamantly offer solutions 
> without identifying the actual problem. Here are some examples:
> 
> Solution: remove printf
> Alleged problem: printf pulls in floating point formatting code
> Actual problem: std.string pulls in floating point formatting code due 
> to reference to __fltused. printf does not pull in floating point 
> formatting code.
> Correct solution: fix compiler to not generate __fltused references in 
> library code
> 
> Solution: implement separate itoa() for typeinfo
> Alleged problem: calling one function in std.string pulls in everything 
> in std.string
> Actual problem: only a small portion of std.string is actually linked in 
> because the free functions are implemented as COMDATs, but due to an 
> error in the compiler, lambda functions are not written as COMDATs. This 
> causes a reference to std.uni to still be pulled in, pulling in a large 
> table in std.uni
> Correct solution: fix compiler to generate COMDATs for lambda functions.


If you'll read the posts again, sans prejudice, I hope you'll find that 
they are about decoupling (like the title says). If you haven't heard of 
it before, it's a generally and widely applicable concept in software 
design. Been applied for probably 40 years now. If that thrust is not 
clear from my writing, then I've been totally lacking in my own conviction.

The 'solutions' you note above are being rather frugal with the truth:

Let's face it; printf should probably be removed from object.d purely 
because it represents poor design judgement (yes; my opinion. I have 
one). That aside; you make much of the fact that it can be stubbed out, 
whilst staunchly "refusing" to examine why it should be present in the 
first place. Instead, there's the persistent "it doesn't make any 
difference to remove it" stonewall. That approach inevitably leads to a 
less than fruitful discourse, and fits the description of futile (since 
you asked).

TypeInfo et. al. should most probably strive to be as isolated as they 
can be from higher level modules (which includes printf). Hooking it up 
contrary to this manner is sometimes called "tight coupling", and it's 
what this topic is about. Implementing a local itoa() is one way to 
decouple TypeInfo; linking to the C lib itoa() is another. You made it 
implicitly clear there was no way you'd consider isolating object.d from 
std.string in order to make the former more amenable to alternate 
libraries. Thus, that aspect was completely ignored also.

Looking again at your recital of adamant examples, I'm rather sorry, and 
entirely disappointed that's all you got from this exchange. Yes, 
there's certainly truth there; but it apparently makes a point of 
purging all mention of decoupling ~ that's where frugality lies.


> And that is the *entirety* of what phobos.lib needs for everything in 
> phobos. A big chunk of it is Windows API imports. A quick look through 
> it shows the following related to C I/O:
> 
> _printf
> ___fp_lock
> ___fp_unlock
> __fputc_nlock
> __fputwc_nlock
> __iob
> _exit
> _fclose
> _fdopen
> _feof
> _fflush
> _fgetc
> _fopen
> _fprintf
> _fputc
> _fread
> _free
> _fseek
> _ftell
> _fwide
> _fwrite
> _ungetc
> 
> Applying grep tells us where these are used: modules like std.cstream, 
> which is "C" streams, no surprise there. gzio.c, a C function that's 
> part of zlib, no surprise there, either. trace's file logging function, 
> no big deal, that wouldn't get shipped with a released application. 
> std.stdio, no surprise there either, it needs to sync with C's stdio.
> 
> There isn't anywhere near 50 routines, and if you don't use cstream, 
> zlib, trace, or writef, it's hard to see any difficulty at all. In fact, 
> I find it hard to find any other uses of stdio other than printf 
> (perhaps I overlooked some?). So why can't 'hooking' printf, as outlined 
> above, work?


Yeah ~ I posted the same lists last year, gained simply by hiding the C 
library.

You've again omitted a crucial part. The C runtime itself apparently has 
all kinds of interdependencies (the console startup/exit code is a prime 
example). Thus, the lists you show are simply the tip of the iceberg. I 
imagine you already know this quite intimately, so will suggest you do a 
step-by-step examination of the .map file for Derek's example:

void main() {}

and ask yourself just why and where the kitchen-sink is linked? I'm not 
telling you this to be a jerk ~ it would surely be of benefit to D if 
you were to understand where the dependencies actually lie.


> 
> BTW, internal\dmain2.d also uses printf to print out an error message 
> relating to any uncaught exceptions.


I had not forgotton it. There's a time for that one also.