On Monday, 5 March 2012 at 04:39:59 UTC, Adam D. Ruppe wrote:
Huh, I thought there was one in phobos by now.
You could spin your own with something like this:
struct NotNull(T) {
T t;
alias t this;
@disable this();
@disable this(typeof(null));
this(T value) {
assert(value !is
On Tuesday, 6 March 2012 at 00:01:20 UTC, Jason House wrote:
The opAssign kills all type safety. I think only NotNull!T
should be accepted... So foo = bar won't compile if bar is
nullable. To fix, foo = NotNull(bar),
In both cases, the assert(x !is null), whether in
opAssign or in the
Jason House:
The opAssign kills all type safety. I think only NotNull!T should
be accepted... So foo = bar won't compile if bar is nullable.
To fix, foo = NotNull(bar),
I think NotNull also needs this, as a workaround to what I think is a DMD bug:
@disable enum init = 0;
It disallows
Adam D. Ruppe:
I've trained myself to use assert (or functions with assert
in out contracts/invariants) a lot to counter these.
I think contracts are better left to higher level ideas. The simple not-null
contracts you are adding are better left to a type system that manages a
succinct
On 2012-03-05 22:31:34 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
newshou...@digitalmars.com wrote:
I don't get this at all. I find it trivial to run the program with a debugger:
gdb foo
run
that's it.
This argument
On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
michel.for...@michelf.com wrote:
That said, throwing an exception might not be a better response all the
time. On my operating system (Mac OS X) when a program crashes I get a
nice crash log with the date, a stack trace for each thread
On Monday, March 05, 2012 21:04:20 Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
michel.for...@michelf.com wrote:
That said, throwing an exception might not be a better response all the
time. On my operating system (Mac OS X) when a program crashes I get a
On Mon, 05 Mar 2012 23:31:34 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 3/4/2012 11:50 PM, Chad J wrote:
Problems:
- I have to rerun the program in a debugger to see the stack trace.
This
On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
There are two independent discussions being conflated here. One about
getting more
information out of crashes even in release mode and the other about
adding runtime checks to prevent crashing merely in debug builds.
A segfault should
On 03/05/2012 11:27 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
There are two independent discussions being conflated here. One about
getting more
information out of crashes even in release mode and the other about
adding runtime checks to prevent
On Monday, March 05, 2012 23:58:48 Chad J wrote:
On 03/05/2012 11:27 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
There are two independent discussions being conflated here. One about
getting more
information out of crashes even in release mode and
On 03/06/2012 12:07 AM, Jonathan M Davis wrote:
If you dereference a null pointer, there is a serious bug in your program.
Continuing is unwise. And if it actually goes so far as to be a segfault
(since the hardware caught it rather than the program), it is beyond a doubt
unsafe to continue. On
On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
It's defined. The operating system protects you. You get a
segfault on *nix and
an access violation on Windows. Walter's take on it is that
there is no point
in checking for what the operating system is already checking
for -
On Tuesday, March 06, 2012 07:16:52 Nathan M. Swan wrote:
On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
It's defined. The operating system protects you. You get a
segfault on *nix and
an access violation on Windows. Walter's take on it is that
there is no point
in
On Tuesday, 6 March 2012 at 06:27:31 UTC, Jonathan M Davis wrote:
scope(failure) is _not_ guaranteed to always execute on
failure. It is _only_
guaranteed to run when an Exception is thrown. Any other
Throwable - Errors
included - skip all finally blocks, scope statements, and
destructors.
On 2012-03-06 02:17, Michel Fortin wrote:
On 2012-03-05 22:31:34 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
newshou...@digitalmars.com wrote:
I don't get this at all. I find it trivial to run the program with a
debugger:
gdb foo
On 2012-03-06 03:04, Steven Schveighoffer wrote:
Certainly for Mac OS X, it should do the most informative appropriate
thing for the OS it's running on. Does the above happen for D programs
currently on Mac OS X?
When an exception if thrown and uncaught it will print the stack trace
to in the
On 2012-03-06 08:53, Jacob Carlborg wrote:
On 2012-03-06 03:04, Steven Schveighoffer wrote:
Certainly for Mac OS X, it should do the most informative appropriate
thing for the OS it's running on. Does the above happen for D programs
currently on Mac OS X?
When an exception if thrown and
On Saturday, 3 March 2012 at 02:51:41 UTC, Walter Bright wrote:
Adding in software checks for null pointers will dramatically
slow things down.
What about the debug/release difference? Isn't the point of debug
mode to allow checks such as assert, RangeError, etc?
Segmentation fault: 11
On 03/03/2012 02:06 PM, Walter Bright wrote:
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow
things
down.
Define this use of dramatically in a more quantitative and objective
way,
please. Is Java dramatically slower than
On Monday, 5 March 2012 at 02:32:12 UTC, Chad J wrote:
I hate hate HATE vague error messages that don't help me.
In a lot of cases, getting more info is very, very easy:
$ dmd -g -debug test9
$ ./test9
Segmentation fault
$ gdb ./test9
GNU gdb (GDB) 7.1
[...]
(gdb) r
Starting program:
On Mon, Mar 05, 2012 at 03:43:15AM +0100, Adam D. Ruppe wrote:
[...]
There's two cases where null annoys me though:
1) if it is stored somewhere where it isn't supposed to be.
Then, the location of the dereference doesn't help - the
question is how it got there in the first place.
And
On 03/04/2012 09:43 PM, Adam D. Ruppe wrote:
On Monday, 5 March 2012 at 02:32:12 UTC, Chad J wrote:
I hate hate HATE vague error messages that don't help me.
In a lot of cases, getting more info is very, very easy:
$ dmd -g -debug test9
$ ./test9
Segmentation fault
$ gdb ./test9
GNU gdb
On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
News to me. I've had bad runs with that back in the day, but
maybe things have improved a bit.
Strangely, I've never had a problem with gdb and D,
as far back as 2007.
(at least for the basic stack trace kind of stuff).
But, yeah,
On 03/04/2012 11:39 PM, Adam D. Ruppe wrote:
On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
News to me. I've had bad runs with that back in the day, but maybe
things have improved a bit.
Strangely, I've never had a problem with gdb and D,
as far back as 2007.
(at least for the basic
On 3/4/2012 6:31 PM, Chad J wrote:
class Bar
{
int foo;
}
void main()
{
Bar bar;
try {
bar.foo = 5;
} catch ( Exception e ) {
writefln(%s,e);
}
}
DMD 2.057 on Gentoo Linux, compiled with -g -debug. It prints this:
Segmentation fault
Very frustrating!
This is what I get (I added in an import
On Sunday, March 04, 2012 21:31:21 Chad J wrote:
On 03/03/2012 02:06 PM, Walter Bright wrote:
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow
things
down.
Define this use of dramatically in a more quantitative and
On 03/05/2012 01:25 AM, Walter Bright wrote:
On 3/4/2012 6:31 PM, Chad J wrote:
class Bar
{
int foo;
}
void main()
{
Bar bar;
try {
bar.foo = 5;
} catch ( Exception e ) {
writefln(%s,e);
}
}
DMD 2.057 on Gentoo Linux, compiled with -g -debug. It prints this:
Segmentation fault
Very
Walter:
Adding in software checks for null pointers will dramatically slow things
down.
Define this use of dramatically in a more quantitative and objective way,
please. Is Java dramatically slower than C++/D here?
Bye,
bearophile
On Saturday, 3 March 2012 at 10:13:34 UTC, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically
slow things down.
Define this use of dramatically in a more quantitative and
objective way, please. Is Java dramatically slower than C++/D
here?
Bye,
On 3 March 2012 23:13, bearophile bearophileh...@lycos.com wrote:
Walter:
Adding in software checks for null pointers will dramatically slow things
down.
Define this use of dramatically in a more quantitative and objective way,
please. Is Java dramatically slower than C++/D here?
Bye,
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow things
down.
Define this use of dramatically in a more quantitative and objective way,
please. Is Java dramatically slower than C++/D here?
You can try it for yourself. Take
Le 03/03/2012 20:06, Walter Bright a écrit :
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow
things
down.
Define this use of dramatically in a more quantitative and objective
way,
please. Is Java dramatically slower than
On 03/03/2012 09:00 PM, deadalnix wrote:
Le 03/03/2012 20:06, Walter Bright a écrit :
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow
things
down.
Define this use of dramatically in a more quantitative and objective
way,
I would recommend doing what Microsoft does in this case, use SEH
(Structured exception handling) on windows i.e. use OS facilities
to trap and convert hardware exceptions into software exceptions.
See the /EHa flag in the Microsoft C++ compiler.
I hope Linux has something similar, then we are
On 3/3/2012 12:29 PM, Sandeep Datta wrote:
I would recommend doing what Microsoft does in this case, use SEH
(Structured exception handling) on windows i.e. use OS facilities
to trap and convert hardware exceptions into software exceptions.
D for Windows already does that.
It's been there for
On Saturday, 3 March 2012 at 22:24:59 UTC, Walter Bright wrote:
On 3/3/2012 12:29 PM, Sandeep Datta wrote:
I would recommend doing what Microsoft does in this case, use
SEH (Structured exception handling) on windows i.e. use OS
facilities to trap and convert hardware exceptions into
software
It's been there for 10 years, and turns out to be a solution
looking for a problem.
I beg to differ, the ability to catch and respond to such
asynchronous exceptions is vital to the stable operation of long
running software.
It is not hard to see how this can be useful in programs which
On Sunday, 4 March 2012 at 02:53:54 UTC, Sandeep Datta wrote:
Thus the inability of handling such exceptions undermines D's
ability to support dynamically loaded modules of any kind and
greatly impairs modularity.
You can catch it in D (on Windows):
import std.stdio;
void main() {
You can catch it in D (on Windows):
This is great. All we have to do now is provide a more specific
exception (say NullReferenceException) so that the programmer has
the ability to provide a specific exception handler for
NullReferenceException etc.
I gave it a try on Linux but
On Sunday, 4 March 2012 at 03:15:19 UTC, Sandeep Datta wrote:
All we have to do now is provide a more specific exception (say
NullReferenceException) so that the programmer has the ability
to provide a specific exception handler for
NullReferenceException etc.
Looks like it is pretty easy to
On 3/3/2012 6:53 PM, Sandeep Datta wrote:
It's been there for 10 years, and turns out to be a solution looking for a
problem.
I beg to differ, the ability to catch and respond to such asynchronous
exceptions is vital to the stable operation of long running software.
It is not hard to see how
On Sun, Mar 04, 2012 at 04:29:27AM +0100, Adam D. Ruppe wrote:
On Sunday, 4 March 2012 at 03:15:19 UTC, Sandeep Datta wrote:
All we have to do now is provide a more specific exception (say
NullReferenceException) so that the programmer has the ability to
provide a specific exception handler
On Sat, Mar 03, 2012 at 07:34:50PM -0800, Walter Bright wrote:
[...]
3. Intercepting and recovering from seg faults, div by 0, etc., all
sounds great on paper. In practice, it is almost always wrong. The
only exception (!) to the rule is when sandboxing a plugin (as you
suggested). Making such
On 3/3/2012 8:20 PM, H. S. Teoh wrote:
Don't know how this would work on Windows, but presumably there are
clean ways of doing it that doesn't endanger the health of the process
creating the sandbox.
If you're dealing with plugins from an unknown source, it's a good design to
separate plugins
On Sun, 04 Mar 2012 03:53:53 +0100, Sandeep Datta
datta.sand...@gmail.com wrote:
It's been there for 10 years, and turns out to be a solution looking
for a problem.
I beg to differ, the ability to catch and respond to such asynchronous
exceptions is vital to the stable operation of long
A misbehaving plugin could easily corrupt your process.
Destroying data
is always much worse than crashing.
At this point I usually say memory corruption is not an option
for type safe languages but D doesn't really provide runtime type
safety guarantees, or does it?
I think in the future
1. SEH isn't portable. There's no way to make it work under
non-Windows systems.
Ok after some digging around it appears (prima facie) that Linux
doesn't have anything close to SEH. I am aware of POSIX signals
but I am not sure if they work for individual threads in a
process. Last I checked
If you're dealing with plugins from an unknown source, it's a
good design to separate plugins and such as entirely separate
processes. Then, when one goes down, it cannot bring down
anyone else, since there is no shared address space.
They can communicate with the OS-supplied interprocess
On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
o.opCmp(new Object); // segmentation fault on my OSX
machine
Peter Alexander peter.alexander...@gmail.com wrote in message
news:vicaibqyaerogseqs...@forum.dlang.org...
It's defined. The operating system protects you. You get a segfault on
*nix and
an access violation on Windows.
False.
[snip]
You only get an error if there is a memory access
On 2012-03-02 10:22, Peter Alexander wrote:
On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
o.opCmp(new Object); //
On Friday, March 02, 2012 11:56:52 Jacob Carlborg wrote:
I never thought about that.
It's the same in C++. I was quite surprised when I first ran into it. But as
Daniel points out, the behavior is still defined, just less expected. If you
actually use this (or any member variable, since that
On 03/02/2012 10:22 AM, Peter Alexander wrote:
You only get an error if there is a memory access involved (vtable,
member data etc.)
In non-release mode you get an assertion failure.
On Friday, 2 March 2012 at 09:22:28 UTC, Peter Alexander wrote:
You only get an error if there is a memory access involved
(vtable, member data etc.)
By the way, my favorite application of that in C++ is debug
helper member functions (think: using DMD's toChar() in GDB),
which don't crash
On 2012-03-02 12:05, Jonathan M Davis wrote:
On Friday, March 02, 2012 11:56:52 Jacob Carlborg wrote:
I never thought about that.
It's the same in C++. I was quite surprised when I first ran into it. But as
Daniel points out, the behavior is still defined, just less expected. If you
actually
Le 02/03/2012 05:51, Jonathan M Davis a écrit :
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
o.opCmp(new Object); // segmentation fault on my OSX machine
This seems a bit
Le 02/03/2012 11:56, Jacob Carlborg a écrit :
False.
---
import std.stdio;
class Foo
{
final void bar()
{
writeln(I'm null!);
}
}
void main()
{
Foo foo;
foo.bar();
}
---
% dmd test.d -O -release -inline
% ./test
I'm null!
%
---
Am 02.03.2012, 05:37 Uhr, schrieb Nathan M. Swan nathanms...@gmail.com:
I spent a long time trying to find a
bug that crashed the program before writeln-debugging statements
could be flushed.
Instead of writeln use stdout.writeln.
Am 02.03.2012, 14:01 Uhr, schrieb deadalnix deadal...@gmail.com:
Le 02/03/2012 11:56, Jacob Carlborg a écrit :
You only get an error if there is a memory access involved (vtable,
member data etc.)
I never thought about that.
This is a common C++ interview question.
Don't scare him! I
Le 02/03/2012 14:30, Marco Leise a écrit :
Am 02.03.2012, 14:01 Uhr, schrieb deadalnix deadal...@gmail.com:
Le 02/03/2012 11:56, Jacob Carlborg a écrit :
You only get an error if there is a memory access involved (vtable,
member data etc.)
I never thought about that.
This is a common
On 2012-03-02 14:00, deadalnix wrote:
Le 02/03/2012 05:51, Jonathan M Davis a écrit :
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
o.opCmp(new Object); // segmentation fault on my OSX
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
On 2012-03-02 14:00, deadalnix wrote:
Le 02/03/2012 05:51, Jonathan M Davis a écrit :
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
Peter Alexander peter.alexander...@gmail.com wrote in message
news:vicaibqyaerogseqs...@forum.dlang.org...
On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
It's defined. The operating system protects you. You get a segfault on
*nix and
an access violation on Windows.
Technically speaking, there is no dereference of null occurring there. It
*looks* like there is because of the foo.bar notation, but remember,
calling a member function is not really dereferencing. It's just sugar
for:
foo.vtable[index_of_bar](foo);
But usually there's an class invariant.
On Friday, 2 March 2012 at 10:01:32 UTC, Daniel Murphy wrote:
Peter Alexander peter.alexander...@gmail.com wrote in
message
news:vicaibqyaerogseqs...@forum.dlang.org...
It's defined. The operating system protects you. You get a
segfault on *nix and
an access violation on Windows.
False.
On Friday, March 02, 2012 16:19:13 deadalnix wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
On 2012-03-02 14:00, deadalnix wrote:
Le 02/03/2012 05:51, Jonathan M Davis a écrit :
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null
On 3/1/2012 8:51 PM, Jonathan M Davis wrote:
It's defined. The operating system protects you.
Not exactly. It's a feature of the hardware. You get this for free, and your
code runs at full speed.
Adding in software checks for null pointers will dramatically slow things down.
Peter Alexander peter.alexander...@gmail.com wrote in message
news:jxloisomieykanavm...@forum.dlang.org...
On Friday, 2 March 2012 at 10:01:32 UTC, Daniel Murphy wrote:
Peter Alexander peter.alexander...@gmail.com wrote in message
news:vicaibqyaerogseqs...@forum.dlang.org...
It's defined.
On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
Am I correct that trying to use an Object null results in
undefined behavior?
Object o = null;
o.opCmp(new Object); // segmentation fault on my OSX machine
This seems a bit non-D-ish to me, as other bugs like this throw
101 - 170 of 170 matches
Mail list logo
