On Thursday, 12 September 2024 at 22:34:04 UTC, user1234 wrote:
On Wednesday, 11 September 2024 at 10:08:29 UTC, ryuukk_ wrote:
On Wednesday, 11 September 2024 at 09:14:39 UTC, Nick
Treleaven wrote:
On Wednesday, 11 September 2024 at 08:08:45 UTC, ryuukk_
wrote:
[...]
I again apologies for bei
On Wednesday, 11 September 2024 at 10:08:29 UTC, ryuukk_ wrote:
On Wednesday, 11 September 2024 at 09:14:39 UTC, Nick Treleaven
wrote:
On Wednesday, 11 September 2024 at 08:08:45 UTC, ryuukk_ wrote:
[...]
I again apologies for being wrong and i apologies again for
trying to improve things, i d
On Wednesday, 11 September 2024 at 04:01:53 UTC, f wrote:
i mean , is this a bug?
This is not a bug. The problem is due to a misunderstanding of
the -release parameter. The following related topic opened by
Steven and the answers given by Walter are really valuable:
https://forum.dlang.org/t
On Wednesday, 11 September 2024 at 16:40:05 UTC, Bradley Chatha
wrote:
On Wednesday, 11 September 2024 at 12:17:02 UTC, Fox wrote:
I don't care about whether it's a bug or not, I just want to
learn What illegal instructions did this "assert(false);" code
create?
Fortunately Godbolt supports
On Wednesday, 11 September 2024 at 12:17:02 UTC, Fox wrote:
I don't care about whether it's a bug or not, I just want to
learn What illegal instructions did this "assert(false);" code
create?
Fortunately Godbolt supports D, so it's easy to see that it
generates `ud2` on x86(_64): https://god
I don't care about whether it's a bug or not, I just want to
learn What illegal instructions did this "assert(false);" code
create?
On Wednesday, 11 September 2024 at 10:08:29 UTC, ryuukk_ wrote:
On Wednesday, 11 September 2024 at 09:14:39 UTC, Nick Treleaven
wrote:
On Wednesday, 11 September 2024 at 08:08:45 UTC, ryuukk_ wrote:
It is a bug, don't claim it is not, the compiler gives the
wrong information, wich lead to a con
On Wednesday, 11 September 2024 at 09:14:39 UTC, Nick Treleaven
wrote:
On Wednesday, 11 September 2024 at 08:08:45 UTC, ryuukk_ wrote:
It is a bug, don't claim it is not, the compiler gives the
wrong information, wich lead to a confused user
You don't want confused users, you want compiler say
On Wednesday, 11 September 2024 at 08:08:45 UTC, ryuukk_ wrote:
It is a bug, don't claim it is not, the compiler gives the
wrong information, wich lead to a confused user
You don't want confused users, you want compiler say what's up,
if i type assert, it should assert, end of the story
The
On Tuesday, September 10, 2024 10:01:53 PM MDT f via Digitalmars-d-learn
wrote:
> i mean , is this a bug?
No, it's not a bug. Assertions with an expression that is known to be false
at compile time are treated as special. They are always left in the
generated code so that they will kill your prog
i mean , is this a bug?
On Tuesday, 13 June 2023 at 16:46:26 UTC, DLearner wrote:
Only a small thing, but is it intended that:
```
void main() {
// static assert (false, "Static Assert triggered");
assert(false, "Assert triggered");
}
```
produces
```
core.exception.AssertError@staticassertex01.d(4): Assert
trigge
On 7/10/21 12:32 PM, Mathias LANG wrote:
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote:
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote:
I think it's the throwing/catching of the `Throwable` that is
allocating. But I don't know from where the allocation happens
On Saturday, 10 July 2021 at 16:32:30 UTC, Mathias LANG wrote:
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote:
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven
Schveighoffer wrote:
I think it's the throwing/catching of the `Throwable` that is
allocating. But I don't know from where
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote:
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer
wrote:
I think it's the throwing/catching of the `Throwable` that is
allocating. But I don't know from where the allocation happens.
-Steve
i think you are right
Try t
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer
wrote:
On 7/9/21 8:44 PM, russhy wrote:
On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote:
On 7/9/21 4:12 PM, russhy wrote:
>> One way of forcing compile-time evaluation in D is to
>> define
an enum
>> (which means "mani
On 7/9/21 8:44 PM, russhy wrote:
On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote:
On 7/9/21 4:12 PM, russhy wrote:
>> One way of forcing compile-time evaluation in D is to define
an enum
>> (which means "manifest constant" in that use).
That's all I meant. It was a general comment.
On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote:
On 7/9/21 4:12 PM, russhy wrote:
>> One way of forcing compile-time evaluation in D is to define
an enum
>> (which means "manifest constant" in that use).
That's all I meant. It was a general comment.
> this is very bad, assert are goo
On 7/9/21 4:12 PM, russhy wrote:
>> One way of forcing compile-time evaluation in D is to define an enum
>> (which means "manifest constant" in that use).
That's all I meant. It was a general comment.
> this is very bad, assert are good because they are one liner, making it
> 2 line to avoid GC
On Friday, 9 July 2021 at 22:53:10 UTC, Ali Çehreli wrote:
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
One way of for
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at compile
time.
Best regards
One way of forcing compile-time evaluation in D is to define an enum
(whi
i think it only allocate when it hit the assert, but program will
halt so it's not big deal, even though i feel this is a stupid
design to make everything depend on GC... it gives bad impression
when you want avoid it
here is how i do to detect hidden GC allocations
https://run.dlang.io/is/H
On Thursday, 8 July 2021 at 18:11:50 UTC, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
Consider below. Only z will generate an error. This i
On Sunday, 27 September 2020 at 21:41:25 UTC, Adam D. Ruppe wrote:
On Sunday, 27 September 2020 at 21:38:43 UTC, ddcovery wrote:
i.e. checking this Regex expression
`^[a-zA-Z_]*[a-zA-Z0-9_]*[a-zA-Z][a-zA-Z0-9_]*$`
Is there any way to check a regular expression at compile time?
Not really an
On Sunday, 27 September 2020 at 21:38:43 UTC, ddcovery wrote:
i.e. checking this Regex expression
`^[a-zA-Z_]*[a-zA-Z0-9_]*[a-zA-Z][a-zA-Z0-9_]*$`
Is there any way to check a regular expression at compile time?
Not really and I'd actually suggest not trying because even if it
did work, it'd
On 3/23/20 2:14 PM, Steven Schveighoffer wrote:
E.g. https://dlang.org/dmd-osx.html#switch-release
There are also other switches like -boundscheck and -check. It’s
possible you have some library or project that is causing the behavior.
-Steve
Thank you, Steve.
In my case I guess it was my
On Monday, 23 March 2020 at 10:08:58 UTC, drug wrote:
Before I lived in assurance that asserts are actual only in
debug mode and in release mode they are nothing (except
`assert(0)`). But today my whole life is going sour because I
stumbled upon assert in release mode and of course that assert
On 2019-06-30 17:47:27 +, a11e99z said:
Private means that only members of the enclosing class can access the
member, or
vvv
members and functions in the same module as the enclosing class.
^
On Sunday, June 30, 2019 11:24:03 AM MDT Robert M. Münch via Digitalmars-d-
learn wrote:
> I have a case, with templates, where an assert in a unittest can access
> a private memember and I don't know how this can happen.
>
> Before trying to creat an equivalent case, I want to cross-check, if
> as
On Sunday, 30 June 2019 at 17:24:03 UTC, Robert M. Münch wrote:
I have a case, with templates, where an assert in a unittest
can access a private memember and I don't know how this can
happen.
Modules are the units of encapsulation in D:
https://dlang.org/spec/attribute.html#visibility_attrib
On Sunday, 30 June 2019 at 17:24:03 UTC, Robert M. Münch wrote:
I have a case, with templates, where an assert in a unittest
can access a private memember and I don't know how this can
happen.
Before trying to creat an equivalent case, I want to
cross-check, if assert has special semantics in
On 01/28/2018 11:31 AM, Steven Schveighoffer wrote:
>> Fixed it through the "Improve this page" link on that Phobos page:
>>
>>https://github.com/dlang/phobos/blob/master/std/exception.d
>>
>> Ali
>
> Hm... it appears that you committed directly to the branch. Even if
> changing docs, you sho
On 1/27/18 9:31 AM, Ali Çehreli wrote:
On 01/27/2018 05:52 AM, kdevel wrote:
> https://dlang.org/phobos/std_exception.html#enforce states:
>
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks
> | and invariants), because they will be compiled out when compil
On Sun, 28 Jan 2018 00:59:12 +, lobo wrote:
> On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
>> On 01/27/2018 10:33 AM, kdevel wrote:
>>
>>> I suggest the deletion of the sentence "Use assert in contracts."
>>
>> Done.
>>
>> Ali
>
> Wait, no this isn't right, is it? Enforce
On 01/27/2018 04:59 PM, lobo wrote:
> On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
>> On 01/27/2018 10:33 AM, kdevel wrote:
>>
>>> I suggest the deletion of the sentence "Use assert in contracts."
>>
>> Done.
>>
>> Ali
>
> Wait, no this isn't right, is it?
It is right because
On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
On 01/27/2018 10:33 AM, kdevel wrote:
I suggest the deletion of the sentence "Use assert in
contracts."
Done.
Ali
Wait, no this isn't right, is it? Enforce should not be used in
contracts so the "Use assert in contracts" sta
On 01/27/2018 10:33 AM, kdevel wrote:
I suggest the deletion of the sentence "Use assert in contracts."
Done.
Ali
On Saturday, 27 January 2018 at 18:00:32 UTC, rjframe wrote:
I think I see what you mean; you interpret "use asserts,
because enforce will be compiled out" to imply that asserts
wouldn't be compiled out, correct?
Is there any other meaningful interpretation?
Since, in reality, both would be c
On Saturday, January 27, 2018 17:12:25 kdevel via Digitalmars-d-learn wrote:
> Then please explain to me, in which respect the advice to "Use
> assert[s] in contracs" makes sense if the contracts are to be
> compiled out. I don't get it.
The entire point of contracts is to be asserting pre or post
On Sat, 27 Jan 2018 17:12:25 +, kdevel wrote:
> This is not a problem, because this is perfectly legal. The problem is
> the wording of this phrase on the docs:
>
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks | and invariants), because they will be com
On Saturday, 27 January 2018 at 16:19:30 UTC, Jonathan M Davis
wrote:
On Saturday, January 27, 2018 14:59:50 kdevel via
Digitalmars-d-learn wrote:
>>> https://github.com/dlang/phobos/blob/master/std/exception.d
>>
>> "Use $(D assert) in contracts." is still in there.
>
> What's wrong with that?
On Saturday, January 27, 2018 14:59:50 kdevel via Digitalmars-d-learn wrote:
> On Saturday, 27 January 2018 at 14:51:23 UTC, Ali Çehreli wrote:
> > On 01/27/2018 06:36 AM, kdevel wrote:
> >> On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli
> >>
> >> wrote:
> >>> > But assert is also ignore
On Saturday, 27 January 2018 at 14:51:23 UTC, Ali Çehreli wrote:
On 01/27/2018 06:36 AM, kdevel wrote:
On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli
wrote:
> But assert is also ignored in release mode:
The documentation is not clear. "they will be compiled out"
means "contracts ar
On 01/27/2018 06:36 AM, kdevel wrote:
On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli wrote:
> But assert is also ignored in release mode:
The documentation is not clear. "they will be compiled out" means
"contracts are compiled out". So, an enforce() would disappear if it's
inside
On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli wrote:
> But assert is also ignored in release mode:
The documentation is not clear. "they will be compiled out"
means "contracts are compiled out". So, an enforce() would
disappear if it's inside such a block, which should not be what
On 01/27/2018 05:52 AM, kdevel wrote:
> https://dlang.org/phobos/std_exception.html#enforce states:
>
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks
> | and invariants), because they will be compiled out when compiling with
> -release.
> | Use assert in contra
On Sat, 27 Jan 2018 13:52:47 +, kdevel wrote:
> https://dlang.org/phobos/std_exception.html#enforce states:
>
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks | and invariants), because they will be compiled out when
> compiling with -release.
> | Use asser
On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
The compiler can easily prove that the value of data.length
does not change between the two points in the program.
According to the specification, the behavior of the program is
undefined in case the assertion fails, not just the b
On 14.10.2017 23:36, kdevel wrote:
On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
Also, UB can and does sometimes mean that the program can execute
arbitrary code. It's called "arbitrary code execution":
https://en.wikipedia.org/wiki/Arbitrary_code_execution
This confuses dif
On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
Also, UB can and does sometimes mean that the program can
execute arbitrary code. It's called "arbitrary code execution":
https://en.wikipedia.org/wiki/Arbitrary_code_execution
This confuses different levels of reasoning. In C/C++
On 14.10.2017 07:20, Jesse Phillips wrote:
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
This is an example of what I mean :-
undefined what it is meant to do anyway, so the compiler can
"optimize" out the if condition as it only affects the case where the
language doesn't
On Saturday, October 14, 2017 05:20:47 Jesse Phillips via Digitalmars-d-
learn wrote:
> The point is assert tells the compiler something it can use to
> reason about its job, not that it can insert additional runtime
> checks to see if you code is invalid an then add new jumps to
> execute whatever
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
This is an example of what I mean :-
undefined what it is meant to do anyway, so the compiler can
"optimize" out the if condition as it only affects the case
where the language doesn't define what it's supposed to do
anyway, an
On Friday, October 13, 2017 11:26:54 kdevel via Digitalmars-d-learn wrote:
> On Friday, 13 October 2017 at 02:22:24 UTC, Jonathan M Davis
>
> wrote:
> > You've told it that i should never be 3 at that point and that
> > it's a bug if it is, and as such, it is free to assume that i
> > is never 3 af
On Friday, 13 October 2017 at 02:22:24 UTC, Jonathan M Davis
wrote:
You've told it that i should never be 3 at that point and that
it's a bug if it is, and as such, it is free to assume that i
is never 3 after the assertion even if the assertion is
compiled out with -release - that is the only
On Thursday, October 12, 2017 21:22:29 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 12 October 2017 at 20:27:03 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, October 12, 2017 20:15:41 kdevel via
> >
> >> ---
> >> void main ()
> >> {
> >>
> >> assert (false);
> >>
> >> }
> >> ---
> >
On Thursday, 12 October 2017 at 20:27:03 UTC, Jonathan M Davis
wrote:
On Thursday, October 12, 2017 20:15:41 kdevel via
---
void main ()
{
assert (false);
}
---
qualifies as "invalid, and therefore has undefined behaviour."
A statement, which makes no sense to me. Either it is a
"debuggin
On Thursday, October 12, 2017 20:15:41 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
> > C++ compilers can and do perform such optimizations so I was
> > wondering if assert in D could cause such behavior according to
> > the spec.
>
> In t
On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:
C++ compilers can and do perform such optimizations so I was
wondering if assert in D could cause such behavior according to
the spec.
In the context of ISO-C++ it is meaningless to reason about the
"actual behavior" of a non-co
On Thursday, 12 October 2017 at 14:22:43 UTC, Timon Gehr wrote:
On 11.10.2017 11:27, John Burton wrote:
Yes, that's what it is saying. (The other answers, that say or
try to imply that this is not true or true but not a bad thing,
are wrong.)
...
However, in practice, I think none of the
On 11.10.2017 11:27, John Burton wrote:
The spec says this :-
"As a contract, an assert represents a guarantee that the code must
uphold. Any failure of this expression represents a logic error in the
code that must be fixed in the source code. A program for which the
assert contract is false
On Wednesday, 11 October 2017 at 09:39:04 UTC, user1234 wrote:
On Wednesday, 11 October 2017 at 09:27:49 UTC, John Burton
wrote:
[...]
I therefore feel like I ought to not use assert and should
instead validate my assumptions with an if statement and a
throw or exit or something.
Yes, that's
On 10/11/2017 02:27 AM, John Burton wrote:
> The spec says this :-
>
> "As a contract, an assert represents a guarantee that the code must
> uphold. Any failure of this expression represents a logic error in the
> code that must be fixed in the source code. A program for which the
> assert contrac
On Wednesday, October 11, 2017 09:27:49 John Burton via Digitalmars-d-learn
wrote:
> The spec says this :-
>
> "As a contract, an assert represents a guarantee that the code
> must uphold. Any failure of this expression represents a logic
> error in the code that must be fixed in the source code.
On Wednesday, 11 October 2017 at 09:27:49 UTC, John Burton wrote:
[...]
I therefore feel like I ought to not use assert and should
instead validate my assumptions with an if statement and a
throw or exit or something.
Yes, that's the way of doing. assert() are just used to test the
program.
On 11/10/2017 10:27 AM, John Burton wrote:
The spec says this :-
"As a contract, an assert represents a guarantee that the code must
uphold. Any failure of this expression represents a logic error in the
code that must be fixed in the source code. A program for which the
assert contract is fa
On 8/5/16 6:25 AM, Nordlöw wrote:
Should range members front() and back() assert() or throw() on emptyness?
If it should assert() doesn't that lead to unsafer code in release mode?
What's the consensus here?
If the code is @safe, then it should trigger an error if you try to do
unsafe things
On Friday, August 05, 2016 15:50:50 H.Loom via Digitalmars-d-learn wrote:
> On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
> > Should range members front() and back() assert() or throw() on
> > emptyness?
> >
> > If it should assert() doesn't that lead to unsafer code in
> > release mode?
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
nothing, but examples exist in pbobos such as front() on na
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
It is unsafer, the rationale is that your code should be debugged
to comply with the assumption of the release mode that there are
no
On Friday, August 05, 2016 10:25:42 Nordlöw via Digitalmars-d-learn wrote:
> Should range members front() and back() assert() or throw() on
> emptyness?
>
> If it should assert() doesn't that lead to unsafer code in
> release mode?
>
> What's the consensus here?
It is a programming error for any r
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
if you can and it is not costly, do `assert(false, "BOOM!")
On 08/05/2016 12:25 PM, Nordlöw wrote:
Should range members front() and back() assert() or throw() on emptyness?
If it should assert() doesn't that lead to unsafer code in release mode?
What's the consensus here?
It's an error in the program when front/back is called on an empty
range. Every
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
I'm pretty sure it's assert() here. The contract is that the
caller is responsible for checking emptiness beforehand, and the
whole of Phobos is coded around that
On Tuesday, 26 July 2016 at 12:13:02 UTC, DLearner wrote:
What is the recommended way of identifying which assert has
been triggered?
If you compile with -g, run the program in a debugger. It will
tell you.
If you compile and do NOT use -release, the error message
automatically printed by t
On 7/26/16 8:13 AM, DLearner wrote:
Suppose a program contains several points that control should not get to.
So each such point is blocked by assert(0).
What is the recommended way of identifying which assert has been triggered?
Is one allowed anything like 'assert(0,"Crashed at point A");', wh
On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote:
Thanks, I'm aware of these tools.
But it's easier to use the stacktrace...if I only get one. The
function where the assert() is called is, in turn, called in
hundreds of places.
Which platform are you on? Are all your binaries com
On Thursday, 28 January 2016 at 18:13:59 UTC, Vladimir Panteleev
wrote:
You can use Digger to find the exact compiler change that
caused this assert to manifest, and Dustmite to find the
minimal program which behaves differently in two compiler
versions.
Thanks, I'm aware of these tools.
But
On Thursday, 28 January 2016 at 18:13:59 UTC, Vladimir Panteleev
wrote:
On Thursday, 28 January 2016 at 18:01:09 UTC, Nordlöw wrote:
After upgrading to 2.070.0 I get an assert failure in my
application that wasn't there before:
core.exception.AssertError@knet/linking.d(235): Assertion
failure
On Thursday, 28 January 2016 at 18:01:09 UTC, Nordlöw wrote:
After upgrading to 2.070.0 I get an assert failure in my
application that wasn't there before:
core.exception.AssertError@knet/linking.d(235): Assertion
failure
Why isn't there any stacktrace? I thought has been fixed.
Please help
TheFlyingFiddle:
When should i use enforce instead of assert?
Others have already told you most of the answer. Let me add that
enforce() is heavier for the compiler, so don't put an enforce in
a performance-critical path in your code.
Bye,
bearophile
Asserts are removed in release builds, enforces remain.
Asserts are used to verify internal sanity of application and
never happen if it does not contain programming errors.
Enforces provide syntax sugar for routine error handling under
normal workflow.
On Friday, 20 December 2013 at 23:08:32 UTC, TheFlyingFiddle
wrote:
When should i use enforce instead of assert?
Assert is for things that is completely controlled by your
program. If an assert fails, it is something you, the programmer,
can fix by changing the code.
enforce is for things t
On Jul 9, 2013, at 3:33 PM, Jonathan M Davis wrote:
> On Tuesday, July 09, 2013 10:39:59 Sean Kelly wrote:
>> If you join the thread, any unhanded exception will be rethrown in the
>> joining thread by default.
>
> What about threads which were spawned by std.concurrency? IIRC, those are
> neve
On Tuesday, July 09, 2013 10:39:59 Sean Kelly wrote:
> If you join the thread, any unhanded exception will be rethrown in the
> joining thread by default.
What about threads which were spawned by std.concurrency? IIRC, those are
never explicitly joined. Is catching Throwable in the spawned thread
On Jul 1, 2013, at 4:04 AM, Joseph Rushton Wakeling
wrote:
> I've noticed that when an assert fails inside a thread, no error message is
> printed and the program/thread just hangs.
>
> Is there any way to ensure that an assertion failure inside a thread does
> output
> a message? For the pur
On Fri, Jun 21, 2013 at 12:36:13AM +0100, Joseph Rushton Wakeling wrote:
[...]
> private size_t diceImpl(Rng, Range)(ref Rng rng, Range proportions)
> if (isForwardRange!Range && isNumeric!(ElementType!Range) &&
> isForwardRange!Rng)
> {
> double sum = reduce!("(assert(b >= 0),
On 06/21/2013 02:56 AM, Joseph Rushton Wakeling wrote:
> I did also have to think about it for a few seconds. You have
> a sum of values from an array; you generate a
> uniformly-distributed random number point in [0.0, sum); you
> sequentially sum values from the same array, and return when
> t
On Thu, 20 Jun 2013 15:48:38 -0400, Joseph Rushton Wakeling
wrote:
Is it considered good/recommended practice to insert an assert(false)
statement
in parts of the code that should be unreachable? Or simply an optional
choice
that may be useful for debugging?
I think it's more than good
On 06/21/2013 09:51 AM, monarch_dodra wrote:
> Reading that code, it's not immediately obvious to me: The assert makes it
> self
> documenting.
I did also have to think about it for a few seconds. You have a sum of values
from an array; you generate a uniformly-distributed random number point in
On Thursday, 20 June 2013 at 23:36:35 UTC, Joseph Rushton
Wakeling wrote:
On 06/20/2013 11:36 PM, Jonathan M Davis wrote:
... one is necessary as it's in a function that is supposed
to return a
value.
I don't think that that's supposed to be necessary. The only
reason that that should happen
On 06/20/2013 11:36 PM, Jonathan M Davis wrote:
>> ... one is necessary as it's in a function that is supposed to return a
>> value.
>
> I don't think that that's supposed to be necessary. The only reason that that
> should happen is if the compiler can deterimine that the execution can
> defini
On Thursday, June 20, 2013 15:45:14 Timothee Cour wrote:
> A)
> does assert(foo) where foo is an expression that cat be evaluated at
> compile time (eg via CTFE etc) behave same as assert(true)/assert(false)?
If it _is_ known at compile time, then yes, but simply calling a function that
_could_ b
A)
does assert(foo) where foo is an expression that cat be evaluated at
compile time (eg via CTFE etc) behave same as assert(true)/assert(false)?
B)
It is usually "bad practice" to keep an assert in release
> ("assert(false)"), because the code should already have been checked, and
> you shouldn
On Thursday, June 20, 2013 22:37:17 Joseph Rushton Wakeling wrote:
> On 06/20/2013 10:33 PM, Joseph Rushton Wakeling wrote:
> > On 06/20/2013 10:25 PM, Jonathan M Davis wrote:
> >> Putting it at the end of the function is unnecessary. The compiler
> >> already
> >> does that for you.
> >
> > Then
Ali Çehreli:
And a reminder that assert(false) (and assert(0)) is never
removed from code (even when other asserts are).
Because in release mode assert(false) is not an assert any more,
it's an HALT instruction, and it doesn't show the error message:
assert(false, "Not shown in release optim
On 06/20/2013 10:33 PM, Joseph Rushton Wakeling wrote:
> On 06/20/2013 10:25 PM, Jonathan M Davis wrote:
>> Putting it at the end of the function is unnecessary. The compiler already
>> does that for you.
>
> Then there are a bunch of functions in std.random ending with unnecessary
> assert(false
On 06/20/2013 10:25 PM, Jonathan M Davis wrote:
> Putting it at the end of the function is unnecessary. The compiler already
> does that for you.
Then there are a bunch of functions in std.random ending with unnecessary
assert(false) statements. Shall I make this tweak as an addition to current
On Thursday, June 20, 2013 22:21:28 Joseph Rushton Wakeling wrote:
> In my case it was a bunch of if/else where the program should return from
> one of the blocks. I saw comparable cases in RandomCover with an
> assert(false) at the very end of the function, so thought I'd better tweak
> my code ac
On 06/20/2013 10:15 PM, Jonathan M Davis wrote:
> I definitely use assert(false) for what is supposed to be unreachable code.
> The
> two prime places that I can think of off the top of my head are
>
> 1. In a catch block when it's supposed to be impossible for the try block to
> throw (e.g. wh
1 - 100 of 203 matches
Mail list logo
