www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - NotNull pointers

reply Walter Bright <newshound2 digitalmars.com> writes:
For the latest dmd, 
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943
42daae0a5ccf262272e 
,
  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) one can now 
build any type that is a restricted subset of another type. I suspect that a 
non-null type is just scratching the surface of this ability.

Here's a draft prototype of the NotNull type:

import std.c.stdio;

struct NotNull(P) if (is(typeof({P p = null;})))
{
     P p;

     this()  disable;

     this(P q)
     {
         assert(q);
         p = q;
     }

     NotNull opAssign(P q)
     {
         assert(q);
         p = q;
         return this;
     }

     alias p this;
}

void main()
{
     int x;
     NotNull!(int*) s = &x;
     *s = 3;
     printf("test1 %d\n", *s);
     s++;
     printf("test2 %d\n", s[-1]);
}

What it does is:
1. disallows instantiation with any type that null doesn't implicitly convert to
2. disables default construction (this is the new feature)
3. intercepts construction and assignment to enforce not-nullness
4. uses alias this to forward the rest to the wrapped pointer type

For example, try this:

void main()
{
     NotNull!(int*) s;
// Error: variable test.main.s initializer required for type NotNull!(int*)
}

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 of default construction syntax and the  disable, so in a 
sense it is just connecting existing dots, which has a compelling value.
Aug 29 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 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 a library based "NotNull" type without a special syntax
 for it.
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; } }
Aug 29 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.)
Aug 29 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 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)
      {
          notNull = ptr;
      }
 }
Try it and see! (It works as you'd expect.)
http://d.puremagic.com/test-results/ DMD doesn't even build right now.
Aug 29 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/29/2011 2:09 PM, dsimcha wrote:
 DMD doesn't even build right now.
Dang ships passing in the night. Fixed.
Aug 29 2011
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 For the latest dmd,  
 https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943
42daae0a5ccf262272e  
 ,
   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) one can now build any type that is a restricted subset of  
 another type. I suspect that a non-null type is just scratching the  
 surface of this ability.
Awesome! How does it deal with arrays whose elements have no default constructor? I believe increasing the length of such an array should be an error (which likely also excludes decreasing it except for slices).
 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 of default construction syntax and the  
  disable, so in a sense it is just connecting existing dots, which has a  
 compelling value.
I think it's perfect, you just need the words to trade places: disable this(); One could argue that disabled would work better, but that's a can of worms I'm not touching. Really looking forward to trying this out. -- Simen
Aug 29 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 29 Aug 2011 16:41:19 -0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright  
 <newshound2 digitalmars.com> 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 of default construction syntax and  
 the  disable, so in a sense it is just connecting existing dots, which  
 has a compelling value.
I think it's perfect, you just need the words to trade places: disable this(); One could argue that disabled would work better, but that's a can of worms I'm not touching.
I think it works on both sides. And I agree, it's not that cringeworthy, especially if you put it on the left. -Steve
Aug 30 2011
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 29 Aug 2011 22:41:19 +0200, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright  
 <newshound2 digitalmars.com> wrote:

 For the latest dmd,  
 https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943
42daae0a5ccf262272e  
 ,
   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) one can now build any type that is a restricted subset of  
 another type. I suspect that a non-null type is just scratching the  
 surface of this ability.
Awesome! How does it deal with arrays whose elements have no default constructor? I believe increasing the length of such an array should be an error (which likely also excludes decreasing it except for slices).
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? -- Simen
Aug 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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 released, then sure.
Aug 30 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 a
 special syntax for it. The rationale for this is (rather than making it
 builtin) one can now build any type that is a restricted subset of
 another type. I suspect that a non-null type is just scratching the
 surface of this ability.

 Here's a draft prototype of the NotNull type:

 import std.c.stdio;

 struct NotNull(P) if (is(typeof({P p = null;})))
 {
 P p;

 this()  disable;

 this(P q)
 {
 assert(q);
 p = q;
 }

 NotNull opAssign(P q)
 {
 assert(q);
 p = q;
 return this;
 }

 alias p this;
 }
[snip] This is very compelling. Great work! FWIW the implementation could be refined to never expose the held reference as an lvalue: struct NotNull(P) if (is(typeof({P p = null;}))) { private P p; this() disable; this(P q) { assert(q); p = q; } NotNull opAssign(P q) { assert(q); p = q; return this; } property P get() { return p; } alias get this; // force rvalue access } Andrei
Aug 29 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
Oh, one more thing:  What about this:

NotNull!(int*) notNull = void;
Aug 29 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 29 2011
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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 a
 special syntax for it. The rationale for this is (rather than making it
 builtin) one can now build any type that is a restricted subset of
 another type. I suspect that a non-null type is just scratching the
 surface of this ability.
Nice! Clean RAII with structs comes to mind, before you'd have to have .init to be as an invalid state that is always checked later on, e.g.: File f; f.write("blah");//will fail enforce inside write I suspect it can get a bit tricky to deal with arrays of such types though. -- Dmitry Olshansky
Aug 29 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 come later, as it's happening with tuple unpacking now (dmd pull 341). I have tried the feature, but what's the way to use it? import core.stdc.stdio; struct NotNull(P) if (__traits(compiles, {P p = null;})) { private P p; this() disable; this(P q) { assert(q); p = q; } NotNull opAssign(P q) { assert(q); p = q; return this; } property P get() { return p; } alias get this; // force rvalue access } struct Foo { int x; } alias NotNull!(Foo*) NFooP; void bar(NFooP foop) { // Error: variable test2.bar.foop initializer required for type NotNull!(Foo*) printf("d\n", foop.x); } void main() { NFooP p = new Foo; bar(p); } Bye, bearophile
Aug 29 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 29 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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! https://github.com/D-Programming-Language/dmd/commit/883ccdb8b2d423de0f028522edd0c91b5992113f
Aug 29 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
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 opAssign(P q) { assert(q); p = q; return this; } property P get() { return p; } alias get this; // force rvalue access } class Foo { int x; this(int x_) { this.x = x_; } } alias NotNull!(Foo) nFoo; // if nFoo is a good enough nonnull type, then this // function should _never_ cause an Access Violation void bar(nFoo foo) { printf("%d\n", foo.x); } void main() { auto a = new nFoo[5]; bar(a[0]); } Bye, bearophile
Aug 29 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 What's the way to solve this problem?
This gives you some ideas: http://research.microsoft.com/pubs/67461/non-null.pdf Bye, bearophile
Aug 29 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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, argument2, ..., argumentn) creates an array of Type of size n. Each element is constructed with argument list (argument1, argument2, ..., argumentn). Andrei
Aug 30 2011
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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 syntax that has long been proposed to both C++ and D: new Type[n](argument1, argument2, ..., argumentn) creates an array of Type of size n. Each element is constructed with argument list (argument1, argument2, ..., argumentn).
That particular syntax does kind of fly in the face of discusssions to remove new Type[n] in favor of requiring new Type[](n). And even if that's not considered a problem, how does that interact with multi-dimensional arrays? e.g. new Type[][](4, 5)? Or does it just not make sense with multi-dimensional arrays? I suppose that we could just say that a second set of parens is required. So, new Type[n](args) works as long as we have new Type[n](args), and new Type[] (n)(args) works for the case where you put the size in the parens (as arguably should be required). Then if it supported multi-dimensional arrays, it would be something like new Type[][](4, 5)(args), though I'm not quite sure how you'd really support it in multidimensional arrays except perhaps something like new Type[][](4, 5)((args1), (args2), (args3), (args4)) - where each argsX is a full arguments list for each inner array. That's arguably pretty ugly though. However, I don't see any other way to support multi-dimensional arrays if we want to. Regardless, the issue of how to properly distinguish between the current new Type[](n) and the the array-with-constructor syntax. And I'd _love_ to see new Type[n] die, given the confusion that it causes when going to multi- dimensional arrays. But assuming that we can't do that, we should at least make sure that there's no ambiguity with new Type[](n). - Jonathan M Davis
Aug 30 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Aug 30 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 need to use array append (if you want to keep the x fields mutable): struct Foo { int x; const int y; } void main() { Foo[] foos; foos.reserve(10); foreach (i; 0 .. 10) foos ~= Foo(i, i*10); } With an array comp the compiler doesn't need to use an an array append, just array assign (when there is no if condition), that in D is quite faster: struct Foo { int x; const int y; } void main() { auto a = [Foo(i, i*10) foreach(i; 0 .. 10)]; } I think a good compiler is able to optimize even the following code, removing the array append, but this is less simple to do if the body of foreach becomes more complex, with gotos, etc: foos.reserve(10); foreach (i; 0 .. 10) foos ~= Foo(i, i*10); Bye, bearophile
Aug 30 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 31 Aug 2011 01:11:20 +0200, bearophile <bearophileHUGS lycos.com>  
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))]
I think this warrants discussion. Earlier, I have implemented rudimentary range comprehensions that look like this: list!"2 * a" | iota(10) & where!"a & 1" It works, for simple cases. In my opinion, any D array/list/range comprehension should work on ranges as its base, so foreach is out. Instead, a range should be the base for the comprehension. A simple solution would thus be: [(x){return 2 * x;}; iota(10); (x){return x & 1;}] This could even be implemented in a library: list((int x){return 2 * x;}, iota(10), (int x){return x & 1;}) However, as anyone can see, this is crap. It uses delegates, is waay too verbose, and hurts my eyes. (It could be somewhat better with the functions passed as template alias parameters, but that would mess up the order of parameters, and on the whole not help that much) Next iteration: [x; 2 * x; iota(10); x & 1] This is a syntax I could accept. I would like to have the x be more closely associated with the range, something more akin to this: [2 * x; x <= iota(10); x & 1] I am however at a loss as to what combination of squiggles could be used in place of the <= (which is of course not a good choice). The following variations should be allowed: [x; ; iota(10); x & 1]; // (or [; x <= iota(10); x & 1]) [x; 2 * x; iota(10); ]; // (or [2 * x; x <= iota(10); ]) With the first being simply a filter, the second simply a map. -- Simen
Aug 31 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Aug 31 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 31 Aug 2011 18:57:01 +0200, bearophile <bearophileHUGS lycos.com>  
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 x in 0 .. 10 if x & 1]
I feel it is too much a departure from the style otherwise present in D. It is important not only that the syntax is good in and of itself, but also in the context of D. -- Simen
Aug 31 2011
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 31.08.2011, 19:36 Uhr, schrieb Simen Kjaeraas <simen.kjaras gmail.com>:

 On Wed, 31 Aug 2011 18:57:01 +0200, bearophile  
 <bearophileHUGS lycos.com> 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 x in 0 .. 10 if x & 1]
I feel it is too much a departure from the style otherwise present in D. It is important not only that the syntax is good in and of itself, but also in the context of D.
I agree with Simen. Use semicolons where you separate logical parts of the expression like in for(each) and commas when you have an argument list or enumerations where all elements have the same context or meaning (hard to explain). So the Python syntax is [<calculation> for <counter> in <range> if <filter>]. I don't know if the filter is actually required, but it sounds like a neat idea. How about multidimensional arrays though?
Aug 31 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 and hard to read. Array/seq comps are all (or most) a matter of syntax sugar. So if their syntax is bad, they miss their main point by a mile. Bye, bearophile
Aug 31 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 31 Aug 2011 21:16:37 +0200, bearophile <bearophileHUGS lycos.com=
  =
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 in the context of D.
The syntax you have shown is noisy and hard to read. Array/seq comps are all (or most) a matter of syntax sugar. So if thei=
r =
 syntax is bad, they miss their main point by a mile.
And this is where we disagree. I think the syntax is pretty good, and th= at = the pythonesque syntax sticks out like a sore thumb. Instead of conflating t= he concepts of filter, map and source data, I aimed for a solution that is = = familiar to those accustomed to D, with clear distinctions and the benefits that = = brings. My design is meant to be somewhat similar to for-loops, with the semicolon-separated expressions, and to set builder notation. I kinda wi= sh = 'in' was used in foreach loops (foreach(x in foo){}), as that would be a = perfect fit for the <=3D in the proposed syntax: My notation: [2 * x; x in iota(10); x*x > 4] Set builder notation: {2 =C2=B7 x | x =E2=88=88 =E2=84=95, x=C2=B2 > 4} Personally, I find set builder notation to be very clear and = understandable, and thus worth striving to imitate. In D however, the curly brackets and com= ma operator already have other meanings that we should try not to interfere= = with. -- = Simen
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/31/2011 11:10 PM, Simen Kjaeraas wrote:
 On Wed, 31 Aug 2011 21:16:37 +0200, bearophile
 <bearophileHUGS lycos.com> 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 in the context of D.
The syntax you have shown is noisy and hard to read. Array/seq comps are all (or most) a matter of syntax sugar. So if their syntax is bad, they miss their main point by a mile.
And this is where we disagree. I think the syntax is pretty good, and that the pythonesque syntax sticks out like a sore thumb. Instead of conflating the concepts of filter, map and source data, I aimed for a solution that is familiar to those accustomed to D, with clear distinctions and the benefits that brings. 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 the proposed syntax: My notation: [2 * x; x in iota(10); x*x > 4] Set builder notation: {2 · x | x ∈ ℕ, x² > 4} Personally, I find set builder notation to be very clear and understandable, and thus worth striving to imitate. In D however, the curly brackets and comma operator already have other meanings that we should try not to interfere with.
The meaning of the comma is already quite overloaded, so, if it is better readable, I think using comma would be fine.
Aug 31 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 31 Aug 2011 23:16:26 +0200, Timon Gehr <timon.gehr gmx.ch> 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 <=3D in the proposed syntax:

 My notation:
 [2 * x; x in iota(10); x*x > 4]

 Set builder notation:
 {2 =C2=B7 x | x =E2=88=88 =E2=84=95, x=C2=B2 > 4}

 Personally, I find set builder notation to be very clear and
 understandable, and
 thus worth striving to imitate. In D however, the curly brackets and =
=
 comma
 operator already have other meanings that we should try not to interf=
ere
 with.
The meaning of the comma is already quite overloaded, so, if it is =
 better readable, I think using comma would be fine.
I'm afraid that's not really an option in this case. It would conflict w= ith both array literals and the comma operator. e.g. [2 * x, x in iota(10), x*x > 4] would be seen by the compiler as an= attempt to create an array containing three different types. also, [2 * x; x in iota(10); log(x), x*x > 4] would be more complex to = write ([2 * x; x in iota(10); (a){ log(a); return a*a > 4;}(x)], possibly?) -- = Simen
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/31/2011 11:33 PM, Simen Kjaeraas wrote:
 On Wed, 31 Aug 2011 23:16:26 +0200, Timon Gehr <timon.gehr gmx.ch> 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 the proposed syntax:

 My notation:
 [2 * x; x in iota(10); x*x > 4]

 Set builder notation:
 {2 · x | x ∈ ℕ, x² > 4}

 Personally, I find set builder notation to be very clear and
 understandable, and
 thus worth striving to imitate. In D however, the curly brackets and
 comma
 operator already have other meanings that we should try not to interfere
 with.
The meaning of the comma is already quite overloaded, so, if it is better readable, I think using comma would be fine.
I'm afraid that's not really an option in this case. It would conflict with both array literals and the comma operator. e.g. [2 * x, x in iota(10), x*x > 4] would be seen by the compiler as an attempt to create an array containing three different types. also, [2 * x; x in iota(10); log(x), x*x > 4] would be more complex to write ([2 * x; x in iota(10); (a){ log(a); return a*a > 4;}(x)], possibly?)
[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};
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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 <timon.gehr gmx.ch> 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 the proposed syntax:

 My notation:
 [2 * x; x in iota(10); x*x > 4]

 Set builder notation:
 {2 · x | x ∈ ℕ, x² > 4}

 Personally, I find set builder notation to be very clear and
 understandable, and
 thus worth striving to imitate. In D however, the curly brackets and
 comma
 operator already have other meanings that we should try not to
 interfere
 with.
The meaning of the comma is already quite overloaded, so, if it is better readable, I think using comma would be fine.
I'm afraid that's not really an option in this case. It would conflict with both array literals and the comma operator. e.g. [2 * x, x in iota(10), x*x > 4] would be seen by the compiler as an attempt to create an array containing three different types. also, [2 * x; x in iota(10); log(x), x*x > 4] would be more complex to write ([2 * x; x in iota(10); (a){ log(a); return a*a > 4;}(x)], possibly?)
[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};
Aug 31 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr <timon.gehr gmx.ch> 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(Range)(int n, Range r) { return compr!q{x * n; x <- arr, log(x), x*x > 4}; } More importantly, IMO, is that the notation does not clearly mark what is what. is that interpreted (iota(10), log(x)) or (log(x), x*x > 4)? -- Simen
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/01/2011 12:26 AM, Simen Kjaeraas wrote:
 On Wed, 31 Aug 2011 23:54:04 +0200, Timon Gehr <timon.gehr gmx.ch> 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.
I know, that is why I have not implemented this yet. Basically it should be possible to implicitly pass a whole scope to a template, or at least, to have local templates.
 Example:

 auto foo(Range)(int n, Range r) {
 return compr!q{x * n; x <- arr, log(x), x*x > 4};
 }
Workaround: auto foo(Range)(int n, Range r) { mixin Compr!q{x * n ; x <- arr, log(x), x*x > 4}; return compr; }
 More importantly, IMO, is that the notation does not clearly
 mark what is what. is that interpreted (iota(10), log(x))
 or (log(x), x*x > 4)?
It actually does. The comma is a mere separator, and imho it looks very clean. It is just like the set builder syntax you like. (it even has the curly brackets!)
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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 <timon.gehr gmx.ch> 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.
I know, that is why I have not implemented this yet. Basically it should be possible to implicitly pass a whole scope to a template, or at least, to have local templates.
 Example:

 auto foo(Range)(int n, Range r) {
 return compr!q{x * n; x <- arr, log(x), x*x > 4};
 }
Workaround: auto foo(Range)(int n, Range r) { mixin Compr!q{x * n ; x <- arr, log(x), x*x > 4}; return compr; }
but auto foo(Range)(int n, Range r) { return mixin(compr!q{x * n ; x <- arr, log(x), x*x > 4}); } is clearly better.
Aug 31 2011
next sibling parent reply kennytm <kennytm gmail.com> writes:
Timon Gehr <timon.gehr gmx.ch> 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 <timon.gehr gmx.ch> 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.
I know, that is why I have not implemented this yet. Basically it should be possible to implicitly pass a whole scope to a template, or at least, to have local templates.
 Example:
 
 auto foo(Range)(int n, Range r) {
 return compr!q{x * n; x <- arr, log(x), x*x > 4};
 }
Workaround: auto foo(Range)(int n, Range r) { mixin Compr!q{x * n ; x <- arr, log(x), x*x > 4}; return compr; }
but auto foo(Range)(int n, Range r) { return mixin(compr!q{x * n ; x <- arr, log(x), x*x > 4}); } is clearly better.
Hey guys, the expression 'x <- arr' always means "is x less than negation of arr?" in D. Please choose another symbol.
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/01/2011 05:02 AM, kennytm wrote:
 Timon Gehr<timon.gehr gmx.ch>  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<timon.gehr gmx.ch>  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.
I know, that is why I have not implemented this yet. Basically it should be possible to implicitly pass a whole scope to a template, or at least, to have local templates.
 Example:

 auto foo(Range)(int n, Range r) {
 return compr!q{x * n; x<- arr, log(x), x*x>  4};
 }
Workaround: auto foo(Range)(int n, Range r) { mixin Compr!q{x * n ; x<- arr, log(x), x*x> 4}; return compr; }
but auto foo(Range)(int n, Range r) { return mixin(compr!q{x * n ; x<- arr, log(x), x*x> 4}); } is clearly better.
Hey guys, the expression 'x<- arr' always means "is x less than negation of arr?" in D. Please choose another symbol.
Yes, unless it is tokenized in a different way (which is very feasible). Any suggestions? ∈ ?
Sep 01 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 01 Sep 2011 13:33:20 +0200, Timon Gehr <timon.gehr gmx.ch> wrote=
:

 On 09/01/2011 05:02 AM, kennytm wrote:
 Timon Gehr<timon.gehr gmx.ch>  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<timon.gehr gmx.ch> =
=
 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.
I know, that is why I have not implemented this yet. Basically it =
 should
 be possible to implicitly pass a whole scope to a template, or at  =
 least,
 to have local templates.

 Example:

 auto foo(Range)(int n, Range r) {
 return compr!q{x * n; x<- arr, log(x), x*x>  4};
 }
Workaround: auto foo(Range)(int n, Range r) { mixin Compr!q{x * n ; x<- arr, log(x), x*x> 4}; return compr; }
but auto foo(Range)(int n, Range r) { return mixin(compr!q{x * n ; x<- arr, log(x), x*x> 4}); } is clearly better.
Hey guys, the expression 'x<- arr' always means "is x less than negat=
ion
 of arr?" in D. Please choose another symbol.
Yes, unless it is tokenized in a different way (which is very feasible=
). =
 Any suggestions? =E2=88=88 ?
You should try to split condition and production rules from element = feeding. Sequence allows for any state = http://www.digitalmars.com/d/2.0/phobos/std_range.html#sequence and has a special symbol 'n'. This idea proved to be efficient as in binaryF= un. Comp!(q{2 * a + b}, q{a * b > 4})(range, range2) would offer the same = degree of freedom as do Haskell's list comprehensions. And even more important you restrict scope issues to only two functions,= = that can use usual predicates. P.S.: 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. martin
Sep 01 2011
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 01 Sep 2011 21:11:43 +0200, Martin Nowak <dawg dawgfoto.de> 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 Philippe Sigaud has created naryFun: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/functional.html -- Simen
Sep 01 2011
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 01 Sep 2011 01:21:12 +0200, Timon Gehr <timon.gehr gmx.ch> 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 possible to = massively abuse that to make things completely unreadable, but I like to believe programmers other than me are also capable of making some decisions on = their own. ;p I still really don't like the <-. Like Kenny=E2=84=A2 said, it already h= as a = defined meaning that would make (some) sense in that location. <=3D really is no= = better, and those are the two best squiggle combinations for this, I think. Perhaps <: or :=3D could be used. Those have no other meaning in D, and = kinda conveys what we want. Given a good IDE and keyboard, I'd love to use =E2= =88=88, but it's not really feasible.
 More importantly, IMO, is that the notation does not clearly
 mark what is what. is that interpreted (iota(10), log(x))
 or (log(x), x*x > 4)?
It actually does. The comma is a mere separator, and imho it looks ver=
y =
 clean.
D allows you to string expressions together using the comma operator. Wh= at = does this mean: [x; x <: iota(10), iota(9), true] Is that iota(10) to be simply discarded, or is the iota(9) of value as = something other than a range for x to take elements from?
 It is just like the set builder syntax you like. (it even has the curl=
y
 brackets!)
Well yes, I like that syntax. For D though, the square brackets indicate= array-like behavior, so I would like to use those. Lastly, I feel that a library solution is suboptimal for this, even if = 'mixin' were elidible. Compare: compr!q{2 * x; x <: iota(10), x*x > 4}; [2 * x; x <: iota(10); x*x > 4] -- = Simen
Sep 01 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Aug 29 2011
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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 a
 special syntax for it. The rationale for this is (rather than making it
 builtin) one can now build any type that is a restricted subset of
 another type. I suspect that a non-null type is just scratching the
 surface of this ability.

 Here's a draft prototype of the NotNull type:

 import std.c.stdio;

 struct NotNull(P) if (is(typeof({P p = null;})))
 {
 P p;

 this()  disable;

 this(P q)
 {
 assert(q);
 p = q;
 }

 NotNull opAssign(P q)
 {
 assert(q);
 p = q;
 return this;
 }

 alias p this;
 }

 void main()
 {
 int x;
 NotNull!(int*) s = &x;
 *s = 3;
 printf("test1 %d\n", *s);
 s++;
 printf("test2 %d\n", s[-1]);
 }

 What it does is:
 1. disallows instantiation with any type that null doesn't implicitly
 convert to
 2. disables default construction (this is the new feature)
 3. intercepts construction and assignment to enforce not-nullness
 4. uses alias this to forward the rest to the wrapped pointer type

 For example, try this:

 void main()
 {
 NotNull!(int*) s;
 // Error: variable test.main.s initializer required for type NotNull!(int*)
 }

 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 of default construction syntax and the
  disable, so in a sense it is just connecting existing dots, which has a
 compelling value.
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. Thanks! - Alex
Aug 30 2011
parent bearophile <bearophileHUGS lycos.com> writes:
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 if Walter will improve it a lot. Bye, bearophile
Aug 30 2011
prev sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
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 not an assert. That's because assert(someclass) does not check if someclass is non-null at all, it verifies its invariant instead! All the asserts should be assert(q !is null);.
Aug 30 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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(null); you'll get a segmentation fault and not an assert. That's because assert(someclass) does not check if someclass is non-null at all, it verifies its invariant instead! All the asserts should be assert(q !is null);.
Imho cast(bool)someclass should be changed to mean someclass !is null && someclass.__invariant() immediately, if that is even how Andrei and Walter expect it to work.
Aug 30 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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(null); you'll get a segmentation fault and not an assert. That's because assert(someclass) does not check if someclass is non-null at all, it verifies its invariant instead! All the asserts should be assert(q !is null);.
Is it really a bug? If you compile in release mode, and q is null, and you use !is null, you'll get a processor hardware halt. Halt or seg fault - there's not much practical difference. As I've said many times, I really don't understand the fear of seg faults. The important thing is that the program stop running as near as possible to the source of the error. Whether it stops because of a software detected error or a hardware detected error is simply not relevant.
Aug 30 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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!Object(null); you'll get a segmentation fault and not an assert. That's because assert(someclass) does not check if someclass is non-null at all, it verifies its invariant instead! All the asserts should be assert(q !is null);.
Is it really a bug? If you compile in release mode, and q is null, and you use !is null, you'll get a processor hardware halt. Halt or seg fault - there's not much practical difference.
You mean, in release mode the assert gets compiled out, and it seg faults in the code sequence that depends on the assertion, right?
 As I've said many times, I really don't understand the fear of seg
 faults. The important thing is that the program stop running as near as
 possible to the source of the error. Whether it stops because of a
 software detected error or a hardware detected error is simply not
 relevant.
I am not afraid of seg faults so much, but in debug mode it is certainly an annoyance, because you don't get the source line and stack trace. I'd say it would be really nice if assert(classreference); would never seg fault during debugging. Is there any practical use for manually running the class invariant?
Aug 30 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 mode it is certainly an
 annoyance, because you don't get the source line and stack trace. I'd say it
 would be really nice if assert(classreference); would never seg fault during
 debugging.
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. Andrei will reply that there are some environments where you cannot use a debugger, and he's right. But there are other workarounds for that - D doesn't *prevent* you from doing soft debugging.
 Is there any practical use for manually running the class invariant?
Looking for corruption of the data.
Aug 30 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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 afraid of seg faults so much, but in debug mode it is
 certainly an
 annoyance, because you don't get the source line and stack trace. I'd
 say it
 would be really nice if assert(classreference); would never seg fault
 during
 debugging.
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.
I don't usually run my programs in a debugger, and with a few assertions now and then this is practical. For me, a seg fault is always more of a productivity blocker than an AssertError.
 Andrei will reply that there are some environments where you cannot use
 a debugger, and he's right. But there are other workarounds for that - D
 doesn't *prevent* you from doing soft debugging.
It does prevent me from writing assert(classreference); for no apparent reason. :)
 Is there any practical use for manually running the class invariant?
Looking for corruption of the data.
Well, ok. But is there any reason why assert(classreference); should not be changed to assert(classreference !is null && classreference.__invariant()); ? Basically, all it does is making debugging more pleasant if you don't run a debugger, and save you some key strokes. (It is also more consistent, because assert(classreference&&1); will never segfault either.)
Aug 30 2011
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
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?
Aug 30 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 30 2011
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
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 does the null check for you, which is what a seg fault is.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :) Would you entertain a pull request with this fairly simple change?
Aug 30 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Because the hardware does the null check for you, which is what a seg fault is.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
 Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Aug 30 2011
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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.
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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
 Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Well, for those that would like it.. yebblies created a pull request with the appropriate changes: https://github.com/D-Programming-Language/dmd/pull/358 (I haven't tried it myself.) Later, Brad
Aug 30 2011
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Brad Roberts (braddr 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, 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
 Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Well, for those that would like it.. yebblies created a pull request with the
appropriate changes:
   https://github.com/D-Programming-Language/dmd/pull/358
 (I haven't tried it myself.)
 Later,
 Brad
You should be able to do it with less changes than that. :~) In GDC I settled with assert(e1 != null ? e1.invariant() : _d_assert(...)) I agree, it can be a bit of a nuance if code were to ICE in the runtime library and it takes away several minutes just to find that and pinpoint the source of the problems. Regards
Aug 31 2011
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wednesday, August 31, 2011 12:06:57 AM, Iain Buclaw wrote:
 == Quote from Brad Roberts (braddr 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, 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
 Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Well, for those that would like it.. yebblies created a pull request with the
approp
riate changes:
   https://github.com/D-Programming-Language/dmd/pull/358
 (I haven't tried it myself.)
 Later,
 Brad
You should be able to do it with less changes than that. :~) In GDC I settled with assert(e1 != null ? e1.invariant() : _d_assert(...)) I agree, it can be a bit of a nuance if code were to ICE in the runtime library and it takes away several minutes just to find that and pinpoint the source of the problems. Regards
I didn't look at the impl, just the existence. Please comment on the pull request.
Aug 31 2011
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> 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 with assert(e1 != null ? e1.invariant() : _d_assert(...))
dmd was using "e || __assert(msg)", so I used "auto tmp = e, tmp || __assert(msg), tmp.__invariant"
Aug 31 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 31 Aug 2011 01:35:51 -0400, Walter Bright  
<newshound2 digitalmars.com> 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 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
Seg faults are not as useful as asserts. It's a fact. If you have a seg fault, you must reproduce the error while in a debugger, or generate a core dump. Reproducing not be possible, or might take considerable time. Any argument against this is revisionist history. Yes, if I go back in time and run it in a debugger for that execution, it would be useful. Yes, if I go back in time and change my shell options to generate a core dump, it would be useful. If you have an assert, you get a stack trace, no need to reproduce the assert in a debugger, or enable non-default settings in your shell. It just gives you the information you need.
 Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Define "a lot"... Running a test: class C {} void foo(C c) { int x = 1; version(bloat) { if(c !is null) assert(c); } else { assert(c); } } diff bloat.asm nobloat.asm < mov -4[EBP],EAX < cmp dword ptr -4[EBP],0 < je L17 < mov EAX,-4[EBP] So 4 instructions per assert of a class reference (which is arguably not common) is a lot of bloat? And let's not forget that we are not in release mode here, the bloat does not affect release code. In other words, people are willing to have 4 extra instructions per function in order to avoid needless seg faults. You can actually *DO AWAY* with all this bloat by instead calling a global runtime assertObject function, which first checks that the object is not null, then calls object.__invariant. This is a similar approach that opEquals has. -Steve
Aug 31 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/11 6:46 AM, Steven Schveighoffer wrote:
 On Wed, 31 Aug 2011 01:35:51 -0400, Walter Bright
 <newshound2 digitalmars.com> 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 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
Seg faults are not as useful as asserts. It's a fact. If you have a seg fault, you must reproduce the error while in a debugger, or generate a core dump. Reproducing not be possible, or might take considerable time. Any argument against this is revisionist history. Yes, if I go back in time and run it in a debugger for that execution, it would be useful. Yes, if I go back in time and change my shell options to generate a core dump, it would be useful. If you have an assert, you get a stack trace, no need to reproduce the assert in a debugger, or enable non-default settings in your shell. It just gives you the information you need.
Good. I'm equally baffled by Walter's neglect of these fairly obvious arguments :o). Andrei
Aug 31 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 while in a debugger, or generate a core dump.
 Reproducing not be possible, or might take considerable time. Any argument
 against this is revisionist history. Yes, if I go back in time and run it in a
 debugger for that execution, it would be useful. Yes, if I go back in time and
 change my shell options to generate a core dump, it would be useful. If you
have
 an assert, you get a stack trace, no need to reproduce the assert in a
debugger,
 or enable non-default settings in your shell. It just gives you the information
 you need.
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. Optlink's register dump on a seg fault is not Windows' doing, it installs a seg fault handler which does this.
 So 4 instructions per assert of a class reference (which is arguably not 
common) is a lot of bloat? 15 bytes. And yes, this stuff adds up surprisingly quickly, especially if you're the type that wants to leave the asserts on even in release mode.
Aug 31 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 31 Aug 2011 16:02:56 -0400, Walter Bright  
<newshound2 digitalmars.com> 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 :-)
Not at all. If you prefer that mode of debugging, that's fine. But if I have 150 systems running a program I wrote, and one of them fails every week (random which one, and length of time), you'd better bet I'm going to prefer a stack trace to a seg fault. I don't want to wait another week + install debuggers on each of those systems. When I said Seg faults are not as useful as asserts, I meant *unplanned* seg faults. If you plan for a seg fault to occur, (or even an assert) you can use a debugger to capture it.
 If you have a seg fault,
 you must reproduce the error while in a debugger, or generate a core  
 dump.
 Reproducing not be possible, or might take considerable time. Any  
 argument
 against this is revisionist history. Yes, if I go back in time and run  
 it in a
 debugger for that execution, it would be useful. Yes, if I go back in  
 time and
 change my shell options to generate a core dump, it would be useful. If  
 you have
 an assert, you get a stack trace, no need to reproduce the assert in a  
 debugger,
 or enable non-default settings in your shell. It just gives you the  
 information
 you need.
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 have no idea why that wasn't included. Do you?
 Optlink's register dump on a seg fault is not Windows' doing, it  
 installs a seg fault handler which does this.
I predominantly use Linux, so Optlink/Windows tools really don't help. D is supposed to support all OSes not just be useful on Windows. On linux, the shell options are what determine whether the OS generates a core dump, and by default they are off. It also does not hook seg faults to start a debugger by default, it just says "Segmentation Fault" on the command line and gives you a prompt. Useless.
  > So 4 instructions per assert of a class reference (which is arguably  
 not common) is a lot of bloat?

 15 bytes. And yes, this stuff adds up surprisingly quickly, especially  
 if you're the type that wants to leave the asserts on even in release  
 mode.
How is this possible? I thought release mode removed asserts? 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. Besides, you ignored my comment about how we can eliminate the bloat. Care to respond? -Steve
Aug 31 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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 have no idea why that wasn't included. Do you?
It's not easy to catch SIGSEGV on linux, there's a library that'll do it but it's GPL (iirc), an equivalent would need writing from scratch if it were to be included in druntime/phobos. -- Robert http://octarineparrot.com/
Aug 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 31 Aug 2011 16:40:02 -0400, Robert Clipsham  
<robert octarineparrot.com> 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 that did this a while back.
This would also be a valid option. I have no idea why that wasn't included. Do you?
It's not easy to catch SIGSEGV on linux, there's a library that'll do it but it's GPL (iirc), an equivalent would need writing from scratch if it were to be included in druntime/phobos.
You can catch sigsegv on linux. It takes one call to signal to register a handler. The difficult part is unwinding the stack. You can't throw an exception from a signal handler (or reliably do it anyways). Also, the stack may be in some other language (e.g. C). But I do remember the patch and discussion, I thought all these problems were solved, no? Why wasn't this adopted? -Steve
Aug 31 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
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://octarineparrot.com/
Aug 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 31 Aug 2011 17:20:04 -0400, Robert Clipsham  
<robert octarineparrot.com> 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 library: http://libsigsegv.sourceforge.net/
I think that may be a way to override the OS's page fault handling. Here's how a page fault (which is *NOT* a segmentation fault necessarily) works (this might be really badly described, it's been a while since I had to know this): The cpu requests a certain memory address. If the memory isn't in the CPU's cache, it requests the page from the MMU (memory management unit). If the page isn't in memory, it triggers an interrupt to the OS for a page fault. If the OS sees the page is cached on disk in the swap file, it loads the page from disk, and then gets it from the MMU. If the page is not on disk, then the process is sent the SIGSEGV signal. Maybe the library hooks the signal to do it's own retrieval of memory from some other cache. No clue. But this program works swimmingly: import core.stdc.signal; import std.stdio; extern(C) void sigsegvhandler(int sig) { writeln("in signal handler!"); assert(0); } void main() { signal(SIGSEGV, &sigsegvhandler); int * i; *i = 5; } output: in signal handler! core.exception.AssertError testsignal(7): Assertion failure ---------------- ./testsignal(onAssertError+0x2e) [0x8086b9e] ./testsignal(_d_assertm+0x16) [0x80844b6] ./testsignal() [0x8081e96] ./testsignal(sigsegvhandler+0x1e) [0x8081de2] [0x8bf400] ./testsignal(_D2rt6dmain24mainUiPPaZi7runMainMFZv+0x1a) [0x808495e] ./testsignal(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80845f8] ./testsignal(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x32) [0x80849a2] ./testsignal(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x20) [0x80845f8] ./testsignal(main+0x94) [0x80845a4] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0xa79e37] ./testsignal() [0x8081d11] ---------------- -Steve
Aug 31 2011
parent "Eric Poggel (JoeCoder)" <dnewsgroup2 yage3d.net> writes:
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?
Aug 31 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 have no idea why that wasn't included. Do you?
Nobody spent the time to do it, mainly because it takes a fairly advanced low level Windows programmer to understand and do it correctly.
 Optlink's register dump on a seg fault is not Windows' doing, it installs a
 seg fault handler which does this.
I predominantly use Linux, so Optlink/Windows tools really don't help. D is supposed to support all OSes not just be useful on Windows.
Sure. It's just that since debuggers work on Linux, there should be no technical reason why this cannot be made to work. Of course it will be very different code than for Windows, but the user wouldn't see that.
 On linux, the shell options are what determine whether the OS generates a core
 dump, and by default they are off. It also does not hook seg faults to start a
 debugger by default, it just says "Segmentation Fault" on the command line and
 gives you a prompt. Useless.

 So 4 instructions per assert of a class reference (which is arguably not
common) is a lot of bloat? 15 bytes. And yes, this stuff adds up surprisingly quickly, especially if you're the type that wants to leave the asserts on even in release mode.
How is this possible? I thought release mode removed asserts?
I misspoke. -release does remove the asserts, but some developers do not use -release because they wish to leave the asserts on in their release builds.
 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.
You'd be surprised. I was surprised to discover that all the asserts in std.datetime caused the unittest build of phobos to exceed all available memory on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more runtime memory, he's got like 7500 in there.) Minimizing the footprint of assert's reduces the resistance people have to using them. Bloat can get to be a big problem if you're using templates, the templates contain asserts, and those templates get inlined. People have regularly complained about the size of D binaries.
 Besides, you ignored my comment about how we can eliminate the bloat. Care to
 respond?
I haven't thought about it.
Aug 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright  
<newshound2 digitalmars.com> 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 that did this a while back.
This would also be a valid option. I have no idea why that wasn't included. Do you?
Nobody spent the time to do it, mainly because it takes a fairly advanced low level Windows programmer to understand and do it correctly.
You said there was a patch...? Was it not complete?
 Optlink's register dump on a seg fault is not Windows' doing, it  
 installs a
 seg fault handler which does this.
I predominantly use Linux, so Optlink/Windows tools really don't help. D is supposed to support all OSes not just be useful on Windows.
Sure. It's just that since debuggers work on Linux, there should be no technical reason why this cannot be made to work. Of course it will be very different code than for Windows, but the user wouldn't see that.
Again, starting a debugger because you *know* an assert/segfault is about to occur is vastly different than diagnosing an *unexpected* assert in the field or on a machine that has no debugger. Not all seg faults occur in tightly controlled scenarios. Please stop suggesting debuggers are the only tool we should be using, it's just not always possible in the real world. Otherwise, why have logging, stack traces, etc.
 So 4 instructions per assert of a class reference (which is arguably  
not common) is a lot of bloat? 15 bytes. And yes, this stuff adds up surprisingly quickly, especially if you're the type that wants to leave the asserts on even in release mode.
How is this possible? I thought release mode removed asserts?
I misspoke. -release does remove the asserts, but some developers do not use -release because they wish to leave the asserts on in their release builds.
And that leaves in all bounds checking and every method call on any object calls the invariant (whether the derived object defines an invariant or not) without inlining. Let me know who these people are so I never use their products! There are much better tools for this, e.g. enforce.
 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.
You'd be surprised. I was surprised to discover that all the asserts in std.datetime caused the unittest build of phobos to exceed all available memory on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more runtime memory, he's got like 7500 in there.) Minimizing the footprint of assert's reduces the resistance people have to using them.
I think that: 1. this is likely a combination of code generation issues in dmd and proliferation of asserts with templates/inlining as you say (I still feel there is something wrong with dmd, but I have no evidence). 2. Are more than 10% of those 7500 asserts of object references? I'd be surprised if that were true.
 Bloat can get to be a big problem if you're using templates, the  
 templates contain asserts, and those templates get inlined.

 People have regularly complained about the size of D binaries.
Bloat is something to be combated, yes. I am still of the school of thought that smaller exes are much better than bloatier ones, even when we have oodles of memory at our disposal. But we are talking about *debug* builds. I don't think your "people like to ship code compiled in non-release mode" argument holds water like a strainer. And I think people *expect* bloat when they enable debugging information. 15 extra bytes per assert is nothing. writeln adds 500k of "bloat". Do people who use console output debugging (a.k.a. printf debugging) complain about bloat because they added in writeln? I know I don't, and that's my main form of debugging. -Steve
Aug 31 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, August 31, 2011 14:18 Steven Schveighoffer wrote:
 On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
 <newshound2 digitalmars.com> 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 that all the asserts in std.datetime caused the unittest build of phobos to exceed all available memory on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more runtime memory, he's got like 7500 in there.) Minimizing the footprint of assert's reduces the resistance people have to using them.
I think that: 1. this is likely a combination of code generation issues in dmd and proliferation of asserts with templates/inlining as you say (I still feel there is something wrong with dmd, but I have no evidence). 2. Are more than 10% of those 7500 asserts of object references? I'd be surprised if that were true.
I don't think that there's even one assert on an object reference in there (if nothing else, there are very few classes in std.datetime), and none of them have invariants (some of the structs do but the few classes have very little state). The issue with std.datetime is almost certainly related to the number of templates (including _assertPred, which is definitely templatized). Given the general proliferation of templates in D (and Phobos in particular), dmd definitely needs to be efficient when it comes to compiling templates, and that doesn't generally seem to be the case with regards to memory consumption. That does remind me though that I need to get back to cleaning up std.datetime's unit tests soon. - Jonathan M Davis
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
 <newshound2 digitalmars.com>  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 that all the asserts in std.datetime caused the unittest build of phobos to exceed all available memory on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more runtime memory, he's got like 7500 in there.) Minimizing the footprint of assert's reduces the resistance people have to using them.
I think that: 1. this is likely a combination of code generation issues in dmd and proliferation of asserts with templates/inlining as you say (I still feel there is something wrong with dmd, but I have no evidence). 2. Are more than 10% of those 7500 asserts of object references? I'd be surprised if that were true.
I don't think that there's even one assert on an object reference in there (if nothing else, there are very few classes in std.datetime), and none of them have invariants (some of the structs do but the few classes have very little state). The issue with std.datetime is almost certainly related to the number of templates (including _assertPred, which is definitely templatized). Given the general proliferation of templates in D (and Phobos in particular), dmd definitely needs to be efficient when it comes to compiling templates, and that doesn't generally seem to be the case with regards to memory consumption.
Probably that is because dmd leaks most memory it allocates. I seem to recall that is because of some bugs with interplay of the GC, which were resolved by just turning off the GC. What bugs were those? I consider this an important issue, because I often cause the OS to swap heavily when compiling my Metaprogramming heavy code on my 2GB Ram machine, and I get one or two complete meltdowns each week.
Aug 31 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
 
 <newshound2 digitalmars.com> 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 that all the asserts in std.datetime caused the unittest build of phobos to exceed all available memory on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more runtime memory, he's got like 7500 in there.) Minimizing the footprint of assert's reduces the resistance people have to using them.
I think that: 1. this is likely a combination of code generation issues in dmd and proliferation of asserts with templates/inlining as you say (I still feel there is something wrong with dmd, but I have no evidence). 2. Are more than 10% of those 7500 asserts of object references? I'd be surprised if that were true.
I don't think that there's even one assert on an object reference in there (if nothing else, there are very few classes in std.datetime), and none of them have invariants (some of the structs do but the few classes have very little state). The issue with std.datetime is almost certainly related to the number of templates (including _assertPred, which is definitely templatized). Given the general proliferation of templates in D (and Phobos in particular), dmd definitely needs to be efficient when it comes to compiling templates, and that doesn't generally seem to be the case with regards to memory consumption.
Probably that is because dmd leaks most memory it allocates. I seem to recall that is because of some bugs with interplay of the GC, which were resolved by just turning off the GC. What bugs were those? I consider this an important issue, because I often cause the OS to swap heavily when compiling my Metaprogramming heavy code on my 2GB Ram machine, and I get one or two complete meltdowns each week.
LOL. The std.datetime unit tests have been disabled in Windows for some time now, because dmd ran out of memory compiling them. I think that it might be okay now, since the Windows makefile seems to have been changed so that modules are compiled and tested in blocks instead of just using one file, and various improvements have been made to CTFE and the like of late which should reduced memory consumption, but this is definitely a problem. 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 know if templates have the same problem or not. There are several bugs which have been reported on issues with dmd running out of memory. It doesn't appear to be a high priority issue though, since it hasn't been fixed yet. I do think that there were some recent improvements to it though (for instance, it used to be insanely easy to get startsWith to cause the compiler to run out of memory - since it's a recursive template - but that was supposedly fixed with the last release). - Jonathan M Davis
Aug 31 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2616.1314834798.14074.digitalmars-d 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 know if templates have the same problem or not.
The dmd frontend basically almost never frees any memory. Running semantic generally involves duplicating the entire expression tree.
 There are several bugs
 which have been reported on issues with dmd running out of memory. It 
 doesn't
 appear to be a high priority issue though, since it hasn't been fixed yet. 
 I
 do think that there were some recent improvements to it though (for 
 instance,
 it used to be insanely easy to get startsWith to cause the compiler to run 
 out
 of memory - since it's a recursive template - but that was supposedly 
 fixed
 with the last release).
This one was fixed, but not by improving memory management in dmd. There was a bug that caused templates without type specializations to be instantiated more than once, and this coupled with a recursive constraint caused something like n! templates to be instantiated (and allocated).
Aug 31 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 also need to keep in account where the bloat is. If the bloat means functions that never get called and are physically collocated far from the hot function, then this bloat is not hurting much. If your bloat is instead spread inside hot function and close enough to their hot paths, this bloat will cause problems, and slowdown of the program. Bye, bearophile
Aug 31 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 01 Sep 2011 00:18:16 -0400, bearophile <bearophileHUGS lycos.com>  
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.
Bytes are not enough to measure "bloat". You also need to keep in account where the bloat is. If the bloat means functions that never get called and are physically collocated far from the hot function, then this bloat is not hurting much. If your bloat is instead spread inside hot function and close enough to their hot paths, this bloat will cause problems, and slowdown of the program.
Yeah but, this is in non-release mode. Performance is not as important as finding bugs. -Steve
Sep 01 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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 with 'b _d_assert'? (for gdb at least) You still get back traces, the ability to inspect variables etc. -- Robert http://octarineparrot.com/
Aug 31 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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 I can use a debugger on it :-)
What's wrong with 'b _d_assert'? (for gdb at least)
Nothing. Just more than one way to do things.
Aug 31 2011
prev sibling next sibling parent reply kennytm <kennytm gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> 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 number and stack
 trace. There was a patch to Phobos that did this a while back.
 
 Optlink's register dump on a seg fault is not Windows' doing, it installs
 a seg fault handler which does this.
Please stop caring only about Windows. In Mac OS X because of the broken dSYM and the ancient gdb (having no D support) supplied by Xcode, it's almost impossible to get any valuable information - in particular the __FILE__ and __LINE__ - from the debugger.
 15 bytes. And yes, this stuff adds up surprisingly quickly, especially if
 you're the type that wants to leave the asserts on even in release mode.
Then you should just kill D's RTTI, the TypeInfos from the unused template instances pile up at a much faster rate. 15 bytes mean nothing then the executable size is already in megabytes. Also, the proposal only affects asserts of the form assert(classObj); all other asserts won't have those extra 15 bytes. I believe you're strongly exaggerating, and I'd challenge you to compile Phobos with and without the patch and compare if the size is really bloated a lot.
Aug 31 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"kennytm" <kennytm gmail.com> wrote in message
 Also, the proposal only affects
 asserts of the form

    assert(classObj);
And assert(ptrToStructWithInvariant);
Aug 31 2011
prev sibling next sibling parent reply travert phare.normalesup.org (Christophe) writes:
Maybe think assert should not be rewritten, but opCast!(bool) should 
test if the class reference is null, which would be consistent with 
opEquals
Aug 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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 assert(classref); is special cased to segfault on invalid class references.
Aug 31 2011
parent travert phare.normalesup.org (Christophe) writes:
OK, so basically there is a confusing special case just to save few bits 
on debug programs...
Sep 01 2011
prev sibling parent David Nadlinger <see klickverbot.at> writes:
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 have your reasons, because, well, you are Walter Bright, but wouldn't this rather be a testament of the inadequacy of the assert() implementation than an argument for – well, what is it exactly you are proposing? Using an assert solely for the segfault it causes as a side effect while the condition is evaluated? All C++ implementations of assert() I have encountered so far provide a way of breaking on failing assertions if the program is being debugged: MSVC-compiled binaries display the »Abort/Retry/Ignore« dialog, and on Posix systems, the SIGABRT raised by abort() is usually caught by the debugger, causing it to break. Have you considered following a similar approach for D? This could be implemented via a custom assert handler, but setAssertHandler has been deprecated in druntime commit fbbd2a7 (the commit message unfortunately doesn't mention a reason, IIRC because DMD doesn't generate a normal stack). David
Aug 31 2011
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
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
{
  invariant() {}
}

class A
{
  void fun(X x)
  in
  {
    assert(x);
  }
  body
  {
  }
}

class B : A
{
  void fun(X x)
  in
  {
  }
  body
  {
  }
}

void main()
{
  auto b = new B();
  b.fun(null);
}
Aug 31 2011
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
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% of users expect of it. One question which I don't think has been raised yet is: Why the inconsistency with assert(pointer), which always tests for null? I fear that when D gets broader adoption and people start writing down coding conventions, every one of them will have an item saying "Do NOT use assert(classref), use assert(classref !is null && classref) instead". -Lars
Sep 01 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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:

 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
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% of users expect of it. One question which I don't think has been raised yet is: Why the inconsistency with assert(pointer), which always tests for null? I fear that when D gets broader adoption and people start writing down coding conventions, every one of them will have an item saying "Do NOT use assert(classref), use assert(classref !is null&& classref) instead". -Lars
Actually, to test both for non-null and the invariant, it would have to read version(release){}else{if(classref) assert(classref);else assert(0);} or similar. cast(bool)classref will not check the invariant. To check just for null, assert(classref&&1); is the most concise variant.
Sep 01 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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:

 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
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% of users expect of it.
I think 99.9% would be an underestimation. Who'd be part of the 0.1%? Andrei
Sep 01 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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: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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
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% of users expect of it.
I think 99.9% would be an underestimation. Who'd be part of the 0.1%?
Someone's big toe agrees with him? ;) Personally, I think that the fact that asserting on a class calls the invariant instead of checking for null is incredibly surprising. It's potentially useful, but it's one of those things that I think suprises pretty much everyone when they first find out. So, having it test for null and _then_ test for the invariant instead of just testing the invariant just makes good sense. And since this debate only seems to be about when people assert on a reference (which can't be all _that_ common honestly - _especially_ if people actually expect it to call the invariant instead of checking for null; that should already be verified just by calling its functions) rather than something like every time that a reference is used, I don't see how Walter has a foot to stand on in this case. Now, if we were debating whether we were going to introduce a general check for null similar to what Java does to get its NullPointerExceptions, _then_ I could see a definite debate. But just for assertions on object references? I just don't see it. - Jonathan M Davis
Sep 01 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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 without calling member functions on it comes in handy.
Sep 01 2011
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 01 Sep 2011 16:40:13 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> 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:

 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.
The frequency with which this comes up and the lack of converts to that point of view ought to tell you something here. :)
I am simply baffled by it.
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% of users expect of it.
I think 99.9% would be an underestimation. Who'd be part of the 0.1%? Andrei
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 exceptions but always a core dump. martin
Sep 01 2011
parent reply David Nadlinger <see klickverbot.at> writes:
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 exceptions
 but always a core dump.
This behavior could also be enabled by providing a way to provide a custom trace handler. By default, an AssertError would be thrown (or whatever deemed appropriate), but druntime could include an implementation which does the OS-specific things to invoke a debugger/cause it to break. I don't know the details about the aforementioned assertion call stack »issue« though (druntime's setTraceHandler is currently disabled because of it) – Walter, Sean, et al., could you comment on whether a trace handler like described above would be feasible? David
Sep 01 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ouch, I've found a naughty bug:

---------------------------
dmd.exe - Application Error
---------------------------
The instruction at "0x0040235d" referenced memory at "0x00000000". The
memory could not be "written".

Code:
void main()
{
    Foo foo;
}

struct Foos
{
     disable this();
}

Notice I've accidentally named my struct "Foos" instead of "Foo". The
console does output the error message:
"Error: undefined identifier Foo, did you mean struct Foos?"

But DMD crashing can't be good. Built from commit
34f2b4ddfafcea4d561e3c1ac8318db79f713638
Sep 01 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Err, DMD crashes on every error, even this:

int z = "bla";

I guess a due to a bad commit?
Sep 01 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 01 2011
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.2630.1314899211.14074.digitalmars-d 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.
Sep 01 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 01 Sep 2011 14:27:36 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.2630.1314899211.14074.digitalmars-d 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.
Yesterday in defense of using segfaults instead of asserts: 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 :) -Steve
Sep 01 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2011 11:33 AM, Steven Schveighoffer wrote:
 On Thu, 01 Sep 2011 14:27:36 -0400, Daniel Murphy <yebblies nospamgmail.com>
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 often use: *(char*)0=0; in C++ code :-) Very handy.
Sep 01 2011
parent David Nadlinger <see klickverbot.at> writes:
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 trap [-Wnull-dereference] *(char*)0=0; ^~~~~~~~~ test.cpp:2:5: note: consider using __builtin_trap() or qualifying pointer with 'volatile' 1 warning generated. ——— David
Sep 01 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
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% of users expect
 of it.
I think 99.9% would be an underestimation. Who'd be part of the 0.1%? Andrei
Depending on how many we are in the community, only Walter :) -- /Jacob Carlborg
Sep 01 2011
prev sibling next sibling parent reply "Eric Poggel (JoeCoder)" <dnewsgroup2 yage3d.net> writes:
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 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 my program at all. That was the main reason I switched to Tango, since it always prints a stack trace on any error--greatly improved my productivity. But D2 is looking very sweet and I want to switch.
Aug 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
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 my program at all.

 That was the main reason I switched to Tango, since it always prints a stack
 trace on any error--greatly improved my productivity. But D2 is looking very
 sweet and I want to switch.
\dmd\windows\bin\windbg.exe
Aug 30 2011
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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 afraid of seg faults so much, but in debug mode it is
 certainly an
 annoyance, because you don't get the source line and stack trace. I'd
 say it
 would be really nice if assert(classreference); would never seg fault
 during
 debugging.
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. Andrei will reply that there are some environments where you cannot use a debugger, and he's right. But there are other workarounds for that - D doesn't *prevent* you from doing soft debugging.
 Is there any practical use for manually running the class invariant?
Looking for corruption of the data.
You loose time by having to run it under the debugger. If it just showed you the line of the null pointer it would be much faster to develop.
Aug 31 2011
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
It's worth mentioning that for some reason, Solaris doesn't protect the enti=
re first page of memory--only the zero address. For accesses the where the c=
ompiler pre-computes the offset and reads that location directly, you won't g=
et a segfault if the pointer is null (at least with GCC--haven't tested with=
 Sun's compiler). This makes no sense to me and it's been the source of a to=
n of problems in C apps I've found. I'm just mentioning this because it's ma=
de me leery of relying on the hardware to flag null accesses.=20

Sent from my iPhone

On Aug 30, 2011, at 4:19 PM, Walter Bright <newshound2 digitalmars.com> wrot=
e:

 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?
=20 Yes. Any dereference of a null class ref would cause a seg fault. =20
 I am not afraid of seg faults so much, but in debug mode it is certainly a=
n
 annoyance, because you don't get the source line and stack trace. I'd say=
it
 would be really nice if assert(classreference); would never seg fault dur=
ing
 debugging.
=20 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% o= f what a debugger is good for.
=20
 Andrei will reply that there are some environments where you cannot use a d=
ebugger, and he's right. But there are other workarounds for that - D doesn'= t *prevent* you from doing soft debugging.
=20
=20
 Is there any practical use for manually running the class invariant?
=20 Looking for corruption of the data. =20
Aug 31 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 is null (at least with GCC--haven't
 tested with Sun's compiler). This makes no sense to me and it's been the
 source of a ton of problems in C apps I've found. I'm just mentioning this
 because it's made me leery of relying on the hardware to flag null accesses.
Solaris is dead anyway :-) Also, the virtual function table pointer is at offset 0 in the class object, and that is the most likely one to be referenced. And lastly, different code could be generated for Solaris targets.
Aug 31 2011
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Walter Bright (newshound2 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 offset and reads that location directly, you
 won't get a segfault if the pointer is null (at least with GCC--haven't
 tested with Sun's compiler). This makes no sense to me and it's been the
 source of a ton of problems in C apps I've found. I'm just mentioning this
 because it's made me leery of relying on the hardware to flag null accesses.
Solaris is dead anyway :-)
Long live openIndiana! :)
Aug 31 2011