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 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 seconds to
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 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,
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 Tue, 23 Sep 2014 15:19:56 +0100
Bruno Medeiros via Digitalmars-d digitalmars-d@puremagic.com 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
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 digitalmars-d@puremagic.com wrote:
Even if I had to choose between an occasional savefile corruption
that would render a game impossible to win, and
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
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 digitalmars-d@puremagic.com
wrote:
* a small (or big) visual
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,
corrupted
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 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
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 Thu, 18 Sep 2014 08:57:20 -0400, Kagamin s...@here.lot 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.
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
On Thu, 18 Sep 2014 17:05:31 +0100
Bruno Medeiros via Digitalmars-d digitalmars-d@puremagic.com 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
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 unknown to
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 digitalmars-d@puremagic.com wrote:
* a small (or big) visual glitch, like pixels out of place,
corrupted textures, or 3D model of an object becoming
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 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 jmdavisp...@gmx.com
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
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
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
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
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
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
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
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
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 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 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 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 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 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
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
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
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,
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?
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
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.
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
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
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
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
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
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
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
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
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
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?
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
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 cutpasted from
Am Sat, 02 Aug 2014 12:34:54 -0700
schrieb Walter Bright newshou...@digitalmars.com:
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
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
On Thursday, 31 July 2014 at 21:29:59 UTC, Sean Kelly wrote:
On Thursday, 31 July 2014 at 21:11:17 UTC, Walter Bright wrote:
On 7/31/2014 1:52 PM, Sean Kelly wrote:
Could you expand on what you consider input?
All state processed by the program that comes from outside the
program. That
On Thursday, 31 July 2014 at 19:31:51 UTC, Jonathan M Davis wrote:
The whole type is templated, so the assertions will be compiled
in based on whether the user's code is compiled with -released
or not.
Sounds tricky. Doesn't the compiler optimize template
instantiation? If it finds an
On Friday, 1 August 2014 at 06:53:17 UTC, Kagamin wrote:
On Thursday, 31 July 2014 at 19:31:51 UTC, Jonathan M Davis
wrote:
The whole type is templated, so the assertions will be
compiled in based on whether the user's code is compiled with
-released or not.
Sounds tricky. Doesn't the
On Friday, 1 August 2014 at 01:20:04 UTC, Walter Bright wrote:
On 7/31/2014 3:07 PM, David Bregman wrote:
On Thursday, 31 July 2014 at 18:58:11 UTC, Walter Bright wrote:
On 7/31/2014 4:28 AM, David Bregman wrote:
Sigh. Of course you can assume the condition after a runtime
check has been
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 parameters using
assert() because the user of that library knows what the library
expects and should write their code
On Friday, 1 August 2014 at 04:12:40 UTC, 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
On Thursday, 31 July 2014 at 22:21:46 UTC, Daniel Gibson wrote:
Am 31.07.2014 23:59, schrieb Walter Bright:
On 7/31/2014 10:40 AM, Daniel Gibson wrote:
It's a major PITA to debug problems that only happen in
release builds.
Debugging optimized code was a well known problem even back in
the
Am Fri, 01 Aug 2014 07:01:48 +
schrieb Jonathan M Davis jmdavisp...@gmx.com:
Since all template instantiations must happen when you compile
your program rather than in any libraries you're linking against,
why would it matter? If you compile your program without
That's not true,
Am 01.08.2014 12:03, schrieb Marc Schütz schue...@gmx.net:
A compiler is a program that turns code in one programming language to
equivalent machine code, according to a language specification. There
are obviously many different equivalent machine code programs
corresponding to any sufficiently
On Thursday, 31 July 2014 at 21:11:17 UTC, Walter Bright wrote:
On 7/31/2014 1:52 PM, Sean Kelly wrote:
Could you expand on what you consider input?
All state processed by the program that comes from outside the
program. That would include:
1. user input
2. the file system
3. uninitialized
Johannes Pfau wrote in message news:lrfqqt$1jem$1...@digitalmars.com...
Which symbols are
actually used in the final executable is up to the linker and not
standardized.
Isn't it? dmd will set it up so the definitions in the library will only
get pulled in if undefined, and this will
Daniel Gibson wrote in message news:lrg0k5$1nl1$1...@digitalmars.com...
I'd prefer language specifications *not* to include such parts.
C wouldn't be any worse without the you can eliminate writes to code
that's not read afterwards part, for example.
Of course it would, that's why that's in
On Friday, 1 August 2014 at 01:41:40 UTC, Daniel Gibson wrote:
Yep, also a good point.
(Actually it's 187 -f* options, the rest is -O* which can't be
combined of course and some of them most probably imply many of
the -f* switches, but it'll still be an unmanageable/untestable
amount of
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 parameters using
assert() because the user of that library knows
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
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 compiler switch ever. What I
really want is a way to ship release and non-release
On Friday, 1 August 2014 at 07:01:49 UTC, Jonathan M Davis wrote:
Since all template instantiations must happen when you compile
your program rather than in any libraries you're linking
against, why would it matter?
AFAIK, there's no distinction between a library and a program in
D, only
On 8/1/14, 12:40 AM, David Bregman wrote:
It's not a position. I'm just giving you the definition of assume so
you can understand the difference from assert.
After reading your posts I still can't understand what your definition
of assume is. Here's what I found:
assert:
is a runtime check
Am Fri, 1 Aug 2014 23:20:02 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:
Johannes Pfau wrote in message
news:lrfqqt$1jem$1...@digitalmars.com...
Which symbols are
actually used in the final executable is up to the linker and not
standardized.
Isn't it? dmd will set it up
On Friday, 1 August 2014 at 14:26:35 UTC, Dicebot wrote:
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
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 compiler switch ever. What I
On Friday, 1 August 2014 at 15:23:03 UTC, Kagamin wrote:
On Friday, 1 August 2014 at 14:26:35 UTC, Dicebot wrote:
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
Druntime uses contracts and asserts in places. Which are of
course removed because we ship only a release build. Once
Sorry to hijack the thread, but:
On 07/31/2014 09:27 PM, Walter Bright via Digitalmars-d wrote:
If you're brave and want to have some fun, fill up your hard disk so
it is nearly full. Now run your favorite programs that read and write
files. Sit back and watch the crazy results (far too many
Am 01.08.2014 16:58, schrieb Andrei Alexandrescu:
You may dislike what Walter wanted assert to be, but really this has
been it from the beginning. Back in the day when I joined him I
questioned the validity of making assert a keyword. He explained that
he wanted it to be magic in the same way
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. The linker usually uses the first symbol it sees, but I
have not
On 08/01/2014 06:36 AM, Walter Bright wrote:
On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
But if we do that, then assume() starts to sound more and more like
assert()...
I see that my posts are starting to work :-)
No, you are suffering from confirmation bias.
On 08/01/2014 06:42 AM, Tofu Ninja wrote:
On Friday, 1 August 2014 at 04:36:13 UTC, Walter Bright wrote:
On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
But if we do that, then assume() starts to sound more and more like
assert()...
I see that my posts are starting to work :-)
I
On 08/01/2014 04:58 PM, Andrei Alexandrescu wrote:
assume:
passes a hint to the optimizer to allow better code generation.
is used when the expression is proven to be true (by the programmer,
like @trusted).
There are a few corrections needed for assert, i.e. is a runtime
check of the
Daniel Gibson wrote in message news:lrgcei$211u$1...@digitalmars.com...
I'm a bit surprised that back then your reaction was not well, that's a
neat idea, but people must know about it, so let's make it explicit in the
documentation.
Haha, I think back then there were much more serious
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 compiler switch ever. What I really want is a way to ship release and
Am 01.08.2014 18:47, schrieb Daniel Murphy:
Daniel Gibson wrote in message news:lrgcei$211u$1...@digitalmars.com...
I'm a bit surprised that back then your reaction was not well, that's
a neat idea, but people must know about it, so let's make it explicit
in the documentation.
Haha, I think
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?
Unless the assertions trigger in debug build, you will not end up
On 8/1/14, 2:19 PM, 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?
Unless the assertions
On 8/1/14, 9:25 AM, Timon Gehr wrote:
Even then, such a semantics is non-standard and almost nobody else knew.
This notion of standard has been occasionally mentioned in this
discussion. I agree that D's assert is different from traditional C and
C++ assert, and I also agree that might
On 08/01/2014 07:19 PM, 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?
...
It would often be foolish to simply assume so, and disabling of the
assertions can be
On 08/01/2014 07:39 PM, Andrei Alexandrescu wrote:
...
I did what I though was right. Do what you like. I'm off.
On Fri, Aug 01, 2014 at 06:58:16PM +0200, Daniel Gibson via Digitalmars-d wrote:
Lines: 29
Am 01.08.2014 18:47, schrieb Daniel Murphy:
Daniel Gibson wrote in message news:lrgcei$211u$1...@digitalmars.com...
I'm a bit surprised that back then your reaction was not well,
that's a neat
On Fri, Aug 01, 2014 at 10:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 8/1/14, 9:25 AM, Timon Gehr wrote:
Even then, such a semantics is non-standard and almost nobody else
knew.
This notion of standard has been occasionally mentioned in this
discussion. I agree that D's
On Fri, Aug 01, 2014 at 11:18:47AM -0400, Assaf Gordon via Digitalmars-d wrote:
Sorry to hijack the thread, but:
On 07/31/2014 09:27 PM, Walter Bright via Digitalmars-d wrote:
If you're brave and want to have some fun, fill up your hard disk so
it is nearly full. Now run your favorite
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 about the ranges+algorithms style of programming is
things like I/O don't get mixed up in
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
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 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
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 about
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 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
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 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,
1 - 100 of 249 matches
Mail list logo
