April 30, 2021
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.


April 30, 2021
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.

April 30, 2021
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
April 30, 2021
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.
April 30, 2021
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.

April 30, 2021
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.


April 30, 2021
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.
April 30, 2021
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.)


April 30, 2021
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.
April 30, 2021

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


    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();
      });
    }