Christopher Wright dhase...@gmail.com wrote in message
news:ghlntc$ku...@digitalmars.com...
In this case, File should close itself in its destructor. Class A can't
close its file in its destructor because the file might have already been
collected and finalized. And you can't use a scope
Jim Hewes wrote:
Maybe it's better to think of memory and non-memory resources as different
things and handle them differently as opposed to lumping them together using
the same mechanism. I'm not sure if there is already a way to deal with this
in D as I'm not quite that familiar with D.
It
Jim Hewes wrote:
Yes. Thanks for the example. I do that sort of thing a lot, and it
applies to anything with a handle such as mutexes, files, etc. In
garbage-collected languages, what am I supposed to do there? It would
seem that garbage collection and exceptions don't play nice together. Or
Nick Sabalausky:
I think you might be confusing duck with dynamic/variant. Duck typing
doesn't refer to any particular data type, unlike dynamic typing which
implies a variant data type.
I was referring to the built-in duck type of the Boo language... it's a kind
of variant, with few more
bearophile, el 7 de diciembre a las 13:31 me escribiste:
15) Unhelpful standard library: Tango, etc, I think this is fixed enough.
I don't think this is fair. Unfortunately Tango is *not* the standard
library. If you say this is fixed because of Tango, one could say that
it's fixed in C++ too
Christopher Wright [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
And what are you going to throw an exception from, besides a function? I
think you are talking about situations like this:
class A
{
private File file;
this () { file = new File (somePath); }
// some
The following is a list of some of the main defects of C++, as seen by Yossi
Kreinin:
http://yosefk.com/c++fqa/defective.html
So I have tried to see how D1/D2 score in such regard. In the following list *
denotes a point that (I think) D doesn't address enough.
Note that I'm ignorant of C++ and
Nick Sabalausky wrote:
Walter Bright [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
bearophile wrote:
1) No compile time encapsulation: In naturally written C++ code,
changing the private members of a class requires recompilation of the
code using the class. I think D solves this
Nick Sabalausky wrote:
Walter Bright [EMAIL PROTECTED] wrote in message
Changing the private members changes offsets
of other members and derived classes, so they must all be recompiled.
Inline functions are also, of course, affected.
The way to avoid this is to use interfaces.
Would there
bearophile [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
12) No high-level built-in types: D has some very useful built-in data
structures, but they lack several useful methods (lazy views, dict
cleaning, dict equality, etc etc) and one or two more can be added (a set?
10 matches
Mail list logo
