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 a special syntax
for it. The rationale
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> 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
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 initialization. This
makes it practical to implement a library ba
On 8/29/11 3:22 PM, 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
Oh, one more thing: What about this:
NotNull!(int*) notNull = void;
== 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)
> >
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.)
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 2:09 PM, dsimcha wrote:
DMD doesn't even build right now.
Dang ships passing in the night. Fixed.
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
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 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.
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
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.
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
> What's the way to solve this problem?
This gives you some ideas:
http://research.microsoft.com/pubs/67461/non-null.pdf
Bye,
bearophile
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
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
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 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
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 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
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 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
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 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
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
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 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!
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/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 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 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, 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 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 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 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 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.
>
== 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 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
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 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 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 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
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
"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
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
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
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
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
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
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
== 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 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
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 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
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 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
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 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 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 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
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 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
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 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 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 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: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 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 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 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 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 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 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 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 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 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
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),
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
"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
"kennytm" wrote in message
> Also, the proposal only affects
> asserts of the form
>
>assert(classObj);
>
And assert(ptrToStructWithInvariant);
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
OK, so basically there is a confusing special case just to save few bits
on debug programs...
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),
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 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 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 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 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 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 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
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
Err, DMD crashes on every error, even this:
int z = "bla";
I guess a due to a bad commit?
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
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
"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 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.
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 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
1 - 100 of 104 matches
Mail list logo
