Re: DMD svn and contract inheritance
Walter Bright wrote: Stewart Gordon wrote: I'm still none the wiser about why it absolutely has to be done like this instead of the simpler solution I proposed years ago. Can you refresh my memory? Seems straightforward to find to me, but here it is: http://www.digitalmars.com/d/archives/digitalmars/D/31595.html (The nested function approach is fairly simple in terms of lines of code to implement.) I can imagine how it works now. Essentially it's a function that can act as a nested function to the function for which it is originally defined or any override of it, which works since a nested function is really just a function with a pointer to the outer function's stack frame as a parameter. Correct? BTW I just rediscovered this old thread http://www.digitalmars.com/d/archives/digitalmars/D/9775.html which is making me think we probably ought to enable contracts on bodyless functions some time. Stewart.
Re: What does Coverity/clang static analysis actually do?
Brad Roberts wrote: * graphing of issue trends That's a crock g. Uh, whatever. Most of the rest of us humans respond much better to pictures and trends than to raw numbers. Show me some visual indication of the quality of my code (ignoring the arguments about the validity of such graphs) and I can pretty much guarantee that I'll work to improve that measure. Nearly everyone I've ever worked with behaves similarly.. once they agree that the statistic being measured is useful. One of the best examples is percent of code covered by unit tests. The same applies to number of non-false positive issues discovered through static analysis. A long time ago, the company I worked for decided to put up a huge chart on the wall that everyone could see, and every day the current bug count was plotted on it. The idea was to show a downward trend. It wasn't very long (a few days) before this scheme completely backfired: 1. engineers stopped submitting new bug reports 2. the engineers and QA would argue about what was a bug and what wasn't 3. multiple bugs would get combined into one bug report so it only counted once 4. if a bug was X is not implemented, then when X was implemented, there might be 3 or 4 bugs against X. Therefore, X did not get implemented. 5. there was a great rush to submit half-assed fixes before the daily count was made 6. people would invent bugs for which they would simultaneously submit fixes (look ma, I fixed all these bugs!) 7. arguing about it started to consume a large fraction of the engineering day, including the managers who were always called in to resolve the disputes In other words, everyone figured out they were being judged on the graph, not the quality of the product, and quickly changed their behavior to work the graph rather than the quality. To the chagrin of the QA staff, management finally tore down the chart. Note that nobody involved in this was a moron. They all knew exactly what was happening, it was simply irresistible. A specific case of this: At informix we had a step in our build process that ran lint (yes, it's ancient, but this was a decade ago and the practice was at least a decade old before I got there). Any new warnings weren't tolerated. The build automatically reported any delta over the previous build. It was standard practice and kept the code pretty darned clean. I think that's something different - it's not graphing or trending the data.
Re: What does Coverity/clang static analysis actually do?
Walter Bright wrote: Brad Roberts wrote: * graphing of issue trends That's a crock g. Uh, whatever. Most of the rest of us humans respond much better to pictures and trends than to raw numbers. Show me some visual indication of the quality of my code (ignoring the arguments about the validity of such graphs) and I can pretty much guarantee that I'll work to improve that measure. Nearly everyone I've ever worked with behaves similarly.. once they agree that the statistic being measured is useful. One of the best examples is percent of code covered by unit tests. The same applies to number of non-false positive issues discovered through static analysis. A long time ago, the company I worked for decided to put up a huge chart on the wall that everyone could see, and every day the current bug count was plotted on it. The idea was to show a downward trend. It wasn't very long (a few days) before this scheme completely backfired: 1. engineers stopped submitting new bug reports 2. the engineers and QA would argue about what was a bug and what wasn't 3. multiple bugs would get combined into one bug report so it only counted once 4. if a bug was X is not implemented, then when X was implemented, there might be 3 or 4 bugs against X. Therefore, X did not get implemented. 5. there was a great rush to submit half-assed fixes before the daily count was made 6. people would invent bugs for which they would simultaneously submit fixes (look ma, I fixed all these bugs!) 7. arguing about it started to consume a large fraction of the engineering day, including the managers who were always called in to resolve the disputes In other words, everyone figured out they were being judged on the graph, not the quality of the product, and quickly changed their behavior to work the graph rather than the quality. To the chagrin of the QA staff, management finally tore down the chart. Note that nobody involved in this was a moron. They all knew exactly what was happening, it was simply irresistible. Existence of a bad case doesn't disprove the usefulness in general. Yes, I agree that number of bugs is a bad metric to measure all by itself. Water can drown a person, but that doesn't make it something to avoid. Sigh, Brad
Re: What does Coverity/clang static analysis actually do?
Hello Walter, 3) Rule creation. The core engine usually generates some digested dataset upon rules are evaluated. The systems come with a builtin set that do the sorts of things already talked about. In addition they come with the ability to develop new rules specific to your application and business needs. For example: * tracking of taint from user data * what data is acceptable to log to files (for example NOT credit-cards) There have been several proposals for user-defined attributes for types, I think that is better than having some external rule file. For open source and libs, yes. For proprietary code bases, I'd say it's about a wash. Having it in another file could make the language/code base easier to read and also allow a much more powerful rules language (because it doesn't have to fit in the host language). And because only you will be maintaining the code, needing another tool (that you already have) and another build step isn't much of an issue.
Re: What does Coverity/clang static analysis actually do?
Hello Walter, Consider the Bible. It's long and complicated, and by careful examination of it you can find a verse here and there to justify *any* behavior. This is true of any long document if you are willing to string together enough quotes and ignore enough of it. I'd bet you could get the Declaration of Intendance out of Playboy if you wanted to. D is complicated, and is founded on principles that are not orthogonal - they are often at odds with each other. Any attempt to take one particular aspect of D's behavior and use it as a rule to impose elsewhere is surely doomed to conflict with some other rule. The only reasonable way forward is to evaluate each idea not only in terms of all of D's principles, but also on its own merits, and throw in one's best judgment. Nearly a decade with D has now shown that some ideas and choices were dead wrong, but others were more right than I even dreamed g. You sort of tangentially hit what I think is the key to avoiding creating meaning out of whole cloth; take the document as a whole, look for themes and trends (any document worth reading will have them), use them to answer your questions.
Re: Null references redux + Cyclone
Walter, is that article publicly available?
Re: Null references redux + Cyclone
Dejan Lekic wrote: Walter, is that article publicly available? http://www.codeproject.com/KB/cpp/FastDelegate.aspx
Re: Null references redux + Cyclone
Thanks Don! \o/
Re: restructuring name hiding around the notion of hijacking
On 2009-10-01 23:52:28 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Michel Fortin wrote: On 2009-10-01 12:29:39 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: I think it's a good idea, but there should be a way to *override* static functions. That has the same risks. The problem right now is that in order to use a class, you must absorb the definition of that class and that of each superclass of it, all the way up to Object. With hijacking thwarted, you can specify stuff in the base class that you can be sure will continue to work the same in derived classes. I believe this makes using classes quite a lot easier and safer. But it breaks one pattern of mine. In the D/Objective-C bridge I have a few static functions and variables that must be redefined for each subclass defining an Objective-C interface. I'd say that's a questionable practice (but then I don't know any more details). Well, essencially you can have a D class that act as a wrapper to an Objective-C class, or you can also have the reverse: a D class exposing itself as an Objective-C class. In all cases, the type hiearchy is preserved, so if you have NSString as a subclass of NSObject on the Objective-C side, you'll have the same on the D side. The NSString wrapper must have different static members than NSObject, binding it to a different Objective-C class so it can call the right methods on it (and so it allocates the right function), but those members have the same role (just a different value per class) and must be accessible for any class declaring an Objective-C interface (so the bridge can swap between the Objective-C and D value when calling a function on the other side). So it turns out that I'm implementing a mechanism somewhat alike classinfo for storing Objective-C related class-level data, and for that to work I need to reimplement any function accessing this data in each subclass that binds to a different Objective-C class. If I could attach my class-related data to the ClassInfo of a specific class (so it could be retrieved at runtime) and if static functions had access to the classinfo of the class they're called from (practically making them member function of the corresponding ClassInfo) the situation might be different though, and much less code would be needed. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Null references redux
bearophile Wrote: Max Samukha: Don't get confused by 'new' in struct initializers. Structs in C# are value types. Yes, you are right. But in D structs can be allocated on the heap too, so I think having optional nonnull struct pointers can be useful. The syntax and usage is similar to normal struct pointers. Bye, bearophile AYK, in C++ structs are just classes with public protection (for members) by default, or, if you like, classes are just structs with private protection (for members) by default. Other than protection rules there aint any *useful* difference semantically and you can have pointers or references to both. To a certain extent Bjarne would have done C++ a favour by either (1) not introducing class as a separate language entity and simply resigning to #define class struct and adding the OO the features to struct, or (2), instead of bleeding OO features into structs, heeding teacher, teacher leave the struct alone and introducing class as the clean addition that C++ brought to C. With D, the designer has made some rather brilliant distinction between classes and structs in terms of value vs reference. In doing so he has sorted out the dot (.) vs arrow (-) mess that is the infamous signature of C++. Quoting from the D spec: Structs and unions are meant as simple aggregations of data, or as a way to paint a data structure over hardware or an external type. External types can be defined by the operating system API, or by a file format. Object oriented features are provided with the class data type. I think it would be a billion dollar mistake to make the last sentence in that quote obsolete. But, if people insist, then let's be consistent and apply the same logic (re optional nonnull pointers being useful) to unions as well (and, for that matter, to anything that can be pointed to). Ahggg, shock horror. But then again, out of the shock and horror, maybe something beautiful can evolve. Cheers -- Justin Johansson
Re: null references redux + Looney Tunes
For the interest of newsgroups readers, I dropped in at the Cafe the other day and the barista had this to say http://cafe.elharo.com/programming/imagine-theres-no-null/ Disclaimer: YMMV Cheers -- Justin Johansson
Re: restructuring name hiding around the notion of hijacking
On Thu, 01 Oct 2009 22:52:28 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Michel Fortin wrote:
On 2009-10-01 12:29:39 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think it's a good idea, but there should be a way to *override*
static functions.
That has the same risks. The problem right now is that in order to use
a class, you must absorb the definition of that class and that of each
superclass of it, all the way up to Object. With hijacking thwarted,
you can specify stuff in the base class that you can be sure will
continue to work the same in derived classes. I believe this makes
using classes quite a lot easier and safer.
But it breaks one pattern of mine. In the D/Objective-C bridge I have a
few static functions and variables that must be redefined for each
subclass defining an Objective-C interface.
I'd say that's a questionable practice (but then I don't know any more
details).
Andrei
It may be questionable but it is used quite often. The technique can
be illustrated by altering your example of automatic code injection:
class Counted {
mixin(Derived)
{
// Insert here stuff that must be pasted for each subclass
// of Counted (including Counted itself).
// Use Derived as the name of the current subtype of
Counter
private static uint _counter;
uint staticCounter() { return _counter; }
static if (is(Counted == Derived))
uint getCounter() { return staticCounter; }
else
override uint getCounter() { return staticCounter; }
}
...
}
The counter variable is now incapsulated.
If the counter is, for example, an object that should be lazily
created, then you cannot get away without the static function any
more.
BTW, your example shows that 'override' being optional may actually be
a good idea and in this particular case allows to avoid the static
check and code duplication
Re: restructuring name hiding around the notion of hijacking
On 2009-10-02 08:29:09 -0400, Max Samukha spam...@d-coding.com said:
class Counted {
mixin(Derived)
{
// Insert here stuff that must be pasted for each subclass
// of Counted (including Counted itself).
// Use Derived as the name of the current subtype of
Counter
private static uint _counter;
uint staticCounter() { return _counter; }
static if (is(Counted == Derived))
uint getCounter() { return staticCounter; }
else
override uint getCounter() { return staticCounter; }
}
...
}
The counter variable is now incapsulated.
Hum, I think you forgot to make staticCounter static, as in:
static uint staticCounter() { return _counter; }
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: restructuring name hiding around the notion of hijacking
On Fri, 2 Oct 2009 08:54:49 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2009-10-02 08:29:09 -0400, Max Samukha spam...@d-coding.com said:
class Counted {
mixin(Derived)
{
// Insert here stuff that must be pasted for each subclass
// of Counted (including Counted itself).
// Use Derived as the name of the current subtype of
Counter
private static uint _counter;
uint staticCounter() { return _counter; }
static if (is(Counted == Derived))
uint getCounter() { return staticCounter; }
else
override uint getCounter() { return staticCounter; }
}
...
}
The counter variable is now incapsulated.
Hum, I think you forgot to make staticCounter static, as in:
static uint staticCounter() { return _counter; }
Yes, I do it all the time. Thanks!
Re: restructuring name hiding around the notion of hijacking
Michel Fortin wrote: If I could attach my class-related data to the ClassInfo of a specific class (so it could be retrieved at runtime) and if static functions had access to the classinfo of the class they're called from (practically making them member function of the corresponding ClassInfo) the situation might be different though, and much less code would be needed. It has crossed my mind more than once to put an Object userdata[string] member somewhere in TypeInfo or Classinfo (in fact the two will be soon merged). That way client code would be able to plant their own arbitrary data on a per-class basis. Andrei
Re: Should certain abstract classes be instantiable?
On Thu, Oct 1, 2009 at 11:48 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: But.. you mark something abstract when you want it to be .. abstract. How would you argue that abstract is basically a no-op when used on methods with bodies? It's not a no-op. Try it. Yeah, not *currently*, but isn't that what you're proposing?
Re: null references redux + Looney Tunes
Justin Johansson wrote: For the interest of newsgroups readers, I dropped in at the Cafe the other day and the barista had this to say http://cafe.elharo.com/programming/imagine-theres-no-null/ Disclaimer: YMMV Cheers -- Justin Johansson Most of the bugs he expose are trivial to debug and mostly come from beginners. From the article: The distinction between primitive and object types is a relic of days when 40 MHz was considered a fast CPU I so disagree with that on so many levels. That's exactly what I believe is wrong with programmers today, they excuse their sloppy programming and lazy debugging with safe constructs which have way more overhead than is actually needed. It doesn't really make the program easier to code but the programmer less careful, leading to new kind of bugs. Maybe for financial or medical domains its acceptable since speed is not an issue, but I expect my $3k computer to not slow down to a crawl because its software is written in a safe way and I like people with older computers to still be able to run my programs without waiting 5 minutes between any two mouse clicks.
Re: What does Coverity/clang static analysis actually do?
Hi, Walter Bright wrote: There's a lot of hoopla about these static checkers, but I'm not impressed by them based on what I can find out about them. What do you know about what these checkers do that is not on this list? Any other kinds of checking that would be great to implement? The development edition of VS2008 also has a static code analyzer. There is a list of issued warnings for C/C++ with examples at: http://msdn.microsoft.com/en-us/library/a5b9aa09.aspx There are a lot more messages generated for managed code: http://msdn.microsoft.com/en-us/library/ee1hzekz.aspx The analyzer does inter-procedural-analysis, so it (sometimes) knows, what range of values function arguments can have. I've run the analysis on the dmd source code, but deactivated some warnings regarding memory leaks and variable hiding to not get flooded with messages. After that, code analysis added about 150 warnings to the 1000 already issued by the compiler (mostly signed/unsigned mismatch and unreferenced local variable). The code analyzer warnings often deal with - Dereferencing NULL pointer (I've added __assume statements to assert, so the compiler does not warn null pointers, if there is an assert(pointer) somewhere before the indirection). Most of these warnings are not so easy to verify, but some are probably correct. - Using uninitialized memory: mostly after switch-statements without variable initialization in default. - Invalid data: accessing 'variable', the readable size is 'X' bytes, but 'Y' bytes might be read: as far as I could see, these are often false positives, because the analyzer could not deal with variable sized arrays at the end of structs (you can add annotation to help the analyzer, though, but I have not tried). Even with constant size arrays, some of the warnings are plain wrong. - stdlib/windows-api calls (e.g. printf arguments, ignored return codes) I guess, that you'll have to annotate the code a lot if you want to have the compiler always do the analyzing and get reasonable results. I've also seen C# code with a lot of attributes just to suppress warnings from the analyzer. Rainer
Re: null references redux + Looney Tunes
On Fri, Oct 2, 2009 at 8:13 AM, Justin Johansson n...@spam.com wrote: For the interest of newsgroups readers, I dropped in at the Cafe the other day and the barista had this to say http://cafe.elharo.com/programming/imagine-theres-no-null/ Disclaimer: YMMV Cheers -- Justin Johansson I always think it's funny when people are like so, I had this idea, lemme throw this out there. I know it sounds weird, but just bear with me - what if there were _no null_? Did I just _blow your mind?_ And the perspective of languages with better type systems, it's like.. and? data Maybe T = Just T | Nothing The whole null/nonnull debate is a complete nonissue in languages like Haskell because _they actually treat it formally and correctly_. And they've _been_ doing this for years. For all the Java-ites to be like OMG PARADIGM SHIFT it's just funny.
Re: null references redux + Looney Tunes
Justin Johansson wrote: For the interest of newsgroups readers, I dropped in at the Cafe the other day and the barista had this to say http://cafe.elharo.com/programming/imagine-theres-no-null/ Disclaimer: YMMV Cheers -- Justin Johansson This article brings up a very interesting point that beats Walter's argument to a pulp, then puts salt on it. Walter's overriding argument (I'm sure you know it, he repeated it claiming nobody understands it until we learned it by heart) was: I don't want the compiler to require a value there! People will just put some crappy value in to get the code to compile, and the code with errors in it will soldier on instead of duly crashing! How is that better??? etc. Yet D has structs. Walter knows D has structs, and knows how D structs operate. He put structs in D because he thought structs, vegetables, exercising, and flossing are good for you. Yet structs operate the exact way that Walter claim is pernicious. Structs don't have a singular null value and always are nominally valid objects. Yet I've never heard Walter continuing his argument with Just look at those stinky structs. It must be a million times I had a bug caused by the absence of null structs! I just had to put a crappy struct there in my code, and my code soldiered on in error instead of crashing! Why didn't he continue his argument that way? And why didn't anybody else continue his argument that way? Because nobody has had such a problem. Everybody uses structs, and everybody's happy about them lacking null. To complete the irony, Walter and I discussed a while ago about structs and .init values. We concluded that D, at least for the time being, will allow struct construction without any code invocation, by just bitcopying the .init value of the struct over. He was very happy about that because a lot of code generation got majorly simplified that way. (I was less happy because that meant less user control over struct construction.) So Walter was happy that he had for structs a feature he thinks is amazingly dangerous for classes. So I don't think Walter's argument is invalid, I think it simply doesn't exist. This post made it disappear. Andrei
Re: Should certain abstract classes be instantiable?
Jarrett Billingsley wrote: On Thu, Oct 1, 2009 at 11:48 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: But.. you mark something abstract when you want it to be .. abstract. How would you argue that abstract is basically a no-op when used on methods with bodies? It's not a no-op. Try it. Yeah, not *currently*, but isn't that what you're proposing? No. I think it would help going back to my original message instead of asking one-liner questions. This would work much better in real life, but it's a time sink in a newsgroup. You spend five seconds on asking a question with a foregone answer just because you don't want to invest fifteen seconds in re-reading my initial post, and then you have me spend five minutes explain things again. It's counter-productive. If a class defines an abstract method and also provides a body for it, it still requires the derived class to override the method. So abstract still has some meaning. On the other hand, technically such a class would become instantiable because it defines all of its methods. I wanted to explain that, however, that wouldn't be a good idea because... and here's where 1-2 good examples would have helped. I guess I'm going to drop it. Andrei
Re: null references redux + Looney Tunes
On 02/10/2009 16:16, Jeremie Pelletier wrote: Justin Johansson wrote: For the interest of newsgroups readers, I dropped in at the Cafe the other day and the barista had this to say http://cafe.elharo.com/programming/imagine-theres-no-null/ Disclaimer: YMMV Cheers -- Justin Johansson Most of the bugs he expose are trivial to debug and mostly come from beginners. From the article: The distinction between primitive and object types is a relic of days when 40 MHz was considered a fast CPU I so disagree with that on so many levels. That's exactly what I believe is wrong with programmers today, they excuse their sloppy programming and lazy debugging with safe constructs which have way more overhead than is actually needed. It doesn't really make the program easier to code but the programmer less careful, leading to new kind of bugs. Maybe for financial or medical domains its acceptable since speed is not an issue, but I expect my $3k computer to not slow down to a crawl because its software is written in a safe way and I like people with older computers to still be able to run my programs without waiting 5 minutes between any two mouse clicks. all I can say is: Thank God I'm an atheist. it seems you do not want to hear a different opinion despite the fact that option types exist in FP for half a century already and provide the correct semantics for nullable types. with your logic we should remove seat-belts from cars since it makes for less careful drivers.
scope class members - in-situ
I think this has been discussed in this group already.
An object storing another object needs two allocations:
class A { ... }
class B {
A a;
this() {
a = new A;
}
}
auto b = new B; // two allocations
I'm thinking of using scope in this situation to imply in-situ storage:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That
means the constructor needs special scrutiny, in particular a cannot be
null because that wouldn't make much sense.
What do you think?
Andrei
Re: scope class members - in-situ
On Fri, Oct 2, 2009 at 8:33 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think this has been discussed in this group already.
An object storing another object needs two allocations:
class A { ... }
class B {
A a;
this() {
a = new A;
}
}
auto b = new B; // two allocations
I'm thinking of using scope in this situation to imply in-situ storage:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That means
the constructor needs special scrutiny, in particular a cannot be null
because that wouldn't make much sense.
What do you think?
I think it would be nice, but there are enough issues that I'm not
convinced that saving a few allocations is worth it.
Mainly what happens if you do someB.a = someOtherA later on?
The answer to that might be different than how you treat someB.a = new A().
The latter could be converted into a placement new. But the former
has to still point to the original someOtherA to maintain proper
reference semantics.
You can sidestep these issues by saying that a scope A in a class is
not rebindable. But that no doubt cuts out some useful cases.
Another option would be to make scope A reserve space for both a
pointer to an A and the memory for it. Then the someB.a is just a
regular A reference that can be rebound like any other, or made null
if desired. It would just leave orphaned memory sitting there if
rebound to point to some other A. Or it could use placement
construction if you assign a new A to it. (but not if you say
someB.a = new DerivedFromA()).
--bb
Re: scope class members - in-situ
Andrei Alexandrescu wrote: I think this has been discussed in this group already. *Think*?! http://www.digitalmars.com/d/archives/digitalmars/D/scope_inline_optimizations_scoped_attributes_95025.html http://www.digitalmars.com/d/archives/digitalmars/D/D2_s_feature_set_91823.html http://www.digitalmars.com/d/archives/digitalmars/D/important_proposal_scope_keyword_for_class_members_85524.html http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_write_a_proper_class_destructor_6113.html#N6120 http://www.digitalmars.com/d/archives/digitalmars/D/38329.html And I'm certain I've missed quite a few. I know history is cyclical, but this is getting ridiculous.
Re: scope class members - in-situ
Andrei Alexandrescu:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That
means the constructor needs special scrutiny, in particular a cannot be
null because that wouldn't make much sense.
What do you think?
I have recently discussed about this. One idea is to keep the compiler simpler,
keeping such scoped class as possible similar to normal class. So you keep the
indirection. So B keeps inside itself the memory needed to keep an A plus a
reference to A itself. This wastes a little memory for the reference and keeps
the indirection, but allows to keep the semantics of A almost unchanged,
because you can always do reassign a to another instance of A (an instance
that can allocated on the heap too).
In such situation the main and maybe only thing you have to keep care of is the
deallocation of a, that has to not happen (well, you can call its destructor,
but you can't actually free its memory), because even if the GC has declared it
as dead (because of a delete or because a has being reassigned to something
else), it can't be deallocated until the instance of B is deallocated.
There are other ways to implement this, but I think they require more
special-casing and more changes to the frontend and probably a little more
complexity.
Bye,
bearophile
Re: scope class members - in-situ
Bill Baxter wrote:
On Fri, Oct 2, 2009 at 8:33 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think this has been discussed in this group already.
An object storing another object needs two allocations:
class A { ... }
class B {
A a;
this() {
a = new A;
}
}
auto b = new B; // two allocations
I'm thinking of using scope in this situation to imply in-situ storage:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That means
the constructor needs special scrutiny, in particular a cannot be null
because that wouldn't make much sense.
What do you think?
I think it would be nice, but there are enough issues that I'm not
convinced that saving a few allocations is worth it.
Mainly what happens if you do someB.a = someOtherA later on?
The answer to that might be different than how you treat someB.a = new A().
The latter could be converted into a placement new. But the former
has to still point to the original someOtherA to maintain proper
reference semantics.
You can sidestep these issues by saying that a scope A in a class is
not rebindable. But that no doubt cuts out some useful cases.
Yah, the idea was to make it not rebindable. Initially I even thought of
using final instead of scope.
Another option would be to make scope A reserve space for both a
pointer to an A and the memory for it. Then the someB.a is just a
regular A reference that can be rebound like any other, or made null
if desired. It would just leave orphaned memory sitting there if
rebound to point to some other A. Or it could use placement
construction if you assign a new A to it. (but not if you say
someB.a = new DerivedFromA()).
Having a reference plus in-situ storage also crossed my mind, but I
think it would serve corner cases that could best be served by either
using two allocations, or having the user herself define one reference +
one scope object.
Andrei
Re: scope class members - in-situ
Bill Baxter: Or it could use placement construction if you assign a new A to it. (but not if you say someB.a = new DerivedFromA()). I hope Andrei's book will explain how (and where) to use placement construction for classes in D. Bye, bearophile
Re: dmg for Snow Leopard x86_64 ?
simon Wrote: Was just wondering if there were plans to create a Snow Leopard build of D 2.0? After reading this I thought D2.0 and D1.0 isnt working at all on 10.6. But in fact compiling a testprog in D1.0 worked out of the box while D2.0 gives me segfault. Is D2 supposed to be working at all in OSX10.6?
Re: Defining some stuff for each class in turn
On Thu, 01 Oct 2009 13:53:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Jarrett Billingsley wrote:
On Thu, Oct 1, 2009 at 12:25 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
[code injection]
What do you think?
I think it sounds interesting enough, but I can't help but wonder if
this is a feature that you've really thought through (especially wrt.
how it interacts with mechanisms such as template mixins and normal
symbol inheritance), or if you just want it to support some pattern
you want to use in Phobos 2.
I've known for a long time this was in store if we want to define decent
reflection. It's also been a perennial source of trouble with a lot of
code that needs to inject members.
Let me give another example. When we discussed opCmp around here, people
said that's the old way of doing things and that the right way is to use
an interface Comparator!T, akin to Java's ComparatorT:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Comparator.html
That only solves exactly one level of inheritance. It's a more elaborate
solution that doesn't quite help that much. Consider:
interface Comparator(T)
{
int opCmp(T rhs); // yum, exact type
}
class Widget : Comparator!Widget
{
override opCmp(Widget rhs) { ... } // yum, exact type
}
class Gadget : Widget
{
override opCmp(Gadget rhs) { ... } // ERROR
}
Of course that didn't work. Gadget.opCmp doesn't override anything.
Gadget needs to remember to inherit Comparator!Gadget:
class Gadget : Widget, Comparator!Gadget
{
override opCmp(Gadget rhs) { ... } // oh ok
}
So any class X in Widget's hierarchy that forgets to inherit
Comparator!X undergoes the risk of having the wrong opCmp called for it.
With injection, Comparator can be made to work for any interface:
interface Comparator(T)
{
int opCmp(Comparator!T rhs);
mixin(Impl) // for each implementation Impl
{
int opCmp(Impl rhs);
override int opCmp(Comparator!T rhs)
{
return opCmp(cast(Impl) rhs);
}
}
}
class Widget : Comparator!Widget { ... }
Now every derived class of Widget, including Widget itself, commits to
define a opCmp with the proper signature (failure to do so results in a
linker error), and also defines the interface function in terms of it.
This still isn't optimal. For example, two different derivatives of the
same class could try to compare to eachother and end up passing null into
your opCmp. It would be nice if the compiler could reject unrelated
comparisons:
class X: Comparator!X
{
int opCmp(X) {}
}
class Y: X
{
int opCmp(Y) {}
}
class Z: X
{
int opCmp(Z) {}
}
void main()
{
auto y = new Y;
auto z = new Z;
z y; // error, rejected because they can't possibly be related
}
If there was a way to do that it would be cool. I also think the
auto-defined opCmp should look like this:
override int opCmp(Comparator!T rhs)
{
if(auto imp = cast(Impl) rhs)
return opCmp(imp);
return false;
}
That would cut down on calls into your actual opCmp function with a null
argument.
-Steve
Re: Should certain abstract classes be instantiable?
On Thu, 01 Oct 2009 16:30:43 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Consider:
class A {
abstract void fun() {}
}
The class defines a function that is at the same time abstract (so it
requires overriding in derivees) and has implementation.
Currently the compiler disallows creation of objects of type A, although
technically that is feasible given that A defines the abstract method.
Should A be instantiable? What designs would that help or hinder?
If you want to force a class to be abstract, even though it technically
could be concrete given it has implementations for all functions, you
could allow that by marking the class abstract. i.e.:
abstract class A {
void fun() {}
}
The other side, allowing A to be instantiated, makes no sense whatsoever.
If you (as a class designer) want something to be instantiated, and it has
all methods implemented, why mark it abstract? IMO, it should be a
compiler error to give implementation to an abstract method.
-Steve
Re: Should certain abstract classes be instantiable?
On 2-10-2009 8:32, Lionello Lunesu wrote:
On 2-10-2009 4:30, Andrei Alexandrescu wrote:
Consider:
class A {
abstract void fun() {}
}
The class defines a function that is at the same time abstract (so it
requires overriding in derivees) and has implementation.
Currently the compiler disallows creation of objects of type A, although
technically that is feasible given that A defines the abstract method.
Should A be instantiable? What designs would that help or hinder?
Andrei
If it were instantiable, what would be the difference between abstract
and virtual?
OK, so I reread your post and yes, it requires overriding in derivees.
Derived classes would still be allowed to do super.fun(), calling the
'abstract' class's implementation. It's like NVI, only worse?
L.
Re: null references redux + Looney Tunes
Fri, 02 Oct 2009 10:16:05 -0400, Jeremie Pelletier thusly wrote: I expect my $3k computer to not slow down to a crawl because its software is written in a safe way and I like people with older computers to still be able to run my programs without waiting 5 minutes between any two mouse clicks. Your $3k computer can probably run about 7200 billion instructions in 5 minutes - it will eventually get old in the coming years. I really hope the bloat in various software components never gets that bad that you would have to wait 5 minutes between two mouse clicks!
Re: null references redux + Looney Tunes
Fri, 02 Oct 2009 10:30:24 -0400, Jarrett Billingsley thusly wrote: I always think it's funny when people are like so, I had this idea, lemme throw this out there. I know it sounds weird, but just bear with me - what if there were _no null_? Did I just _blow your mind?_ And the perspective of languages with **better type systems**, it's like.. *plonk* :-P (old-timers might know) The whole null/nonnull debate is a complete nonissue in languages like Haskell because _they actually treat it formally and correctly_. And they've _been_ doing this for years. For all the Java-ites to be like OMG PARADIGM SHIFT it's just funny. You know, mainstream is pretty much religion driven.. many might have already plonked you automatically because your postings have contained the words 'disagree', 'progress', 'haskell', or 'scala'. The performance focused people from the c++ land seem to have a strong conservative view towards new things - like it or not. Walter being mostly a C++ guy and not having written much code in any other language (including D!) only makes the situation a bit worse, if you prefer progress.
Re: Should certain abstract classes be instantiable?
On Fri, Oct 2, 2009 at 11:00 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: No. I think it would help going back to my original message instead of asking one-liner questions. This would work much better in real life, but it's a time sink in a newsgroup. You spend five seconds on asking a question with a foregone answer just because you don't want to invest fifteen seconds in re-reading my initial post, and then you have me spend five minutes explain things again. It's counter-productive. If a class defines an abstract method and also provides a body for it, it still requires the derived class to override the method. So abstract still has some meaning. Yes, I see now the parenthesized requires overriding in derivees now. On the other hand, technically such a class would become instantiable because it defines all of its methods. I wanted to explain that, however, that wouldn't be a good idea because... and here's where 1-2 good examples would have helped. I guess I'm going to drop it. Speaking of counterproductive timesinks, why would you bring up a proposal only to argue that it's a bad idea?
generalizing hiding rules
I was just playing with some nested classes:
class Base {
int x;
}
class A {
private int x, y;
class B : Base {
int z;
this() {
x = 42;
y = 43;
this.outer.x = 44;
z = 45;
}
}
}
In the code above, if you just write x in A.B's constructor, Base.x is
fetched. So Base.x hides this.outer.x.
Disallowing hiding vertically in nested scopes has been quite
successful. Also, D's no-hijack stance is also shaping up to be a hit. I
am therefore thinking - why not apply the no-hijack rule throughout the
language?
If one symbol leads to working code through two different lookups, an
ambiguity error would be issued. The only exception would be if one
symbol is scoped and the other is at module scope (for the reasons I
discussed in another post).
I wonder to what extent this would break modular code, or foster more
intelligible code. With this rule in tow, A.B.this() would have to use
Base.x and this.outer.x to access the two x's.
What do you think?
Andrei
Re: scope class members - in-situ
Andrei Alexandrescu wrote:
I think this has been discussed in this group already.
An object storing another object needs two allocations:
class A { ... }
class B {
A a;
this() {
a = new A;
}
}
auto b = new B; // two allocations
I'm thinking of using scope in this situation to imply in-situ storage:
class B {
scope A a;
this() {
a = new A;
}
}
Now the A member actually lies inside of B - no more indirection. That
means the constructor needs special scrutiny, in particular a cannot be
null because that wouldn't make much sense.
What do you think?
I think it should be done in userland, not built-in. Here's a
proof-of-concept implementation:
import std.stdio;
string scopeInstance(string type, string name) {
return `
private byte[__traits(classInstanceSize, `~type~`)]
_scopeInstance__`~name~`;
static this() {
const int off = _scopeInstance__`~name~`.offsetof;
const int len = __traits(classInstanceSize, `~type~`);
typeof(this).classinfo.init[off .. off + len] =
`~type~`.classinfo.init;
}
`~type~` `~name~`() {
return cast(`~type~`)_scopeInstance__`~name~`.ptr;
}
void `~name~`(`~type~` f) {
_scopeInstance__`~name~`[] =
(cast(byte*)f)[0.._scopeInstance__`~name~`.sizeof];
}`;
}
class Foo {
int x;
float y;
string zomg = zomg;
this(int x, float y) {
writeln(making a Foo);
this.x = x;
this.y = y;
}
~this() {
writeln(death-tracting a Foo);
}
}
class Bar {
string x;
this (string x) {
writeln(making a Bar);
this.x = x;
}
}
class Baz {
mixin(scopeInstance(Foo, foo));
mixin(scopeInstance(Bar, bar));
this() {
writeln(making a Baz);
foo.__ctor(1, 3.14f);
bar.__ctor(ohai);
}
~this() {
writeln(death-tracting a Baz);
foo.__dtor();
}
}
void main() {
scope b = new Baz;
writeln(b.foo.x, , b.foo.y, , b.foo.zomg);
writeln(b.bar.x);
writeln(Foo size: , __traits(classInstanceSize, Foo));
writeln(Bar size: , __traits(classInstanceSize, Bar));
writeln(Baz size: , __traits(classInstanceSize, Baz));
}
Result:
making a Baz
making a Foo
making a Bar
1 3.14 zomg
ohai
Foo size: 24
Bar size: 16
Baz size: 48
death-tracting a Baz
death-tracting a Foo
Now for a brief summary:
* I couldn't get hold of the initializer of a class at compile-time.
I've tried using symbol.mangleof ~ 6__initZ, but DMD told me it could
not be an initializer for a static array. This forced me to initialize
the 'inline' / 'scope' class instances in a static ctor. I'm not sure if
this is legal - can ClassInfo ever wind up to live in ROM? Perhaps
__traits(classInitializer, _) could be added.
* The long proposed __ident extension would allow turning the string
mixin into a regular template mixin.
* __ctor should be standardized (or is it?)
I'm not very good at D2, so perhaps there are better ways to implement
it by now. Here's a similar proposal in pseudo-D2-code:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=85684
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Re: Should certain abstract classes be instantiable?
Jarrett Billingsley wrote: On Fri, Oct 2, 2009 at 11:00 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: No. I think it would help going back to my original message instead of asking one-liner questions. This would work much better in real life, but it's a time sink in a newsgroup. You spend five seconds on asking a question with a foregone answer just because you don't want to invest fifteen seconds in re-reading my initial post, and then you have me spend five minutes explain things again. It's counter-productive. If a class defines an abstract method and also provides a body for it, it still requires the derived class to override the method. So abstract still has some meaning. Yes, I see now the parenthesized requires overriding in derivees now. On the other hand, technically such a class would become instantiable because it defines all of its methods. I wanted to explain that, however, that wouldn't be a good idea because... and here's where 1-2 good examples would have helped. I guess I'm going to drop it. Speaking of counterproductive timesinks, why would you bring up a proposal only to argue that it's a bad idea? It was a question, you one-liner-asker you. Andrei
Re: scope class members - in-situ
Tom S wrote: I think it should be done in userland, not built-in. Here's a proof-of-concept implementation: [awesome code snipped] I am struck with awe. Thanks. Andrei
Re: scope class members - in-situ
Tom S wrote: I think it should be done in userland, not built-in. Here's a proof-of-concept implementation: [awesome code snipped] I am struck with awe. Thanks. Andrei
Re: null references redux + Looney Tunes
language_fan wrote: Fri, 02 Oct 2009 10:30:24 -0400, Jarrett Billingsley thusly wrote: I always think it's funny when people are like so, I had this idea, lemme throw this out there. I know it sounds weird, but just bear with me - what if there were _no null_? Did I just _blow your mind?_ And the perspective of languages with **better type systems**, it's like.. *plonk* :-P (old-timers might know) The whole null/nonnull debate is a complete nonissue in languages like Haskell because _they actually treat it formally and correctly_. And they've _been_ doing this for years. For all the Java-ites to be like OMG PARADIGM SHIFT it's just funny. You know, mainstream is pretty much religion driven.. many might have already plonked you automatically because your postings have contained the words 'disagree', 'progress', 'haskell', or 'scala'. The performance focused people from the c++ land seem to have a strong conservative view towards new things - like it or not. Walter being mostly a C++ guy and not having written much code in any other language (including D!) only makes the situation a bit worse, if you prefer progress. I'll note two things. For one, Walter is a heck more progressive than his pedigree might lead one to think. He has taken quite some risks with a number of features that made definite steps outside the mainstream, and I feel he bet on the right horse more often than not. Second, this particular discussion is not about efficiency. Andrei
Re: Should certain abstract classes be instantiable?
On Fri, Oct 2, 2009 at 1:34 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: It was a question, you one-liner-asker you. What? ;)
Re: What does Coverity/clang static analysis actually do?
Walter Bright wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
2. possible dereference of NULL pointers (some reaching definitions
of a pointer are NULL)
2. Optimizer collects the info, but ignores this, because people are
annoyed by false positives.
If you mean something like this:
Foo f;
if(cond)
f = new Foo();
f.bar();
Then I *want* the compiler to tell me. C# does this and I've never
been annoyed by it, in fact I've always appreciated it. I'm not aware
of any other C# user that has a problem with that either. If that's
not what you mean though, then could you elaborate?
The problem crops up when there are two connected variables:
void foo(bool flag)
{
char* p = null;
if (flag)
p = hello;
...
if (flag)
bar(*p);
}
The code is logically correct, there is no null pointer dereference
possible. However, the data flow analysis will see the *p and see two
reaching definitions for p: null and hello, even though only one
actually reaches.
Hence the false positive. To eliminate the false error report, the user
would have to insert a redundant null check.
Does this happen in practice? Yes.
I don't know about Coverity/clang, but I have used Klocwork a
couple of times and it will work properly in the example you have
given. I.e it sees that both conditions are linked and that you
don't use p if you haven't initialized it.
Of course, if the condition is more complex or if the condition
might be modified by another thread (even if you know it isn't),
there comes a point at which it will give a warning.
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: null references redux + Looney Tunes
Fri, 02 Oct 2009 12:38:33 -0500, Andrei Alexandrescu thusly wrote: I'll note two things. For one, Walter is a heck more progressive than his pedigree might lead one to think. He has taken quite some risks with a number of features that made definite steps outside the mainstream, and I feel he bet on the right horse more often than not. Second, this particular discussion is not about efficiency. I apologize that I said it in a way that might hurt Walter. I know he is extremely talented programmer and also open for new ideas. That is often not the problem. But it is not that hard to find features in D that are there only to make old C++ users feel comfortable. E.g. C style pointer syntax is harmful for the syntax of new features like tuples. It is also really confusing, but somehow has to be there since D must feel like C+ +, otherwise someone would notice that D is actually a modern multi- paradigm language that allows even functional programming, which is a bit bad for the reputation in conservative c++ circles. Some people would not even touch the language with a 10 foot pole, if someone dared to provide a practical garbage collector library for it. Because that would mean that there are people with wrong opinions (tm) in the community. I know there is a old and stubborn language war between academic foofoo and practical aspects.
Multiple subtyping with alias this and nested classes
I just realized that nested classes work so well with alias this, you'd
think it was an evil plot all along. It wasn't, but I'm happy about the
coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
void main()
{
auto obj = new Multiple;
Base1 obj1 = obj;
obj1.fun();
Base2 obj2 = obj;
obj2.gun();
}
The program above segfaults because somehow obj2 is null. That is a bug
I just reported. For now, you can replace obj2.gun() with obj.gun() to
make things work.
When we first introduced alias this, I knew multiple subtyping was
possible. I didn't expect it to dovetail so nicely with nested classes.
Andrei
Re: Multiple subtyping with alias this and nested classes
Fri, 02 Oct 2009 13:00:05 -0500, Andrei Alexandrescu thusly wrote:
I just realized that nested classes work so well with alias this, you'd
think it was an evil plot all along. It wasn't, but I'm happy about the
coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
override void fun() { writeln(Multiple.fun); }
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
I do not get why didn't you just use the 'import' keyword here instead of
alias, since what you are basically doing is importing the symbols from
one scope to another. It would seem a perfect generalization of import to
also include cases where 'with' is currently used and also alias. The use
of the term 'alias' is somewhat confusing.
Re: generalizing hiding rules
Andrei Alexandrescu: Disallowing hiding vertically in nested scopes has been quite successful. Also, D's no-hijack stance is also shaping up to be a hit. I am therefore thinking - why not apply the no-hijack rule throughout the language? I agree that making D tidier in such regards is positive, helps avoid errors. Explicit is better than implicit says Python Zen (even if in such attribute scoping regards Python has some design holes). Bye, bearophile
Re: Multiple subtyping with alias this and nested classes
language_fan wrote:
Fri, 02 Oct 2009 13:00:05 -0500, Andrei Alexandrescu thusly wrote:
I just realized that nested classes work so well with alias this, you'd
think it was an evil plot all along. It wasn't, but I'm happy about the
coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
override void fun() { writeln(Multiple.fun); }
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
I do not get why didn't you just use the 'import' keyword here instead of
alias, since what you are basically doing is importing the symbols from
one scope to another. It would seem a perfect generalization of import to
also include cases where 'with' is currently used and also alias. The use
of the term 'alias' is somewhat confusing.
Well if we did use 'import' people would have asked why we don't use
'alias' because that's much closer to what really happens.
Note that the feature does not only import symbols from one scope to
another. It just allows you to substitute some expression when someone
tries to use this under another type.
Andrei
Re: Multiple subtyping with alias this and nested classes
On Fri, 02 Oct 2009 13:00:05 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I just realized that nested classes work so well with alias this, you'd
think it was an evil plot all along. It wasn't, but I'm happy about the
coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
void main()
{
auto obj = new Multiple;
Base1 obj1 = obj;
obj1.fun();
Base2 obj2 = obj;
obj2.gun();
}
The program above segfaults because somehow obj2 is null. That is a bug
I just reported. For now, you can replace obj2.gun() with obj.gun() to
make things work.
When we first introduced alias this, I knew multiple subtyping was
possible. I didn't expect it to dovetail so nicely with nested classes.
Andrei
Neat! But what if there is Base3? Is it supposed to be subtyped like
this:
class Base3
{
void run() {}
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
class MyBase3 : Base3
{
override void run() { writeln(Multiple.run); }
}
MyBase3 _base3;
this() { _base3 = new MyBase3; }
alias _base3 this;
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
MyBase2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
?
Note that there is an additional level of indirection per each
subtype:
auto m = new Multiple;
m.run is unrolled to m._base2._base3.run
Re: Multiple subtyping with alias this and nested classes
On Fri, 02 Oct 2009 21:41:54 +0300, Max Samukha spam...@d-coding.com wrote: Note that there is an additional level of indirection per each subtype: subtype = subtyped type
Don Clugston's article Member Function Pointers and the Fastest Possible C++ Delegates
http://www.reddit.com/r/programming/comments/9q52z/member_function_pointers_and_the_fastest_possible/
Re: Multiple subtyping with alias this and nested classes
Max Samukha wrote:
On Fri, 02 Oct 2009 13:00:05 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I just realized that nested classes work so well with alias this, you'd
think it was an evil plot all along. It wasn't, but I'm happy about the
coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
void main()
{
auto obj = new Multiple;
Base1 obj1 = obj;
obj1.fun();
Base2 obj2 = obj;
obj2.gun();
}
The program above segfaults because somehow obj2 is null. That is a bug
I just reported. For now, you can replace obj2.gun() with obj.gun() to
make things work.
When we first introduced alias this, I knew multiple subtyping was
possible. I didn't expect it to dovetail so nicely with nested classes.
Andrei
Neat! But what if there is Base3? Is it supposed to be subtyped like
this:
class Base3
{
void run() {}
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
class MyBase3 : Base3
{
override void run() { writeln(Multiple.run); }
}
MyBase3 _base3;
this() { _base3 = new MyBase3; }
alias _base3 this;
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
MyBase2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
?
Note that there is an additional level of indirection per each
subtype:
auto m = new Multiple;
m.run is unrolled to m._base2._base3.run
Multiple alias this declarations must be allowed.
Andrei
Re: scope class members - in-situ
Andrei Alexandrescu: I'm thinking of using scope in this situation to imply in-situ storage: It may be good for the compiler to show a warning (that explains exactly why) where the compiler can't scope a class marked as scope (both in a function or in a method). Bye, bearophile
Re: generalizing hiding rules
Andrei Alexandrescu Wrote: Disallowing hiding vertically in nested scopes has been quite successful. Also, D's no-hijack stance is also shaping up to be a hit. I am therefore thinking - why not apply the no-hijack rule throughout the language? If one symbol leads to working code through two different lookups, an ambiguity error would be issued. The only exception would be if one symbol is scoped and the other is at module scope (for the reasons I discussed in another post). I wonder to what extent this would break modular code, or foster more intelligible code. With this rule in tow, A.B.this() would have to use Base.x and this.outer.x to access the two x's. Count my vote in favor of this change. -- Auria
Re: Defining some stuff for each class in turn
Andrei Alexandrescu wrote: Christopher Wright wrote: Andrei Alexandrescu wrote: I am becoming increasingly aware that we need to provide some means to define certain members (data and functions) for each class as if they were pasted there. Most of the examples given would be well served by decent builtin reflection. Walter thinks reflection is too expensive to be active by default. Find a cheaper way to provide runtime reflection. It's not as sexy as using templates, but it's DRY and easier to use. Slower, but you don't pay the cost of reflection multiple times if you have multiple libraries requiring reflection. What cheaper way would be than allowing a base class to prescribe reflection for its hierarchy? Where do templates even enter the mix? What's slower and why? Why do reflection as a language feature (increases base language size, buggy, rigid) instead of allowing it as a library if we so can? I'm totally against that. Andrei Once you get two or three libraries using reflection, it's cheaper to have the language provide it than to have separate, incompatible reflection systems. It doesn't matter whether the language provides reflection or the standard library. (The only way for me to tell is whether I'm importing from core or from std.) Either way, it should be standardized and easy to opt in or out (depending on the default), and there should be no way or no cost for opting in twice. You have to use templates to get reflection info, currently. Unless CTFE has gotten a lot better, in which case it's effectively the same as using templates, but with a bit less executable bloat. Template-based solutions can be faster than reflection-based solutions because you can access fields and methods directly. But runtime reflection doesn't disallow templates.
Re: What does Coverity/clang static analysis actually do?
BCS wrote: Hello Walter, Consider the Bible. It's long and complicated, and by careful examination of it you can find a verse here and there to justify *any* behavior. This is true of any long document if you are willing to string together enough quotes and ignore enough of it. I'd bet you could get the Declaration of Intendance out of Playboy if you wanted to. What is this Declaration of Intendance you speak of? As for ignoring context...well, I'm willing to discuss this, but not here.
Re: What does Coverity/clang static analysis actually do?
Rainer Schuetze wrote: I've run the analysis on the dmd source code, but deactivated some warnings regarding memory leaks and variable hiding to not get flooded with messages. After that, code analysis added about 150 warnings to the 1000 already issued by the compiler (mostly signed/unsigned mismatch and unreferenced local variable). Could you turn it all on, run it through the dmd source code, and send me the results? I'd like to see if it detected any real bugs.
Arrays template arguments and CT data structures
(after a small discussion on IRC) Tuples may be used for similar purposes, but
fixed-sized arrays are simpler to use, simpler to define, and they don't induce
compilation/code bloat. Is this a good idea?
int foo(int[3] arr)() {
return arr[1];
}
const int[3] a = [10, 20, 30];
void main() {
foo!(a)(); // a must be a constant fixed-sized array
}
--
Related:
A good purpose for compile-time functions is to pre-generate constant data
structures, avoiding to waste time generating them at compile time. But
currently creating fixed-sized arrays at compile time while possible is tricky
(it's easy for me to write code that doesn't compile. So I'd like D2 to become
more flexible here).
Constant associative arrays defined at compile time may use perfect hashing
functions that can be used at run time.
And generating structures with pointers is not possible at compile time
(possible usage for such structure: a trie that stores a constant dictionary,
avoiding both build and load time, even if loading the precomputed chunk of
memory of the array at run time takes a short time). At compile time indexes
can be used instead of pointers, for example allocating the trie nodes into a
compile time array and then using indexes to link nodes together.
Bye,
bearophile
Re: What does Coverity/clang static analysis actually do?
Bill Baxter wbax...@gmail.com wrote in message
news:mailman.122.1254431062.20261.digitalmar...@puremagic.com...
Probably more like
Foo f;
createAndSetOutParam(f);
f.bar();
or
Foo f;
if (a 10) { f = new Foo(10); }
...
if (a 10) {
f.bar();
}
How does C# handle the cases above?
Just did a little test:
---
static void Main(string[] args)
{
Foo f;
if(args.Count() 2) { f = new Foo(); }
if(args.Count() 2)
{
f.bar(); // ERROR: Use of unassgned local variable 'f'
}
Foo f2;
createFoo(ref f2); // ERROR: Use of unassgned local variable 'f2'
f2.bar();
}
static void createFoo(ref Foo f)
{
f = new Foo();
}
-
The first one is rather strange coding though and makes it easy to hide
errors anyway. And the second one's a tad odd too, plus I don't see any harm
in solving that with Foo f2=null: it would at least be a hell of a lot
better than the compiler doing that very same =null automatically. I know
Walter doesn't agree, but I'd much rather have a few slightly inconvinient
false positives (or would it really be a false negative?) than even a mere
possibility for a hidden error.
Re: Multiple subtyping with alias this and nested classes
Andrei Alexandrescu, el 2 de octubre a las 13:00 me escribiste:
I just realized that nested classes work so well with alias this,
you'd think it was an evil plot all along. It wasn't, but I'm happy
about the coincidence.
Here's how to effect multiple subtyping in D very effectively:
import std.stdio;
class Base1 {
void fun() { writeln(Base.fun); }
}
class Base2 {
void gun() { writeln(Base.fun); }
}
class Multiple : Base1 {
// Override method in Base1
override void fun() { writeln(Multiple.fun); }
// Override method in Base2
class MyBase2 : Base2 {
override void gun() { writeln(Multiple.gun); }
}
// Effect multiple subtyping
Base2 _base2;
alias _base2 this;
this() {
_base2 = new MyBase2;
}
}
void main()
{
auto obj = new Multiple;
Base1 obj1 = obj;
obj1.fun();
Base2 obj2 = obj;
obj2.gun();
}
The program above segfaults because somehow obj2 is null. That is a
bug I just reported. For now, you can replace obj2.gun() with
obj.gun() to make things work.
When we first introduced alias this, I knew multiple subtyping was
possible. I didn't expect it to dovetail so nicely with nested
classes.
We might have very different taste, but I find that a little... horrible.
What do you have against mixins? I think you're trying to use D as C++ :)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
EL PRIMER MONITO DEL MILENIO...
-- Crónica TV
Re: Should certain abstract classes be instantiable?
Andrei Alexandrescu Wrote:
Jarrett Billingsley wrote:
On Thu, Oct 1, 2009 at 4:30 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Consider:
class A {
abstract void fun() {}
}
The class defines a function that is at the same time abstract (so it
requires overriding in derivees) and has implementation.
Currently the compiler disallows creation of objects of type A, although
technically that is feasible given that A defines the abstract method.
Should A be instantiable? What designs would that help or hinder?
Uh... why?
Because I want to give a good argument one way or another in TDPL. FWIW,
I can't imagine why you'd ever... or Never needed that are not
strong enough arguments.
Andrei
I had a brilliant maths teacher at high school. Every now and then
someone would ask a question which everyone else though was silly.
Often he would jokingly reply, Good question. Next question. and then,
after a pause, explore the subtleties of the silly question to everyone's
total amazement.
There was one really, really smart guy who asked enough silly questions
and ended up getting his Ph.D. in Mathematics before the age of 20.
Because I want to give a good argument one way or another in TDPL.
Fair enough, Andrei. I'm trying hard with the following use case
to demonstrate that instantiation of the abstract is possibly useful.
Hope this helps or leads to further insight.
class NonNegativeInteger
{
static NonNegativeInteger infinity;
static this() {
infinity = new NonNegativeInteger();
}
/+abstract+/ long value() {
// In Andrei's scenario, this method is marked abstract
// so we don't really care what we return here;
// For moment comment out abstract keyword so that the
// initialization of the singleton instance of
// NonNegativeInteger, infinity, gets past the current
// compiler.
// Other than the private singleton instantiation inside
// the static this block, no external code is allowed to
// call new NonNegativeInteger() because the class
// is, for all intensive purposes, abstract (once the
// abstract keyword is uncommented).
assert(false);
return infinity.value;
}
void print() {
writefln( Infinity);
}
}
class FiniteNonNegativeInteger: NonNegativeInteger
{
private long val;
this( long value) {
val = value;
}
long value() {
return val;
}
NonNegativeInteger opDiv( NonNegativeInteger divisor) {
return (divisor.value != 0) ?
new FiniteNonNegativeInteger( value / divisor.value) :
NonNegativeInteger.infinity;
}
void print() {
writefln( %d, val);
}
}
void main() {
auto hundred = new FiniteNonNegativeInteger( 100);
auto two = new FiniteNonNegativeInteger( 2);
auto zero = new FiniteNonNegativeInteger( 0);
auto fifty = hundred / two;
auto infinity = hundred / zero;
hundred.print();
two.print();
fifty.print();
infinity.print();
}
Outputs:
100
2
50
Infinity
Cheers
Justin Johansson.
Re: Arrays template arguments and CT data structures
Fri, 02 Oct 2009 16:56:48 -0400, bearophile thusly wrote: A good purpose for compile-time functions is to pre-generate constant data structures, avoiding to waste time generating them at compile time. But currently creating fixed-sized arrays at compile time while possible is tricky (it's easy for me to write code that doesn't compile. So I'd like D2 to become more flexible here). Constant associative arrays defined at compile time may use perfect hashing functions that can be used at run time. And generating structures with pointers is not possible at compile time (possible usage for such structure: a trie that stores a constant dictionary, avoiding both build and load time, even if loading the precomputed chunk of memory of the array at run time takes a short time). At compile time indexes can be used instead of pointers, for example allocating the trie nodes into a compile time array and then using indexes to link nodes together. You have probably already noticed that there is always a tradeoff to be made. Either you get smaller binaries and faster compilation times or larger binaries and (perhaps) more efficient runtime performance. Note that if the data structures are small, generating them takes very little time on modern 32/64-bit hardware. OTOH if you have tens of megabytes of binary data in your .exe, hard drives are a serious bottleneck.
Re: Multiple subtyping with alias this and nested classes
Fri, 02 Oct 2009 19:35:55 -0300, Leandro Lucarella thusly wrote: We might have very different taste, but I find that a little... horrible. What do you have against mixins? I think you're trying to use D as C++ :) So basically the diamond problem is again implementable in D, yay?
Re: Arrays template arguments and CT data structures
bearophile wrote: (after a small discussion on IRC) Tuples may be used for similar purposes, but fixed-sized arrays are simpler to use, simpler to define, and they don't induce compilation/code bloat. (...) What do you mean by that? So parametrizing a template with a static array would cause less bloat than doing so with a tuple? I guess you might shave off a few bytes if mangling was shorter, but except that? *gasp* -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Multiple subtyping with alias this and nested classes
Leandro Lucarella wrote: We might have very different taste, but I find that a little... horrible. What do you have against mixins? I think you're trying to use D as C++ :) If mixins work better, all the better. How would you use them to achieve multiple inheritance? Andrei
Re: Arrays template arguments and CT data structures
language_fan: Note that if the data structures are small, generating them takes very little time on modern 32/64-bit hardware. OTOH if you have tens of megabytes of binary data in your .exe, hard drives are a serious bottleneck. You forget an important thing: If you generate things at compile time the compiler is more able to optimize the code, because more data is available at compile time (it can be a form of partial specialization). - Tom S: What do you mean by that? So parametrizing a template with a static array would cause less bloat than doing so with a tuple? I guess you might shave off a few bytes if mangling was shorter, but except that? *gasp* Tuples seems composed of dynamically typed items at compile time, so an array may need less memory to be managed by the compiler because its items have all the same type. And regarding the binary bloat, I was thinking about the static foreach over tuples, that has inflated some of my programs. But this isn't a real problem, so please breath normally :-) Bye and thank you, bearophile
Re: Multiple subtyping with alias this and nested classes
language_fan wrote: Fri, 02 Oct 2009 19:35:55 -0300, Leandro Lucarella thusly wrote: We might have very different taste, but I find that a little... horrible. What do you have against mixins? I think you're trying to use D as C++ :) So basically the diamond problem is again implementable in D, yay? Nah, there's no ambiguity - when in doubt, the primary inherited class is the source of the function. AFAIK, alias this only kicks in on otherwise undefined functions.
Re: implicit ubyte casting
Saaa wrote: Jeremie Pelletier wrote Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? Minus toggles the most significant bit, be it on a signed or unsigned type. When converting it to an int, the byte being signed or unsigned does make a difference: when unsigned the number is copied as is, when signed the most significant bit (bit 7) is shifted to the most significant bit of the int (bit 31). Its therefore pretty standard logic, no warning is given since the entire ubyte range fits within an int Jeremie Thanks, but it is not that I do not know how it occurs more that I should have asked whether people use this kind of logic. For me it resulted in annoying bug like this: for(int i = nloop;i10;i++);//ubyte nloop is created quite a few lines above. This has been discussed before, and it really should be an error. It's reasonable to implicitly cast between integral types of different size, and also signed-unsigned, but performing both within the same expression is almost always a bug. It should not be possible without an explicit cast.
Test - ignore - browser problems
Testing 1, 2, 3, testing
Re: implicit ubyte casting
Jeremie Pelletier wrote: Don wrote: Saaa wrote: Jeremie Pelletier wrote Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? Minus toggles the most significant bit, be it on a signed or unsigned type. When converting it to an int, the byte being signed or unsigned does make a difference: when unsigned the number is copied as is, when signed the most significant bit (bit 7) is shifted to the most significant bit of the int (bit 31). Its therefore pretty standard logic, no warning is given since the entire ubyte range fits within an int Jeremie Thanks, but it is not that I do not know how it occurs more that I should have asked whether people use this kind of logic. For me it resulted in annoying bug like this: for(int i = nloop;i10;i++);//ubyte nloop is created quite a few lines above. This has been discussed before, and it really should be an error. It's reasonable to implicitly cast between integral types of different size, and also signed-unsigned, but performing both within the same expression is almost always a bug. It should not be possible without an explicit cast. I know VC++ shouts a warning everytime signed and unsigned integrals are mixed, maybe that's the road D should take too. We can do *much* better than that. About two releases ago D2 got integer range tracking, so you can do things like: long a = someCrazyFunction(); ubyte b = (a 7) | 0x60; // No worries! This is perfectly fine! ubyte c = a; // Error, might overflow. It just needs to be extended a bit more. It's far from finished.
Re: implicit ubyte casting
Brad Roberts wrote:
On Thu, 1 Oct 2009, Saaa wrote:
I think is very bug-prone, isn't it obvious iub should be -5?
ubyte ub = 5;
int iub = -ub; // iub now is 251
What is the reasoning to do it this way?
The inclusion of the 'int' part obscures what I think the real problem
is..
Does it make sense to use uniary-minus on a unsigned type?
My answer.. no.
I agree. But you don't actually need unary minus to see the problem:
import std.stdio;
void main()
{
uint a = 0;
uint b = 5;
long ib = a - b;
writefln(%s, ib); // prints: 4294967291
}
Re: implicit ubyte casting
On Fri, 02 Oct 2009 16:25:01 +0200, Don wrote:
Brad Roberts wrote:
On Thu, 1 Oct 2009, Saaa wrote:
I think is very bug-prone, isn't it obvious iub should be -5?
ubyte ub = 5;
int iub = -ub; // iub now is 251
What is the reasoning to do it this way?
The inclusion of the 'int' part obscures what I think the real problem
is..
Does it make sense to use uniary-minus on a unsigned type?
My answer.. no.
I agree. But you don't actually need unary minus to see the problem:
import std.stdio;
void main()
{
uint a = 0;
uint b = 5;
long ib = a - b;
writefln(%s, ib); // prints: 4294967291
}
I feel like walking on the edge of a cliff all time without noticing. :
Re: implicit ubyte casting
Moritz Warning wrote:
snip
ubyte z = 5;
int x = -z; // x now is 251
int y = -1 * z; // y is now -5
Indeed, I've just looked at the spec, and it appears that the promotion
of all smaller integer types to int/uint applies only to binary
operations. Why?
It even arguably breaks the looks like C, acts like C principle (which
I thought was the reason behind these promotions in D):
--
#include stdio.h
int main() {
unsigned char z = 5;
int x = -z; // x now is 251
int y = -1 * z; // y is now -5
printf(%d %d %d\n, z, x, y);
return 0;
}
--
5 -5 -5
--
(DMC 8.42n Win)
Stewart.
Re: looking for an IDE
Phil Deets Wrote: Is there a Windows IDE with support for D2 debugging, building, The Zeus IDE can be easily configured to run the D compiler or any of the build tools: http://www.zeusedit.com/forum/viewtopic.php?t=2465 and basic code navigation (such as go to definition)? Zeus comes with a modified version of ctags meaning it can generate tag information for the D language. This tag information is used to drive the code navigation, class browsing and intelisensing features. I made these ctags changes quite some time ago changes when there was no D2 so I am not sure if this tagger stil works for D2. For any one that is inerested her are my ctags code changes: htp://www.zeusedit.com/z300/ctags_src.zip NOTE: Zeus is shareware Jussi Jumppanen Author: Zeus IDE
Re: implicit ubyte casting
Stewart Gordon wrote:
snip
#include stdio.h
int main() {
unsigned char z = 5;
int x = -z; // x now is 251
snip
Needless to say, this comment is a mistake.
Stewart.
[Issue 3359] New: Cannot parse pure/const/immutable functions with inferred return type
http://d.puremagic.com/issues/show_bug.cgi?id=3359
Summary: Cannot parse pure/const/immutable functions with
inferred return type
Product: D
Version: 2.031
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2009-10-02 00:07:23 PDT ---
This bug was originally reported as part of bug 3174.
int goo(int i) pure { return i; } // OK
auto foo(int i) pure { return i; } // Can't parse
class A {
auto hoo(int i) pure { return i; } // can't parse
const boo(int i) const { return i; } // can't parse
auto coo(int i) const { return i; } // can't parse
auto doo(int i) immutable { return i; } // can't parse
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3356] Make pure functions require immutable parameters
http://d.puremagic.com/issues/show_bug.cgi?id=3356 --- Comment #3 from Don clugd...@yahoo.com.au 2009-10-02 08:03:51 PDT --- (In reply to comment #2) (In reply to comment #1) (In reply to comment #0) 2. When a function takes a reference type parameter, the chanses are slim, that the return value doesn't depend on the referenced data. Yes. So the referenced data must be immutable. That conclusion does not follow. I don't think you're seeing all of the benefits of 'pure'. Consider foo(a) + foo(a). This can be changed into 2*foo(a), even though a is not immutable. You participated in discussion of bug 3057, where I described my view of the problem. The question is *how* can you benefit from advertised pureness of in fact impure functions? If you pass it the same *values*, you get the same results. It is true that in the case where all parameters are immutable, additional optimisations (such as caching) can be performed. But there's more to pure than that. But what you did with foo(a)+foo(a) if not caching? You effectively cached the result of function without any requirement for immutability. You don't need immutability in this case. foo(a) cannot change a, because foo is pure. There is nothing else in the expression which uses a. Therefore a does not change during the expression. (I'm assuming a is not shared). Therefore both calls to foo(a) have the same parameters, and the transformation foo(a) + foo(a) --- 2*foo(a) is legal. As soon as you have an assignment, or a call to an impure function, you can't do this any more. But if a is immutable, you have a much stronger guarantee. I'm asking to remove a bug from the language, because I think it's incorrect to allow marking impure functions as pure (and later benefit from this). Caching can only occur if all parameters passed to the function are the same. If the parameters are references, you need to ensure the value being referenced has not changed. Which is trivial if it's an immutable reference, but that's not the _only_ case where it is true. This is just an argument that const references _could_ be allowable in pure functions. But after all that, the spec currently says that parameters have to be implicitly immutable! So you can just change this to an accepts-invalid bug. ... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3361] New: code in std.zlib concatenates void[] arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3361 Summary: code in std.zlib concatenates void[] arrays Product: D Version: 1.045 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: thecybersha...@gmail.com --- Comment #0 from Vladimir thecybersha...@gmail.com 2009-10-02 18:39:32 PDT --- Created an attachment (id=468) proposed patch In several places, the code in the std.zlib concatenates void[] arrays. This causes allocation of data incorrectly marked as possibly containing pointers. This bug is the main source of severe memory leaks in my application, thus it is marked as critical. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
