Timon Gehr:
Comparing signed/unsigned is perfectly reasonable.
Right, but only if the numbers don't get implicit
reinterpretations to other intervals, as C/C++/D do.
Bye,
bearophile
On 03/09/2012 01:43 AM, bearophile wrote:
Adam D. Ruppe:
D rox the web (and has for a while).
(Oh, you are starting to copy Andrei talk style now :-) The birth of community
words, idioms and sub-languages is a very common thing, sociology studies such
things a lot).
But there's always some
On 03/08/2012 10:40 AM, H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 02:57:00PM +0100, Andrej Mitrovic wrote:
I think what Chad is looking for is a BlackHole/WhiteHole equivalent
which doesn't need abstract functions but which figures out all the
methods of a class at compile time and creates a su
Adam D. Ruppe:
> D rox the web (and has for a while).
(Oh, you are starting to copy Andrei talk style now :-) The birth of community
words, idioms and sub-languages is a very common thing, sociology studies such
things a lot).
But there's always some space for improvements :-)
In D.learn ther
On Friday, 9 March 2012 at 00:19:38 UTC, bearophile wrote:
So maybe for her D language is not needed, other more flexible
languages are better for her.
D rox the web (and has for a while).
Regarding people that desire a compiler switch to add run-time tests inside the
binary that guard against null seg-faults to turn turn them into errors with a
stack trace: I have recently shown the D language to a friend. She answered me
that most code she writes is for the Web and it's not CPU-
On Thursday, 8 March 2012 at 22:20:10 UTC, Walter Bright wrote:
I agree, it really is very flexible and useful. The downside is
that it leaves significant overhead in functions that are
exception-aware, even if they never throw or unwind.
This problem is avoided by the switch to the table-base
On 3/8/2012 12:58 AM, Don Clugston wrote:
The documentation is terrible, but it's really a beautiful design.
I agree, it really is very flexible and useful. The downside is that it leaves
significant overhead in functions that are exception-aware, even if they never
throw or unwind.
And you
On Thu, Mar 08, 2012 at 05:49:20PM +0100, Andrej Mitrovic wrote:
> On 3/8/12, H. S. Teoh wrote:
> > foreach (name; __traits(allMembers, typeof(obj))) {
> > static if (__traits(compiles, &__traits(getMember, obj,
> > name)))
> > {
> >
I like the way Scala handles this with the Option class. None
indicates no value which is equivalent to your null sentinal
value but it is a value itself so it is always safe to use.
Combined with pattern matching and the orElse methods makes it
very easy to use one variable that both stores t
Plus I left over some code. Anyway the point is that was just a
hardcoded example of something that's doable, you'd probably want it
to be much more sophisticated before it goes into a library.
Sorry,
mixin(getOverloads!(UnreliableResource)()); should be:
mixin(getOverloads!(Base)());
On 3/8/12, H. S. Teoh wrote:
> foreach (name; __traits(allMembers, typeof(obj))) {
> static if (__traits(compiles, &__traits(getMember, obj,
> name)))
> {
> alias typeof(__traits(getMember, obj, name))
>
could it be a good idea to add something like an check-scope for
modules,functions,etc. for typical fails to easy the detection?
wild-idea-and-syntax-list:
@CheckForNull
@CheckForNaN
@CheckForUnnormalFloat
...
x.d
modul x
@CheckForNull // will introduce NullChecks for the complete module
On Mar 8, 2012, at 12:58 AM, Don Clugston wrote:
> On 06/03/12 17:05, Sean Kelly wrote:
>> On Mar 6, 2012, at 3:14 AM, Don Clugston wrote:
>>>
>>> Responding to traps is one of the very few examples I know of, where
>>> Windows got it completely right,
>>> and *nix got it absolutely completely
On Thu, Mar 08, 2012 at 02:57:00PM +0100, Andrej Mitrovic wrote:
[...]
> I don't know why we don't have __traits(allFunction). We have
> 'getVirtualFunctions' but it requires a function name, but using
> allMembers to filter out function names is damn difficult if you ask
> me.
foreach (na
I think what Chad is looking for is a BlackHole/WhiteHole equivalent
which doesn't need abstract functions but which figures out all the
methods of a class at compile time and creates a subclass that
throws/does nothing on method invocation. An 'alias this' field would
be used that is default-initi
On Thu, 08 Mar 2012 03:58:22 -0500, Don Clugston wrote:
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugston wrote:
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it absolutely completely wrong. M
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugston wrote:
Responding to traps is one of the very few examples I know of, where Windows
got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for floating point
On 03/07/2012 11:17 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J
On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
> On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
> >> On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
> >>> On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> On 03/07/2012 10:21 AM,
On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
-
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
> On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> >> On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> >>> You can use sentinels other than null.
> >>>
> >>> -Steve
> >>
> >> Example?
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
-Steve
Example?
Create an instance of the class which is immutable and represents an invalid
value.
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> > You can use sentinels other than null.
> >
> > -Steve
>
> Example?
Create an instance of the class which is immutable and represents an invalid
value. You could check whether something
On 03/07/2012 07:39 PM, Timon Gehr wrote:
On 03/08/2012 01:24 AM, Chad J wrote:
Though, more to the point:
I would probably forbid "Foo foo = new Foo(this);". The design that
leads to this is creating circular dependencies, which is usually bad to
begin with.
Circular object references are of
On 03/07/2012 02:09 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.
The point is, it's impossi
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
wrote:
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
I spoke too soon!
We missed one:
1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted point
On 03/08/2012 01:24 AM, Chad J wrote:
On 03/07/2012 04:41 AM, Timon Gehr wrote:
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy = 5;
On 03/07/2012 04:41 AM, Timon Gehr wrote:
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy = 5; }
}
Which would be lowered by the com
On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
> It's not that the null pointer itself corrupts memory. It's that the
> null pointer is a sign that something may have corrupted memory *before*
> you got to that point.
>
> The point is, it's impossible to tell whether the null pointer was
On Wed, Mar 07, 2012 at 09:22:27AM -0500, Chad J wrote:
> On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
[...]
> >However, there are several causes of seg faults:
> >
> >1. You forgot to initialize a variable.
> >2. Your memory has been corrupted, and some corrupted pointer now
> >points into
On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
wrote:
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to acc
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access
memory
that is not available. Since the 0 page is
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access
memory
that is not available. Since the 0 page is
On Wed, 07 Mar 2012 09:22:27 -0500, Chad J
wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access memory
that is not available. Since the 0 page is never
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access memory
that is not available. Since the 0 page is never allocated, any null
pointer dereferencing results in a
On Mon, 05 Mar 2012 23:58:48 -0500, 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 th
On Tue, 06 Mar 2012 23:07:24 -0500, Walter Bright
wrote:
On 3/6/2012 8:05 PM, Walter Bright wrote:
What I'm talking about is the idea that one can recover from seg faults
resulting from program bugs.
I've written about this before, but I want to emphasize that attempting
to recover from
On Mon, 05 Mar 2012 22:51:28 -0500, Jonathan M Davis
wrote:
On Monday, March 05, 2012 21:04:20 Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
wrote:
> That said, throwing an exception might not be a better response all
the
> time. On my operating system (M
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy = 5; }
}
Which would be lowered by the compiler into this:
class Bar
{
// Assume we'
On 03/07/2012 02:40 AM, Chad J wrote:
On 03/06/2012 12:19 PM, Timon Gehr wrote:
...
For example:
http://pm.inf.ethz.ch/publications/getpdf.php/bibname/Own/id/SummersMuellerTR11.pdf
CTFE and static constructors solve that issue for static data.
I can't seem to download the PDF... it always
Oh alright. Then we're in complete agreement.
On Mar 6, 2012, at 8:05 PM, Walter Bright wrote:
> On 3/6/2012 7:08 PM, Sean Kelly wrote:
>> Minor point, but some apps are designed such that segfaults are intended. I
>> worked on a DB that dynamically mapped memory in the segfault handler and
>>
On 3/6/2012 7:08 PM, Sean Kelly wrote:
Minor point, but some apps are designed such that segfaults are intended. I
worked on a DB that dynamically mapped memory in the segfault handler and
then resumed execution. Since D is a systems languages, very few assumptions
can be made about error condit
On 3/6/2012 8:05 PM, Walter Bright wrote:
What I'm talking about is the idea that one can recover from seg faults
resulting from program bugs.
I've written about this before, but I want to emphasize that attempting to
recover from program BUGS is the absolutely WRONG way to go about writing
f
On Mar 6, 2012, at 6:29 PM, Walter Bright wrote:
> On 3/6/2012 5:29 PM, Chad J wrote:
>> But what do you say to the notion of isolation? someFunc is isolated from
>> riskyShenanigans becuase it /knows/ what state is touched by
>> riskyShenanigans.
>> If riskyShenanigans does something strange an
Chad J:
> I can't seem to download the PDF... it always gives me just two bytes.
>
> But to initialize non-null fields, I suspect we would need to be able to
> do stuff like this:
There are some links here:
http://d.puremagic.com/issues/show_bug.cgi?id=4571
Bye,
bearophile
On Tue, Mar 06, 2012 at 08:29:35PM -0500, Chad J wrote:
[...]
> But what do you say to the notion of isolation? someFunc is
> isolated from riskyShenanigans becuase it /knows/ what state is
> touched by riskyShenanigans. If riskyShenanigans does something
> strange and unexpected, and yes, it doe
On 3/6/2012 5:29 PM, Chad J wrote:
But what do you say to the notion of isolation? someFunc is isolated from
riskyShenanigans becuase it /knows/ what state is touched by riskyShenanigans.
If riskyShenanigans does something strange and unexpected, and yes, it does have
a bug in it, then I feel tha
On 03/06/2012 12:19 PM, Timon Gehr wrote:
On 03/06/2012 04:46 PM, foobar wrote:
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types means
that they are the default and checked statically, ideally using data
flow analysis.
I
On 03/06/2012 03:39 PM, Mantis wrote:
06.03.2012 8:04, Chad J пишет:
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
06.03.2012 8:04, Chad J пишет:
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 beyo
On Tuesday, 6 March 2012 at 15:46:54 UTC, foobar wrote:
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types
means that they are the default and checked statically,
ideally using data flow analysis.
I agree that non-nullable
On 03/06/2012 04:46 PM, foobar wrote:
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types means
that they are the default and checked statically, ideally using data
flow analysis.
I agree that non-nullable types should be ma
On Tue, 06 Mar 2012 12:14:56 +0100, Don Clugston wrote:
On 04/03/12 04:34, Walter Bright wrote:
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 asynchronou
On Tue, 06 Mar 2012 14:22:09 +0100, bearophile
wrote:
Sandeep Datta:
I am just going to leave this here...
*Fast Bounds Checking Using Debug Register*
http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
Is this idea usable in DMD to speed up D code compiled in non-release
mode?
Bye,
bearophi
On Mar 6, 2012, at 3:14 AM, Don Clugston wrote:
>
> Responding to traps is one of the very few examples I know of, where Windows
> got it completely right,
> and *nix got it absolutely completely wrong. Most notably, the hardware is
> *designed* for floating point traps to be fully recoverable.
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types
means that they are the default and checked statically, ideally
using data flow analysis.
I agree that non-nullable types should be made the default and
statically checked
On Tuesday, 6 March 2012 at 09:11:07 UTC, James Miller wrote:
If you have a possible null, then check for it *yourself*
sometimes
you know its null, sometimes you don't have any control.
However, the
compiler has no way of knowing that. Its basically an
all-or-nothing
thing with the compiler.
On 2012-03-06 13:48, Chad J wrote:
On 03/06/2012 02:54 AM, Jacob Carlborg wrote:
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 ha
On 2012-03-06 10:53:19 +, Jacob Carlborg said:
On Mac OS X the runtime would only need to catch any exception (as it
already does) and print the stack trace. But also re-throw the
exception to let the OS handle the logging of the exception (at least I
hope that will work).
Actually if y
Sandeep Datta:
> I am just going to leave this here...
>
> *Fast Bounds Checking Using Debug Register*
>
> http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
Is this idea usable in DMD to speed up D code compiled in non-release mode?
Bye,
bearophile
On 03/06/2012 03:27 AM, Walter Bright wrote:
On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
Yeah, C and C++ might not do what's suggested but basically all other
languages
do it.
People turn to C and C++ for systems work and high performance.
Optional. Flags.
If there is a truly unavoidable
On 03/06/2012 02:54 AM, Jacob Carlborg wrote:
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
James Miller:
> If you have a possible null, then check for it *yourself* sometimes
> you know its null, sometimes you don't have any control. However, the
> compiler has no way of knowing that. Its basically an all-or-nothing
> thing with the compiler.
In a normal program there are many situatio
On 04/03/12 04:34, Walter Bright wrote:
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 runni
On 2012-03-06 10:11, James Miller wrote:
If you have a possible null, then check for it *yourself* sometimes
you know its null, sometimes you don't have any control. However, the
compiler has no way of knowing that. Its basically an all-or-nothing
thing with the compiler.
If I know there is a p
On 03/05/2012 05:39 AM, 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 st
On 3/5/2012 12:05 PM, Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:jiunst$qrm$1...@digitalmars.com...
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 sa
If you have a possible null, then check for it *yourself* sometimes
you know its null, sometimes you don't have any control. However, the
compiler has no way of knowing that. Its basically an all-or-nothing
thing with the compiler.
However, the compiler can (and I think does) warn of possible
null
On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
Yeah, C and C++ might not do what's suggested but basically all other languages
do it.
People turn to C and C++ for systems work and high performance.
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 uncaug
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 02:17, Michel Fortin wrote:
On 2012-03-05 22:31:34 +, "Steven Schveighoffer"
said:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
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 continually
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. That
gt; That's _very_ inconsistent with the scope(failure) guarantee of
> _always_ executing.
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 statemen
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 - espe
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 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
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 crashing
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 Mon, 05 Mar 2012 23:31:34 +0100, Steven Schveighoffer
wrote:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
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 is a
slow workflow. It's a big improvement if
On Monday, March 05, 2012 21:04:20 Steven Schveighoffer wrote:
> On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
>
> 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 w
On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
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 with named
functions, the
On 2012-03-05 22:31:34 +, "Steven Schveighoffer"
said:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
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 continually irks me to no end. It seems like
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 not-
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 disa
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 cons
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 nu
On 3/5/12 2:31 PM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
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 continually irks me to no end. It seems like the trusty
(rusty?) sword
On Monday, 5 March 2012 at 22:50:46 UTC, H. S. Teoh wrote:
In theory, we *could* have druntime install a handler for
SIGSEGV upon program startup that prints a stacktrace and
exits
This sounds like a good idea to me.
(or do whatever the
equivalent is on Windows, if compiled on Windows).
On
On Monday, March 05, 2012 15:05:57 Nick Sabalausky wrote:
> "Walter Bright" wrote in message
> news:jiunst$qrm$1...@digitalmars.com...
>
> > 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
>
On Mon, Mar 05, 2012 at 05:31:34PM -0500, Steven Schveighoffer wrote:
[...]
> I wholeheartedly agree that we should use the hardware features that
> we are given, and that NullPointerException is not worth the bloat.
> But we should be doing *something* better than just printing
> "Segmentation Fau
Steven Schveighoffer wrote:
> On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix wrote:
>
>> Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
>>> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix
>>> wrote:
>>>
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
> Isn't it quite unsafe to throw an
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
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 is a
slow workflow. It's a big improvement if the segfault is hard to find,
but only
a small improvement if the
On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix wrote:
Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix
wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
Isn't it quite unsafe to throw an exception in a signal ?
One does not need to thr
"Walter Bright" wrote in message
news:jiunst$qrm$1...@digitalmars.com...
>
> 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).
"Adam D. Ruppe" wrote in message
news:ewuffoakafwmuybbz...@forum.dlang.org...
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>
I *hat
On 2012-03-05 20:02, Walter Bright wrote:
On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
On 2012-03-05 11:38, Walter Bright wrote:
Notably, C and C++ do not do what you suggest.
Just because C and C++ do something in a certain way doesn't make it a
valid
reason to do the same thing in D.
I think
"Walter Bright" wrote in message
news:jj252v$15vf$1...@digitalmars.com...
> 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
>> is a
>> slow workflow. It's a big improvement if the segfault is hard to find,
>> but only
1 - 100 of 173 matches
Mail list logo