www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Modern C++ Won't Save Us

reply Walter Bright <newshound2 digitalmars.com> writes:
https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Lists some perfectly reasonable code in Modern C++ style that has hidden memory 
safety bugs.
Apr 25
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Unfortunately, Phobos got bitten by exactly the same use-after-free bug as the article showcases: https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e97687065fe66a33e2cb8
Apr 26
next sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
On Monday, 26 April 2021 at 07:21:38 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Unfortunately, Phobos got bitten by exactly the same use-after-free bug as the article showcases: https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e97687065fe66a33e2cb8
Yeah. And were got it bitten? In its f***ing C interface. null terminated strings are a piece from hell that should be banned, not proliferated!
Apr 26
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/26/21 7:44 AM, Dominikus Dittes Scherkl wrote:
 On Monday, 26 April 2021 at 07:21:38 UTC, Petar Kirov [ZombineDev] wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that has 
 hidden memory safety bugs.
Unfortunately, Phobos got bitten by exactly the same use-after-free bug as the article showcases: https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e 7687065fe66a33e2cb8
Yeah. And were got it bitten? In its f***ing C interface. null terminated strings are a piece from hell that should be banned, not proliferated!
Null terminated strings have nothing to do with it. The issue is not the null termination, but the use after free (change this to a temporary D array, and it still will have the same problem). How do we fix it? tempCString is a horrifically unsafe construct. You can extract a pointer out of it without even trying, and now you have a reference that will easily outlive the thing it refers to. The idea here is, tempCString must be stored, it can never be a temporary inside the expression. How do you express that in code? I'd start AT LEAST by removing the alias this, so at least it's not so trivial to violate safety. I also can't see any marking of system for anything, IMO, system should be all over this type to avoid accidentally compiling in safe code. -Steve
Apr 26
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 26 April 2021 at 11:44:26 UTC, Dominikus Dittes 
Scherkl wrote:
 Unfortunately, Phobos got bitten by exactly the same 
 use-after-free bug as the article showcases:

 https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e97687065fe66a33e2cb8
Bug was in trusted code.
Apr 27
prev sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Monday, 26 April 2021 at 07:21:38 UTC, Petar Kirov 
[ZombineDev] wrote:
 Unfortunately, Phobos got bitten by exactly the same 
 use-after-free bug as the article showcases:

 https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e97687065fe66a33e2cb8
Isn't this an error that should be detected by DIP25 / DIP1000? I was quite surprised that -preview=dip1000 accepted this code.
Apr 26
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/26/2021 1:20 PM, MoonlightSentinel wrote:
 On Monday, 26 April 2021 at 07:21:38 UTC, Petar Kirov [ZombineDev] wrote:
 Unfortunately, Phobos got bitten by exactly the same use-after-free bug as the 
 article showcases:

 https://github.com/dlang/phobos/pull/7988/commits/08927149ccbb3a20fb7e
7687065fe66a33e2cb8 
Isn't this an error that should be detected by DIP25 / DIP1000? I was quite surprised that -preview=dip1000 accepted this code.
The checks are defeated by the trusted function: property inout(To)* buffPtr() inout { return _ptr == useStack ? _buff.ptr : _ptr; } https://github.com/dlang/phobos/blob/master/std/internal/cstring.d#L229
Apr 26
next sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Tuesday, 27 April 2021 at 05:01:09 UTC, Walter Bright wrote:
 The checks are defeated by the  trusted function:
DMD doesn't catch the error even when making `tempCString` and `browse` ` safe` (using appropriate ` trusted` lambdas, ...): https://issues.dlang.org/show_bug.cgi?id=21868
Apr 27
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/27/2021 2:37 AM, MoonlightSentinel wrote:
 https://issues.dlang.org/show_bug.cgi?id=21868
Thanks!
Apr 27
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 27 April 2021 at 09:37:42 UTC, MoonlightSentinel 
wrote:
 DMD doesn't catch the error even when making `tempCString` and 
 `browse` ` safe` (using appropriate ` trusted` lambdas, ...):

 https://issues.dlang.org/show_bug.cgi?id=21868
What does `scope` mean on a function declaration?
Apr 27
parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Tuesday, 27 April 2021 at 10:53:10 UTC, Vladimir Panteleev 
wrote:
 What does `scope` mean on a function declaration?
It applies to the `this` pointer for member methods, just like `return`. (Allthough `scope` is implicitly applied for structs IIRC)
Apr 27
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 27 April 2021 at 11:33:45 UTC, MoonlightSentinel 
wrote:
 On Tuesday, 27 April 2021 at 10:53:10 UTC, Vladimir Panteleev 
 wrote:
 What does `scope` mean on a function declaration?
It applies to the `this` pointer for member methods, just like `return`. (Allthough `scope` is implicitly applied for structs IIRC)
If I had a magic wand I would make the this pointer explicit, now that we annotate it often.
Apr 27
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 27 April 2021 at 11:33:45 UTC, MoonlightSentinel 
wrote:
 On Tuesday, 27 April 2021 at 10:53:10 UTC, Vladimir Panteleev 
 wrote:
 What does `scope` mean on a function declaration?
It applies to the `this` pointer for member methods, just like `return`.
Aah, so it makes `scope` with classes great again. I keep getting surprised by how awesome DIP1000 is.
 (Allthough `scope` is implicitly applied for structs IIRC)
That's interesting, because it seems to be required in the bug you filed.
Apr 27
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/27/2021 4:33 AM, MoonlightSentinel wrote:
 On Tuesday, 27 April 2021 at 10:53:10 UTC, Vladimir Panteleev wrote:
 What does `scope` mean on a function declaration?
It applies to the `this` pointer for member methods, just like `return`. (Allthough `scope` is implicitly applied for structs IIRC)
This isn't quite right. For structs, struct S { int* ptr; int* hello() scope; static int* betty(scope ref S s); } The `this` reference is passed by `ref`. So, `hello` is exactly equivalent to `betty`. The `ref` already prevents returning the address of a struct. The `scope` prevents the return of `s.ptr` and equivalently `this.ptr`. This is likely why, in the bug report, the `ptr` field was necessary. As always, when confused about this, rewrite the code in terms of simple ref's and pointers.
Apr 27
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 27 April 2021 at 23:38:14 UTC, Walter Bright wrote:
 As always, when confused about this, rewrite the code in terms 
 of simple ref's and pointers.
I think a large part of the confusion here stems from the fact that `scope ref T` behaves very differently from `scope T*`, even though `ref T` and `T*` are the same "under the hood." safe: static int* betty(scope ref S s) { return s.ptr; } // Error static int* veronica(scope S* s) { return s.ptr; } // Ok Unfortunately, there is no documentation of this distinction in the language spec (or anywhere else, as far as I know), so the only way anyone can learn about it is through trial and error.
Apr 27
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/27/2021 5:17 PM, Paul Backus wrote:
 On Tuesday, 27 April 2021 at 23:38:14 UTC, Walter Bright wrote:
 As always, when confused about this, rewrite the code in terms of simple ref's 
 and pointers.
I think a large part of the confusion here stems from the fact that `scope ref T` behaves very differently from `scope T*`, even though `ref T` and `T*` are the same "under the hood."    safe:    static int* betty(scope ref S s) { return s.ptr; } // Error    static int* veronica(scope S* s) { return s.ptr; } // Ok Unfortunately, there is no documentation of this distinction in the language spec (or anywhere else, as far as I know), so the only way anyone can learn about it is through trial and error.
`scope` is for pointers, `ref` is for references. That's the distinction. `ref` never applies to pointers, `scope` never applies to references. (A class reference is treated as a pointer.)
Apr 27
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 28 April 2021 at 03:40:55 UTC, Walter Bright wrote:
 On 4/27/2021 5:17 PM, Paul Backus wrote:
 [...]
`scope` is for pointers, `ref` is for references. That's the distinction. `ref` never applies to pointers, `scope` never applies to references. (A class reference is treated as a pointer.)
Is that written explicitly anywhere in the docs?
Apr 29
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/29/2021 8:13 AM, Imperatorn wrote:
 Is that written explicitly anywhere in the docs?
https://github.com/dlang/dlang.org/pull/2543
Apr 30
prev sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 27 April 2021 at 05:01:09 UTC, Walter Bright wrote:
 On 4/26/2021 1:20 PM, MoonlightSentinel wrote:
 Isn't this an error that should be detected by DIP25 / 
 DIP1000? I was quite surprised that -preview=dip1000 accepted 
 this code.
The checks are defeated by the trusted function: property inout(To)* buffPtr() inout { return _ptr == useStack ? _buff.ptr : _ptr; } https://github.com/dlang/phobos/blob/master/std/internal/cstring.d#L229
Introduced in https://github.com/dlang/phobos/commit/681964cfbfb4480e756f5f40d3e9871db2469937 How old is it?
Apr 28
prev sibling next sibling parent reply Calvin P <cloudlessapp gmail.com> writes:
On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects). Rust replace c++ jobs, go replace java jobs. D need better long-term strategy.
Apr 26
next sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects). Rust replace c++ jobs, go replace java jobs. D need better long-term strategy.
it is sad but such message is put with regularity years after years. It is fun to see the rust born by reading old message in this forum. About the long-term strategy, to my understanding they works on D language and expect that someone will do the killer application «à la» ruby on rails or python datascience or java hadoop. But the problem is still here, years after years. Maybe a day …
Apr 27
prev sibling next sibling parent reply mw <mingwu gmail.com> writes:
On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects). Rust replace c++ jobs, go replace java jobs. D need better long-term strategy.
For me, D replace Python for data crutching.
Apr 27
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Tuesday, 27 April 2021 at 22:45:58 UTC, mw wrote:
 On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects). Rust replace c++ jobs, go replace java jobs. D need better long-term strategy.
For me, D replace Python for data crutching.
D do not have yet a competitive framework on Big Data «à la» Spark, datascience «à la» Pandas/Dask (pandas with multi nodes computing)
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 28 April 2021 at 10:33:43 UTC, bioinfornatics wrote:
 D do not have yet a competitive framework on Big Data «à la» 
 Spark, datascience «à la» Pandas/Dask (pandas with multi nodes 
 computing)
I've found it to be very difficult to move away from Python in general, it isn't only about frameworks but the massive amount of focused tested libraries available. For instance, I recently were to analyze a set of HRTFs (signal processing impulse responses) in a file format called SOFA, and I only found C++ and Python libraries for it. I tried to set up the C++ library, but it turned out to be time consuming, Python was just plug and play... so I ended up doing everything in numpy. At the end of the day developer time was more precious than execution time, which was somewhat slow, but not slower than the time I saved on development time. It is very difficult for any language to get there, not because of the computational aspect, but because of the interfacing, both social and technical.
Apr 28
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Wednesday, 28 April 2021 at 13:18:57 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 28 April 2021 at 10:33:43 UTC, bioinfornatics 
 wrote:
 D do not have yet a competitive framework on Big Data «à la» 
 Spark, datascience «à la» Pandas/Dask (pandas with multi nodes 
 computing)
I've found it to be very difficult to move away from Python in general, it isn't only about frameworks but the massive amount of focused tested libraries available. For instance, I recently were to analyze a set of HRTFs (signal processing impulse responses) in a file format called SOFA, and I only found C++ and Python libraries for it. I tried to set up the C++ library, but it turned out to be time consuming, Python was just plug and play... so I ended up doing everything in numpy. At the end of the day developer time was more precious than execution time, which was somewhat slow, but not slower than the time I saved on development time. It is very difficult for any language to get there, not because of the computational aspect, but because of the interfacing, both social and technical.
Exactly the strength of python is the eco-system and not a library alone. For datascience they are a rich ecosystem with pandas/dask/ray/numpy/scikitlearn as core. I see in my works when you have to choose a language is not for a killer app but for a set of library that meet our needs. This eco-system have to be easy to set as our job is to make an application with all requested feature not a try hard path to install and configure new things. And I am a D fan but for reason above I never yet be able to use D for a professional needs. Moreover we have to take in account the number of candidate to hire which would like to do a D application … Its is close to impossible to find while Rust most have never used it but it is a dreamed technology and they want to learn it with a professional use case. Recently with the declaration of linus torvald that c++ is a shit and Rust is now into to the kernel. The Rust hype growth even quickly. To me, Walter Bright or Andrei Alexandrescu have to meet Linus Torvald to shown how D is a good language. And After let the influencer Linus Torvald to do the job.
Apr 28
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 29 April 2021 at 06:46:40 UTC, bioinfornatics wrote:
 On Wednesday, 28 April 2021 at 13:18:57 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 28 April 2021 at 10:33:43 UTC, bioinfornatics 
 wrote:
 D do not have yet a competitive framework on Big Data «à la» 
 Spark, datascience «à la» Pandas/Dask (pandas with multi 
 nodes computing)
I've found it to be very difficult to move away from Python in general, it isn't only about frameworks but the massive amount of focused tested libraries available. For instance, I recently were to analyze a set of HRTFs (signal processing impulse responses) in a file format called SOFA, and I only found C++ and Python libraries for it. I tried to set up the C++ library, but it turned out to be time consuming, Python was just plug and play... so I ended up doing everything in numpy. At the end of the day developer time was more precious than execution time, which was somewhat slow, but not slower than the time I saved on development time. It is very difficult for any language to get there, not because of the computational aspect, but because of the interfacing, both social and technical.
Exactly the strength of python is the eco-system and not a library alone. For datascience they are a rich ecosystem with pandas/dask/ray/numpy/scikitlearn as core. I see in my works when you have to choose a language is not for a killer app but for a set of library that meet our needs. This eco-system have to be easy to set as our job is to make an application with all requested feature not a try hard path to install and configure new things. And I am a D fan but for reason above I never yet be able to use D for a professional needs. Moreover we have to take in account the number of candidate to hire which would like to do a D application … Its is close to impossible to find while Rust most have never used it but it is a dreamed technology and they want to learn it with a professional use case. Recently with the declaration of linus torvald that c++ is a shit and Rust is now into to the kernel. The Rust hype growth even quickly. To me, Walter Bright or Andrei Alexandrescu have to meet Linus Torvald to shown how D is a good language. And After let the influencer Linus Torvald to do the job.
I am afraid it might be already too late by now, https://security.googleblog.com/2021/04/rust-in-android-platform.html https://docs.microsoft.com/en-us/windows/dev-environment/rust
Apr 29
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 29 April 2021 at 12:32:25 UTC, Paulo Pinto wrote:
 On Thursday, 29 April 2021 at 06:46:40 UTC, bioinfornatics 
 wrote:
 [...]
I am afraid it might be already too late by now, https://security.googleblog.com/2021/04/rust-in-android-platform.html https://docs.microsoft.com/en-us/windows/dev-environment/rust
It's so strange to me that Rust is everywhere. Like, it's "ok", but not really more than that. Also, productivity isn't really great compared to D for example imo. What *is* a plus for Rust tho is the ecosystem, but maybe D can improve there in time? *dreaming*
Apr 29
parent reply throway <thro way.way> writes:
On Thursday, 29 April 2021 at 15:18:50 UTC, Imperatorn wrote:
 On Thursday, 29 April 2021 at 12:32:25 UTC, Paulo Pinto wrote:
 On Thursday, 29 April 2021 at 06:46:40 UTC, bioinfornatics 
 wrote:
 [...]
I am afraid it might be already too late by now, https://security.googleblog.com/2021/04/rust-in-android-platform.html https://docs.microsoft.com/en-us/windows/dev-environment/rust
It's so strange to me that Rust is everywhere. Like, it's "ok", but not really more than that. Also, productivity isn't really great compared to D for example imo. What *is* a plus for Rust tho is the ecosystem, but maybe D can improve there in time? *dreaming*
the biggest invention in static-typing is templates, you can forgive c++ for the ugly syntax and the shorcomings since they had no idea at the time, what excuse do the new languages have? rust looks almost as ugly as c++ and afaik only d got templates right. i have nothing against optional gc but knowing the code-generation powers of d plus RAII, you would think gc would be a secondary concern, because you finally have the tools to eliminate most of the memory issues that plagues c/c++.
Apr 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 12:21:05 UTC, throway wrote:
 the biggest invention in static-typing is templates, you can 
 forgive c++ for the ugly syntax and the shorcomings since they 
 had no idea at the time, what excuse do the new languages have? 
 rust looks almost as ugly as c++ and afaik only d got templates 
 right.
Hm. I think D templates are rather close to C++. What aspects of D templating do you think makes a difference?
 i have nothing against optional gc but knowing the 
 code-generation powers of d plus RAII, you would think gc would 
 be a secondary concern, because you finally have the tools to 
 eliminate most of the memory issues that plagues c/c++.
I don't really have memory issues in C++, if I do it tends to be related to issues that can only be easily solved by a GC... (E.g. ownership not being obvious and avoiding circular reference being difficult)
Apr 30
next sibling parent reply throway <thro way.way> writes:
On Friday, 30 April 2021 at 12:35:42 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 30 April 2021 at 12:21:05 UTC, throway wrote:
 the biggest invention in static-typing is templates, you can 
 forgive c++ for the ugly syntax and the shorcomings since they 
 had no idea at the time, what excuse do the new languages 
 have? rust looks almost as ugly as c++ and afaik only d got 
 templates right.
Hm. I think D templates are rather close to C++. What aspects of D templating do you think makes a difference?
please do not say that out loud, in every aspect c++ templates to d is horse to a ufo where your task is intergalactic travel. and i am sure the trend will continue no matter the version, c++999 will probably be at where d is now.
Apr 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 12:50:17 UTC, throway wrote:
 please do not say that out loud, in every aspect c++ templates 
 to d is horse to a ufo where your task is intergalactic travel.
Ok? I guess I just have to take your word for it, but it doesn't make me any wiser. I think they are mostly the same and use mostly the same mechanisms, some differences, but whether one approach is better than the other depends on what you are trying to do. My opinion.
 and i am sure the trend will continue no matter the version, 
 c++999 will probably be at where d is now.
I think C++20/23 is moving in a different direction than D and I don't think D should follow suit, but rather find its own strengths.
Apr 30
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 30 April 2021 at 15:47:19 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 30 April 2021 at 12:50:17 UTC, throway wrote:
 please do not say that out loud, in every aspect c++ templates 
 to d is horse to a ufo where your task is intergalactic travel.
Ok? I guess I just have to take your word for it, but it doesn't make me any wiser. I think they are mostly the same and use mostly the same mechanisms, some differences, but whether one approach is better than the other depends on what you are trying to do. My opinion.
 and i am sure the trend will continue no matter the version, 
 c++999 will probably be at where d is now.
I think C++20/23 is moving in a different direction than D and I don't think D should follow suit, but rather find its own strengths.
+1 for this. D should be the "sane" alternative. Like allow low level stuff, but also enable high productivity and safety. I think that's an area where D could be/is great. Also more embedded focus imo.
Apr 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 16:29:09 UTC, Imperatorn wrote:
 +1 for this. D should be the "sane" alternative. Like allow low 
 level stuff, but also enable high productivity and safety. I 
 think that's an area where D could be/is great.
I found it interesting that several people want async/await in D. I have only limited experience with async/await, but people seem to be enthusiastic about it.
 Also more embedded focus imo.
Then one should target one platform such as Arduino and do it really well for that platform. To reach the embedded audience on would need a smaller default runtime I think. Also solid support for fixed allocations and proving stack depth is wanted in that area. A task-based system is actually quite useful in that space. All preallocated, allow suspension only when the stack is empty, put all other variables in the task-object. (Basically a stackless coroutine.)
Apr 30
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Friday, 30 April 2021 at 16:36:26 UTC, Ola Fosheim Grøstad 
wrote:
 I found it interesting that several people want async/await in 
 D. I have only limited experience with async/await, but people 
 seem to be enthusiastic about it.
Maybe it would be cool, but I have no idea how to use it. I'm still using dlangui, and this means it has to be build on top of dlangui event loop, or dlangui moved to new standard, I also had vibe.d/dlangui mixed app as well, where should I put event loop now? The good thing, vibe.d has accounted for this (handle messages function to manually process messages from external event loop). Same with existing solutions, I kind of want it, but unfortunately limited to something like this copy pasted all over my app... ```d void handleDrop(string[] files) { import std.file; auto paths = files.filter!(exists).array; paths.each!(path => _images[path] = null); if (paths.length < 1) return; // async, yay auto loadTask = task!( (path) { App.instance.onImageLoaded(path, loadImage(path)); })(paths[0]); loadTask.executeInNewThread(); } private void onImageLoaded(string path, ColorDrawBuf data) { _images[path] = data; setCurrentImage(path); } void setCurrentImage(string file) { _activeImage = file; // execute on next gui event imageView.executeInUiThread({ imageView.setImage(_images[file]); }); // even more async, yay \0/ auto detectorTask = task!((s) { opencv.run_objectedetector(s); App.instance.onDetectFinished(); })(detector); detectorTask.executeInNewThread(); } private void onDetectFinished() { dstring text; foreach(det; detector.detections){ text ~= format!"%s [%s%%] %s\n"d(det.label, det.accuracy * 100f, det.rect); } // update text on next gui event editBox.executeInUiThread({ editBox.text = text; imageView.invalidate(); }); } ```
Apr 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 17:27:57 UTC, evilrat wrote:
 Maybe it would be cool, but I have no idea how to use it. I'm 
 still using dlangui, and this means it has to be build on top 
 of dlangui event loop, or dlangui moved to new standard, I also 
 had vibe.d/dlangui mixed app as well, where should I put event 
 loop now?
So, having an overview over how existing applications are structured would be important for writing a DIP. So you experience here could be useful, I would think?
Apr 30
parent reply evilrat <evilrat666 gmail.com> writes:
On Friday, 30 April 2021 at 18:27:27 UTC, Ola Fosheim Grøstad 
wrote:
 So, having an overview over how existing applications are 
 structured would be important for writing a DIP. So you 
 experience here could be useful, I would think?
No, not me. That was just an example on how it currently looks like. And that one important details is to make sure there should be a way to manually run one loop iteration (aka process events) from outside in such cases as above. Can't find that project now, but I have another simple prototype, too bad it simply runs new thread, so this means actually no integration. No surprises then, no common API, nothing to agree upon on for different loops :/ ```d // Minimal vibe.d example using worker thread parallel to UI thread void runServer() { auto settings = new HTTPServerSettings; settings.port = 8080; listenHTTP(settings, &handler); try while(processEvents()) receiveTimeout( msecs(10), (TaskTerm term) { exitEventLoop(); } ); catch (OwnerTerminated e) Log.i("exiting worker thread due to owning thread stop"); } ```
Apr 30
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 30 April 2021 at 18:52:50 UTC, evilrat wrote:
 Can't find that project now, but I have another simple 
 prototype, too bad it simply runs new thread, so this means 
 actually no integration. No surprises then, no common API, 
 nothing to agree upon on for different loops :/
Welcome to the dub ecosystem, where every library reinvents the same abstractions since there's no standard baseline for libraries to support; may not work across all platforms (esp Windows); probably has deficiencies for common/specific use cases, and probably hasn't been updated within the last 2 years, and so newer libraries reinvent the same abstractions since... etc. Basically feels like this XKCD when searching on dub: https://xkcd.com/927/
Apr 30
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Friday, 30 April 2021 at 22:19:25 UTC, SealabJaster wrote:
 On Friday, 30 April 2021 at 18:52:50 UTC, evilrat wrote:
 Can't find that project now, but I have another simple 
 prototype, too bad it simply runs new thread, so this means 
 actually no integration. No surprises then, no common API, 
 nothing to agree upon on for different loops :/
Welcome to the dub ecosystem, where every library reinvents the same abstractions since there's no standard baseline for libraries to support; may not work across all platforms (esp Windows); probably has deficiencies for common/specific use cases, and probably hasn't been updated within the last 2 years, and so newer libraries reinvent the same abstractions since... etc. Basically feels like this XKCD when searching on dub: https://xkcd.com/927/
See also, The Lisp Curse: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Apr 30
prev sibling parent evilrat <evilrat666 gmail.com> writes:
On Friday, 30 April 2021 at 22:19:25 UTC, SealabJaster wrote:
 On Friday, 30 April 2021 at 18:52:50 UTC, evilrat wrote:
 Can't find that project now, but I have another simple 
 prototype, too bad it simply runs new thread, so this means 
 actually no integration. No surprises then, no common API, 
 nothing to agree upon on for different loops :/
Welcome to the dub ecosystem, where every library reinvents the same abstractions since there's no standard baseline for libraries to support; may not work across all platforms (esp Windows); probably has deficiencies for common/specific use cases, and probably hasn't been updated within the last 2 years, and so newer libraries reinvent the same abstractions since... etc. Basically feels like this XKCD when searching on dub: https://xkcd.com/927/
And we have std.allocator on the other hand, but because there is who knows how old compiler version in the wild still alive, in practice "everyone" just uses stdx.allocator from dub.
Apr 30
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 30 April 2021 at 16:36:26 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 30 April 2021 at 16:29:09 UTC, Imperatorn wrote:
 [...]
I found it interesting that several people want async/await in D. I have only limited experience with async/await, but people seem to be enthusiastic about it.
 [...]
Then one should target one platform such as Arduino and do it really well for that platform. To reach the embedded audience on would need a smaller default runtime I think. Also solid support for fixed allocations and proving stack depth is wanted in that area. A task-based system is actually quite useful in that space. All preallocated, allow suspension only when the stack is empty, put all other variables in the task-object. (Basically a stackless coroutine.)
The only reason basically I want async/await in D is so that I It's kind of a blocker as it is today 😔
Apr 30
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 30 April 2021 at 15:47:19 UTC, Ola Fosheim Grøstad 
wrote:
 I think C++20/23 is moving in a different direction than D and 
 I don't think D should follow suit, but rather find its own 
 strengths.
What direction is that in your opinion? What I've seen so far is that C++ has copied several features from D, like modules and if constexpr.
Apr 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 17:20:35 UTC, IGotD- wrote:
 What direction is that in your opinion? What I've seen so far 
 is that C++ has copied several features from D, like modules 
 and if constexpr.
There is a focus on "low level" concurrency building blocks, at least that is my impression. I don't think they copied modules or if constexpr, it is just that the adoption process in an ISO process is very slow? I think D should focus more on streamlining the low level and make high level easier. E.g. async/await, tasks, local GC, as high level constructs, but allow the user to write their own runtimes and schedulers. So the API has to be concise.
Apr 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 17:41:31 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 30 April 2021 at 17:20:35 UTC, IGotD- wrote:
 What direction is that in your opinion? What I've seen so far 
 is that C++ has copied several features from D, like modules 
 and if constexpr.
There is a focus on "low level" concurrency building blocks, at least that is my impression.
Stuff like this: https://www.modernescpp.com/index.php/a-short-detour-executors
Apr 30
prev sibling parent reply sighoya <sighoya gmail.com> writes:
On Friday, 30 April 2021 at 12:35:42 UTC, Ola Fosheim Grøstad 
wrote:

 I don't really have memory issues in C++, if I do it tends to 
 be related to issues that can only be easily solved by a GC... 
 (E.g. ownership not being obvious and avoiding circular 
 reference being difficult)
At some expert level, you would exhibit this kind of confidence. However, only for the code you write. The problem lies in semantic shadowing by different kinds of casts to raw pointer coupled with different memory management strategies among the frameworks. Passing a pointer given by framework A to B doesn't mean A and B share the same assumptions about managing the pointer.
Apr 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 14:59:46 UTC, sighoya wrote:
 At some expert level, you would exhibit this kind of confidence.
Yes, C++ is only suitable for professional programmers... It isn't a "friendly" language at all.
 However, only for the code you write.
 The problem lies in semantic shadowing by different kinds of 
 casts to raw pointer coupled with different memory management 
 strategies among the frameworks.
 Passing a pointer given by framework A to B doesn't mean A and 
 B share the same assumptions about managing the pointer.
This is probably true. I don't use frameworks (beyond the basic system level ones). I don't really view C++ as a stand-alone language, except for very focused applications like compilers or image conversion). I think what it is best at is the same as C, to augment other languages. E.g. to provide more speed to Swift.
Apr 30
prev sibling parent Bienlein <ffm2002 web.de> writes:
On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
 On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects). Rust replace c++ jobs, go replace java jobs. D need better long-term strategy.
 Rust replace c++ jobs
No
 go replace java jobs.
Not at all.
Apr 30
prev sibling next sibling parent Kagamin <spam here.lot> writes:
STL can be reasonably seen as C heritage too as it was 
intentionally designed to be unsafe by default, and now it's kept 
for consistency.
Apr 26
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
 https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

 Lists some perfectly reasonable code in Modern C++ style that 
 has hidden memory safety bugs.
Not at all reasonable to take a borrowing reference from a temporary... string_view is not owning. C++ does not use the compiler to check for memory safety issues. Ownership in C++ is a library concept, not a language concept. C++ is more geared towards using linters for such things. Or rather, that is what is being suggested by providing annotations for owning/non-wning references.
Apr 27