In article <dcp2vg$2v6p$1@digitaldaemon.com>, Mike Capp says...
>
>In article <dcp03v$2t8k$1@digitaldaemon.com>, Sean Kelly says...
>>
>>So what would you suggest?
>
>Shrug. I'd suggest that GC is a lousy official memory management strategy for a language like D, but I've already done that and seem to be in a minority of one. (Cue 'Hearts and Flowers'...)

You earlier stated that you found pin / unpin as being ugly:

    Plus, of course, many if not most calls to C APIs will have to be wrapped
with
    pin/unpin calls. Verbose, ugly and easy to forget. Even worse with
asynchronous
    operations or userdata pointers for callbacks.

Yet you, in the msg I quoted, say that you'd rather there be no GC.  So you'd rather be doing ugly verbose memory management everywhere than a few ugly verbose pin/unpin calls when you occasionally need to call into a C library?

-Sha

In article <dcr6l7$1l46$1@digitaldaemon.com>, Shammah Chancellor says...
>
>You earlier stated that you found pin / unpin as being ugly:

If manually wrapped around almost every C API call, yes. Particularly since D's easy integration with C means that it's not necessarily blindingly obvious which calls are to C APIs.

>Yet you, in the msg I quoted, say that you'd rather there be no GC.

No, I said I thought it was a lousy official memory management strategy. My problem isn't with D having GC; it's with D not having much else. GC is a reasonable approach to managing memory, but it's a completely worthless approach to managing most other resources. When non-memory resources are tightly coupled to objects, e.g. handles in an SWT-like GUI library that uses native peers, that inadequacy spills over.

>So you'd
>rather be doing ugly verbose memory management everywhere than a few ugly
>verbose pin/unpin calls when you occasionally need to call into a C library?

Resource management (and not just memory) in a language with deterministic dtors is far from ugly or verbose. (My current C++ project contains a grand total of one 'delete' and one 'delete[]'.) And it's consistent; the same mechanism works for everything. You don't have to worry about whether class Foo needs to be Dispose()d or Close()d or whatever, and when, and what happens to the 'zombie' object afterwards. You just let it go. The class knows how to clean itself up, and does so predictably as soon as possible and no sooner. Yes, there are costs. Yes, it takes a bit of discipline. IMHO it's worth it.

cheers
Mike

In article <dcrcql$1qpi$1@digitaldaemon.com>, Mike Capp says...
>
>In article <dcr6l7$1l46$1@digitaldaemon.com>, Shammah Chancellor says...
>>
>>You earlier stated that you found pin / unpin as being ugly:
>
>If manually wrapped around almost every C API call, yes. Particularly since D's easy integration with C means that it's not necessarily blindingly obvious which calls are to C APIs.

Eh?  D Requires imports, just like perl or any other language.  With the proper
imports any calls to C
from perl, php, qbasic, or whatever else look the same as a normal call.  If
you're talking about the
imports already in phobos.  I should hope you know which functions are in
std.c.* that you're
importing.  If not, you can easily check by removing that import and looking at
the slew of errors.

>>Yet you, in the msg I quoted, say that you'd rather there be no GC.
>
>No, I said I thought it was a lousy official memory management strategy. My problem isn't with D having GC; it's with D not having much else. GC is a reasonable approach to managing memory, but it's a completely worthless approach to managing most other resources. When non-memory resources are tightly coupled to objects, e.g. handles in an SWT-like GUI library that uses native peers, that inadequacy spills over.
>
>>So you'd
>>rather be doing ugly verbose memory management everywhere than a few ugly
>>verbose pin/unpin calls when you occasionally need to call into a C library?
>
>Resource management (and not just memory) in a language with deterministic dtors is far from ugly or verbose. (My current C++ project contains a grand total of one 'delete' and one 'delete[]'.) And it's consistent; the same mechanism works for everything. You don't have to worry about whether class Foo needs to be Dispose()d or Close()d or whatever, and when, and what happens to the 'zombie' object afterwards. You just let it go. The class knows how to clean itself up, and does so predictably as soon as possible and no sooner. Yes, there are costs. Yes, it takes a bit of discipline. IMHO it's worth it.

Congradulations, you spent a helluva alot of time getting your stuff setup
perfectly and have no
memory leaks.  (Which is a big problem with C++ programs...  Exactly the reason
there is a huge
market for memory debuggers.  Have you used one of these on your program? you
might be surprised.)

Being required to pin a variable which is getting passed to a C function is not
that big of a deal IMO.  If
if becomes such a big problem, it might not be hard to auto-pin references
passed to stuff which is
extern(C)  I don't know.