3 ms·

D seems to be more sensitive to these concerns than other languages, at least as of late. Classes can be marked as "auto", which indicates they are to be destru

D seems to be more sensitive to these concerns than other languages, at least as of late. Classes can be marked as "auto", which indicates they are to be destructed deterministically. I think this is a more elegant solution than requiring users to opt-in to proper semantics, though requiring the auto specifier at the use-site would make things more explicit. Also, most languages have some sort of thread-based tasking framework that can make it easier to implement async message-passing based concurrency.

acqq 16y ago
It's still bad, since it will lead to the effect "just write every class with auto." C++ combined memory allocation and the object destruction in one thing and now we have too many people that think those should be one primitive. They shouldn't. Once you recognize that you have to care about both separately, you start to recognize that even GC is an answer to the wrong question. For really "cool" programs (using the most of the resources etc) you simply have to manage memory yourself. Object should not manage their allocation, they should just "know" who's in charge for their allocation. Some Bloomberg guys recognized that and made some libraries for C++, ans some work was done to get something like that in C++ standard, but I don't know if the result is useful. I also don't know if such ideas would look nicer in D.
SamReidHughes 16y ago
I'm somewhat confused by the D documentation. The documentation refers to "auto objects" in the prose somewhere, but it seems to refer to the feature as "scope classes" and uses the scope keyword to do so. Here is the page I am referring to: http://www.digitalmars.com/d/2.0/class.html http://www.digitalmars.com/d/2.0/class.html . The reference also says the use of the scope keyword is required at the declaration site for references to scope classes.
pmjordan 16y ago
The problem I can see with specially tagging types like that is that you can't compose them within classes that use GC. The determinism is viral. You could make it an error to rely on destruction for resource release, but what stops the programmer from wrapping the resource in an object of his own making, and freeing the resource in the wrapper's destructor? Walk the stack to check if the code is called from ANY destructor?

acqq 16y ago

It's still bad, since it will lead to the effect "just write every class with auto." C++ combined memory allocation and the object destruction in one thing and now we have too many people that think those should be one primitive. They shouldn't. Once you recognize that you have to care about both separately, you start to recognize that even GC is an answer to the wrong question. For really "cool" programs (using the most of the resources etc) you simply have to manage memory yourself. Object should not manage their allocation, they should just "know" who's in charge for their allocation. Some Bloomberg guys recognized that and made some libraries for C++, ans some work was done to get something like that in C++ standard, but I don't know if the result is useful. I also don't know if such ideas would look nicer in D.

SamReidHughes 16y ago

I'm somewhat confused by the D documentation. The documentation refers to "auto objects" in the prose somewhere, but it seems to refer to the feature as "scope classes" and uses the scope keyword to do so. Here is the page I am referring to: http://www.digitalmars.com/d/2.0/class.html http://www.digitalmars.com/d/2.0/class.html . The reference also says the use of the scope keyword is required at the declaration site for references to scope classes.

pmjordan 16y ago

The problem I can see with specially tagging types like that is that you can't compose them within classes that use GC. The determinism is viral. You could make it an error to rely on destruction for resource release, but what stops the programmer from wrapping the resource in an object of his own making, and freeing the resource in the wrapper's destructor? Walk the stack to check if the code is called from ANY destructor?