This is a hilariously misinformed take, indicative of reading news in a bubble. The cryptosphere benefits when folks like you don your tin foil hats.

You do realize the amount of scrutiny is far greater, affects all individuals above a certain pay grade at publicly traded companies, and that regulation continuously evolves? Protections against wash and insider trades are an important consumer protection but crypto advocates would rather you believe the current system doesn’t offer those affordances than admit deficiencies in their blockchain based ecosystems

Insider trading laws, to the extent they work, make the market less efficient because they delay the entry of information into the market. The majority of markets outside of equities, like real estate, don't have insider trading laws yet have managed perfectly fine.

The real estate market requires sellers to disclose property risks to potential sellers, which is an alternative to insider trading laws (one that would scale poorly to stock trading). Similarly, commodities are often sold under a warranty, with any hidden flaws being the responsibility of the seller - another solution to the problem of unequal information.

I couldn’t disagree more with your opinion. Symbol servers and pdbs are a tremendous advantage to C and C++ development on Windows. Are you sure you have equivalent experience with both Windows and non-MSVC toolchains?

Coroutines let you control where allocations go though? Just override operator new/delete on your promise types. Honestly the feature has been amazing and has cleaned up my code a ton. It’s not for average users. It’s for library writers who then build abstractions on it to make async code easier to write for others. Exposing the coroutine frame as a non opaque structure is simply not practical. Not a super well-informed article IMO.

> It’s not for average users. It’s for library writers

Justifying the complexity of an interface by appeal to caste system is pretty poor, IMO.

A very common methodology for solving big problems is to break them down into smaller problems, solve each one in turn, and compose them together. In other words, we use library-oriented programming. A productive feature in a programming language makes it easy to both create the library elements of the solution and to compose them together.

There are tons of facilities in the language intended for library authors and abstractions that are absolutely intended to be used out of the box. This is just how things are, features are provided at various levels of abstractions. I know HN loves to collectively hate on C++ but “caste system?” Lol

I think "caste system" is the perfect word for it. I don't think it is a bad thing though, I am fine with having such castes in c++. First time I saw coroutines of c++ I was definitely like "yep, this is for library writers". I am not excited about it, but I am excited about libraries that will use it.

It is similar how templated code that basically becomes "magic" for an average programmer like me. I can't wrap my head around such complex templated libraries either but the simplicity of using such libraries are sure welcomed by me. I think it is perfectly have some language features for more advanced users.

Hey, at least they are adding concepts. Maybe I will move up to another caste and will be able to write more complex templated code now.

Yeah, it's part of the charm of C++. The is almost horrifyingly modifiable. As a library author, that gives a lot of control over the functionalities of the abstractions you expose.

For a day to day programmer, that sort of concern is (usually) overkill.

The difference is in the capabilities of what a library can do. C++ goes through a lot of effort to ensure any library has all the same building blocks as the standard library. Almost no other language does this. Instead, they just grant the standard library magic powers that they don't trust you with or just refuse to provide.

The "caste system" as a result exists in all languages. Just the vast majority prevent you from ever being a duke much less a king. C++ doesn't stop you. Whether or not this is valuable to you is then personal preference, but it's not complexity for the fun of it, either.

> Justifying the complexity of an interface by appeal to caste system is pretty poor, IMO.

Ahhh, I mean, isn't that a decent-sized chunk of template-based code as well? I would hazard a guess that even for a "simple" one like std::vector<foo>, there are way more C++ developers who can use std::vector than who could implement a templated vector from scratch.

I, myself, fall kind of in the zone between. I'm not a template guru, but I work on the foundational/library-type code on my team and have to do my absolute best to make sure that the stuff I build for everyone is usable without needing to know the minutia about how all that stuff works.

Yes, and that's why templates are also often criticised as a poor design.

I think many C++ devs haven't read Stroustrup's book. The intro to C++ chapter covers most of what they need to know and then the rest of the book goes into beautiful detail with examples.

Most of the C++ developers I worked with were C++ developers in name only and wrote appalling code. I was one of these developers until reading Stroustrup's book and doing my own side projects to improve skills.

I think the fundamental flaw of C++ is the bifurcation of its target users into elite (i.e. library) programmers and "average" programmers. It makes the C++ standard library incomprehensible for normal users. The C++ committee members are composed of elite programmers, of course, so they keep adding features which are inscrutable to most users, and the complexity of the language spirals out of control.

I have a soft spot in my heart for C++. I have used it on and off for about 30 years, 8-9 of those years professionally. But the complexity of the language has increased so much that I am actually looking forward to not writing it anymore.

I wonder if Rust is any different. I wouldn't know.

I regularly read source code of the Rust standard library. With C++ I don't even bother, it's futile.

Rust has a similar bifurcation. Most "regular users" of rust will not write macros, for example. Although my impression is that the divide is not as big as C++'s

Rust has two macro systems. First it has declarative "by example" macros which I wouldn't give to an absolute beginner but they're very safe and give a flavour of meta-programming. A programmer with a good general knowledge of Rust, and a nagging feeling that there must be a better way to make these several almost-identical-but-not-quite new types they're working on can learn how to write "by example" macros and while learning probably won't set anything on fire. Rust even provides, out of the box, an easy way to see what the result was of your macro substitution.

Second, modern Rust has stable procedural macros. The procedural macros have essentially unlimited power, since they literally run inside the compiler processing the tokens of the program. Still, two kinds of proc macro, derive macros and attribute macros are fairly tame and, with due caution, merely competent programmers can experiment for themselves. It's really only the function-like proc macro that makes unlimited chaos likely and wants an expert. Stuff like whichever_compiles! (a macro which takes a series of code blocks and your program has the first one that compiled successfully...) is in this last category and is clearly toxic. Anybody who could write such things hopefully knows enough to do so only as an elaborate joke.

I don't know that I would consider writing macros a sign of language expertise. I work on a large, intricate Rust project and macro stuff, while it does come up occasionally, is not what I would see as the "elite" bit of writing Rust. The best Rust folks I have seen understand Rust's type system, how it relates to the memory model and how those relate to the underlying machine.

I feared macros initially, but when I tried I was actually surprised by how easy they were. Way easier than Scala 2.x macros.

How can floats be totally ordered. This isn’t even a matter of NaNs or not. A set of floats where two or more floats compare equal does not permit a total ordering.

I think that's the parent comment's point. Floats are not totally ordered but C++'s type system is weak enough that it appears they are.

IEEE754 provides a total ordering algorithm actually, but it's not used when you do double a, b; ... a < b

What do you mean? I'm pretty sure no two distinct floats compare as equal.

-0 and 0 do.

-0.0 and +0.0?

Are those floats actually distinct? I mean you could represent 3.0 + 4.0 = 7.0 as well. Are "-0.0" and "0.0" actually different?

(This is a serious question I honestly don't know.)

As other users mentioned, the most relevant part is when you divide by 0, you get different infinities depending on if you're dividing by +0.0 or -0.0. But even beyond that: the binary representation of floating point numbers [1] necessarily means that there are two values for zero with distinct bit patterns.

Floating point numbers have a dedicated sign bit that specifies the sign, which means that you can flip the sign of any floating point number and get a float with a different bit pattern (and opposite sign). That means that you get necessarily get both +0.0 and -0.0, and they have different internal representation in bits.

This is one of the major advantages of two's complement notation for representing integers: it doesn't have a dedicated sign bit in the same way, so you only get one representation for 0. You can still check the sign by looking at the top bit, but if you flip it for the number 0, you don't get -0 (which doesn't really exist), you get -128 (for 8 bit signed integers).

[1]: https://en.wikipedia.org/wiki/Double-precision_floating-poin...

They are distinct values but they compare equal. For almost all uses they are effectively equal, except where you are producing infinities.

I hadn't thought about the infinities part. If they had the same behavior in all operations involving other numbers, then I could see how they could nonetheless be the same from a C++ type perspective, but given they behave differently, C++ certainly couldn't consider them the same.

Thanks for clearing that up!

If you keep infinities and NaNs out of a subsystem, then float and double are totally ordered within that subsystem. So, it is a choice. I would not hesitate on that basis.

Of more moment is that floating point variables often represent imprecise values, such that e.g. 1.41 could represent a value that should equal another transcribed as 1.39. The type system will not help you there. You are obliged to code in tolerance the hard way.

And the title would clue you in that it’s a 4G virtual address reservation which isn’t the same thing

reserve(4GB) doesn't actually touch the pages it allocates so it too is only reserving virtual address space... so it is the same after all.

Not exactly unexpected. Most of us work with the virtual address space these days.

UE5 does not use geometric textures, nor does rasterization have anything to do with the lighting system (irradiance caching)

Says the guy who didn’t read the article where the author actually identifies and tries a 10min caramelization tech she finds and discovers it too doesn’t work.

What a weird article to post. Why not std::barrier, or std::binary_semaphore, or std::counting_semaphore which is also new as of C++20

People find a cool thing online and share it. Not weirder than sharing a specific wikipedia page.

Not exactly "random," I am sure...

In a text editor....

If they'd wanted you to do that, they would have named the files something like "CMakeLists.txt".

You can do that with Rust too if you want to live like it's still the 70s.

> ... I don't know what is