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 :)
