On Tuesday, 5 January 2021 at 18:42:42 UTC, Marvin wrote:
On Monday, 4 January 2021 at 15:39:50 UTC, ludo456 wrote:
Listening to the first visioconf of the Dconf 2020, titled
Destroy All Memory Corruption,
(https://www.youtube.com/watch?v=XQHAIglE9CU) Walter talks
about not using exceptions
On Thursday, 7 January 2021 at 19:35:00 UTC, H. S. Teoh wrote:
Whether or not something is inlined has nothing to do with what
line number it was written in.
Okay, I've tried it out, and it seems it isn't the problem in the
binary case as the code was first compiled and the inlined, so
the
On Thu, Jan 07, 2021 at 07:00:15PM +, sighoya via Digitalmars-d-learn wrote:
> On Thursday, 7 January 2021 at 18:12:18 UTC, H. S. Teoh wrote:
[...]
> > Wrong. Out of memory only occurs at specific points in the code
> > (i.e., when you call a memory allocation primitive).
>
> What about
On Thursday, 7 January 2021 at 18:12:18 UTC, H. S. Teoh wrote:
If you're unfamiliar with the subject, I recommend reading a
textbook on compiler construction.
I already read one.
Because every introduced catch block in the libunwind
implementation introduces additional overhead.
But only
On Thu, Jan 07, 2021 at 05:47:37PM +, sighoya via Digitalmars-d-learn wrote:
> On Thursday, 7 January 2021 at 14:34:50 UTC, H. S. Teoh wrote:
> > This has nothing to do with inlining. Inlining is done at
> > compile-time, and the inlined function becomes part of the caller.
>
> True
>
> >
On Thursday, 7 January 2021 at 14:34:50 UTC, H. S. Teoh wrote:
This has nothing to do with inlining. Inlining is done at
compile-time, and the inlined function becomes part of the
caller.
True
There is no stack pointer decrementing involved anymore
Also true.
because there's no longer
On Thu, Jan 07, 2021 at 11:15:26AM +, sighoya via Digitalmars-d-learn wrote:
> On Thursday, 7 January 2021 at 10:36:39 UTC, Jacob Carlborg wrote:
[...]
> > It's claimed that exceptions are not zero cost, even when an
> > exception is not thrown. Because the compiler cannot optimize
> >
On Thu, Jan 07, 2021 at 12:01:23AM +, sighoya via Digitalmars-d-learn wrote:
> On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
[...]
> > You don't need to box anything. The unique type ID already tells
> > you what type the context is, whether it's integer or pointer and
> >
On Thursday, 7 January 2021 at 10:36:39 UTC, Jacob Carlborg wrote:
Swift can throw anything that implements the Error protocol.
Classes, structs and enums can implement protocols.
True, Swift can throw anything what implements the Error
protocol. It seems the error protocol itself doesn't
On 2021-01-07 01:01, sighoya wrote:
Thanks, reminds on swift error types which are enum cases.
Swift can throw anything that implements the Error protocol. Classes,
structs and enums can implement protocols.
Oh, no please not. Interestingly we don't use longjmp in default
exception
On 2021-01-06 22:27, H. S. Teoh wrote:
That's the whole point of Sutter's proposal: they are all unified with
the universal Error struct. There is only one "backend": normal
function return values, augmented as a tagged union to distinguish
between normal return and error return. We are
On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
It must be unique because different functions may return
different sets of error codes. If these sets overlap, then once
the error propagates up the call stack it becomes ambiguous
which error it is.
Contrived example:
On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
It must be unique because different functions may return
different sets of error codes. If these sets overlap, then once
the error propagates up the call stack it becomes ambiguous
which error it is.
I don't think this is the
On Wed, Jan 06, 2021 at 05:36:07PM +, sighoya via Digitalmars-d-learn wrote:
> On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote:
> > 4) The universal error type contains two fields: a type field and a
> > context field.
> >
> > a) The type field is an ID unique to every thrown
On Monday, 4 January 2021 at 15:39:50 UTC, ludo456 wrote:
Listening to the first visioconf of the Dconf 2020, titled
Destroy All Memory Corruption,
(https://www.youtube.com/watch?v=XQHAIglE9CU) Walter talks
about not using exceptions any more in the future. He says
something like "this is
Citing Herb Sutter:
As noted in §1.1, preconditions, postconditions, and assertions
are for identifying program bugs, they are never recoverable
errors; violating them is always corruption, undefined behavior.
Therefore they should never be reported via error reporting
channels (regardless of
On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote:
4) The universal error type contains two fields: a type field
and a context field.
a) The type field is an ID unique to every thrown exception
--
uniqueness can be guaranteed by making this a pointer to
some static
On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote:
implemented, rather than the concept of exceptions itself. If
we implement Sutter's proposal, or something similar suitably
adapted to D, it would eliminate the runtime overhead, solve
the @nogc exceptions issue, and still support
On Tuesday, 5 January 2021 at 22:01:08 UTC, Ola Fosheim Grøstad
wrote:
Also, I think this is better determined using whole program
optimization, the chosen integer bit pattern used for
propagating errors has performance implications. The most
freguently thrown/tested value should be the one
On Tue, Jan 05, 2021 at 06:23:25PM +, sighoya via Digitalmars-d-learn wrote:
> Personally, I don't appreciate error handling models much which
> pollute the return type of each function simply because of the
> conclusion that every function you define have to handle errors as
> errors can
On Tuesday, 5 January 2021 at 19:42:40 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2021 at 18:23:25 UTC, sighoya wrote:
No error handling model was the HIT and will never be,
therefore I would recommend to leave things as they are and to
develop alternatives and not to replace
On Tuesday, 5 January 2021 at 18:23:25 UTC, sighoya wrote:
No error handling model was the HIT and will never be,
therefore I would recommend to leave things as they are and to
develop alternatives and not to replace existing ones.
Or implement C++ exceptions, so that D can catch C++
Bye bye nothrow functions in Dlang.
On Monday, 4 January 2021 at 15:39:50 UTC, ludo456 wrote:
Listening to the first visioconf of the Dconf 2020, titled
Destroy All Memory Corruption,
(https://www.youtube.com/watch?v=XQHAIglE9CU) Walter talks
about not using exceptions any more in the future. He says
something like "this is
Personally, I don't appreciate error handling models much which
pollute the return type of each function simply because of the
conclusion that every function you define have to handle errors
as errors can happen everywhere even in pure functions.
You don't believe me? What about memory
On 1/4/21 7:39 AM, ludo456 wrote:
> Can someone point me to an article or more explanations about that?
Joe Duffy has a very complete document contrasting various error
management strategies in the context of Midori:
http://joeduffyblog.com/2016/02/07/the-error-model/
Herb Sutter has a
On 04.01.21 16:39, ludo456 via Digitalmars-d-learn wrote:
Can someone point me to an article or more explanations about that?
already came up, see:
https://forum.dlang.org/thread/jnrvugxqjzenykztt...@forum.dlang.org
https://forum.dlang.org/thread/lhyagawrjzzmrtbok...@forum.dlang.org
27 matches
Mail list logo
