August 03, 2005 Re: Interfacing to C - Storage Allocation - eek? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Capp | 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 |
August 03, 2005 Re: Interfacing to C - Storage Allocation - eek? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | 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 |
August 04, 2005 Re: Interfacing to C - Storage Allocation - eek? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Capp | 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. |
Copyright © 1999-2021 by the D Language Foundation