Modern C++ Won't Save Us (page 5)

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 can port C# to D. It's kind of a blocker as it is today 😔

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.

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

April 30, 2021

Re: Modern C++ Won't Save Us

Posted by evilrat
in reply to Ola Fosheim Grøstad

Permalink

evilrat

Posted in reply to Ola Fosheim Grøstad

Permalink

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 :/


// 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");
}

On Friday, 30 April 2021 at 22:19:25 UTC, SealabJaster wrote:

On Friday, 30 April 2021 at 18:52:50 UTC, evilrat wrote:

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.

Forums