June 02, 2022
On Thu, Jun 02, 2022 at 04:45:04PM +0000, monkyyy via Digitalmars-d wrote:
> On Thursday, 2 June 2022 at 14:24:00 UTC, Guillaume Piolat wrote:
> > Sometimes it feels like people with a conservative bias live in a world where only "established" languages and brands exist.
> 
> Sometimes it feels like people with a commie bias live in a world where all the established languages will be trivially replaced by the next thing they think up

+1, LOL. :-D


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
June 02, 2022
On Thu, Jun 02, 2022 at 05:00:35PM +0000, IGotD- via Digitalmars-d wrote:
> On Thursday, 2 June 2022 at 10:36:24 UTC, twinbee wrote:
> > Quote from Elon Musk on Twitter:
> > 
> > "Side note: I hate the bloated mess that is modern C++, but love simple C, as you know what it will compile to in terms of actual CPU operations."
> > 
> > Source: https://twitter.com/elonmusk/status/1532274289893904384
> 
> While I can understand the frustration of modern C++, the right tool for the right job is more important. Try doing string manipulation with the C standard library, in that case I would pick C++ over C any day. C is not always simpler.

C++?  And string manipulation?  In the same sentence??

You make me cringe. :-/

(Now, if it was *D* and string manipulation in the same sentence, it
would be a different story. ;-))


T

-- 
Computers aren't intelligent; they only think they are.
June 02, 2022
On Thursday, 2 June 2022 at 13:38:27 UTC, Araq wrote:
> On Thursday, 2 June 2022 at 11:51:30 UTC, forkit wrote:
>> On Thursday, 2 June 2022 at 10:36:24 UTC, twinbee wrote:
>>>
>>
>> Well, you know what they say:
>>
>> "The weakness of the C language comes from its strength"
>
> Assembly instruction `mov rcx, [rax]`. Cost: 1 cycle. Or 500.
>
> It's not 1980 anymore, there is hardly a benefit in looking at the assembler, you need to measure things. Musk is surprisingly bad at working from "first principles" sometimes.

Can even be zero on Zen3 with the stack to register file optimization.
June 02, 2022
On Thursday, 2 June 2022 at 17:26:43 UTC, H. S. Teoh wrote:
>
> C++?  And string manipulation?  In the same sentence??
>
> You make me cringe. :-/
>
> (Now, if it was *D* and string manipulation in the same sentence, it
> would be a different story. ;-))
>
>
> T

I know it's a bit strange because C++ is actually much better than C (not even mentioning the security hazards). That's why I like D because in this case it's much better than C++.
June 03, 2022
On Thursday, 2 June 2022 at 17:42:42 UTC, IGotD- wrote:
> I know it's a bit strange because C++ is actually much better than C (not even mentioning the security hazards). That's why I like D because in this case it's much better than C++.

?

Isnt c++ extremely slow? Like c++ adopts every feature and like thats .... fine; but it can never be good
June 03, 2022

On Friday, 3 June 2022 at 19:24:03 UTC, monkyyy wrote:

>

Isnt c++ extremely slow? Like c++ adopts every feature and like thats .... fine; but it can never be good

No, C++ is similar to C in performance, in theory C++ could do better than C because of stricter typing, but I don’t think compilers exploit that. It would break existing code...

Most new C++ features are either syntax sugar or library additions, relatively few new features. Although stackless coroutines is a major recent one.

June 03, 2022

On Friday, 3 June 2022 at 19:55:48 UTC, Ola Fosheim Grøstad wrote:

>

On Friday, 3 June 2022 at 19:24:03 UTC, monkyyy wrote:

>

Isnt c++ extremely slow? Like c++ adopts every feature and like thats .... fine; but it can never be good

No, C++ is similar to C in performance, in theory C++ could do better than C because of stricter typing, but I don’t think compilers exploit that. It would break existing code...

Most new C++ features are either syntax sugar or library additions, relatively few new features. Although stackless coroutines is a major recent one.

I meant compile speeds, adopting every feature will make a slow compiler and I dont want to spend an hour waiting

June 03, 2022
On Friday, 3 June 2022 at 19:24:03 UTC, monkyyy wrote:
> On Thursday, 2 June 2022 at 17:42:42 UTC, IGotD- wrote:
>> I know it's a bit strange because C++ is actually much better than C (not even mentioning the security hazards). That's why I like D because in this case it's much better than C++.
>
> ?
>
> Isnt c++ extremely slow? Like c++ adopts every feature and like thats .... fine; but it can never be good

When it comes to strings? Depends what you are doing and how you are doing it. C++ made a strange decision to include the null terminator at the end of the strings even if it isn't really necessary. The result is that you cannot slice strings and can lead to unnecessary deep copies. In order avoid this C++ invented string_view and associated literals. Now you suddenly have two types of strings and if you make an API you might have to support both string and string_view. This is one of the crazy things with "modern C++". Still it is more user friendly than the old C library strings which also are prone to buffer overflows.

D in this case did the right choice not including the null terminator so that you can slice strings all you want and no extra string view.
June 03, 2022
On Friday, 3 June 2022 at 20:12:01 UTC, IGotD- wrote:
> On Friday, 3 June 2022 at 19:24:03 UTC, monkyyy wrote:
>> On Thursday, 2 June 2022 at 17:42:42 UTC, IGotD- wrote:
>>>
>>> ****I know it's a bit strange because C++ is actually much better than C****
>>>
>> ?
> When it comes to strings?

no, c > c++ in general because the sanest way to use c++ is as c + one or two features and c++ will be extremely slow to compile and iterate on.

C is an extremely high bar, c++ "spread itself to thin", "has to many cooks", "jack of all trades, master of none"


June 03, 2022

On Friday, 3 June 2022 at 20:04:37 UTC, monkyyy wrote:

>

I meant compile speeds, adopting every feature will make a slow compiler and I dont want to spend an hour waiting

If you write you own libraries and break dependencies then you can get decent compilation speeds, but many existing code bases #include way too much leading to many pointless dependencies and slower builds.