On 9/29/2014 6:01 AM, Bruno Medeiros via Digitalmars-d wrote:
I would invite you to buy a *retail copy* of Elder Scrolls 3 : Morrowind
for PC and try playing that. The game did exactly what Walter and you
guys suggested: when an assertion tripped, it would crash straight away
to the desktop, with
On Monday, 29 September 2014 at 13:41:33 UTC, Paulo Pinto wrote:
And the right attitude as consumer is to ask for the money
back, not to wait patiently for the day those bugs eventually
get fixed.
If everyone did that, the quality in IT would be much better.
The mobile freemium model where
On Monday, 29 September 2014 at 13:01:19 UTC, Bruno Medeiros
wrote:
On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>it game will crash on ANY bug, it will contain alot less
>bugs. 'cause
>even the dumbiest QA full of monkeys will not let the game
>which
>crashes once in a ten second
On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>it game will crash on ANY bug, it will contain alot less bugs. 'cause
>even the dumbiest QA full of monkeys will not let the game which
>crashes once in a ten seconds to go out of the door.
When doing QA, that's a whole different thing
On Tue, Sep 23, 2014 at 09:25:51PM +0300, ketmar via Digitalmars-d wrote:
> On Tue, 23 Sep 2014 15:19:56 +0100
> Bruno Medeiros via Digitalmars-d wrote:
>
> > Even if I had to choose between an occasional savefile corruption
> > that would render a game impossible to win, and having my games
> >
On Tue, 23 Sep 2014 15:19:56 +0100
Bruno Medeiros via Digitalmars-d wrote:
> Even if I had to choose between an occasional savefile corruption
> that would render a game impossible to win, and having my games crash
> every time ANY bug happened, I would still prefer the former.
it game will crash
On 18/09/2014 17:49, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in
On Friday, 19 September 2014 at 13:56:14 UTC, Sean Kelly wrote:
I suspect/hope that it won't be long before communications
software is held to standards similar to telephone, which will
require a huge adjustment on the part of programmers. People
in this industry still tend to not think of thi
On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via
Digitalmars-d wrote:
Seriously, this philosophy of ignoring supposedly "minor" bugs
in
software is what led to the sad state of software today, where
nothing
is reliable and people have come to expect that software will
inevitably
On Thursday, 18 September 2014 at 16:05:32 UTC, Bruno Medeiros
wrote:
"If it's a game, who cares" -> Oh let's see... let's say I'm
playing a game, and then there's a bug (which happens often).
What would I prefer to happen:
* a small (or big) visual glitch, like pixels out of place,
corrupt
On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via
Digitalmars-d wrote:
On Thu, 18 Sep 2014 17:05:31 +0100
Bruno Medeiros via Digitalmars-d
wrote:
> * a small (or big) visual glitch, like pixels out of plac
On 18/09/14 18:49, H. S. Teoh via Digitalmars-d wrote:
What if the program has a bug that corrupts your save game file, but
because the program ignores these logic errors, it just bumbles onward
and destroys all your progress *without* you even knowing about it until
much later?
Happened to me
The point is that using these enforce() statements means that
these methods cannot be nothrow, which doesn't seem
particularly nice if it can be avoided. Now, on the one hand,
one could say that, quite obviously, these methods cannot
control their input. But on the other hand, it's reasonable
On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via Digitalmars-d wrote:
> On Thu, 18 Sep 2014 17:05:31 +0100
> Bruno Medeiros via Digitalmars-d wrote:
>
> > * a small (or big) visual glitch, like pixels out of place,
> > corrupted textures, or 3D model of an object becoming deformed, or
> > the
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
> On 01/08/2014 05:12, Walter Bright wrote:
> >On 7/31/2014 2:21 PM, Sean Kelly wrote:
> >>Thoughts?
> >
> >If a process detects a logic error, then that process is in an
> >invalid state that is unanticipated and un
On Thu, 18 Sep 2014 17:05:31 +0100
Bruno Medeiros via Digitalmars-d wrote:
> * a small (or big) visual glitch, like pixels out of place, corrupted
> textures, or 3D model of an object becoming deformed, or the physics
> of some object behaving erratically, or some broken animation.
or the whole
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in an invalid
state that is unanticipated and unknown to the developer. The only
correct solution is to halt that process, and all processes that
On Thu, 18 Sep 2014 08:57:20 -0400, Kagamin wrote:
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven Schveighoffer
wrote:
The cost for this is tremendous. You may as well not use classes.
Looks like ldc has a separate option to turn off invariants.
That's a good thing. I'm actually th
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven
Schveighoffer wrote:
The cost for this is tremendous. You may as well not use
classes.
Looks like ldc has a separate option to turn off invariants.
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven
Schveighoffer wrote:
You may as well not use classes.
Always a good idea ;)
On Fri, 01 Aug 2014 01:07:55 -0400, Jonathan M Davis
wrote:
On Thursday, 31 July 2014 at 20:49:18 UTC, Timon Gehr wrote:
On 07/31/2014 09:37 PM, Jonathan M Davis wrote:
disable contracts, turn assert(0) into a halt
instruction, and disable bounds checking in @system and @trusted code.
So, i
On Tuesday, 5 August 2014 at 16:35:42 UTC, Andrew Godfrey wrote:
out, but in general if the compiler keeps track of properties
of things then it could start making algorithmic-level
performance decisions that today we always have to make by
hand. To me that's interesting.
I think the most "po
On Tuesday, 5 August 2014 at 09:42:26 UTC, Ola Fosheim Grøstad
wrote:
But I don't think this path is all that new… so I hope Walter,
if he continues walking down this path, remains unrelenting and
keeps walking past "assert as assume" until he finds truly new
territory in the realm of formal me
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
I can totally relate to people who hold a conviction strong
enough to
have difficulty acknowledging a contrary belief as even remotely
reasonable
Yes, it's difficult to acknowledge a belief, reason for which
wasn't provided,
On Tuesday, 5 August 2014 at 10:00:55 UTC, eles wrote:
It is wise to mix them to such degree as to no longer
distinguish them? For me, assume and the like shall rather go
with the annotations.
That's one of the reasons I think it is not new territory, since
letting assert have side effects ba
On Tuesday, 5 August 2014 at 09:42:26 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
For my money, consider Walter's response:
I feel a bit confused about the mixture between compiler and
optimizer. While I agree the compiler does the opti
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
For my money, consider Walter's response:
What I see is Microsoft attempting to bring D's assert
semantics into
C++. :)
As I've mentioned before, there is inexorable pressure for
this to
happen, and it will happen.
I fin
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
I find it to the point, clear, and funny. Expanded it would go
like "I see more similarities than differences, and a definite
convergence dictated by market pressure."
I find this to be a non-sequitur. Firstly, making a joke
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
On 8/3/14, 11:55 AM, Kagamin wrote:
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman
wrote:
OK, I'm done. It's clear now that you're just being
intellectually
dishonest in order to "win" what amounts to a trivial
arg
On 8/3/14, 11:55 AM, Kagamin wrote:
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman wrote:
OK, I'm done. It's clear now that you're just being intellectually
dishonest in order to "win" what amounts to a trivial argument. So
much for professionalism.
Haha, this time it's not as bad
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman wrote:
OK, I'm done. It's clear now that you're just being
intellectually dishonest in order to "win" what amounts to a
trivial argument. So much for professionalism.
Haha, this time it's not as bad as it was in catch syntax
discussion
On Friday, 1 August 2014 at 16:04:21 UTC, Daniel Murphy wrote:
"Johannes Pfau" wrote in message
news:lrgar7$1vrr$1...@digitalmars.com...
Do you know if linkers actually guarantee that behaviour?
AFAICS dmd
doesn't do anything special, it always emits weak symbols and
just calls
gcc to link.
On Sunday, 3 August 2014 at 02:27:16 UTC, Jonathan M Davis wrote:
On Saturday, 2 August 2014 at 09:46:57 UTC, Marc Schütz wrote:
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis
wrote:
And why is that a problem? By definition, if an assertion
fails, your code is in an invalid state,
On Saturday, 2 August 2014 at 09:46:57 UTC, Marc Schütz wrote:
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis
wrote:
And why is that a problem? By definition, if an assertion
fails, your code is in an invalid state,
Only in an ideal world. In practice, the condition in the
asserti
Am Sat, 02 Aug 2014 12:34:54 -0700
schrieb Walter Bright :
> On 8/1/2014 3:58 PM, Jonathan M Davis wrote:
> > But even if I
> > could think of a better name, I think that we're stuck with -debug
> > at this point.
>
> One thing that people hate even more than breaking existing code is
> breaking
On 8/1/2014 3:58 PM, Jonathan M Davis wrote:
But even if I
could think of a better name, I think that we're stuck with -debug at this
point.
One thing that people hate even more than breaking existing code is breaking
their makefile (or equivalent).
Makefiles typically are cut&pasted from s
On 8/1/2014 4:24 PM, bearophile wrote:
H. S. Teoh:
IMO the correct solution is for the compiler to insert preconditions at the
calling site,
I have seen this suggestion tens of times, but nothing has happened. (delegates
make the management of contract blame more compex).
There's a bugzilla
On Saturday, 2 August 2014 at 05:35:26 UTC, Walter Bright wrote:
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish
I'd thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.micros
"bearophile" wrote in message news:nadqefjfnjfzghope...@forum.dlang.org...
What defines "possible"? A compiler switch that allows to define the
amount of compile time?
At the moment it's the criteria I listed in the bug report. Beyond this, it
will be limited by what constfolding is capable
By the way, I will be absent for more than a week. My comments or
answers in bug reports and threads will have to wait.
Bye,
bearophile
Daniel Murphy:
This doesn't need a lot of text to explain either: "when
possible, the compiler will check preconditions at compile time"
What defines "possible"? A compiler switch that allows to define
the amount of compile time?
I feel like you're confusing this pull request with another
"bearophile" wrote in message news:hnbybyssdlwaomesc...@forum.dlang.org...
I like compile-time tests, you can see it from several of my last posts,
but:
1) It's better to be able to express general tests using CTFE, instead of
covering a limited but growing list of cases. The general solution
On Saturday, 2 August 2014 at 06:01:30 UTC, Walter Bright wrote:
As to the substance of your question, I can't do it proper
justice in a few lines. It's an important issue, and it is
worthwhile to thoroughly understand it, especially for the kind
of programming you do and the leading role you h
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis wrote:
On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the re
On Saturday, 2 August 2014 at 06:44:48 UTC, Walter Bright wrote:
On 8/1/2014 11:08 PM, Timon Gehr wrote:
You evaded the question.
Those have been posted here before, and I responded in detail
to them, more than once.
I have nothing new to say about it.
Honestly, how can you be so comforta
Daniel Murphy:
What do you think about
https://github.com/D-Programming-Language/dmd/pull/3799 ?
Basically, turn obviously invalid failing function calls into
compile-time errors. IMO this pushes in-contracts well out of
the useless area.
I like compile-time tests, you can see it from sev
"Jonathan M Davis" wrote in message
news:zbkvnbibbmcfwhjvm...@forum.dlang.org...
> IMO the correct solution is for the compiler to insert preconditions at
> the calling site, rather than the callee.
If we had that, I'd actually start using in blocks. As it is, I think that
they're useless e
On 8/1/2014 11:08 PM, Timon Gehr wrote:
You evaded the question.
Those have been posted here before, and I responded in detail to them, more than
once.
I have nothing new to say about it.
On 08/02/2014 07:35 AM, Walter Bright wrote:
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish I'd
thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library
On 08/02/2014 08:04 AM, eles wrote:
On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
It's part of the language standard. The com
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
Yes, but is the same for the C apps. There, you have no assertion in
the release build, the release build is optimized (I imagine very few
would
On 8/1/2014 5:57 PM, Dicebot wrote:
`enforce` does have overload which allows to use pre-allocated exception
instance. Or, alternatively, we may need a similar helper wich does `if
(!condition) abort()` with no interaction with -release or optimizer.
It still throws a *recoverable* exception, w
On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
It's part of the language standard. The compiler can make as
much use of it as p
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
Yes, but is the same for the C apps. There, you have no
assertion in the release build, the release build is optimized
(I imagine very few would use -O0 on it...), then the sefault
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish I'd thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
can you see the difference now
Am 02.08.2014 04:13, schrieb David Bregman:
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
can you see the difference now?
Oh, interesting quote from the __assume() link:
"Use __assume in an ASSERT only when
On Saturday, 2 August 2014 at 00:18:30 UTC, Walter Bright wrote:
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of
attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of
that
On Friday, 1 August 2014 at 19:10:34 UTC, Walter Bright wrote:
On 8/1/2014 6:12 AM, Dicebot wrote:
ok, can this be considered a good summary of using
assertions/contracts for
services where risk of entering undefined state is
unacceptable?
1) never use `assert` or contracts in actual applicat
On 08/02/2014 02:04 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:59:29AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, perhaps one way to work around this, is to have a function with
an in-contract compile into
On 08/02/2014 02:18 AM, Walter Bright wrote:
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of
attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of that
nature when we find
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of that nature when
we find them unconvincing.
To quote my favorite Ham
On Sat, Aug 02, 2014 at 02:04:22AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:52 AM, H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
> >>On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
> >>>Actually,
On Sat, Aug 02, 2014 at 01:59:29AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
> >OTOH, perhaps one way to work around this, is to have a function with
> >an in-contract compile into a preamble and a body:
> >
> > int func(int x)
> >
On 08/02/2014 01:52 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
Actually, I'm thinking of ways of extending this even further, ...
Note that the official stanc
On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, perhaps one way to work around this, is to have a function with an
in-contract compile into a preamble and a body:
int func(int x)
in { assert(x > 5); }
body {
return computeResult(x);
On 08/02/2014 01:51 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:46:44AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
something like --remove-assertions.
What would that do?
Automatically edit your source files and delete a
On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
> >Actually, I'm thinking of ways of extending this even further, ...
>
> Note that the official stance has been that such things are obviously
> ridiculous i
On Sat, Aug 02, 2014 at 01:46:44AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
> >something like --remove-assertions.
>
> What would that do?
Automatically edit your source files and delete all assert expressions
for you.
:-D
T
--
Why waste ti
On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
Actually, I'm thinking of ways of extending this even further, ...
Note that the official stance has been that such things are obviously
ridiculous if not checked dynamically in non-release mode.
On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
something like --remove-assertions.
What would that do?
On Fri, Aug 01, 2014 at 11:24:29PM +, bearophile via Digitalmars-d wrote:
> H. S. Teoh:
>
> >IMO the correct solution is for the compiler to insert preconditions
> >at the calling site,
>
> I have seen this suggestion tens of times, but nothing has happened.
> (delegates make the management o
On 8/1/2014 4:12 PM, Jonathan M Davis wrote:
True, but as long as the runtime cost isn't too great for your debug builds,
having assertions for whatever conditions you think your code relies on and
would ideally be checked is quite beneficial. Any optimizations by the compiler
would then be a bon
On 08/02/2014 01:19 AM, Jonathan M Davis wrote:
If we had that, I'd actually start using in blocks. As it is, I think
that they're useless except when inheritance is involved,
And when it is involved, they are broken because the compiler insists on
removing them on each override by default.
H. S. Teoh:
IMO the correct solution is for the compiler to insert
preconditions at the calling site,
I have seen this suggestion tens of times, but nothing has
happened. (delegates make the management of contract blame more
compex).
Bye,
bearophile
On Friday, 1 August 2014 at 23:13:28 UTC, H. S. Teoh via
Digitalmars-d wrote:
IMO the correct solution is for the compiler to insert
preconditions at the calling site, rather than the callee.
If we had that, I'd actually start using in blocks. As it is, I
think that they're useless except wh
On Friday, 1 August 2014 at 22:34:02 UTC, Walter Bright wrote:
On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
Thinking about it, I'm actually wondering if I should use
assertions _more_ so
that the compiler might be able to do better optimizations in
-release.
I think this will be a productive
On Fri, Aug 01, 2014 at 10:34:20PM +, Sean Kelly via Digitalmars-d wrote:
> On Friday, 1 August 2014 at 16:52:00 UTC, Daniel Murphy wrote:
> >"Sean Kelly" wrote in message
> >news:tngnltzwxprebpbcd...@forum.dlang.org...
> >
> >>Druntime uses contracts and asserts in places. Which are of course
On Fri, Aug 01, 2014 at 03:34:00PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
> >Thinking about it, I'm actually wondering if I should use assertions
> >_more_ so that the compiler might be able to do better optimizations
> >in -release.
>
> I thin
On Friday, 1 August 2014 at 20:57:29 UTC, Walter Bright wrote:
On 8/1/2014 12:47 PM, Tofu Ninja wrote:
Having your augment consistently dismissed by "I see no
difference" or "That is
misuse" is frustrating to say the least.
Indeed.
I repeatedly gave detailed rationales for that.
Unfortuna
On Friday, 1 August 2014 at 21:42:07 UTC, Jonathan M Davis wrote:
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
On Friday, 1 August 2014 at 08:21:28 UTC, Kagamin wrote:
On Thursday, 31 July 2014 at 21:29:59 UTC, Sean Kelly wrote:
So effectively, any factor occurring at runtime. I
On Friday, 1 August 2014 at 21:51:10 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Aug 01, 2014 at 09:42:06PM +, Jonathan M Davis via
Digitalmars-d wrote:
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
[...]
But we probably would be better off if none of the switches
had na
On 8/1/2014 3:34 PM, Sean Kelly wrote:
Also, I don't like the -debuglib option because when a user sets
the debug flag in their build, what they want is to debug their
own code, not the standard library. While it's sometimes useful
to have debug symbols in the standard library you're linking
aga
On 8/1/2014 7:33 AM, Kagamin wrote:
Nobody cares about intermediate files,
I do because it influences build speed, which is a major feature of D.
On Friday, 1 August 2014 at 16:52:00 UTC, Daniel Murphy wrote:
"Sean Kelly" wrote in message
news:tngnltzwxprebpbcd...@forum.dlang.org...
Druntime uses contracts and asserts in places. Which are of
course removed because we ship only a "release" build. Once
again, the worst naming for a com
On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
Thinking about it, I'm actually wondering if I should use assertions _more_ so
that the compiler might be able to do better optimizations in -release.
I think this will be a productive strategy once this gets implemented in
optimizers.
Of course, u
On 08/01/2014 11:50 PM, Jonathan M Davis wrote:
... as far as correctness goes, it never hurts to have more assertions.
Pipe dream.
On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different
input
and hence traverse
On Fri, Aug 01, 2014 at 09:42:06PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
[...]
> But we probably would be better off if none of the switches had names
> like -release or -debug so that folks actually had to figure out what
>
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
On Friday, 1 August 2014 at 08:21:28 UTC, Kagamin wrote:
On Thursday, 31 July 2014 at 21:29:59 UTC, Sean Kelly wrote:
So effectively, any factor occurring at runtime. If I create
a
library, it is acceptable to validate function parame
On 8/1/14, 5:16 PM, eles wrote:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different input
and hence traverse different traces of abstract states. It is not
valid to say that a
On 8/1/2014 12:47 PM, Tofu Ninja wrote:
Having your augment consistently dismissed by "I see no difference" or "That is
misuse" is frustrating to say the least.
I repeatedly gave detailed rationales for that.
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different input
and hence traverse different traces of abstract states. It is not
valid to say tha
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
Yes, but is the same for the C apps. There, you have no
assertion in the release build, the release build is optimized
(I imagine very few would use -O0 on it...), then the sefault
happens.
In c the assert is just a check, no assume, th
On 8/1/2014 1:02 PM, H. S. Teoh via Digitalmars-d wrote:
Not to mention, it lets you *really* unittest your code thoroughly,
because it isolates each separate stage of the processing into its own
self-contained unit, with clearly-defined standard interconnects. Your
unittest can therefore easily
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different
input and hence traverse different traces of abstract states.
It is not valid to say that an assertion will never fail just
On Friday, 1 August 2014 at 17:19:09 UTC, Sebastiaan Koppe wrote:
If assertions are disabled in release builds, and you
specifically instruct the compiler to build one, are you not
assuming that the assertions will hold?
Then what is wrong with extending those assumptions to the
optimizer?
On Fri, Aug 01, 2014 at 12:05:00PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/1/2014 8:18 AM, Assaf Gordon via Digitalmars-d wrote:
> >As Walter said, it's alarming how many programs fail to handle such
> >cases (though D is pretty solid in that regard).
>
> One of the very cool things a
On Friday, 1 August 2014 at 17:53:03 UTC, Timon Gehr wrote:
On 08/01/2014 07:39 PM, Andrei Alexandrescu wrote:
...
I did what I though was right. Do what you like. I'm off.
I feel you, this whole thread is extremely frustrating.
Having your augment consistently dismissed by "I see no
diff
On Friday, 1 August 2014 at 19:47:35 UTC, Tofu Ninja wrote:
Having your augment consistently dismissed by "I see no
*argument not augment :/
On 8/1/2014 6:12 AM, Dicebot wrote:
ok, can this be considered a good summary of using assertions/contracts for
services where risk of entering undefined state is unacceptable?
1) never use `assert` or contracts in actual application code, use `enforce`
instead
2) never use `enforce` in library
1 - 100 of 251 matches
Mail list logo
