A switch bug
In this case I have not appreciated implicit char <-> int conversions in D (this comes from a bug of mine): void main(string[] args) { foreach (c; args[1]) switch (c) { case 0: .. case 9: // do something with the digit default: } } Bye, bearophile
Tuples & const values
Currently this doesn't work, but I'd like to do this: import std.typecons; void main() { const int x = 1; const int y = 2; auto t = tuple(x, y); } Is it possible to modify the tuples to allow this? Bye, bearophile
Clear big AAs
Hi, I'm trying to clear big associative arrays, but I always get an object error - what I currently doing is: private string[uint] myAA; void main() { fill(myAA); myAA.clear(); fill(myAA); // object.Error: Access Violation } void fill(string[uint] aa) { for (uint i = 0; i < 10_000_000_000; i++) { myAA[i] = std.conv.to!(string)(i); } } I already saw the bug report at http://www.digitalmars.com/d/archives/ digitalmars/D/bugs/ Issue_5683_New_Calling_.clear_on_a_fresh_associative_array_causes_subsequent_segfault_28632.html and I'm also using 2.052 - as I saw at the change-log of 2.053 it's also unfixed. So... is there any solution to clear associative arrays without memory leaking?
Re: nested comments
On Mon, May 30, 2011 at 11:58 PM, Jonathan M Davis wrote: > On 2011-05-30 19:53, Nick Sabalausky wrote: >> "Ary Manzana" wrote in message >> news:is1hsa$p53$1...@digitalmars.com... >> >> > On 5/31/11 7:58 AM, Nick Sabalausky wrote: >> >> "bearophile" wrote in message >> >> news:is1dj6$ihb$1...@digitalmars.com... >> >> >> >>> Jesse Phillips: >> The purpose is commenting out code, but note that there is also >> version(none) { } which is never compiled in. >> >>> >> >>> version(none) {} is probably the official way to comment out code. >> >>> And if you use a versioning system to keep your code, then commenting >> >>> out >> >>> code is not a so wise thing to do. >> >> >> >> Why not? I've never heard of a VCS that went around stripping out all >> >> comments. >> > >> > The question is: why comment and commit code that you can already find in >> > the commit history? Then you end up with huge files with things like: >> > >> > /* >> > >> > * Maybe we will use this in a future, this is not working right now >> > ... >> > ... >> > ... >> > */ >> > >> > and the code becomes a mess. >> > >> > So I agree with bearophile here. >> >> But that applies to version(none) {}, too. Maybe I misunderstood >> bearophile, I thought he meant "if you use a versioning system to keep >> your code, then commenting out code [as opposed to using version(none) {}] >> is not a so wise thing to do" > > I'm not sure what he meant. Personally, I don't see much value to > version(none). I believe that the only gain that you get out of it is that the > code must be syntactically correct. And since the code is never going to be > used until you change the version, I don't really see much value in that. > Comments do the job just as well. > > - Jonathan M Davis > Use static if(false) the compiler makes sure that code still compiles at least. The problem with commented out code being saved in common code repositories is that it can suffer from bit rust.
Re: Template parameter defaults
On Mon, 30 May 2011 09:42:53 -0400, Johann MacDonagh wrote: I'm wondering if there's a cleaner way to do this: class Test(T = uint) { this(string s) { } } void main(string[] argv) { auto a = new Test!()("test"); } I'd *like* to be able to do this: auto a = new Test("test"); and: auto a = new Test!double("test"); The only possibility I see is to do this: alias Test!() Test2; But that introduces two types a user has to decide between. Any ideas? Am I out of luck here? Currently, you can omit the template args only in the case of IFTI (Implicit Function Template Instantiation) which actually deduces your template arguments based on the function call. I'd argue actually, that IFTI should be extended to constructors: class Test(T) { this(T t) {} } T t; auto a = new Test(1); static assert(is(typeof(a) == Test!int)); Which would also cover your case. This should be a no-brainer since a constructor call is almost identical in nature to a function call. For sure the overload resolution is the same. I thought there was a bugzilla entry for this, but I couldn't find it with some simple searches, anyone know of one? If not, I'll file one. -Steve
Re: nested comments
On Mon, 30 May 2011 20:43:18 -0400, bearophile wrote: Jesse Phillips: The purpose is commenting out code, but note that there is also version(none) { } which is never compiled in. version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do. I would add that there is a huge difference between version(none) and commenting -- version(none) code must still parse, whereas commenting out code is more flexible. For example: for(int i = 0; i < 100; i++) if(x == i) { writeln("found x") if(y == i) writeln("x and y are the same!"); } if you want to just comment out the if(x == i) line, using version(none) is not going to work well. I would say that commenting out to test things is acceptable, but version(none) should be used when code is to be turned off long-term. -Steve
Re: Template parameter defaults
On 2011-05-31 10:49, Steven Schveighoffer wrote: > On Mon, 30 May 2011 09:42:53 -0400, Johann MacDonagh > > wrote: > > I'm wondering if there's a cleaner way to do this: > > > > class Test(T = uint) > > { > > > > this(string s) > > { > > } > > > > } > > > > void main(string[] argv) > > { > > > > auto a = new Test!()("test"); > > > > } > > > > I'd *like* to be able to do this: > > > > auto a = new Test("test"); > > > > and: > > > > auto a = new Test!double("test"); > > > > The only possibility I see is to do this: > > > > alias Test!() Test2; > > > > But that introduces two types a user has to decide between. Any ideas? > > Am I out of luck here? > > Currently, you can omit the template args only in the case of IFTI > (Implicit Function Template Instantiation) which actually deduces your > template arguments based on the function call. I'm not aware of a bugzilla entry on it. I just know that it doesn't work. - Jonathan M Davis > > I'd argue actually, that IFTI should be extended to constructors: > > class Test(T) > { > this(T t) {} > } > > T t; > auto a = new Test(1); > > static assert(is(typeof(a) == Test!int)); > > Which would also cover your case. > > This should be a no-brainer since a constructor call is almost identical > in nature to a function call. For sure the overload resolution is the > same. > > I thought there was a bugzilla entry for this, but I couldn't find it with > some simple searches, anyone know of one? If not, I'll file one. > > -Steve
Re: Template parameter defaults
On Tue, 31 May 2011 19:49:24 +0200, Steven Schveighoffer wrote: Currently, you can omit the template args only in the case of IFTI (Implicit Function Template Instantiation) which actually deduces your template arguments based on the function call. I'd argue actually, that IFTI should be extended to constructors: class Test(T) { this(T t) {} } T t; auto a = new Test(1); static assert(is(typeof(a) == Test!int)); Which would also cover your case. This should be a no-brainer since a constructor call is almost identical in nature to a function call. For sure the overload resolution is the same. I thought there was a bugzilla entry for this, but I couldn't find it with some simple searches, anyone know of one? If not, I'll file one. I've filed one at some point. Actually, looking at it, this was for static opCall for structs. The idea is still the same, though. http://d.puremagic.com/issues/show_bug.cgi?id=1997 -- Simen
nested class inheritance
Hi, I have a class which defines a nested class: class Outer1 { class Inner1 { } } Now I want to inherit from Outer1, to modify its behavior in a way which also involves modifying the behavior of the corresponding inner objects. My first instinct was to write class Outer2 : Outer1 { class Inner2 : Inner1 { } } but the compiler does not allow this. I guess that a nested class can only be subclassed by a class nested in the same outer class. Obviously it doesn't make sense to subclass a nested class in arbitrary other places, but when nested in a subclass of the outer class it seems sensible to me. I have thought of a workaround with 'alias this': class Outer2 : Outer1 { class Inner2 { Inner1 _self; alias _self this; this() { _self = this.outer.new Inner1(); } } } This seems to work, but requires manually calling all the constructors of Inner1 from corresponding constructors of Inner2. Is there a better way to do what I am after? Thanks! Mike
Re: newbie windows setup help (path settings seem correct) fixed
> > Changed directories back to: > dmd2\windows\bin > dmd2\windows\lib > dmd2\src > fixed. Thank you for your help. Robert Smith
Re: nested class inheritance
On Tue, 31 May 2011 20:17:23 +0200, Michael Shulman wrote: I have thought of a workaround with 'alias this': class Outer2 : Outer1 { class Inner2 { Inner1 _self; alias _self this; this() { _self = this.outer.new Inner1(); } } } This seems to work, but requires manually calling all the constructors of Inner1 from corresponding constructors of Inner2. Is there a better way to do what I am after? Does your inner class require implicit access to the outer class? That is, could a static inner class work? Example: class A { static class AA { } } class B : A { static class BB : A.AA { } } -- Simen
Re: nested class inheritance
On Tue, May 31, 2011 at 2:24 PM, Simen Kjaeraas wrote: >> I have thought of a workaround with 'alias this': >> >> class Outer2 : Outer1 { >> class Inner2 { >> Inner1 _self; >> alias _self this; >> this() { >> _self = this.outer.new Inner1(); >> } >> } >> } >> >> This seems to work, but requires manually calling all the constructors >> of Inner1 from corresponding constructors of Inner2. Is there a better >> way to do what I am after? > > Does your inner class require implicit access to the outer class? That is, > could a static inner class work? Thanks for the suggestion. Yes, my inner class does require access to the outer class. I suppose it doesn't have to be *implicit* access; the inner class could just keep an explicit reference to the outer class. (Is there ever a situation in which the implicit-ness of the 'outer' reference is necessary, rather than just convenient?) I've also realized that my proposed workaround actually doesn't work, because 'alias this' doesn't actually behave like subclassing with respect to references. That is, if Inner2 is 'alias this'ed to Inner1, and I try to pass an Inner2 object to a function that's expecting an Inner1, it actually just passes the _self Inner1 object which knows nothing about Inner2 any more--right? Mike
Re: Clear big AAs
useo: > So... is there any solution to clear associative arrays > without memory leaking? What about remove an item at a time inside a loop (iterations on the keys array), and then doing a rehash? Bye, bearophile
Re: Clear big AAs
I realize that this might sound strange, but try setting myAA to null after clear(), this should fix the crash. David On 5/31/11 4:00 PM, useo wrote: Hi, I'm trying to clear big associative arrays, but I always get an object error - what I currently doing is: private string[uint] myAA; void main() { fill(myAA); myAA.clear(); fill(myAA); // object.Error: Access Violation } void fill(string[uint] aa) { for (uint i = 0; i< 10_000_000_000; i++) { myAA[i] = std.conv.to!(string)(i); } } I already saw the bug report at http://www.digitalmars.com/d/archives/ digitalmars/D/bugs/ Issue_5683_New_Calling_.clear_on_a_fresh_associative_array_causes_subsequent_segfault_28632.html and I'm also using 2.052 - as I saw at the change-log of 2.053 it's also unfixed. So... is there any solution to clear associative arrays without memory leaking?
Re: nested comments
"Steven Schveighoffer" wrote in message news:op.vwcxmwfgeav7ka@localhost.localdomain... > On Mon, 30 May 2011 20:43:18 -0400, bearophile > wrote: > >> Jesse Phillips: >> >>> The purpose is commenting out code, but note that there is also >>> version(none) { } which is never compiled in. >> >> version(none) {} is probably the official way to comment out code. >> And if you use a versioning system to keep your code, then commenting >> out code is not a so wise thing to do. > > I would add that there is a huge difference between version(none) and > commenting -- version(none) code must still parse, whereas commenting out > code is more flexible. > > For example: > > for(int i = 0; i < 100; i++) >if(x == i) >{ > writeln("found x") > if(y == i) > writeln("x and y are the same!"); >} > > > if you want to just comment out the if(x == i) line, using version(none) > is not going to work well. > > I would say that commenting out to test things is acceptable, but > version(none) should be used when code is to be turned off long-term. > I prefer comments even for longer term. That way, it always gets highlighted as "THIS CODE IS NOT ACTIVE" and doesn't end up confusing me.
Re: nested comments
On 2011-05-31 18:03, Nick Sabalausky wrote: > "Steven Schveighoffer" wrote in message > news:op.vwcxmwfgeav7ka@localhost.localdomain... > > > On Mon, 30 May 2011 20:43:18 -0400, bearophile > > > > wrote: > >> Jesse Phillips: > >>> The purpose is commenting out code, but note that there is also > >>> version(none) { } which is never compiled in. > >> > >> version(none) {} is probably the official way to comment out code. > >> And if you use a versioning system to keep your code, then commenting > >> out code is not a so wise thing to do. > > > > I would add that there is a huge difference between version(none) and > > commenting -- version(none) code must still parse, whereas commenting out > > code is more flexible. > > > > For example: > > > > for(int i = 0; i < 100; i++) > > > >if(x == i) > >{ > > > > writeln("found x") > > if(y == i) > > > > writeln("x and y are the same!"); > > > >} > > > > if you want to just comment out the if(x == i) line, using version(none) > > is not going to work well. > > > > I would say that commenting out to test things is acceptable, but > > version(none) should be used when code is to be turned off long-term. > > I prefer comments even for longer term. That way, it always gets > highlighted as "THIS CODE IS NOT ACTIVE" and doesn't end up confusing me. I honestly don't get the point of version(none). Sure, you get syntactic analysis, but what good is that really? The code is still subject to bit-rot. You're still going to have to make sure that it's valid if and when you enable it again. Comments do just as good a job. All you lose is syntactic analysis and syntactic highlighting. And I don't see much point in either for totally inactive code. - Jonathan M Davis
Re: The compiler can not find the property function.
Thanks for your detailed answer :)