betterC becoming unusable (page 2)

On Monday, 7 November 2022 at 09:35:25 UTC, zjh wrote:

On Monday, 7 November 2022 at 09:12:51 UTC, Imperatorn wrote:

I'm also in favor of "fixing" betterC because of similar reasons

There are several betterC container libraries. If they are integrated into the standard library, it would be cool. With the powerful template function, they are not much worser than C++.
If the 'C++' is well interfaced, it is really cool.
Because C++ has several inherent defects. betterC can be more comfortable.
C++'s shortcomings is that you have to use ugly macros anyway.
while 'rust' has ugly syntax, unnecessary wordy lifetime, dependency hell, and slow compilation speed.I don't Why do these people like it?

Mostly because it is an ML inspired language with C++ like capabilities, a cool type system, but above all, it doesn't matter how it looks, because a bunch of big corporations decided it was going to be their C++ replacement, and it already powers part of Android, AWS and Azure.

Just like I am not a big Go fan, yet due to CNCF products, it landed on my plate as well.

On Monday, 7 November 2022 at 12:46:08 UTC, Alexandru Ermicioi wrote: > Doesn't mean that they are doing something right. They should just replace all char* with ubyte* in D for any C header they use, if they just simply cast them, then compiler could spot them when used with string only methods. > > Best would be if such mixing between non utf and utf would not be so easy to do, and that would force user to think twice. I agree, but changing the headers in core.stdc now would break a lot of existing code, so I don't think it's likely to happen.

November 07, 2022

Re: betterC becoming unusable

Posted by Steven Schveighoffer
in reply to rikki cattermole

Permalink

Steven Schveighoffer

Posted in reply to rikki cattermole

Permalink

On 11/7/22 4:50 AM, rikki cattermole wrote:

On 07/11/2022 4:59 PM, Steven Schveighoffer wrote:

Array comparison sometimes fails to link. That's right string1 == string2 may fail depending on whether the compiler decides that the support template in druntime needs to be emitted to the object file. This is unacceptable. If I have to use strcmp in betterC, I might as well just use C.

Lets dig a bit.

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/comparison.d

It is templated (so it should already be emitting correctly).

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/string.d#L239

Also templated.

Yes, it's the template that is not being emitted. Whatever the reason, it's unacceptable.

But why on earth is UTF-8 strings specially cased and not UTF-16 or UTF-32?

Thats not right...

No sanitization, its basically just byte for byte comparison. Which is the wrong way to compare Unicode strings anyway (and requires the tables)!

An array comparison is an array comparison, regardless of element type. I want to see if my array of code units is exactly the same as another array of code units. I don't care about sanitization because that's not what I'm asking for. I don't need unicode tables to tell me if "4.2.0" is the same as "4.2.0".

This focus on unicode is a complete distraction, pretend it's a byte array, same problem.

-Steve

Forums