www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Godot Engine: Disable C++ exception handling

reply ryuukk_ <ryuukk.dev gmail.com> writes:
I always been advocating against EH

This is another missed opportunity at capturing that audience

I think the builtin tuple DIP must be resumed right away once D 
no longer is frozen

https://github.com/godotengine/godot/pull/80612
Aug 14 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
6 years ago: 
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

What happened for things to stop moving? D is in best position to 
be leading at doing better than C/C++
Aug 14 2023
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 15 August 2023 at 02:25:00 UTC, ryuukk_ wrote:

 6 years ago: 
 https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

 What happened for things to stop moving? D is in best position 
 to be leading at doing better than C/C++


I cant speak for the author of the draft but what's certain is 
that The comma expression needs to be totally removed, for now 
it's not even deprecated. You'll mostly get errors when used 
however.
Aug 15 2023
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 8/15/23 04:25, ryuukk_ wrote:

 6 years ago: 
 https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
 
 What happened for things to stop moving? D is in best position to be 
 leading at doing better than C/C++


I got very busy with work (both day job and other volunteering 
engagements) and personal issues. Also quite a few people are pushing 
for the scope of that DIP to be expanded beyond what can reasonably be 
expected to be put into the language and I am not really motivated to 
fight about it. As a result the implementation of the feature is not 
finished. Also, some parts of the design do still need to be improved.
Aug 18 2023
prev sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Tuesday, 15 August 2023 at 02:21:43 UTC, ryuukk_ wrote:

 I always been advocating against EH

 This is another missed opportunity at capturing that audience

 I think the builtin tuple DIP must be resumed right away once D 
 no longer is frozen

 https://github.com/godotengine/godot/pull/80612


I have been saying about how exception handling wasn't a good fit 
for game development, as I said before, games should fail as soon 
as possible, since they are super easy to enter in an invalid 
state, they're the completely the opposite from servers. Hipreme 
Engine is being developed completely without exceptions. I had to 
develop my own JSON solution since the `std.json` one uses 
exception, and also talked with p0nce about his libraries to not 
use exceptions.

The *only* place I use exceptions/error handling are in the hot 
reloading functionality since the user code can easily do errors 
such  as

```
int[] a;
a[0] = 50;
```

This will cause an AssertError, which my engine will handle 
manually to unload the shared library.

Also, my own JSON implementation consistently got 50% of the time 
used by std.json, probably for not throwing any kind of error, it 
is almost a drop-in replacement for it, except you manually check 
after parsing.
Aug 18 2023
parent Guillaume Piolat <first.name gmail.com> writes:
On Friday, 18 August 2023 at 10:06:44 UTC, Hipreme wrote:

 Also, my own JSON implementation consistently got 50% of the 
 time used by std.json, probably for not throwing any kind of 
 error, it is almost a drop-in replacement for it, except you 
 manually check after parsing.


Also kinda in the process of removing exceptions, in order to 
converge upon the custom WebAssembly druntimes that float around. 
Our exceptions were manually allocated anyway with a bearing on 
the catcher.
A pattern that can help is the fail() bit a bit like std::file or 
FILE*. It's the same morass of error codes and boolean a bit 
everywhere, but we can hide it from the library user.
For parsers, having popBack() throw is expensive so it can be 
valuable too to lessen exception usage.
Aug 18 2023