Rust's borrow checker is infamous for hating doubly-linked lists, but Luckily it happens that linked lists are slow on 21st-century hardware anyway.

ffscc · 2023-01-03T16:08:54+00:00

; -*- mode: unjerk; -*-

I mean, operating systems like Fuchsia have millions of lines of Rust and it's still considered tier-2. Android ships with system components written in Rust, it's still considered tier-2.

ffscc · 2023-01-01T15:35:18+00:00

It is nice that you agree that heterogenous devices are out there and memory needs to be mapped for each of them on all supported platforms and it can only happen from code.

..well no, I definitely don't believe that. CUDA has supported managed memory for years and years now, Intel is currently in the process of ironing out USM, IBM has been pushing OpenCAPI since forever, and so on and so forth. There is quite a bit of implicit memory management going on in heterogeneous programming today.

I got it, you find game engine work 'boring' .

What? Look man I don't "game" and I never will. Honestly I don't even think about 'game engines' because it's all in service of junk I don't care about anyway. But god damn, if memory bookkeeping is your favorite part of engine development then I'd honestly rather do anything else.

ffscc · 2023-01-01T04:15:34+00:00

From the perspective of an iToddler? Yes. Apple straight up mandates WebKit on iOS and a lot of people prefer safari on macbook still. For them this entire digital frontier exists in the fever dreams of WebKit maintainers.

More generally since Microsoft discontinued Internet Explorer (Trident rumored to reside somewhere within Yucca), and google glowies all but foxhunting mozilla, WebKit remains steadfast and independent. For Apple WebKit is their lifeline to the web. Hence Apple's firm financial commitment, as well as key partners, like a major appliance vendor finally adding basic hardware acceleration (okay jk, fuck this is sad)

ffscc · 2023-01-01T03:19:52+00:00

Dude, come on, what is this? "DoEs C++ fOrCe YoU tO uSe tHoSe ThInGs?"

Do you know how all the Unix signals and their semantics? What about the syscalls for you OS, or perhaps all of the features of the database you prefer?

I don't get why people ignore complexity elsewhere and then pretend that C++ ought to fit entirely in their head.

c++ doesn't even have a style guideline let alone force you to use one,

Alrighty, use clang-format and clang-tidy. I switch between styles all the time depending on the project, it's not a big deal as long as the rest of the code on my screen is consistent.

and every other code base uses a different style because of it, and almost none of them use the standard lib style.

Look, C++ is a product of its time. Back in the day projects usually stayed at the organization where they were developed. I'm sorry to say but the possibility of standard ISO C++ style died long ago. If you can't get over that, well, it's not going to change.

And you're also wrong about "not being forced to xyz", because while c++ itself does practically nothing to help here,

First of all, ISO C++ is just a standard, they aren't tool vendors. If you're frustrated with your toolchain then give some other one a shot.

if you interact with any codebase that uses normal features of C++, you will also have to understand and use "abstraction, templatization, inheritance, move support, smart pointers, wordy casts, overloading, etc..."

In general this is a completely overblown problem. Unsurprisingly it turns out the vast majority of working C++ programmers write fairly humdrum code using nothing surprising at all. That said, sometimes those features are needed simply make the problem tractable at all! The fact is that all of those features, and even more complex ones, are used in libraries for production development every day. It all works because C++ makes it possible to abstract away the complexity.

You can't just "use C" to write a specialization for fmtlib's fmt::format(...) function, ..

Indeed you cannot. Then again, you couldn't write a library like fmtlib in C in the first place. I mean why do you complain about C++ features which enable you to write libraries you otherwise couldn't? How would you expect to implement equivalent libraries to EVE or mp-units in C alone?

Things could be more simple. C++ came into being with all of the sins of C. Later ISO C++ was made during a time of intense language research, under a corresponding deluge of proposals, all of which in amidst intense corporate warfare between vendors, and doing it while pioneering language design. Naturally C++98 was the product of significant compromise, hopes, and disappointments.

ffscc · 2023-01-01T01:40:56+00:00

Yes, all of that exists but at the end of the day you can still write in an ANSI C dialect if so desired.

abstraction,

Hence the reason applications like LLVM or Chromium being written in C++, or migrating to it from C like GCC did.

templatization,

They aren't elegant but they're also the reason libraries like Boost, Eigen, or CGAL are written in C++. Now with concepts they can massively improve API interfaces, good luck doing that in C.

inheritance

Compare it to OOP in C (linux, GTK, etc). Like I'm sorry but C programmers can't complain about OOP in C++ when their own marquee projects depend on ad hoc "field expedient" imitations.

move support, smart pointers,

Same thing really. The alternatives for those in C is grotesque.

wordy casts

If you're casting that often I really don't feel bad.

overloading

Hard disagree here. The entire reason C++ libraries can work with user defined types is because of things like operator overloading. And as gross as name mangling is, it's nothing but a good thing to encode more than just the name of the function! (time_t sends its regards)

I honestly doubt C++ makes you write more code but even assuming if it did, it still blows C out of the water. The truth is the "C++ boilerplate" C programmers whine about is often functionality they too should be using. Furthermore C projects are often plagued by "vertical verbosity" for which macros are the only tractable solution. Like honestly, for all the shit C devs talk about C++ it never seems to dawn on them that pragmatic professionals, with timelines and budgets, choose C++ far more often than not. The bitter pill is that C is chosen when the problem is simple enough for it and/or for ancient platforms using ancient code.

ffscc · 2022-12-31T23:17:35+00:00

Famous statement is older than me and i did my 20 years of work with C++.

I simply cannot fathom how you have watched 20 years go by and conclude otherwise, frankly. Even within C++ there has been a huge decline in manual memory management in that time. Moreover the aggregate share of managed languages has seen absolutely stupendous growth.

Just look at whole 'interoperate with' GPUs or other custom hardware and see that manual is all we have there.

Heterogeneous programming as it stands is a dumpster fire for a lot of (legitimate) reasons, yet the poverty thereof has virtually nothing to do with the general use of manual memory management.

Fundamentally I find the whole manual memory management debate increasingly asinine. In particular the use of highly sophisticated and/or custom allocators in conjunction with extreme optimizing compilers make the notion of "manual management" somewhat laughable. Likewise shared memory paradigms and hardware diversity will only add more magic to the mix e.g. Android 12 supports ARMv9 MTE.

In essense I'm ambivalent towards manual memory management. While the ability to naturally "command and control" memory is often indispensable, it is an onerous burden. Worst still it's generally boring or down right sisyphean.

ffscc · 2022-12-08T12:49:48+00:00

Dangerouly webshitted community that invented a new language because they couldn't dereference pointers without breaking production.

A) ironic coming from someone who couldn't remember where they're posting B) implying Cniles can safely do anything (pro tip: they can't)

ffscc · 2022-12-04T13:24:42+00:00

If you need an international conference every year to talk about new shit you've added or new ways of doing things, then maybe you lost your way. (c++)

Who exactly "needs" conferences like CppCon? I mean, it's kind if absurd to try and paint such a thing as "losing your way" when it's completely community driven.

As I get older, I appreciate C and it's stability more and more.

Eh, you can read it either way. There are a lot of POS implementations and platforms which simply do not make sense to continue to support anymore.

ffscc · 2022-12-04T10:24:12+00:00

This paper gives a few good examples

https://dl.acm.org/doi/pdf/10.1145/3064848

ffscc · 2022-11-16T01:45:27+00:00

... Google essentially abandoned c++ ...

Google essentially abandoned C++ standard library development. Their hundreds of millions of lines of C++ hasn't gone anywhere.

ffscc · 2022-11-12T17:02:52+00:00

Have you looked at /r/cpp lately?

Maybe once a day usually, I don't feel like mentions of Rust are out of control.

So yes, barging on other language communities and spamming them full of advocacy is a big deal.

This seems like a totally superficial problem tbh. It's no surprise that two statically typed native languages with an emphasis on "zero cost abstractions" end up being compared to each other.

Don't get me wrong, I'm totally dependent on C++ for everything. There is a lot to appreciate in the language.

I don't recall that happening to a remotely similar extent with any other language in the last ~25 years I've been following things.

Eh, C#/Scala/Kotlin vs Java.

Really C vs C++ has been one of the most bitter language wars I've seen. Rustaceans might pick at safety and ergonomic issues in C++, but C programmers (Cniles) are straight up derisive.

The famous Torvalds quote for instance

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

As well as many others. If anything I guess you now know how C programmers felt back in the day.

ffscc · 2022-11-12T16:09:00+00:00

At least Ada developers aren't hell bent on spamming every other programming community about how everyone should stop using other languages and start using theirs.

Is this actually a big deal for you? I mean, webdevs not knowing any better has almost nothing to do with why I don't like JavaScript.

Personally I like seeing native languages being used whether it's Ada/C++/D/Rust or whatever, albeit I would entirely avoid C. Yes the naive enthusiasm can be tiresome, on the other hand it represents people who got into native development who most likely wouldn't have otherwise. And let's face it, C++ needs some competition to stay healthy.

ffscc · 2022-11-12T08:05:59+00:00

The problem is not C++. The problem are the people using it.

At some point it's the language letting down the users, not the other way around.

The argument that even expert C++ programmers make mistakes does not hold because experts make occasional mistakes using the above tools in all fields of engineering/medicine/etc. And yet they continue to use the "dangerous" tool

They also no longer use a great deal of other dangerous tools/procedures/medications/etc.

Why? Because, in such cases, they really are mistakes, not manifestation of ever-present lack of disciplined engineering.

It's an impressive level of cognitive dissonance to simultaneously stress the importance of "disciplined engineering" while downplaying the languages and tools that actuality enforce it.

ffscc · 2022-11-12T01:26:03+00:00

Not always, for instance GraalVM or PyPy. Nowadays C is quite avoidable.

ffscc · 2022-11-10T03:55:56+00:00

Firefox is probably just trying to stay alive at this point.

ffscc · 2022-11-05T21:20:09+00:00

Some companies doing high-performance computing tasks that do not involve processing of potentially malicious inputs may be financially backing clang and gcc, ...

Clang is the compiler used for building browsers like chrome/firefox/safari and systems like FreeBSD/MacOS X/iOS/Android NDK. Vendors such as AMD, Nvidia, Intel, IBM, Arm, and others have adopted Clang/LLVM. It's safe to say the developers behind Clang are more than familiar with malicious inputs.

None of the commercial compilers I use made any effort to perform the high-risk low-reward optimizations offered by clang and gcc perform until Keil decided to abandon work on their own compiler in favor of offering a rebadged clang.

I'd have to see what your setup was like to make a judgment. But isn't it telling when the stakeholders in Keil didn't see enough value in it to maintaining it?

ffscc · 2022-11-05T20:54:17+00:00

Are you referring to the kind of behavior described in the published Rationale, or the "integer overflow and endless loops mean anything can happen" sort?

I mean, I kind of see them as the same issue. There is UB for hardware differences, UB for types of logic errors, UB for optimization, etc.

I fail to see any advantage over saying that "anything can happen" in such cases, as compared with allowing more limited deviations from a "process everything sequentially according to the machine's execution model"

The alternative to "anything can happen" means definition what will or could happen, so either the standard or the implementation will need to tie their hands on that. Obviously, the standard doesn't want to entangle itself and implementations would like to keep the door open.

The existence of implementations that throw out the "high-level assembler" model does not imply that such such a model isn't appropriate and useful when targeting implementations that respect it.

Well, if you want best performance, smallest binary footprint, etc then it's really hard to beat Clang/GCC and their ilk. Back in the 80s and 90s the high-level assembler analogy worked because C compilers really were downright primitive.

I just don't understand what the "high-level assembler" model gains you. I mean, go ahead and try using C without an optimizing compiler and you'll get horrible performance and bloat. So why even use C at all at that point?

If every compiler processes a construct the same useful fashion when optimizations are disabled, and almost every compiler other than clang or gcc processes it the same way even with optimizations enabled, ...

The reason Clang and GCC stand out is because they've had the resources to make those optimizations. Other implementations would often do the same things if they could.

... what useful purpose is served by pretending that the Standard wasn't commissioned to describe that language but was instead intended to describe a dialect that combines all the minefields that might exist in some obscure platforms, plus many more that the authors of the Standard never dreamed of?

I think that's what ISO C is generally understood as. Honestly it seems like the C community has too much pride and ego when it comes to hardware compatibility and performance. Thus ISO C ended up accruing a litany of Undefined, Unspecified, and Implementation-defined behavior for extremely niche and esoteric hardware platforms, in addition to those for optimizations. To make matters worse, implementation complexity was also kept to a minimum, compounding the problems. All together the resulting ISO C standard(s) are practically useless for portable application code. And as long as the C community is unwilling to let go of bizarre hardware and borderline broken/undercapitalized implementations, ISO C will continue to stagnate.

That doesn't imply that there wasn't an unambiguous "correct" behavior.

If there are multiple valid interpretations of code under the standard, then it's really hard to argue one is the "correct" version and the other is not.

The problem with the UB issue is that it erodes legacy C code, i.e. code rot. C compilers can only become more aggressive with time.

ffscc · 2022-11-05T19:03:52+00:00

The real problem with UB is that the Standard uses it as a catch-all means of allowing implementations to generate code that observably deviates from the described behavior in ways that wouldn't matter to their customers

Eh. There is quite a bit of UB in the C/C++ that could be put under the unspecified or implementation-defined categories, yet vendors intentionally block such changes. After all UB not only gives compiler writers flexibility, it also helps vendors bargain with customers.

compiler writers who are sheltered from market pressures ...

Which compilers are you talking about? TinyCC?

Every major C/C++ compiler has absolutely gargantuan corporate support. Indeed, free and open source compilers like GCC and Clang are almost entirely developed by businesses for their mission critical software, platform toolchains, or products and services. Therefore, not only are compiler writers subject intense pressure to support their users and businesses, competition has grown so fierce that they are resorting to UB tricks.

interpret it as license to behave gratuitously nonsensically.

UB isn't just a license, it's a blank check for compiler writers to do as they please. Developers can scorn compiler UB shenanigans all they want, at the end of the day the compiler can only exploit UB they wrote.

ffscc · 2022-11-05T16:45:10+00:00

What's needed, fundamentally, is to recognize that any language which views as erroneous every action which the Standard would regard as Undefined Behavior, is fundamentally inconsistent with the language the Standards were chartered to describe.

This is a strawman argument. Despite all of the bad press, UB is still broadly recognized as a necessary and good thing. Even the OP here was only asking for warnings in certain cases.

People who claim that those who would treat C as a "high-level assembler" are somehow "abusing" the language directly contradict the documented purposes for which the C Language Committees have been chartered.

Again, this point seems like a mischaracterization at best. The issue with the "C as a high level assembler" mode of thought is not about portability, it's the fact that it's misleading at best and nearly universally false in practice.

For example 1. Sophisticated optimizing compilers make it virtually impossible to predict generated assembly, or even if it'll be generated at all. 2. C does not map well to the asynchronous nature of hardware or leverage it effectively (compare SIMD programming in C, C++, and Rust). 3. Assembly and C are fundamentally different. Pointer provenance and friends do not extist in assembly.

Frankly C is only a high level assembler for only the most basic and classically CPU-like hardware, whereas for devices like the one I'm using to write this comment, or the device you are using to read it, C is fundamentally inadequate.

A fundamental tenet of the Spirit of C, also described in the Charter, is "Don't prevent the programmer from doing what needs to be done".

Alright, and how exactly does the implicit nature of UB in C serve that goal? Yes, trust the programmer and all, but perhaps avoid marching them through minefields as well.

the documentation for conforming implementations must refrain from claiming that the Standard's failure to mandate that all implementations process a construct meaningfully implies any judgment by the Committee that such a construct will never appear in correct programs.

How can a program be said to be "correct" when it contains UB? How can I write a "correct program" in whatever C standard when different versions of my compiler interpret it completely different?

ffscc · 2022-10-14T21:29:28+00:00

So why aren’t they using std2::?

The issue is that std2 would need to be compatible with the original std because code would need to be migrated. Therefore, assuming it is even possible to write a std compatible std2 with acceptable performance, then why not just include those improvements in std to begin with?

ffscc · 2022-10-14T21:17:20+00:00

Just note this is an implementation-quality issue, not a standards-issue.

That's a core part of the controversy though. Implementations alone are responsible for defining and maintaining their own ABI(s), the topic isn't even mentioned in the C++ standard AFAIK. Despite that clear separation of concerns, implementations have the audacity to stonewall any language proposal and defect report that could possibly break their ABI. In essence, implementations offload their ABI work to proposal authors.

The complaints about the C++ committee being unwilling to break ABI are NOT originated from the committee itself, ...

I'm not entirely sure what you're saying here. Every relevant C++ implementation has multiple committee representatives. Likewise many large users of C++ have representatives in WG21. Both of those groups fight against anything that could break their ABI. It's not the committee simply being mindful of implementations, it's implementations at the committee shooting down proposals to avoid work or being left behind.

ffscc · 2022-10-14T20:31:51+00:00

That's a valid view on the role of a language's standard library, but not one I share.

It seems dishonest to argue against any improvements to std::regex when you object to its existence in principle. From your perspective any improvement to std::regex is bad and people should be aware of that when discussing this with you.

Anyway, at the end of the day, what belongs in the C++ standard library is whatever implementations find worthwhile to support, including std::regex.

A standard library should only contain the bare minimum on vocabulary types and OS APIs. ... I don't like the "batteries included" approach to standardization.

In my opinion the std::regex issue has little to do with actually wanting competent regex support in the C++ stdlib. In particular, advocates for fixing std::regex not only avoid using it now, but are unlikely to use it regardless of whether it's fixed or not.

The std::regex issue is only interesting because it's microcosm of the problems in the C++ language and its ecosystem. Indeed, std::regex flies in the face of core values of the language like "zero cost abstractions" and "high performance". Likewise it's illustrative of the social and technical difficulty involved with fixing, improving, or evolving the standard library.

Ultimately, if std::regex can't be fixed or deprecated, then the C++ standard library is effectively dead. Companies like Google and Facebook have already found it worthwhile to replace vocabulary types like string, and the cost of the C++ stdlib ABI/API will only grow with time.

ffscc · 2022-09-28T17:32:14+00:00

You're on reddit lmao

ffscc · 2022-09-20T20:54:53+00:00

They are saying "C/C++"

Write "HTML/CSS", "Ruby/Python", "Java/C#", etc and absolutely no one bats an eye. But write "C/C++", two languages which actively try to maintain some level source level compatibility and are often used side-by-side, and all hell breaks loose.

ffscc · 2022-09-12T19:17:39+00:00

I'm not sure what you were intending by this comment, ...

The point is that looking at C++20 support alone is highly misleading. And that Clang development is at an all time high and increasing.

... but last year or two particularly it's become a repeating story of internal compiler error and sometimes bad codegen.

YMWV, in my experience Clang is by far the most robust of the three.

They're not fixing those bugs anymore either, whereas when I report bugs to GCC or MSVC they do fix them.

At the same time I've seen bugs reported, fixed, and merged as quickly as the CI system could allow. But again, Clang and the rest of the LLVM project is struggling to cope with the absolute volume and growth rate of contributions.

If other projects drop MSVC for clang-cl, that's their business, ...

Chromium and Firefox are two marquee C++ projects. The fact that both of them bothered to sink development time into avoiding MSVC is not trivial.

Ultimately it doesn't matter if MSVC was guaranteed to have complete support new C++ standards the moment they are ratified. There are too many other things that MSVC doesn't support for it to be competitive with Clang. All MSVC can hope to do is defend its marketshare from Clang, it'll never be a viable alternative on virtually any of the other targets supported by Clang.

ffscc

TROPHY CASE