On Tuesday, 3 November 2020 at 06:04:26 UTC, norm wrote:
>
> Just going to pick on this para. sorry :)
>
> I hear this a lot and it is simply not true. Working in embedded for the last ~18yrs (automotive and medical) every project since 2010 I know of is C++. At conferences and the like over the last 2-3yrs there is a lot of talk about Rust and people are starting to mention MicroPython for prototyping. But as a whole everyone I talk to is looking forward to upgrading their C++ compilers on the next project to get C++20 features.
>
> Every C++ embedded project I have ever seen has exceptions turned off.

It's funny that they talk about C++20 in the embedded environment but many features cannot be used because of STL. STL is just like phobos and will become just as big if you statically link with it. Turning exceptions off also means that many parts of the STL library will be dysfunctional. Usually you need specialized libraries.

Modern C++ is even more of a mess because they have moved much of the functionality to the STL library. std::move for example is a library template, which can be duplicated outside of course but still you need to do that with a lot of functions. Even statically compiled primitives are library templates today with some inunderstandable implementation underneath. STL is this big blob that can include all sort of things that you don't expect even for simple primitives.

Apart of a the ugliness of modern C++, many of the modern features are implemented in such a way it is difficult to make it freestanding from STL. You do not want STL in embedded systems.

Is modern C++ good for embedded systems? No, you need to slice of half of the new features because of the reasons I mentioned above.

On Tuesday, 3 November 2020 at 10:25:15 UTC, IGotD- wrote:
> On Tuesday, 3 November 2020 at 06:04:26 UTC, norm wrote:
>>
>> Just going to pick on this para. sorry :)
>>
>> I hear this a lot and it is simply not true. Working in embedded for the last ~18yrs (automotive and medical) every project since 2010 I know of is C++. At conferences and the like over the last 2-3yrs there is a lot of talk about Rust and people are starting to mention MicroPython for prototyping. But as a whole everyone I talk to is looking forward to upgrading their C++ compilers on the next project to get C++20 features.
>>
>> Every C++ embedded project I have ever seen has exceptions turned off.
>
> It's funny that they talk about C++20 in the embedded environment but many features cannot be used because of STL. STL is just like phobos and will become just as big if you statically link with it. Turning exceptions off also means that many parts of the STL library will be dysfunctional. Usually you need specialized libraries.
>
> Modern C++ is even more of a mess because they have moved much of the functionality to the STL library. std::move for example is a library template, which can be duplicated outside of course but still you need to do that with a lot of functions. Even statically compiled primitives are library templates today with some inunderstandable implementation underneath. STL is this big blob that can include all sort of things that you don't expect even for simple primitives.
>
> Apart of a the ugliness of modern C++, many of the modern features are implemented in such a way it is difficult to make it freestanding from STL. You do not want STL in embedded systems.
>
> Is modern C++ good for embedded systems? No, you need to slice of half of the new features because of the reasons I mentioned above.

To be fair same applies to C, hence C89 + OEM extensions.

In some domains even C11 is a challenge regarding adoption, as per the reports I usually read.

On Tuesday, 3 November 2020 at 10:25:15 UTC, IGotD- wrote:
> Apart of a the ugliness of modern C++, many of the modern features are implemented in such a way it is difficult to make it freestanding from STL. You do not want STL in embedded systems.

Which C++ features depend on STL? I can't think of any... STL is ok for protyping.
They are working on providing exceptions as return values for embedded.

D needs that as well.

> Is modern C++ good for embedded systems?

Define modern C++?

On 11/3/2020 2:25 AM, IGotD- wrote:
> Is modern C++ good for embedded systems? No, you need to slice of half of the new features because of the reasons I mentioned above.

I can't say that D does this better. Phobos is overly complex and layered. DasBetterC at least relies only on the existence of the C standard library, and really not even that.

On Tuesday, 3 November 2020 at 05:26:51 UTC, Walter Bright wrote:

> It's been said that eventually all languages tend to adopt all the features of Lisp. But that doesn't mean that Lisp popularized those features. After all, Lisp is one of the original programming languages, and if it popularized CTFE then C, C++, Pascal, etc., would have had it long ago.

Ok, you have a point.

On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:

> I was wondering if it worthwhile branding -betterC differently - e.g. use a brand such as 'micro-D' or some nicer name. That is, give it a new identity that highlights that it not just better C  - but a D version without GC.

Early next year I am hoping to start a fork of D - the idea is to simply create a new version that has better C option baked in - i.e. full D will be optional.

Looking a for a new name for this subset of D.

Dig
Deal
Delite

Any suggestions for a name?

My plan is to keep the effort low by:
a) just creating new name
b) change the default for option for betterC
c) create a cut-down distro that works with betterC

On Saturday, 31 October 2020 at 16:22:32 UTC, Paulo Pinto wrote:
> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>
>> D popularized CTFE, and other languages followed suit, including Jai.
>
> Sorry but that flag belongs to Lisp and Dylan macros, Java compiler plugins, Java/.NET manipulation of attributes/annotations and C++ template meta-programing.
>
> D CTFE has definitely a very important value, but not everything that other languages adopt was created by D.

You are mixing things. C# attributes and Java annotations are not even close to have the same capabilities as CTFE, nor they work in the same way.

Reading your posts/responses, it looks like you are one of those guys that tries so hard to look smart and ends up writing a lot of wrong information and throws random references.

On Wednesday, 4 November 2020 at 11:23:36 UTC, Dibyendu Majumdar wrote:
> On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:
> Any suggestions for a name?
>
> My plan is to keep the effort low by:
> a) just creating new name
> b) change the default for option for betterC
> c) create a cut-down distro that works with betterC

Feel free to share your ideas, maybe as issues, on this experimental repo:

https://github.com/OlaFosheimGrostad/dex

Nothing is set in stone and I won't have time to play with it until late December anyway. I call it «Dex» for «D-experimental» or «D-extended».

I am thinking about limiting it to Better-D with classes and return-exceptions. So that it will compile most existing D code, but with a small runtime that is embedded friendly.

I'd like to add more sanitizers, maybe borrowing code from clang.

On Wednesday, 4 November 2020 at 13:06:58 UTC, J. V. wrote:
> On Saturday, 31 October 2020 at 16:22:32 UTC, Paulo Pinto wrote:
>> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>>
>>> D popularized CTFE, and other languages followed suit, including Jai.
>>
>> Sorry but that flag belongs to Lisp and Dylan macros, Java compiler plugins, Java/.NET manipulation of attributes/annotations and C++ template meta-programing.
>>
>> D CTFE has definitely a very important value, but not everything that other languages adopt was created by D.
>
> You are mixing things. C# attributes and Java annotations are not even close to have the same capabilities as CTFE, nor they work in the same way.
>
> Reading your posts/responses, it looks like you are one of those guys that tries so hard to look smart and ends up writing a lot of wrong information and throws random references.

I am one of those guys that knows for the large majority of mainstream developers C# attributes and Java annotations do the job, even though they aren't even close to have the same capabilities as CTFE.

I am also one of those guys that still bothers to advocate D when the opportunity comes, but take it as you will.

BetterC has many flaws

- you have to be explicit in your code with @betterC @noGC etc etc etc, it's ugly and  annoying

- GC is still predominant everywhere (AA, arrays, string, libraries)

I am testing ZIG since last month, and let me tell you what, it is what i wanted D to be

NO GC at all! custom allocator friendly

I don't mind having the GC in D when i just want to quickly prototype something, or write a CLI tool

But for anything else, i rely on betterC and the experience is very very very poor!


Before thinking about better branding, what needed is: FIX IT! and make it cleaner


And most importantly! it shouldn't be called betterC, it should be called D, plain simple, just D!

Move the GC as a separate library, and make it opt-in rather than opt-out

Language should be simple, so you can do everything you want as a library (GC, RC)

I still have hopes for D as my main language, but the no gc story needs to be sorted ASAP


But to be very very honest, i doubt that'll ever happen, even NIM is handing that story better..