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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021