On Thu, 01 Sep 2011 21:11:43 +0200, Martin Nowak wrote:
Implementation was simpler than I'd thought.
https://gist.github.com/1186982#file_list_comprehension.d
Sorrowly there is no phobos function to create permutations and
std.functional doesn't extend to n-ary functions.
That's why Philipp
On 9/1/11 9:03 PM, Walter Bright wrote:
I'll often use:
*(char*)0=0;
in C++ code :-)
Very handy.
The result might not quite be what you expect with all C++ compilers,
though:
———
$ clang -Wall test.cpp
test.cpp:2:5: warning: indirection of non-volatile null pointer will be
deleted, not t
On Thu, 01 Sep 2011 13:33:20 +0200, Timon Gehr wrote:
On 09/01/2011 05:02 AM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 01:03 AM, Timon Gehr wrote:
On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr
wrote:
[2 * x ; x<- iota(10), log(x), x
On 9/1/2011 8:52 AM, Jonathan M Davis wrote:
that
should already be verified just by calling its functions) rather than something
like every time that a reference is used,
If you've ever had the joy of trying to track down a memory corruption bug,
being able to verify the state of an object wi
On 9/1/2011 11:33 AM, Steven Schveighoffer wrote:
On Thu, 01 Sep 2011 14:27:36 -0400, Daniel Murphy
wrote:
Walter Bright wrote:
You might be surprised, then, that I'll often temporarily replace an assert
with a HLT instruction so I can use a debugger on it :-)
Now that's karma :)
I'll oft
On Thu, 01 Sep 2011 14:27:36 -0400, Daniel Murphy
wrote:
"Andrej Mitrovic" wrote in message
news:mailman.2630.1314899211.14074.digitalmar...@puremagic.com...
Err, DMD crashes on every error, even this:
int z = "bla";
I guess a due to a bad commit?
Walter left a halt in verror. He does
On 9/1/2011 10:46 AM, Andrej Mitrovic wrote:
Err, DMD crashes on every error, even this:
int z = "bla";
I guess a due to a bad commit?
It works when I try it.
"Andrej Mitrovic" wrote in message
news:mailman.2630.1314899211.14074.digitalmar...@puremagic.com...
> Err, DMD crashes on every error, even this:
>
> int z = "bla";
>
> I guess a due to a bad commit?
Walter left a halt in verror. He does this occasionally.
On Thu, 01 Sep 2011 01:21:12 +0200, Timon Gehr wrote:
auto foo(Range)(int n, Range r) {
return mixin(compr!q{x * n ; x <- arr, log(x), x*x > 4});
}
This is one of the reasons I feel mixin templates should require 'mixin'
only
when defined, not when instantiated. Sure, it would be possi
On 2011-09-01 16:40, Andrei Alexandrescu wrote:
On 09/01/2011 09:02 AM, Lars T. Kyllingstad wrote:
Walter, I don't think there is a single person in this community, at
least not among the vocal ones, who agrees with you on this. It is a
case where the language completely fails to do what 99.9% o
Err, DMD crashes on every error, even this:
int z = "bla";
I guess a due to a bad commit?
Ouch, I've found a naughty bug:
---
dmd.exe - Application Error
---
The instruction at "0x0040235d" referenced memory at "0x". The
memory could not be "written".
Code:
void main()
{
Foo foo;
}
struct Foos
{
@disable this();
}
Notic
On 9/1/11 7:17 PM, Martin Nowak wrote:
Well I agree that segfaults are way more informative than throwing an
AssertError.
It does have less issues with incorrect stack unwinding and the core
file still contains
register data. This is biased somewhat by using FreeBSD. I never get
stack traces for
On Thu, 01 Sep 2011 16:40:13 +0200, Andrei Alexandrescu
wrote:
On 09/01/2011 09:02 AM, Lars T. Kyllingstad wrote:
On Tue, 30 Aug 2011 22:35:51 -0700, Walter Bright wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard He
On Thursday, September 01, 2011 09:40:13 Andrei Alexandrescu wrote:
> On 09/01/2011 09:02 AM, Lars T. Kyllingstad wrote:
> > On Tue, 30 Aug 2011 22:35:51 -0700, Walter Bright wrote:
> >> On 8/30/2011 6:28 PM, Brad Roberts wrote:
> >>> On Tue, 30 Aug 2011, Walter Bright wrote:
> On 8/30/2011 5:
On 09/01/2011 09:02 AM, Lars T. Kyllingstad wrote:
On Tue, 30 Aug 2011 22:35:51 -0700, Walter Bright wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote
On 09/01/2011 04:02 PM, Lars T. Kyllingstad wrote:
On Tue, 30 Aug 2011 22:35:51 -0700, Walter Bright wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote
On Tue, 30 Aug 2011 22:35:51 -0700, Walter Bright wrote:
> On 8/30/2011 6:28 PM, Brad Roberts wrote:
>> On Tue, 30 Aug 2011, Walter Bright wrote:
>>
>>> On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
> Looking for corruption of th
On Thu, 01 Sep 2011 00:18:16 -0400, bearophile
wrote:
Steven Schveighoffer:
Currently, the empty main() program is 256k. Add in writeln("hello,
world") and it adds 500k. Even if I had 10,000 asserts in there for
objects, that adds 150k.
I think bloat can't possibly be a valid concern here
On 09/01/2011 05:02 AM, kennytm wrote:
Timon Gehr wrote:
On 09/01/2011 01:03 AM, Timon Gehr wrote:
On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr wrote:
[2 * x ; x<- iota(10), log(x), x*x> 4]
or, in a library:
compr!q {2 * x ; x<- iota(10),
OK, so basically there is a confusing special case just to save few bits
on debug programs...
One thing that hasn't been mentioned is that asserts do not always terminate
the program. Should this program segfault?
(Not a great example, because while it does segfault inside A.fun's
contract, the contract handler's catch-all ignores it and contines, but
that's a different issue)
class X
"kennytm" wrote in message
> Also, the proposal only affects
> asserts of the form
>
>assert(classObj);
>
And assert(ptrToStructWithInvariant);
"Jonathan M Davis" wrote in message
news:mailman.2616.1314834798.14074.digitalmar...@puremagic.com...
>
> As I understand
> it, with regards to CTFE at least, the compiler doesn't collect _any_
> memory
> until it's done compiling (since the memory management is easier that
> way). I
> don't kn
Steven Schveighoffer:
> Currently, the empty main() program is 256k. Add in writeln("hello,
> world") and it adds 500k. Even if I had 10,000 asserts in there for
> objects, that adds 150k.
>
> I think bloat can't possibly be a valid concern here.
Bytes are not enough to measure "bloat". You
Timon Gehr wrote:
> On 09/01/2011 01:03 AM, Timon Gehr wrote:
>> On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
>>> On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr wrote:
>>>
> [2 * x ; x <- iota(10), log(x), x*x > 4]
>
> or, in a library:
>
> compr!q {2 * x ; x <- iota(10),
On Wednesday, August 31, 2011 16:11 Timon Gehr wrote:
> On 09/01/2011 12:58 AM, Jonathan M Davis wrote:
> > On Wednesday, August 31, 2011 14:18 Steven Schveighoffer wrote:
> >> On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
> >>
> >> wrote:
> >>> On 8/31/2011 1:19 PM, Steven Schveighoffer wrot
On 09/01/2011 01:03 AM, Timon Gehr wrote:
On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr wrote:
[2 * x ; x <- iota(10), log(x), x*x > 4]
or, in a library:
compr!q {2 * x ; x <- iota(10), log(x), x*x > 4};
compr!q{2 * x ; x <- iota(10), log(x
On 09/01/2011 12:58 AM, Jonathan M Davis wrote:
On Wednesday, August 31, 2011 14:18 Steven Schveighoffer wrote:
On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
wrote:
On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
I think bloat can't possibly be a valid concern here.
You'd be surprise
On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr wrote:
[2 * x ; x <- iota(10), log(x), x*x > 4]
or, in a library:
compr!q {2 * x ; x <- iota(10), log(x), x*x > 4};
compr!q{2 * x ; x <- iota(10), log(x), x*x > 4};
The library solution has pro
On Wednesday, August 31, 2011 14:18 Steven Schveighoffer wrote:
> On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
> wrote:
> > On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
> >> I think bloat can't possibly be a valid concern here.
> >
> > You'd be surprised. I was surprised to discover tha
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr wrote:
[2 * x ; x <- iota(10), log(x), x*x > 4]
or, in a library:
compr!q {2 * x ; x <- iota(10), log(x), x*x > 4};
compr!q{2 * x ; x <- iota(10), log(x), x*x > 4};
The library solution has problems with scope variables. Example:
auto foo(
On 8/31/2011 5:40 PM, Steven Schveighoffer wrote:
But this program works swimmingly:
Wow.
Is there any reason to not use that as the default sigsegv handler?
On 8/31/2011 1:38 PM, Robert Clipsham wrote:
On 31/08/2011 21:02, Walter Bright wrote:
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an
assert with a HLT instruction so
On 08/31/2011 11:42 PM, Timon Gehr wrote:
On 08/31/2011 11:33 PM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:16:26 +0200, Timon Gehr wrote:
My design is meant to be somewhat similar to for-loops, with the
semicolon-separated expressions, and to set builder notation. I kinda
wish 'in'
was us
On 08/31/2011 11:33 PM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 23:16:26 +0200, Timon Gehr wrote:
My design is meant to be somewhat similar to for-loops, with the
semicolon-separated expressions, and to set builder notation. I kinda
wish 'in'
was used in foreach loops (foreach(x in foo){}),
On Wed, 31 Aug 2011 17:20:04 -0400, Robert Clipsham
wrote:
On 31/08/2011 22:01, Steven Schveighoffer wrote:
You can catch sigsegv on linux. It takes one call to signal to register
a handler.
Are you sure? I could have sworn it didn't work? If it does work, what
is the purpose of this lib
On 08/31/2011 11:24 PM, Christophe wrote:
Maybe think assert should not be rewritten, but opCast!(bool) should
test if the class reference is null, which would be consistent with
opEquals
It actually does:
class C;
C x;
// assert(x&&1); // no segfault
assert(x); // segfault
The problem is that
On 8/31/11 10:02 PM, Walter Bright wrote:
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an
assert with a HLT instruction so I can use a debugger on it :-)
I am sure you
On Wed, 31 Aug 2011 23:16:26 +0200, Timon Gehr wrote:
My design is meant to be somewhat similar to for-loops, with the
semicolon-separated expressions, and to set builder notation. I kinda
wish 'in'
was used in foreach loops (foreach(x in foo){}), as that would be a
perfect fit
for the <= in th
On 31/08/2011 22:01, Steven Schveighoffer wrote:
You can catch sigsegv on linux. It takes one call to signal to register
a handler.
Are you sure? I could have sworn it didn't work? If it does work, what
is the purpose of this library:
http://libsigsegv.sourceforge.net/
--
Robert
http://octa
Maybe think assert should not be rewritten, but opCast!(bool) should
test if the class reference is null, which would be consistent with
opEquals
On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
wrote:
On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
It's also possible for the program to have its own seg fault handler
that
reads its own symbolic debug info and generates a line number and
stack trace.
There was a patch to Phobos
On 08/31/2011 11:10 PM, Simen Kjaeraas wrote:
On Wed, 31 Aug 2011 21:16:37 +0200, bearophile
wrote:
Simen Kjaeraas:
I feel it is too much a departure from the style otherwise present in D.
This is why I have shown my original syntax with [foreach() if()].
It is important not only that t
On Wed, 31 Aug 2011 21:16:37 +0200, bearophile
wrote:
Simen Kjaeraas:
I feel it is too much a departure from the style otherwise present in D.
This is why I have shown my original syntax with [foreach() if()].
It is important not only that the syntax is good in and of itself,
but also
On Wed, 31 Aug 2011 16:40:02 -0400, Robert Clipsham
wrote:
On 31/08/2011 21:19, Steven Schveighoffer wrote:
It's also possible for the program to have its own seg fault handler
that reads its own symbolic debug info and generates a line number and
stack trace. There was a patch to Phobos tha
On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
It's also possible for the program to have its own seg fault handler that
reads its own symbolic debug info and generates a line number and stack trace.
There was a patch to Phobos that did this a while back.
This would also be a valid option. I
Walter Bright wrote:
> You might be surprised, then, that I'll often temporarily replace an
> assert with a HLT instruction so I can use a debugger on it :-)
> It's also possible for the program to have its own seg fault handler that
> reads its own symbolic debug info and generates a line numbe
On 31/08/2011 21:02, Walter Bright wrote:
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an
assert with a HLT instruction so I can use a debugger on it :-)
What's wrong
On 31/08/2011 21:19, Steven Schveighoffer wrote:
It's also possible for the program to have its own seg fault handler
that reads its own symbolic debug info and generates a line number and
stack trace. There was a patch to Phobos that did this a while back.
This would also be a valid option. I
On Wed, 31 Aug 2011 16:02:56 -0400, Walter Bright
wrote:
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an
assert with a HLT instruction so I can use a debugger on i
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> On 8/31/2011 7:14 AM, Sean Kelly wrote:
> > It's worth mentioning that for some reason, Solaris doesn't protect the
> > entire first page of memory--only the zero address. For accesses the where
> > the compiler pre-computes the o
On 8/31/2011 7:14 AM, Sean Kelly wrote:
It's worth mentioning that for some reason, Solaris doesn't protect the
entire first page of memory--only the zero address. For accesses the where
the compiler pre-computes the offset and reads that location directly, you
won't get a segfault if the pointer
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an assert with
a HLT instruction so I can use a debugger on it :-)
If you have a seg fault,
you must reproduce the error
Simen Kjaeraas:
> I feel it is too much a departure from the style otherwise present in D.
This is why I have shown my original syntax with [foreach() if()].
> It is important not only that the syntax is good in and of itself,
> but also in the context of D.
The syntax you have shown is noisy
Am 31.08.2011, 19:36 Uhr, schrieb Simen Kjaeraas :
On Wed, 31 Aug 2011 18:57:01 +0200, bearophile
wrote:
Simen Kjaeraas:
Next iteration:
[x; 2 * x; iota(10); x & 1]
If you don't like the syntax I've shown with foreach, then use the
Python syntax, it's readable and short and good
On Wed, 31 Aug 2011 18:57:01 +0200, bearophile
wrote:
Simen Kjaeraas:
Next iteration:
[x; 2 * x; iota(10); x & 1]
If you don't like the syntax I've shown with foreach, then use the
Python syntax, it's readable and short and good:
[2 * x for x in iota(10) if x & 1]
Or:
[2 * x for
Simen Kjaeraas:
> Next iteration:
>
> [x; 2 * x; iota(10); x & 1]
If you don't like the syntax I've shown with foreach, then use the Python
syntax, it's readable and short and good:
[2 * x for x in iota(10) if x & 1]
Or:
[2 * x for x in 0 .. 10 if x & 1]
Bye,
bearophile
"Iain Buclaw" wrote in message
news:j3kmih$2g4m$1...@digitalmars.com...
> You should be able to do it with less changes than that. :~)
>
=/
It's really about 8 lines of code. The rest is all whitespace/alignment
changes from making the assert/message generation unconditional.
> In GDC I settled
It's worth mentioning that for some reason, Solaris doesn't protect the entire
first page of memory--only the zero address. For accesses the where the
compiler pre-computes the offset and reads that location directly, you won't
get a segfault if the pointer is null (at least with GCC--haven't te
On 8/30/11 8:19 PM, Walter Bright wrote:
On 8/30/2011 4:07 PM, Timon Gehr wrote:
You mean, in release mode the assert gets compiled out, and it seg
faults in the
code sequence that depends on the assertion, right?
Yes. Any dereference of a null class ref would cause a seg fault.
I am not afr
On 8/31/11 6:46 AM, Steven Schveighoffer wrote:
On Wed, 31 Aug 2011 01:35:51 -0400, Walter Bright
wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
On Wed, 31 Aug 2011 01:35:51 -0400, Walter Bright
wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
Looking for corruption of the data.
Why doe
On Wed, 31 Aug 2011 01:11:20 +0200, bearophile
wrote:
Andrei Alexandrescu:
new Type[n](argument1, argument2, ..., argumentn)
More musings about this.
A generic lazy/eager array comprehension syntax seems better, like (for
the eager one):
[Baz(x, x*y) foreach(x; 0 .. 10) if (isGood(x))
On Wednesday, August 31, 2011 12:06:57 AM, Iain Buclaw wrote:
> == Quote from Brad Roberts (bra...@puremagic.com)'s article
>> On 8/30/2011 10:35 PM, Walter Bright wrote:
>>> On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
> On 8/30/2011 5:08 PM, Be
== Quote from Brad Roberts (bra...@puremagic.com)'s article
> On 8/30/2011 10:35 PM, Walter Bright wrote:
> > On 8/30/2011 6:28 PM, Brad Roberts wrote:
> >> On Tue, 30 Aug 2011, Walter Bright wrote:
> >>
> >>> On 8/30/2011 5:08 PM, Bernard Helyer wrote:
> On Tue, 30 Aug 2011 16:19:00 -0700, Wa
On 8/30/2011 10:35 PM, Walter Bright wrote:
> On 8/30/2011 6:28 PM, Brad Roberts wrote:
>> On Tue, 30 Aug 2011, Walter Bright wrote:
>>
>>> On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
> Looking for corruption of the data.
>
On 8/30/2011 8:41 PM, Eric Poggel (JoeCoder) wrote:
What debugger do you use? It's been years, but the last time I investigated
debuggers on Windows was with dmd1. The ones I tried (I don't remember which)
either added about 30 seconds to my startup time (otherwise 1-2 seconds) or
failed to run m
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
Looking for corruption of the data.
Why doesn't it check for null, and pass if no invariant is defined?
On 8/30/2011 7:19 PM, Walter Bright wrote:
Why? I rely on that for debugging. I run it under the debugger, seg
fault, bing the debugger shows where it faulted and a stack trace. It's
about 98% of what a debugger is good for.
What debugger do you use? It's been years, but the last time I
inves
On Tue, 30 Aug 2011, Walter Bright wrote:
> On 8/30/2011 5:08 PM, Bernard Helyer wrote:
> > On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
> >
> > > Looking for corruption of the data.
> >
> > Why doesn't it check for null, and pass if no invariant is defined?
>
> Because the hardware
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
Looking for corruption of the data.
Why doesn't it check for null, and pass if no invariant is defined?
Because the hardware does the null check for you, which is what a seg fault is.
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
> Looking for corruption of the data.
Why doesn't it check for null, and pass if no invariant is defined?
On 08/31/2011 01:19 AM, Walter Bright wrote:
On 8/30/2011 4:07 PM, Timon Gehr wrote:
You mean, in release mode the assert gets compiled out, and it seg
faults in the
code sequence that depends on the assertion, right?
Yes. Any dereference of a null class ref would cause a seg fault.
I am not
On 8/30/2011 4:07 PM, Timon Gehr wrote:
You mean, in release mode the assert gets compiled out, and it seg faults in the
code sequence that depends on the assertion, right?
Yes. Any dereference of a null class ref would cause a seg fault.
I am not afraid of seg faults so much, but in debug mo
On 08/30/2011 11:07 PM, Walter Bright wrote:
On 8/30/2011 7:58 AM, Christian Kamm wrote:
I want to point out the following bug in the example, because it's
*such* a
common problem and, in my opinion, one of D's warts:
Walter Bright wrote:
this(P q)
{
assert(q);
p = q;
}
Try
auto d = NotNull!
Andrei Alexandrescu:
> new Type[n](argument1, argument2, ..., argumentn)
More musings about this.
A generic lazy/eager array comprehension syntax seems better, like (for the
eager one):
[Baz(x, x*y) foreach(x; 0 .. 10) if (isGood(x))]
Currently to create an array of structs like this Foo you
On 8/30/2011 1:06 PM, Simen Kjaeraas wrote:
Testing concludes that changing the length of the array indeed appends
structs to it, with no compile-time error. Should I file this in BugZilla?
Not yet. I'm not sure that using bugzilla for things under development is that
good an idea. Once it is
On 8/30/2011 7:58 AM, Christian Kamm wrote:
I want to point out the following bug in the example, because it's *such* a
common problem and, in my opinion, one of D's warts:
Walter Bright wrote:
this(P q)
{
assert(q);
p = q;
}
Try
auto d = NotNull!Object(n
Andrei Alexandrescu:
> new Type[n](argument1, argument2, ..., argumentn)
I'd like those constructors to know what's their array index. But too much
magic (like using $) is better left to Perl language.
Bye,
bearophile
On Mon, 29 Aug 2011 22:41:19 +0200, Simen Kjaeraas
wrote:
On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright
wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default init
On Tuesday, August 30, 2011 09:35 Andrei Alexandrescu wrote:
> On 8/29/11 7:49 PM, bearophile wrote:
> [snip]
>
> > void main() {
> >
> > auto a = new nFoo[5];
> > bar(a[0]);
> >
> > }
>
> Ah, that reminds me. The introduction of @disable requires the
> introduction of array-with-constructor sy
On 8/29/11 7:49 PM, bearophile wrote:
[snip]
void main() {
auto a = new nFoo[5];
bar(a[0]);
}
Ah, that reminds me. The introduction of @disable requires the
introduction of array-with-constructor syntax that has long been
proposed to both C++ and D:
new Type[n](argument1, argumen
Alex Rønne Petersen:
> This is great! I've often had to use classes where I wanted to use
> structs because the default state would result in bad behavior.
Currently NotNull is broken, it's a trap. It doesn't really do what I want, and
maybe it does something else that I don't need. Let's see i
On 08/30/2011 04:58 PM, Christian Kamm wrote:
I want to point out the following bug in the example, because it's *such* a
common problem and, in my opinion, one of D's warts:
Walter Bright wrote:
this(P q)
{
assert(q);
p = q;
}
Try
auto d = NotNull!Object
I want to point out the following bug in the example, because it's *such* a
common problem and, in my opinion, one of D's warts:
Walter Bright wrote:
> this(P q)
> {
> assert(q);
> p = q;
> }
Try
auto d = NotNull!Object(null);
you'll get a segmentation fault and
On 29-08-2011 22:22, Walter Bright wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This
makes it practical to implement a library based "NotNull" type without
On Mon, 29 Aug 2011 16:41:19 -0400, Simen Kjaeraas
wrote:
On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright
wrote:
I do think that the "this() @disable;" is an ugly syntax, and I cringe
when seeing it. But I can't think of anything better. It does make
logical sense given the existence
> What's the way to solve this problem?
This gives you some ideas:
http://research.microsoft.com/pubs/67461/non-null.pdf
Bye,
bearophile
Walter:
> Fixed. Keep 'em coming!
You are quick :-)
What's the way to solve this problem?
import core.stdc.stdio;
struct NotNull(P) if (__traits(compiles, {P p = null;})) {
private P p;
@disable this();
this(P q) {
assert(q);
p = q;
}
NotNull opAss
Both:
this() @disable;
and
@disable this();
will work, right? I don't think the syntax is that bad.
Anyway this is a great addition. I've seen numerous use-cases for
disabling a struct's default ctor.
On 8/29/2011 5:11 PM, Walter Bright wrote:
On 8/29/2011 4:52 PM, bearophile wrote:
alias NotNull!(Foo*) NFooP;
void bar(NFooP foop) { // Error: variable test2.bar.foop initializer required
for type NotNull!(Foo*)
Looks like you found a bug. I'll take care of it.
Fixed. Keep 'em coming!
htt
On 8/29/2011 4:52 PM, bearophile wrote:
alias NotNull!(Foo*) NFooP;
void bar(NFooP foop) { // Error: variable test2.bar.foop initializer required
for type NotNull!(Foo*)
Looks like you found a bug. I'll take care of it.
Walter:
> I've implemented the ability to disable default initialization. This makes
> it
> practical to implement a library based "NotNull" type without a special
> syntax
> for it. The rationale for this is (rather than making it builtin)
If it works well enough, a syntax is allowed to co
On 30.08.2011 0:22, Walter Bright wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This
makes it practical to implement a library based "NotNull" type without
On 8/29/2011 2:09 PM, dsimcha wrote:
DMD doesn't even build right now.
Dang ships passing in the night. Fixed.
On 8/29/2011 1:56 PM, dsimcha wrote:
Oh, one more thing: What about this:
NotNull!(int*) notNull = void;
It's accepted, unless it's in @safe code.
On 8/29/2011 1:32 PM, dsimcha wrote:
How does it work for member variables of classes and structs? E.g.:
// Is this legal or not?
struct Foo
{
NotNull!(int*) notNull;
this(int* ptr)
{
notNull = ptr;
}
}
Try it and see! (It works as you'd expect.)
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> On 8/29/2011 1:32 PM, dsimcha wrote:
> > How does it work for member variables of classes and structs? E.g.:
> >
> > // Is this legal or not?
> > struct Foo
> > {
> > NotNull!(int*) notNull;
> >
> > this(int* ptr)
> >
Oh, one more thing: What about this:
NotNull!(int*) notNull = void;
1 - 100 of 104 matches
Mail list logo
