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: I agree and also had a go at it a few months back: http://www.digitalmars.com/d/archives/digitalmars/D/scope_as_template_struct_82104.html What about alignment issues though? I think we need to force that byte array with the class data to have the same alignment restrictions as the class data.
Re: What does Coverity/clang static analysis actually do?
Christopher Wright dhase...@gmail.com wrote in message news:ha5mtp$f3...@digitalmars.com... BCS wrote: 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? That's the one they meant to write.
Re: null references redux + Looney Tunes
Jeremie Pelletier jerem...@gmail.com wrote in message news:ha51v1$24p...@digitalmars.com... 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. Holy crap, I feel like I have a clone ;) (Hopefully that was original enough to rationalize a blatant me too post ;) )
I wrote some D today and it's completely blowing my mind. Ever tried it?
http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
Re: I wrote some D today and it's completely blowing my mind. Ever tried
Walter Bright: http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/ Very nice. Indeed if you come from experience of C, D allows you to write programs in a much faster way. (But C isn't the only language around today, you also have dotnet C#, for example). Currently, it's conservative, but the D programming language semantics are designed to allow for a precise one. Maybe if there are unions it can't be fully precise. I think precision is a matter of degree, so you can build a quite precise GC. Bye, bearophile
Re: scope class members - in-situ
On Sat, 03 Oct 2009 10:52:09 +0400, Christian Kamm
kamm-incasoftw...@removethis.de wrote:
Tom S wrote:
I think it should be done in userland, not built-in. Here's a
proof-of-concept implementation:
I agree and also had a go at it a few months back:
http://www.digitalmars.com/d/archives/digitalmars/D/scope_as_template_struct_82104.html
What about alignment issues though? I think we need to force that byte
array
with the class data to have the same alignment restrictions as the class
data.
Yes, it is possible, but their use is dangerous without non-nullable
*value* types, because user is not forced to initialize it in ctor.
I believe compiler should complain unless user explicitly assigns a value
to such variable:
class Foo
{
Scope!(Bar) bar;
this()
{
//bar.construct(args); - a no-go, use of an unassigned variable.
// How can compiler distinguish between bar.constract(args),
// which is allowed to be called on non-constructed object, and
// bar.doSomething(), which is not?
// Besides, it hides possibly existing Bar.construct method.
// bar = new Bar(args); - desirable syntax, but impossible w/o
compiler help
bar = Scope!Bar(args); // explicitly initialized
bar.doSomething(); // okay
}
}
I think we should either drop scope feature altogether in favor of
library solution, or extend it to scope classes.
The former is not possible unless there is a way to implement scope(exit),
scope(success) and scope(failure) in library, which I am not aware of.
That's why I prefer built-in scope class members ATM.
Be it implemented in a compiler, should it be rebindable or not? Andrei
mentioned that it's probably not, but then it creates an inconsistency
with local scope variable (those are rebindable).
Another difference is that currently the following code is allowed:
Foo createFoo() {
return new FooDerivative();
}
scope Foo foo = createFoo(); // allocates on heap anyway, which might be
confusing
Shouldn't compiler complain in case scope variable is heap-allocated?
Shall we unify the two concepts (local and class member scope variables)?
If yes, then how?
Re: Should certain abstract classes be instantiable?
Justin Johansson Wrote:
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
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.
Just in case I'm misunderstood .. I don't believe the concept is particularly
useful; just that
Andrei was looking for some example, presumably to expand upon in TDPL, and my
sample was just an exploratory idea.
Obviously the sample that I dreamed up results in an infinite loop if the
abstract base class value() method is actually called.
-- Justin
Re: I wrote some D today and it's completely blowing my mind. Ever tried
Walter Bright Wrote: http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/ Don't know why you bother with Reddit, Walter. Going by a lot of the replies there, its a case of pearls before swine. Cheers -- Justin Johansson
Re: I wrote some D today and it's completely blowing my mind. Ever tried
Justin Johansson wrote: Walter Bright Wrote: http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/ Don't know why you bother with Reddit, Walter. Going by a lot of the replies there, its a case of pearls before swine. Cheers -- Justin Johansson Swine are smart.
Re: What does Coverity/clang static analysis actually do?
Nick Sabalausky wrote:
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.
The second one is an error; createFoo might use its argument before
assigning. You should have marked its argument as out instead, which
would not yield an error.
In point of fact, that's a common pattern in C#. Dictionaries define a
method bool TryGetValue(key, out value):
DateTime date;
if (dict.TryGetValue(key, out date))
{
// use date
}
Re: scope class members - in-situ
On 03/10/2009 11:59, Denis Koroskin wrote:
On Sat, 03 Oct 2009 10:52:09 +0400, Christian Kamm
kamm-incasoftw...@removethis.de wrote:
Tom S wrote:
I think it should be done in userland, not built-in. Here's a
proof-of-concept implementation:
I agree and also had a go at it a few months back:
http://www.digitalmars.com/d/archives/digitalmars/D/scope_as_template_struct_82104.html
What about alignment issues though? I think we need to force that byte
array
with the class data to have the same alignment restrictions as the class
data.
Yes, it is possible, but their use is dangerous without non-nullable
*value* types, because user is not forced to initialize it in ctor.
I believe compiler should complain unless user explicitly assigns a
value to such variable:
class Foo
{
Scope!(Bar) bar;
this()
{
//bar.construct(args); - a no-go, use of an unassigned variable.
// How can compiler distinguish between bar.constract(args),
// which is allowed to be called on non-constructed object, and
// bar.doSomething(), which is not?
// Besides, it hides possibly existing Bar.construct method.
// bar = new Bar(args); - desirable syntax, but impossible w/o compiler
help
bar = Scope!Bar(args); // explicitly initialized
bar.doSomething(); // okay
}
}
I think we should either drop scope feature altogether in favor of
library solution, or extend it to scope classes.
The former is not possible unless there is a way to implement
scope(exit), scope(success) and scope(failure) in library, which I am
not aware of.
That's why I prefer built-in scope class members ATM.
Be it implemented in a compiler, should it be rebindable or not? Andrei
mentioned that it's probably not, but then it creates an inconsistency
with local scope variable (those are rebindable).
Another difference is that currently the following code is allowed:
Foo createFoo() {
return new FooDerivative();
}
scope Foo foo = createFoo(); // allocates on heap anyway, which might be
confusing
Shouldn't compiler complain in case scope variable is heap-allocated?
Shall we unify the two concepts (local and class member scope
variables)? If yes, then how?
I think scope should be completely removed from the language. it seems
to me like the register keyword in C.
this aspect of memory management would be better off as an optimization
by the compiler when applicable instead of user specified.
consider:
class B {...}
class A {
// desirable syntax:
// const B obj;
NonRebindable!B obj; // assume language support instead of template
this (args) { obj = new B(args); }
}
since obj is non-rebindable the compiler can optimize this without
requiring the user to specify scope.
local variables in a function would have similar semantics:
void foo() {
NonRebindable!B = new B;
..
}
final classes and immutables can also scoped.
unless the user wants to explicitly handle memory with C malloc, I think
the best thing would be to separate lifetime management from memory
management. the programmer defines the lifetime of the data while the
language/compiler/runtime handle all other aspects like choosing stack
vs. heap, allocating and de-allocating (GC)
D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
I'm currently writing a program that interfaces with C++. C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or just 'unsigned', but is mangled differently. In particular, C++ mangles unsigned long as 'K', and I can't find a D counterpart that would be mangled similarly. This results in an unaccessible function (it is unresolved at link time). Any thoughts?
Re: null references redux + Looney Tunes
language_fan wrote: 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! I was talking about older computers (for example a PIII 500Mhz), I know my laptop will perform just fine for the next 5-10 years :)
Re: null references redux + Looney Tunes
Yigal Chripun wrote: 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. I don't think you understood what I meant, seat-belts don't require you to buy a bigger car engine because they don't affect the performance of the car whatsoever. They're also not enforced, the car will run just as fine if you don't wear them.
Re: null references redux + Looney Tunes
Nick Sabalausky wrote: Jeremie Pelletier jerem...@gmail.com wrote in message news:ha51v1$24p...@digitalmars.com... 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. Holy crap, I feel like I have a clone ;) (Hopefully that was original enough to rationalize a blatant me too post ;) ) It certainly was, thanks :)
Re: null references redux + Looney Tunes
language_fan wrote: 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. You will never be able to please everyone, or get everyone's attention. I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm. Pointers are a critical feature of D, they allow both binary compatibility with C code and optimizations not possible without pointers. I use pointers all the time in D, just not nearly as much as I would in C/C++. 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. Academics also seems to live in a fantasy world where code execute instantly and everyone in the world owns the latest computer hardware. They may not have a pet language but they have pet designs, which is quite equivalent. There are conservative people on all sides :)
Re: null references redux + Looney Tunes
Andrei Alexandrescu 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 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. We all know a serving of structs a day makes for healthy programmers! 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. You're comparing value types to reference types. A class object is also always valid, its the reference that can be null by pointing to no object. You would have the same semantics by using struct pointers. 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! I never pass structs by value in D, except for returns because of RVO, so I can get a null struct pointer sometimes, but thats what contracts and backtraces are for. If my code was still executing on an invalid struct reference it would be much, much harder to pinpoint the origin of the bug. 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. Once again, structs are value types. 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. Classes have an initializer too, it's just copied by the GC after allocation instead. So I don't think Walter's argument is invalid, I think it simply doesn't exist. This post made it disappear. Andrei I disagree, you compared apples to oranges here. Correct me if I'm wrong, but I don't think we should base an argument over reference types by using value types. Jeremie
Re: null references redux + Looney Tunes
Jeremie Pelletier wrote: Andrei Alexandrescu 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 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. We all know a serving of structs a day makes for healthy programmers! 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. You're comparing value types to reference types. A class object is also always valid, its the reference that can be null by pointing to no object. You would have the same semantics by using struct pointers. 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! I never pass structs by value in D, except for returns because of RVO, so I can get a null struct pointer sometimes, but thats what contracts and backtraces are for. If my code was still executing on an invalid struct reference it would be much, much harder to pinpoint the origin of the bug. 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. Once again, structs are value types. 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. Classes have an initializer too, it's just copied by the GC after allocation instead. So I don't think Walter's argument is invalid, I think it simply doesn't exist. This post made it disappear. Andrei I disagree, you compared apples to oranges here. Correct me if I'm wrong, but I don't think we should base an argument over reference types by using value types. Jeremie Save for address taking, value types are indistinguishable from immutable reference types. Value types don't have a null and that doesn't seem to make them unusable. It's a simple point. Andrei
Re: null references redux + Looney Tunes
On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote: I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm. There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D? Pointers are a critical feature of D, they allow both binary compatibility with C code and optimizations not possible without pointers. I use pointers all the time in D, just not nearly as much as I would in C/C++. I did not argue against pointers, in general! Pointers can be useful but you do not need the C style syntax for declaring pointers to functions anywhere. I find it hard to read, especially after reading too much maths or functional code.
Re: Multiple subtyping with alias this and nested classes
Andrei Alexandrescu, el 2 de octubre a las 19:10 me escribiste: 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? Don't design with multiple inheritance in mind, use interfaces + mixins for common functionality instead. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Bermú con papafritas y good show!
Re: null references redux + Looney Tunes
On 03/10/2009 16:09, Jeremie Pelletier wrote: I don't think you understood what I meant, seat-belts don't require you to buy a bigger car engine because they don't affect the performance of the car whatsoever. They're also not enforced, the car will run just as fine if you don't wear them. I understood you quite well. seat belts do not require a bigger car engine and compile time safety features do not add any overhead to run-time execution. seat belts *ARE* enforced. they are required by law and you get a hefty fine if you violate this. also, seat belts save lives and are used by regular drivers and car racers.
Re: Multiple subtyping with alias this and nested classes
Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de octubre a las 19:10 me escribiste: 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? Don't design with multiple inheritance in mind, use interfaces + mixins for common functionality instead. But you're just saying it. I think you'd agree I wouldn't just follow that dogma noncritically just because you told me what to do. I don't think many people design with multiple inheritance in mind. They design aiming at a good design. In my experience, some designs can make gainful use of multiple inheritance of classes, and some of my best designs do use multiple inheritance simply because it was the best tool for the job. Scala supports that with mixins, D supports that with multiple subtyping. Andrei
Re: Multiple subtyping with alias this and nested classes
Andrei Alexandrescu, el 3 de octubre a las 11:23 me escribiste: Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de octubre a las 19:10 me escribiste: 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? Don't design with multiple inheritance in mind, use interfaces + mixins for common functionality instead. But you're just saying it. I think you'd agree I wouldn't just follow that dogma noncritically just because you told me what to do. No, because the language is designed to do that AFAIK, so it will be much easier and clear (for who writes the code and who reads it). I think you hack with alias this is more obscure (we might be hitting personal taste here, I grant you that). I don't think many people design with multiple inheritance in mind. They design aiming at a good design. But you always have to take into account the tools you have when designing. What's the point of designing a perfect bridge assuming you have a material that doesn't exist? Of course you can do that, but when you hit reality, you'll have to hack your design to fit your real tools. So you can design something that looks like multiple-inheritance, because it's easier (or nicer) to do so. But when you want to put that in reality, you have to choose what tool to use. In C++ you probably want to use MI (because the language has a good support for it), but in D you probably want to use interfaces + mixins (because the language has good support for it). Of course you can even implement it in C, or even assembly; you can implement it as in C in C++ or D too, but it would be harder and more obscure. In my experience, some designs can make gainful use of multiple inheritance of classes, and some of my best designs do use multiple inheritance simply because it was the best tool for the job. Sure, the problem comes when the language don't support MI ;) So, there we are, you have D, which doesn't support MI per se, you have to hack it. You can do it with the nested-inherited-classes+alias-this hack, or by using interfaces+mixins. We agree at least that you have the same result with both right? Then, I guess is just a matter of taste. I simply find much more obscure and complex the nested-inherited-classes+alias-this hack than interfaces+mixins :) Scala supports that with mixins, D supports that with multiple subtyping. I don't know what you mean about multiple subtyping. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- I am so psychosomatic it makes me sick just thinking about it! -- George Constanza
Re: Multiple subtyping with alias this and nested classes
Leandro Lucarella wrote: Andrei Alexandrescu, el 3 de octubre a las 11:23 me escribiste: Leandro Lucarella wrote: Andrei Alexandrescu, el 2 de octubre a las 19:10 me escribiste: 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? Don't design with multiple inheritance in mind, use interfaces + mixins for common functionality instead. But you're just saying it. I think you'd agree I wouldn't just follow that dogma noncritically just because you told me what to do. No, because the language is designed to do that AFAIK, so it will be much easier and clear (for who writes the code and who reads it). I think you hack with alias this is more obscure (we might be hitting personal taste here, I grant you that). Alias this was introduced purposedly to allow multiple subtyping. Until yesterday, however, I hadn't realized how much nested classes help with that. Even before that I wasn't worried, since MI designs are not as frequent as SI designs. I don't think many people design with multiple inheritance in mind. They design aiming at a good design. But you always have to take into account the tools you have when designing. What's the point of designing a perfect bridge assuming you have a material that doesn't exist? Of course you can do that, but when you hit reality, you'll have to hack your design to fit your real tools. So you can design something that looks like multiple-inheritance, because it's easier (or nicer) to do so. But when you want to put that in reality, you have to choose what tool to use. In C++ you probably want to use MI (because the language has a good support for it), but in D you probably want to use interfaces + mixins (because the language has good support for it). Of course you can even implement it in C, or even assembly; you can implement it as in C in C++ or D too, but it would be harder and more obscure. In my experience, some designs can make gainful use of multiple inheritance of classes, and some of my best designs do use multiple inheritance simply because it was the best tool for the job. Sure, the problem comes when the language don't support MI ;) So, there we are, you have D, which doesn't support MI per se, you have to hack it. You can do it with the nested-inherited-classes+alias-this hack, or by using interfaces+mixins. We agree at least that you have the same result with both right? Then, I guess is just a matter of taste. I simply find much more obscure and complex the nested-inherited-classes+alias-this hack than interfaces+mixins :) I don't see using a nested class (or any class) with alias this as a hack. It's the way the whole thing is supposed to work in the first place. Scala supports that with mixins, D supports that with multiple subtyping. I don't know what you mean about multiple subtyping. You subtype once by using inheritance, and then some more by using alias this. Andrei
Re: Multiple subtyping with alias this and nested classes
Andrei Alexandrescu, el 3 de octubre a las 12:03 me escribiste: So, there we are, you have D, which doesn't support MI per se, you have to hack it. You can do it with the nested-inherited-classes+alias-this hack, or by using interfaces+mixins. We agree at least that you have the same result with both right? Then, I guess is just a matter of taste. I simply find much more obscure and complex the nested-inherited-classes+alias-this hack than interfaces+mixins :) I don't see using a nested class (or any class) with alias this as a hack. It's the way the whole thing is supposed to work in the first place. Ok, then, I just find it ugly and unnecessary since you can do the same with interfaces+mixins. It's just a matter of personal preferences (as I said in my first mail), there is no point on arguing about it. =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- I'll take a quiet life, a handshake of carbon monoxide, with no alarms and no surprises, no alarms and no surprises.
Re: Multiple subtyping with alias this and nested classes
On Sat, 03 Oct 2009 13:52:51 -0300, Leandro Lucarella wrote: Scala supports that with mixins, D supports that with multiple subtyping. I don't know what you mean about multiple subtyping. I have also not seen the specs for this feature. How does multiple subtyping work exactly in D? Does it have exactly the same semantics as using interfaces + mixing in the traits? Why was the 'alias foo this' chosen if you are also planning to add support for Scala like traits (some other thread here recently discussed this). Andrei, you probably know how Scala chooses the overrides and overloads when traits have conflicts. How does D handle this?
Re: Multiple subtyping with alias this and nested classes
On Sat, 3 Oct 2009 14:11:37 -0300, Leandro Lucarella
llu...@gmail.com wrote:
Ok, then, I just find it ugly and unnecessary since you can do the same
with interfaces+mixins.
Actually, you can't. Consider:
interface IBlipper
{
void blip();
void nameCollision();
}
template Blipper()
{
void blip() {}
void nameCollision() {}
}
interface IFlipper
{
void flip();
void nameCollision();
}
template Flipper()
{
void flip() {}
void nameCollision() {}
}
class FlippingBlipper : IBlipper, IFilpper
{
mixin Flipper;
mixin Blipper;
}
The above sucks because we can't specify which nameCollision gets
implemented by which mixin. In current D, nameCollision of both
interfaces is implemented by Flipper.
We would probably be able to overcome the limitation if and when
explicit interface instantiation is implemented:
template Blipper()
{
void IBlipper.blip() {}
void IBlipper.nameCollision() {}
}
template Flipper()
{
void IFlipper.flip() {}
void IFlipper.nameCollision() {}
}
Until then, mixin + interface just doesn't work.
It's just a matter of personal preferences (as
I said in my first mail), there is no point on arguing about it. =)
Re: null references redux + Looney Tunes
language_fan wrote: On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote: I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm. There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D? Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :) Same for programming, D could have 100 keywords and be the most flexible language ever. Some would think its the best thing since sliced bread, others would only use the subset they're comfortable with, and a few would be scared away back to javascript. People using a very limited subset of words to express their ideas tend to talk more to say less. Pointers are a critical feature of D, they allow both binary compatibility with C code and optimizations not possible without pointers. I use pointers all the time in D, just not nearly as much as I would in C/C++. I did not argue against pointers, in general! Pointers can be useful but you do not need the C style syntax for declaring pointers to functions anywhere. I find it hard to read, especially after reading too much maths or functional code. It makes writing C bindings that much easier, function pointers are mostly used for C code anyways since D has the much better delegate type.
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
Denis Koroskin wrote: I'm currently writing a program that interfaces with C++. C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or just 'unsigned', but is mangled differently. In particular, C++ mangles unsigned long as 'K', and I can't find a D counterpart that would be mangled similarly. This results in an unaccessible function (it is unresolved at link time). Any thoughts? The problem is there is no way to express in D both an unsigned and an unsigned long, since they are both uints in D. I don't know of a way around this, other than changing the C++ code.
Re: What does Coverity/clang static analysis actually do?
On Sat, Oct 3, 2009 at 4:00 AM, Nick Sabalausky a...@a.a wrote: Christopher Wright dhase...@gmail.com wrote in message news:ha5mtp$f3...@digitalmars.com... BCS wrote: 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? That's the one they meant to write. Nicely played.
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
On Sat, Oct 3, 2009 at 2:55 PM, Denis Koroskin 2kor...@gmail.com wrote: I'm currently writing a program that interfaces with C++. C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or just 'unsigned', but is mangled differently. In particular, C++ mangles unsigned long as 'K', and I can't find a D counterpart that would be mangled similarly. This results in an unaccessible function (it is unresolved at link time). Any thoughts? The type of C++ unsigned long depends on the target platform.
Re: null references redux + Looney Tunes
On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote: language_fan wrote: On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote: I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm. There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D? Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :) Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people. And your stance of disagreeing with everyone here does not make you better than the rest of us, it is just irritating. D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures.
Re: I wrote some D today and it's completely blowing my mind. Ever tried
On Sat, 03 Oct 2009 04:35:39 -0400, bearophile wrote: Walter Bright: http://www.reddit.com/r/programming/comments/9qf8i/ i_wrote_some_d_today_and_its_completely_blowing/ Very nice. Indeed if you come from experience of C, D allows you to write programs in a much faster way. (But C isn't the only language around today, you also have dotnet C#, for example). It is funny to note that every time these new fans of D come from the C / C++ / Java community. It is well known that those languages have long been in a stagnant stage and if the developers just had courage to try modern languages, *any* language would have a fresh feel. It is really no wonder that those languages are starting to feel irritating in daily work. I have never heard of a Eiffel / Ada / Erlang / Lisp / Clojure / Scala / Haskell / SML / OCaml / Nemerle /insert your favorite statically typed compiled language here zealot who suddenly found the enlightenment in D.
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
On Sat, 03 Oct 2009 21:50:06 +0400, Tomas Lindquist Olsen
tomas.l.ol...@gmail.com wrote:
On Sat, Oct 3, 2009 at 2:55 PM, Denis Koroskin 2kor...@gmail.com wrote:
I'm currently writing a program that interfaces with C++.
C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',
or
just 'unsigned', but is mangled differently.
In particular, C++ mangles unsigned long as 'K', and I can't find a D
counterpart that would be mangled similarly.
This results in an unaccessible function (it is unresolved at link
time).
Any thoughts?
The type of C++ unsigned long depends on the target platform.
Sure, but it's stands true for all types, not only unsigned long.
I'm on x86, and it is the same as unsigned int here.
BTW, I worked around the issue with a wrapper function:
// workaround.cpp
int foo(unsigned long bar); // extern
int foo(unsigned int bar) { return foo((unsigned long)bar); }
but it's not too handy.
Re: Arrays template arguments and CT data structures
Hello language_fan, 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. If the data is setup correctly (e.i. not mixed in with other stuff) then the only the data that is called for will be paged in. I'm having a hard time thinking of a situation where this would be less than ideal. The only case I can think of is where the data can be compressed a lot and you page in compressed structures and then expand as needed into memory. Most simple systems would read in the same data in a (probably bulkier format) but do it all before the first access.
Re: scope class members - in-situ
Hello Andrei, I think this has been discussed in this group already. [...] That means the constructor needs special scrutiny, in particular a cannot be null because that wouldn't make much sense. I think the same device used for the base class constructor could be used. What syntax it would use could be an issue but...
Re: What does Coverity/clang static analysis actually do?
Hello Christopher, 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? OK so I use spell check as a crutch (and I was trying to pay attention to a lecture when I typed that). As for ignoring context...well, I'm willing to discuss this, but not here. Note: I'm not claiming that some document is saying anything, but, that with enough cut and paste, any long enough document can be made to say anything you want and that sometimes this requiters that you ignore context. The implication is that a selected set of excerpts from some document can't be taken as proof that the document says or doesn't say anything.
Re: Should certain abstract classes be instantiable?
Andrei Alexandrescu wrote: 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. Umm... so it defines a body that will never be used because that class can't be instantiated and the method must be redefined by subclasses? Isn't that the same as doesn't provide a body?
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?
On Sat, 03 Oct 2009 22:47:53 +0400, Walter Bright newshou...@digitalmars.com wrote: Denis Koroskin wrote: I'm currently writing a program that interfaces with C++. C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or just 'unsigned', but is mangled differently. In particular, C++ mangles unsigned long as 'K', and I can't find a D counterpart that would be mangled similarly. This results in an unaccessible function (it is unresolved at link time). Any thoughts? The problem is there is no way to express in D both an unsigned and an unsigned long, since they are both uints in D. I don't know of a way around this, other than changing the C++ code. That's not always possible. Imagine LGPL'd code, or code which is distributed in precompiled form only (header + library).
Re: Should certain abstract classes be instantiable?
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
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.
Umm... so it defines a body that will never be used because that class
can't be instantiated and the method must be redefined by subclasses?
Isn't that the same as doesn't provide a body?
import std.stdio;
class A {
abstract void fun() { writeln(wyda); }
}
class B : A {
void fun() { A.fun(); }
}
unittest {
A a = new B;
a.fun();
a.A.fun();
}
Andrei
Re: Multiple subtyping with alias this and nested classes
language_fan wrote: On Sat, 03 Oct 2009 13:52:51 -0300, Leandro Lucarella wrote: Scala supports that with mixins, D supports that with multiple subtyping. I don't know what you mean about multiple subtyping. I have also not seen the specs for this feature. How does multiple subtyping work exactly in D? The feature is very much in the works. I gave a basic example for two types. Unfortunately at the moment only one alias this declaration is allowed. The plan is to allow any number. Does it have exactly the same semantics as using interfaces + mixing in the traits? No. Why was the 'alias foo this' chosen if you are also planning to add support for Scala like traits (some other thread here recently discussed this). Currently there are no plans to add support for Scala-like traits. Andrei, you probably know how Scala chooses the overrides and overloads when traits have conflicts. How does D handle this? Walter and I are working the kinks of name lookup. If you have ideas, please share. Andrei
Re: Multiple subtyping with alias this and nested classes
language_fan wrote: On Sat, 03 Oct 2009 13:52:51 -0300, Leandro Lucarella wrote: Scala supports that with mixins, D supports that with multiple subtyping. I don't know what you mean about multiple subtyping. I have also not seen the specs for this feature. How does multiple subtyping work exactly in D? The feature is very much in the works. I gave a basic example for two types. Unfortunately at the moment only one alias this declaration is allowed. The plan is to allow any number. Does it have exactly the same semantics as using interfaces + mixing in the traits? No. Why was the 'alias foo this' chosen if you are also planning to add support for Scala like traits (some other thread here recently discussed this). Currently there are no plans to add support for Scala-like traits. Andrei, you probably know how Scala chooses the overrides and overloads when traits have conflicts. How does D handle this? Walter and I are working the kinks of name lookup. If you have ideas, please share. Andrei
Re: null references redux + Looney Tunes
language_fan Wrote: On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote: language_fan wrote: On Sat, 03 Oct 2009 10:32:28 -0400, Jeremie Pelletier wrote: I don't believe D is having some features merely to attract attention to it, that's the thing I like best about D; it provides a very large set of tools and let me choose how to use them, instead of enforcing a certain model or paradigm. There has to be some limit on the amount of features a language can have before managing the complexity gets too large. Imagine that D 4.0 had 50 keywords more than D 2.0 currently has. Those features would make your code 5% faster. Would you still love D? Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :) Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people. And your stance of disagreeing with everyone here does not make you better than the rest of us, it is just irritating. D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures. Re foreach_reverse People might remember that when I picked up D and joined this forum just some 3 or so weeks ago I made mention of being a Scala refugee.*** When asked what I didn't like about Scala I commented about there being too many language constructs. Someone here (maybe you, Fan?) consequently pointed out some of the superfluous cruft like foreach_reverse in D. I couldn't agree more; foreach_reverse should be euthanased by intralexical injection forthwith. (***To be fair, my current interest is in non-JVM-hosted languages and I wouldn't be using a minimalistic language like Clojure (also JVM hosted) either at the moment.) Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. I haven't had much time to investigate/learn meta programming facilities in D so I'm less than a novice in this respect. If it's not too much trouble, Fan, please post your solution for replacing reverse_foreach with a meta-program; I know it sounds lazy of me, but your answer will save me precious time from having to RTFM. Guessing its a recursive solution, and btw I am making use of opApply already in a small collection library that I'm messing with. Cheers Justin Johansson
Re: null references redux + Looney Tunes
language_fan somewh...@internet.com.invalid wrote in message news:ha87kd$2j3...@digitalmars.com... On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote: Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :) Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people. I think his point was that number of keywords isn't a particularly good measure of language complexity. To bring it back to programming languages, VB has keywords coming out the wazoo, but the only thing complex about VB is the complexity involved in trying to express high-level (or low-level) concepts that VB is just too *simple* to handle. And your stance of disagreeing with everyone here does not make you better than the rest of us, it is just irritating. I think I missed the memo indicating that disagreeing with others had suddenly become a bad thing. ;) D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures. Fair enough. *But*, I really think elegantly simple language design is double-edged sword. In my experience, and I think this is what Jeremie was alluding to, I've found that an elegantly simple language, no matter how well-chosen the primitives are, generally results in a problematic lack of expressiveness and a frequent sense of fighting against the language instead of merely using it. For example, the most elegantly simple languages I've seen are Java (at least earlier versions, anyway), JavaScript, Smalltalk, Haskell, and maybe Forth. And I really do admire those languages from a theoretical perspective...but only in the same sense that I admire Brainfuck. I'd never want to actually use any of those languages for any real work simply because their elegantly simple designs lead to many cases where I'd have to (or have had to) fight against them to accomplish what I need. I guess it just comes down to as simple as possible, *but no more*. In a more complex language like D, I never feel like I need to try to keep the whole langauge in my head. I just need some subset at any particular time, and then when (and I do mean when, not if), when I need something else, it's nice to know that it's there to use and that I won't have to try to cram it into the wrong tool for the job or constantly switch between an array of languages while trying to keep them all playing nice with each other. It's like a professional handyman having the smallest possible possible toolbox with only the barest essentialls, versus a big super-toolbox that has all the *right* tools he might need. Just because it's there doesn't mean it has to be used, but if I were a handyman and had to remove a phillips-head screw, I'd want to be able to reach for a forward/reverse drill and an appropriately-sized phillips-head bit, and not have to pry it out with the bare minimum (the back of a hammer, or a sort-of-sized-similarly manual flathead screwdriver), and also not have to put one specialized mini-toolbax back and switch to a differently-specialized mini-toolbox for every different task.
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart inD?
Hello Denis, That's not always possible. Imagine LGPL'd code, or code which is distributed in precompiled form only (header + library). would, explicitly stating the mangled name work? pragam(mangle, mangled name) // proposed feature extern(C++) uint SomeFunction();
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart inD?
On 2009-10-03 17:13:45 -0400, BCS n...@anon.com said: Hello Denis, That's not always possible. Imagine LGPL'd code, or code which is distributed in precompiled form only (header + library). would, explicitly stating the mangled name work? pragam(mangle, mangled name) // proposed feature extern(C++) uint SomeFunction(); Why not just: extern(C++, mangled name) uint SomeFunction(); where mangled name could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Multiple subtyping with alias this and nested classes
On 03/10/2009 20:19, Max Samukha wrote:
On Sat, 3 Oct 2009 14:11:37 -0300, Leandro Lucarella
llu...@gmail.com wrote:
Ok, then, I just find it ugly and unnecessary since you can do the same
with interfaces+mixins.
Actually, you can't. Consider:
interface IBlipper
{
void blip();
void nameCollision();
}
template Blipper()
{
void blip() {}
void nameCollision() {}
}
interface IFlipper
{
void flip();
void nameCollision();
}
template Flipper()
{
void flip() {}
void nameCollision() {}
}
class FlippingBlipper : IBlipper, IFilpper
{
mixin Flipper;
mixin Blipper;
}
The above sucks because we can't specify which nameCollision gets
implemented by which mixin. In current D, nameCollision of both
interfaces is implemented by Flipper.
We would probably be able to overcome the limitation if and when
explicit interface instantiation is implemented:
template Blipper()
{
void IBlipper.blip() {}
void IBlipper.nameCollision() {}
}
template Flipper()
{
void IFlipper.flip() {}
void IFlipper.nameCollision() {}
}
Until then, mixin + interface just doesn't work.
It's just a matter of personal preferences (as
I said in my first mail), there is no point on arguing about it. =)
interfaces implement virtual MI, so FlippingBlipper must implement one
nameCollision which is shared by both interfaces. however you can give
names to mixins so that you could choose which implementation to use for
that and also have both implementations.
class FlippingBlipper : IBlipper, IFilpper
{
mixin Flipper F;
mixin Blipper B;
alias F.nameCollision nameCollision;
}
I wonder if the following would work:
class FlippingBlipper : IBlipper, IFilpper
{
mixin Flipper IFilpper;
mixin Blipper IBlipper;
}
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpart inD?
On Sun, 04 Oct 2009 01:48:38 +0400, Michel Fortin michel.for...@michelf.com wrote: On 2009-10-03 17:13:45 -0400, BCS n...@anon.com said: Hello Denis, That's not always possible. Imagine LGPL'd code, or code which is distributed in precompiled form only (header + library). would, explicitly stating the mangled name work? pragam(mangle, mangled name) // proposed feature extern(C++) uint SomeFunction(); Why not just: extern(C++, mangled name) uint SomeFunction(); where mangled name could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want. I thought about that, too. This is a good idea, but it's also too compiler-specific and somewhat error-prone. I also thought about some Mangler template, which is capable of generating a mangled name for a given function at compile time, and using it instead of some pre-generated string. This is a more generic solution, one could substitute different manglers for different compiler vendors. In this case, I could typedef uint unsigned_long; and my mangler would recognize unsigned_long and mangle it differently from uint. Just an idea...
Re: Multiple subtyping with alias this and nested classes
Max Samukha wrote: The above sucks because we can't specify which nameCollision gets implemented by which mixin. In current D, nameCollision of both interfaces is implemented by Flipper. I don't think that being able to define multiple separate functions with the same name and the same signature is a necessary feature of multiple inheritance, or even a particularly well thought-out one. Python is an example of a language without this feature, and multiple inheritance is very common in Python. -- Rainer Deyke - rain...@eldwood.com
Re: What does Coverity/clang static analysis actually do?
There is a simple and elegant solution to the problem of false positives
in static analysis. Simple provide a way for the programmer to say, I
know this looks dangerous, but I know what I'm doing, so trust me on
this. This could be done by adding some new syntax, either a new
keyword or a reused old keyword, or by changing the semantics of void
initialization.
For example, this would be an error:
T t;
if (i 10) {
t = new T;
}
if (i 10) {
t.f();
}
This would be legal:
T t = unchecked;
if (i 10) {
t = new T;
}
if (i 10) {
t.f();
}
But this would be an error:
T t = unchecked;
t.f();
As would this:
T t = unchecked;
f(t);
'unchecked' has the following properties:
- It is an error to use the value of a variable that is initialized as
'unchecked'.
- 'unchecked' tells the static analysis that the programmer knows what
he's doing. The static analysis should therefore be liberal rather than
conservative.
- At runtime, 'unchecked' is equivalent to 'null' for non-nullable
reference types. This increases the chance that the error will be
detected at runtime.
On the other hand, variables without any explicit initializer at all
will have the following properties:
- It is an error to use the value of the variable.
- The static analysis is conservative by default. If it thinks the
variable could be used uninitialized, an error is reported.
- Since the static analysis guarantees that the variable will not be
used uninitialized, there is no need to initialize the variable at runtime.
--
Rainer Deyke - rain...@eldwood.com
Re: I wrote some D today and it's completely blowing my mind. Ever
language_fan Wrote: On Sat, 03 Oct 2009 04:35:39 -0400, bearophile wrote: Walter Bright: http://www.reddit.com/r/programming/comments/9qf8i/ i_wrote_some_d_today_and_its_completely_blowing/ Very nice. Indeed if you come from experience of C, D allows you to write programs in a much faster way. (But C isn't the only language around today, you also have dotnet C#, for example). It is funny to note that every time these new fans of D come from the C / C++ / Java community. It is well known that those languages have long been in a stagnant stage and if the developers just had courage to try modern languages, *any* language would have a fresh feel. It is really no wonder that those languages are starting to feel irritating in daily work. I have never heard of a Eiffel / Ada / Erlang / Lisp / Clojure / Scala / Haskell / SML / OCaml / Nemerle /insert your favorite statically typed compiled language here zealot who suddenly found the enlightenment in D. What, ... zealot who suddenly found the enlightenment in D? (Rhetorical question). Since when was zealotry (1) regarded as a virtue? (Another rhetorical question). Now, meaning to be neither rhetorical nor tautologous, my question is: Was this phrase meant to be oxymoronic or a contradiction in terms (2), or was it an accidental misuse of the noun (zealot)? (1) Noun * S: (n) fanaticism, fanatism, zealotry (excessive intolerance of opposing views) http://wordnetweb.princeton.edu/perl/webwn?s=zealotry (2) Although a true oxymoron is something that is surprisingly true, a paradox, modern usage has brought a common misunderstanding as being near synonymous with a contradiction. http://en.wikipedia.org/wiki/Oxymoron (The full Wikipedia article is quite an amusing read). -- Justin Johansson
Re: I wrote some D today and it's completely blowing my mind. Ever tried
language_fan wrote: It is funny to note that every time these new fans of D come from the C / C++ / Java community. It is well known that those languages have long been in a stagnant stage and if the developers just had courage to try modern languages, *any* language would have a fresh feel. It is really no wonder that those languages are starting to feel irritating in daily work. I have never heard of a Eiffel / Ada / Erlang / Lisp / Clojure / Scala / Haskell / SML / OCaml / Nemerle /insert your favorite statically typed compiled language here zealot who suddenly found the enlightenment in D. D isn't meant as a language to enlighten people, it isn't a religion, it's a language meant to get things done with.
Re: A possible leak
On Thu, 01 Oct 2009 14:23:48 +0300, bearophile bearophileh...@lycos.com
wrote:
Time ago Jon Harrop has found a memory leak in a F# program running on
Mono, he has reduced the program to a minimal test case. I have
translated that code to D2 and Python2:
Sorry for the late reply. I wanted to get to the bottom of this, and
facilitate others to do the same easily, thus this motivated me to improve
Diamond to make that possible.
What basically happens here is that the program creates an infinite
contiguous linked list. Even though there is no reference to the original
node, a stray reference to any of the nodes in the list will prevent any
nodes following it to be freed. The program's behavior was inconsistent on
my machine (it either leaked or didn't leak memory), because the memory
pools were allocated at different memory addresses.
*** SHAMELESS PLUG ALERT ***
Diamond ( my post-mortem memory debugger -
http://dsource.org/projects/diamond ) should allow to diagnose these
situations easily, more so with the latest additions. Here's an example of
how it's possible to easily analyze this program's memory behavior and
find the source of the leak:
Firstly, the program was backported to D1 (I don't use D2, thus Diamond
doesn't support it ATM). Its execution time is limited, to allow a clean
exit. The final source is as follows:
---
import diamond;
struct Node {
int data;
Node* next;
}
void main() {
Node* lh = new Node;
lh.data = 1;
lh.next = lh;
for(int i=0;i100;i++) {
Node* lh2 = lh;
lh = new Node;
lh.data = 2;
lh.next = lh2.next;
lh2.next = lh;
lh2 = lh;
lh2.next = lh2.next.next;
}
}
---
The diamond runtime module was configured with only the MEMLOG and
MEMLOG_CRC32 options.
The program was compiled and executed; the runtime module created a .mem
file which contained a log of memory operations, and full contents for
every garbage collect. This file was loaded into the memory log analyzer:
Diamond Memory Log Analyzer, v0.2
by Vladimir CyberShadow Panteleev, 2008-2009
Using the most recent memory dump file.
Loading diamond_2009-09-04_02.25.49.mem...
113 events loaded.
Using the most recent map file.
1047 symbols loaded from test1final.map.
dumps
65023 @ 02:25:49: MEMDUMP ( 256/ 256/ 256)
89503 @ 02:25:49: MEMDUMP ( 256/ 256/ 256)
155041 @ 02:25:49: MEMDUMP ( 512/ 512/ 512)
286115 @ 02:25:49: MEMDUMP ( 1024/ 1024/ 1024)
482725 @ 02:25:50: MEMDUMP ( 1792/ 1792/ 1792)
744871 @ 02:25:51: MEMDUMP ( 2816/ 2816/ 2816)
MEMDUMP events are generated automatically before garbage collects.
Judging by the history, the GC failed to free up space starting with the
second collect. Let's look at the memory map before and after the first
collect:
nextdump
D65023 map
Page map for pool 0209 - 0219 ( 256/ 256/ 256 pages):
(page size = 0x1000)+1 +2 +3
0209: 6744
020D:
0211:
0215:
D65023 n
M65024 map
Page map for pool 0209 - 0219 ( 162/ 256/ 256 pages):
(page size = 0x1000)+1 +2 +3
0209: 674.
020D: .444
0211:
0215:
We can see the list's nodes filling up all available memory, before
trigging a collect (4 - pages containing objects =16 bytes in size).
However, the collect stopped at the page at 020F1000. Let's get a closer
look:
M65024 binmap 020F1000
Bin map for page 020F1000 - 020F2000:
(object size = 0x010)+100 +200 +300
020F1000:
020F1400: D...
020F1800:
020F1C00:
Note that inside a page, objects are allocated in reverse order (due to
how freelists are constructed). We can conclude that the rest of the
linked list is not freed due to a stray reference to the node at 020F1600.
To find the stray reference, we use the refs command:
M65024 refs 020F1600 020F1610
00433D2C - 020F160D - in root range 0042F000 - 00438A00
00433D2C is located within the program's static
Re: D2.0 cpp interfacing: what is a C++ unsigned long counterpartinD?
Hello Denis, On Sun, 04 Oct 2009 01:48:38 +0400, Michel Fortin michel.for...@michelf.com wrote: Why not just: extern(C++, mangled name) uint SomeFunction(); where mangled name could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want. I thought about that, too. This is a good idea, but it's also too compiler-specific and somewhat error-prone. It's a low level workaround and anyone who write them by hand is being foolish. The primary cases I see it being used in are be tool generated header files build from c++ header files and or object files or with some kind of template+CTFE support. I also thought about some Mangler template, which is capable of generating a mangled name for a given function at compile time, and using it instead of some pre-generated string. This is a more generic solution, one could substitute different manglers for different compiler vendors. In this case, I could typedef uint unsigned_long; and my mangler would recognize unsigned_long and mangle it differently from uint. Just an idea... Whatever the overall solution, I think something along the lines of Denis' or my idea is the correct primitive to build it on.
Google C++ style guide
I have found this page linked from Reddit (click Toggle all summaries at the top to read the full page): http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml At Google C++ isn't the most used language, so it may be better to use a C++ style guide from a firm that uses C++ more than Google. On the other hand Google has hired many good programmers, and probably some of them have strong C++ experience, so if you are interested in C++/D this style guide deserves to be read. This guide is mostly (as it often happens with C++) a list of features that are forbidden, I think usually to reduce the total bug count of the programs. Some of such imposed limits make me a little nervous, so I'd like to remove/relax some of those limits, but I am ignorant regarding C++, while the people that have written this document are expert, so their judgement has weight. They forbid several features that are present in D too. Does it means D has to drop such features (or make them less natural, so the syntax discourages their use)? Here are few things from that document that I think are somehow interesting. Some of those things may be added to D style guide, or they may even suggest changes in the language itself. --- Function Parameter Ordering: When defining a function, parameter order is: inputs, then outputs. D may even enforce this, allowing out only after in arguments. --- Nested Classes: Do not make nested classes public unless they are actually part of the interface, e.g., a class that holds a set of options for some method. --- Static and Global Variables: Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction. [...] The order in which class constructors, destructors, and initializers for static variables are called is only partially specified in C++ and can even change from build to build, which can cause bugs that are difficult to find. [...] As a result we only allow static variables to contain POD data. I think D avoids such problem. --- Doing Work in Constructors: Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization. [...] If the work calls virtual functions, these calls will not get dispatched to the subclass implementations. Future modification to your class can quietly introduce this problem even if your class is not currently subclassed, causing much confusion. --- Declaration Order: Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc. D may even enforce such order (Pascal does something similar). --- Reference Arguments: All parameters passed by reference must be labeled const. In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers. Input parameters may be const pointers, but we never allow non-const reference parameters. I think C solves part of such problem forcing the programmer to add ref before the variable name in the calling place too. D may do the same. --- Function Overloading: Use overloaded functions (including constructors) only in cases where input can be specified in different types that contain the same information. Cons: One reason to minimize function overloading is that overloading can make it hard to tell which function is being called at a particular call site. Another one is that most people are confused by the semantics of inheritance if a deriving class overrides only some of the variants of a function. Decision: If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append(). This is a strong limitation. One of the things that makes C++ more handy than C. I accept it for normal code, but I refuse it for library code. Library code is designed to be more flexible and reusable, making syntax simpler, etc. So I want D to keep overloaded functions. --- Default Arguments: We do not allow default function parameters. Cons: People often figure out how to use an API by looking at existing code that uses it. Default parameters are more difficult to maintain because copy-and-paste from previous code may not reveal all the parameters. Copy-and-pasting of code segments can cause major problems when the default arguments are not appropriate for the new code. Decision: We require all arguments to be explicitly specified, to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of. This too is a strong limitation. I understand that it may make life a little more complex, but they
Sugar around string mixins (was: Why not move cast to the standard library?)
Fri, 25 Sep 2009 15:35:11 -0400, Adam D. Ruppe wrote:
macro max(int a, int b) {
return a ~~ b ~ ? ~ a ~ : ~ b;
}
void main() {
auto num1 = 10;
auto num2 = 20;
auto result = max(num1, num2);
}
While I like and support the idea, I think that hijacking the macro
keyword now will make it very hard to re-design later. It would be much
better to reuse the mixin keyword for this since it's exactly what's
happening: defining a function for mixing in:
mixin max(int a, int b) {...}
It could be problematic from the grammar perspective though.
Re: Sugar around string mixins (was: Why not move cast to the standard library?)
On Sat, Oct 3, 2009 at 9:22 PM, Sergey Gromov snake.sc...@gmail.com wrote:
While I like and support the idea, I think that hijacking the macro
keyword now will make it very hard to re-design later. It would be much
better to reuse the mixin keyword for this since it's exactly what's
happening: defining a function for mixing in:
mixin max(int a, int b) {...}
It could be problematic from the grammar perspective though.
Newp. 'mixin' could be followed by one of four things:
- '(', it's a string mixin.
- 'ident' '!', it's a template mixin.
- 'ident' ';' it's also a template mixin.
- 'ident' '(', it's a mixin declaration.
Not tough. But then you're really overloading the keyword by using it
for three very different purposes.
Re: Google C++ style guide
bearophile Wrote: Regular Functions: Functions should start with a capital letter and have a capital letter for each new word. No underscores: That's ugly. Coming from a career in acronym-city (aerospace), project management mandated that use of acronyms in identifiers MUST be clearly indicated with uppercase letters. In the event that ambiguity could arise, such as in camel-cased identifiers, the end of an acronym had to be separated by an underscore between it and any following letter in the identifier. This rule, whilst painful/ugly at times, was rigorously enforced in safety critical systems lest there be any possibility, no matter how remote, of confusion with interpretation of nomenclature in systems engineering documents. So, for example, the following were for verboten: ParseXmlDocument(The correct acronym for Xml is XML) PaseXMLDocument (XMLD might be erroneously interpreted as a 4 letter acronym) Required formulation of the identifier in the case must be ParseXML_Document. Ciao Justin Johansson
Re: Google C++ style guide
Jeremie Pelletier: I think these are more programming guidelines than language design rules. Yes, of course. But programming guidelines can give possible ideas to a language designer, because: - if everyone is encouraged to follow a certain idiom to avoid bugs, it may be good to let the language itself enforce the idiom (see D that disallows for(...); ). - if most similar guidelines suggest to not use a certain language feature, such feature may need a redesign, or maybe to be made less nice syntax-wise, so the syntax shows its usage is discouraged. - if in many guidelines suggest to do something in a standard way, to improve uniformity, it may be good to add such thing too to help spreading and transmission of code in the programmer community of that language. One of the causes of Python success is that it forces a very uniform coding style, and this helps people understand and modify each other code, this helps a little the creation of an ecosystem of reusable code. The compile-enforcing of syntax for class attributes in D can be one of such things. enforcing parameter order would also break lots of existing code. D2 is in flux still, every release breaks existing code. I don't recall C having a ref keyword :) Sorry, I meant C# (CSharp). I completely agree here, JavaScript for example has no default parameters and it's annoying as hell. Looking at existing code is really handy to learn about the usage of a function when the documentation is too vague, that documentation is still the best source to learn about the parameters. I'm waiting for named arguments too in D :-) I barely use alloca at all, since you don't always know if the array is going to be 50 bytes or 20k bytes. If you know the array's size or at least the max size it can get then you can just use a fixed-size array which will get allocated on the stack. I was talking about smarter function, that allocates on the heap if the requested size is too much large or if the stack is finishing :-) But of course fixed sized arrays are often enough. I don't think this guideline was about the size of integrals but rather their sign bit. Right, I meant unsigned integral numbers. Yeah I would like overflow tests in D too, although I don't like how you can't control which tests are used and which arent, they're either all enabled or all disabled. There are ways to solve this problem/limit. Putting basic tests in is a starting point. I have given LLVM developers some small enhancements requests to implement such tests more efficiently: http://llvm.org/bugs/show_bug.cgi?id=4916 http://llvm.org/bugs/show_bug.cgi?id=4917 http://llvm.org/bugs/show_bug.cgi?id=4918 I have also discussed this topic with LDC developers, for possible implementations. I agree it can get very hard to maintain readability in C++, but D does not have that problem. Templates in D are very elegant and much more powerful than C++'s at the same time. D template programming can become very unreadable, trust me :-) I think T fits generic template parameters the same way i fits for loops :) Sometimes I avoid i for loops :-) I don't think it should be enforced by the language, it's a great guideline but the programmer should be free to select its flavor (ie m_var, mVar, _var, var_, etc) Here I don't agree with you. Uniformity in such thing is important enough. Bye and thank you for your answers, bearophile
Re: Google C++ style guide
bearophile wrote: Jeremie Pelletier: I think these are more programming guidelines than language design rules. Yes, of course. But programming guidelines can give possible ideas to a language designer, because: - if everyone is encouraged to follow a certain idiom to avoid bugs, it may be good to let the language itself enforce the idiom (see D that disallows for(...); ). - if most similar guidelines suggest to not use a certain language feature, such feature may need a redesign, or maybe to be made less nice syntax-wise, so the syntax shows its usage is discouraged. - if in many guidelines suggest to do something in a standard way, to improve uniformity, it may be good to add such thing too to help spreading and transmission of code in the programmer community of that language. One of the causes of Python success is that it forces a very uniform coding style, and this helps people understand and modify each other code, this helps a little the creation of an ecosystem of reusable code. The compile-enforcing of syntax for class attributes in D can be one of such things. I'm not sure if that's a good thing, different companies enforce different guidelines for different reasons, and then you have independent programmers with their own guidelines too. As for less nice syntax, I'd hate to use __goto, __traits is already ugly enough that I always hide it behind a template with a nicer name and lets not even talk about __gshared showing its ugly self all over my C bindings :) Maybe if the compiler had a -strict switch to enforce a certain guideline over code, we already have -safe for enforcements over memory usage! Such an enforcement would then be an awesome feature for D to have. I'm not against the idea, I'm against making it the only available option! I was talking about smarter function, that allocates on the heap if the requested size is too much large or if the stack is finishing :-) But of course fixed sized arrays are often enough. Those smarts have some overhead to them to first check the allocation size and the remaining stack size, and finally call the appropriate allocator, that overhead would almost make such a smart function useless when compared to direct heap allocations. D template programming can become very unreadable, trust me :-) Not anymore than any other bit of code :) Sometimes I avoid i for loops :-) Sometimes I avoid T for templates :) Here I don't agree with you. Uniformity in such thing is important enough. Again I believe such an enforcement should be behind a -strict switch, I agree with you that uniformity can be a great thing and I can only imagine the all good it does to the python community. However we're talking systems programming here, people want the choice between using the feature or not using it :) Jeremie
Re: Sizeof class instance
Justin Johansson wrote: How does one determine the sizeof (in bytes) of an instance of a class in D? .sizeof works as advertised for structs, but for reference types, .sizeof yields the sizeof the referencing variable (effectively same as size of a pointer) and not the size of the underlying instance. I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it in the latter. btw. I was poking under the hood of std.xml and though, wow, instances of Element class look humongous, and so I'm interested to how exactly how humongous. Thanks for all help. Justin The only way I know of is to access the init array of the classinfo at runtime and get its length property.
Re: Sizeof class instance
On Sat, Oct 3, 2009 at 5:50 PM, Justin Johansson n...@spam.com wrote: How does one determine the sizeof (in bytes) of an instance of a class in D? .sizeof works as advertised for structs, but for reference types, .sizeof yields the sizeof the referencing variable (effectively same as size of a pointer) and not the size of the underlying instance. I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it in the latter. btw. I was poking under the hood of std.xml and though, wow, instances of Element class look humongous, and so I'm interested to how exactly how humongous. Thanks for all help. Justin There's no way to get it at compile-time in D1. The best you can do is Class.classinfo.init.length. In D2, you can use __traits(classInstanceSize, Class).
Re: Sizeof class instance
Jarrett Billingsley Wrote: On Sat, Oct 3, 2009 at 5:50 PM, Justin Johansson n...@spam.com wrote: How does one determine the sizeof (in bytes) of an instance of a class in D? .sizeof works as advertised for structs, but for reference types, .sizeof yields the sizeof the referencing variable (effectively same as size of a pointer) and not the size of the underlying instance. I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it in the latter. btw. I was poking under the hood of std.xml and though, wow, instances of Element class look humongous, and so I'm interested to how exactly how humongous. There's no way to get it at compile-time in D1. The best you can do is Class.classinfo.init.length. In D2, you can use __traits(classInstanceSize, Class). Thanks Jeremie and Jarrett for answers. For investigative purposes (rather than adding up class member sizes in my head), would I get a fair answer if I copied the class data members into a struct, did a struct sizeof and added 4 bytes to allow for a virtual function table pointer (in the class and assuming the class has a VFT)?
Re: Sizeof class instance
Justin Johansson wrote:
Jarrett Billingsley Wrote:
On Sat, Oct 3, 2009 at 5:50 PM, Justin Johansson n...@spam.com wrote:
How does one determine the sizeof (in bytes) of an instance of a class in D?
.sizeof works as advertised for structs, but for reference types,
.sizeof yields the sizeof the referencing variable (effectively same as size of
a pointer)
and not the size of the underlying instance.
I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it in the
latter.
btw. I was poking under the hood of std.xml and though, wow, instances of
Element
class look humongous, and so I'm interested to how exactly how humongous.
There's no way to get it at compile-time in D1. The best you can do is
Class.classinfo.init.length.
In D2, you can use __traits(classInstanceSize, Class).
Thanks Jeremie and Jarrett for answers.
For investigative purposes (rather than adding up class member sizes in my
head),
would I get a fair answer if I copied the class data members into a struct, did
a struct
sizeof and added 4 bytes to allow for a virtual function table pointer (in the
class and
assuming the class has a VFT)?
You forgot the monitor pointer of the class, so thats (size_t.sizeof *
2) to add to the size of the struct.
I wasn't aware of the traits method either, I just made this helper
template to simplify its syntax:
template SizeOf(alias C) if(is(C == class)) {
enum ClassSizeof = __traits(classInstanceSize, C);
}
Re: Sizeof class instance
Jeremie Pelletier Wrote:
Justin Johansson wrote:
Jarrett Billingsley Wrote:
On Sat, Oct 3, 2009 at 5:50 PM, Justin Johansson n...@spam.com wrote:
How does one determine the sizeof (in bytes) of an instance of a class in
D?
.sizeof works as advertised for structs, but for reference types,
.sizeof yields the sizeof the referencing variable (effectively same as
size of a pointer)
and not the size of the underlying instance.
I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it
in the latter.
btw. I was poking under the hood of std.xml and though, wow, instances of
Element
class look humongous, and so I'm interested to how exactly how humongous.
There's no way to get it at compile-time in D1. The best you can do is
Class.classinfo.init.length.
In D2, you can use __traits(classInstanceSize, Class).
Thanks Jeremie and Jarrett for answers.
For investigative purposes (rather than adding up class member sizes in my
head),
would I get a fair answer if I copied the class data members into a struct,
did a struct
sizeof and added 4 bytes to allow for a virtual function table pointer (in
the class and
assuming the class has a VFT)?
You forgot the monitor pointer of the class, so thats (size_t.sizeof *
2) to add to the size of the struct.
I wasn't aware of the traits method either, I just made this helper
template to simplify its syntax:
template SizeOf(alias C) if(is(C == class)) {
enum ClassSizeof = __traits(classInstanceSize, C);
}
Sorry I misread the earlier answer. This works for my investigative purposes
as explained:
writefln( Element instance size = %d, Element.classinfo.init.length);
Still glad I asked this last question though because I hadn't thought of
monitor. Also I imagine that
if a class has interfaces, this can impact upon the size as well.
My early years with microprocessors (8085, 8086, 6809 etc) and assembly
language has always made
me curious about how compilers realize their magic at the bit and byte level.
Getting started - D meta-program question
There was mention** on the general discussion group that the D foreach_reverse language construct could be replaced (emulated?) with a (D) meta-program. ** Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=97362 As I'm less than a novice with the D meta-programming facilities (at this stage of my journey into D), if someone would kindly show me the D meta-program solution to do this, I'd really appreciate the enlightenment. Thanks again.
Re: Getting started - D meta-program question
Justin Johansson wrote: There was mention** on the general discussion group that the D foreach_reverse language construct could be replaced (emulated?) with a (D) meta-program. ** Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=97362 As I'm less than a novice with the D meta-programming facilities (at this stage of my journey into D), if someone would kindly show me the D meta-program solution to do this, I'd really appreciate the enlightenment. Thanks again. Short answer: you can't. Long answer: you can, provided you aren't trying to reverse an opApply, which is patently impossible. As for the meta-program, I would suspect whoever said that was talking about writing a templated type or function to handle it. You would need to use template specialisation or static ifs to switch on what type you've been given to reverse. http://digitalmars.com/d/1.0/template.html http://digitalmars.com/d/1.0/version.html#staticif
Re: Sizeof class instance
Jarrett Billingsley wrote: On Sat, Oct 3, 2009 at 5:50 PM, Justin Johansson n...@spam.com wrote: How does one determine the sizeof (in bytes) of an instance of a class in D? .sizeof works as advertised for structs, but for reference types, .sizeof yields the sizeof the referencing variable (effectively same as size of a pointer) and not the size of the underlying instance. I did try scanning the NG and read spec_D1.00.pdf. Perhaps I missed it in the latter. btw. I was poking under the hood of std.xml and though, wow, instances of Element class look humongous, and so I'm interested to how exactly how humongous. Thanks for all help. Justin There's no way to get it at compile-time in D1. The best you can do is Class.classinfo.init.length. What nonsense, of course there is! http://gist.github.com/140531 Note: this is VERY old code, but I have no reason to think it won't still work. I may need a little dusting off...
Re: Sizeof class instance
Daniel Keep wrote: ... Note: this is VERY old code, but I have no reason to think it won't still work. I may need a little dusting off... *It* may need a little dusting off. Argh.
[Issue 52] ambiguous function pointer silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=52 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2009-10-03 02:29:57 PDT --- The hasOverloads needs to be there for it to work right, as if there is a cast it should select the correct overload. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 102] Forward reference nested class wheel.
http://d.puremagic.com/issues/show_bug.cgi?id=102
--- Comment #11 from Rainer Schuetze r.sagita...@gmx.de 2009-10-03 06:27:15
PDT ---
(In reply to comment #8)
IMHO this is a VERY promising patch since it potentially fixes many difficult
issues. It's not quite complete though.
I've run it though Walter's test suite, and one test fails (all others pass).
The code below should fail to compile, but instead the compiler gets into an
infinite loop --- it's an ice-on-invalid-code regression.
struct A (T) {
mixin B! (T, A! (T));
}
A!(int) x;
I've been running into a similar problem with const initializers, that already
use a similar mechanism in DMD 2.032. If anonymous classes are involved, it
might freeze as well instead of producing an error. It took more time to
extract a sensible test case than to patch it, but here it is
module test;
class C
{
const int a = (new class Object { int x; }).sizeof + y;
S s;
}
struct S
{
int s1;
}
dmd -c test.d causes dmd to freeze, instead of reporting undefined identifer
y.
And this is the additional patch (line number might be skewed a little):
Index: declaration.c
===
--- declaration.c(revision 196)
+++ declaration.c(working copy)
@@ -1106,6 +1155,7 @@
if (!global.errors !inferred)
{
+unsigned progress = Module::dprogress;
unsigned errors = global.errors;
global.gag++;
//printf(+gag\n);
@@ -1127,6 +1177,7 @@
//printf(-gag\n);
if (errors != global.errors)// if errors happened
{
+Module::dprogress = progress; // we are throwing away the
expression copy, so no progress
if (global.gag == 0)
global.errors = errors;// act as if nothing happened
#if DMDV2
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3301] Undefined identifier error dependent on order of imports when a circular import is involved
http://d.puremagic.com/issues/show_bug.cgi?id=3301 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Attachment #454 is|0 |1 obsolete|| --- Comment #15 from Rainer Schuetze r.sagita...@gmx.de 2009-10-03 08:28:17 PDT --- Created an attachment (id=469) improved patch with version/debug support I have improved the patch to look through version/debug conditionals, that would bring back all the troubles if used for the imports. I've also moved the setScope calls into the importAll functions, which was already proposed in a comment nearby. At the same time, version/debug conditional declarations pass the scope to its included branch. StaticIfDeclarations cannot do this, because the semantic analysis is needed to evaluate the condition. In the long run, I'd propose to take the setScope mechanism further, setting the scope as early as possible, allowing semantic analysis in arbitrary order. I've run the qtd build with this patch and it still works. You'll also need the patch of issue 3353 for the build to complete, though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
