Yeah and it took about 150 years until industrial revolution started to actually benefit the common people and the workers started to have their working conditions improved.
What it took was social democracy and unions and other social movements.
Saying that "it's happened before, it'll be alright" is a bit naive and short-sighted.
It took a literal civil war, which you don't read about in history books so much because it's not beneficial for the owners of those publishing houses to have more people hear about it. Lots of people died on both sides.
> which you don't read about in history books so much
Just to clarify, are we referring to the American Civil War? The reason I ask is that the idea that it is not a topic that is broadly covered in history books and discussed at depth all throughout schooling is simply false.
User entering wrong input is a logical condition and typically handling a logical condition (point being it's not an error from the software's operational point of view) using tools that allow easier logic flow (i.e. error codes) etc.
Out of memory error can happen in many environments because for example in C++ it's about the allocator. You might have a custom allocator with some limit that has no bearing whatsoever what the OS does.
* Use asserts/panics for bugs.
* Use "error codes/values/enums" for logical conditions (that are errors to the user, not errors to the software)
* Use exceptions for unexpected errors in the execution of the software (normally more or less just resource allocation failures)
I don't know, but maybe spending 15 years working on something that you felt was not only a job but also in part a mission shapes a lot of you as a person and you want to express your feelings about that huge part of your life.
I would say about 99% of the population views software corporations as these monolithic inhuman cubes of pure shitanium. What these posts are important for is
1: reminding the average population that corporations are just abstract human pyramids and made up of normal people.
And
2: doing that through a very human, biased, and filtered perspective that can provide some genuine insight into the function of these opaque systems.
Now, does the average consumer of hacker news get all that? Probably not, but I do think insider perspective is still valuable.
Gstreamer is a multimedia framework where the user creates media DAGs by placing video/audio/multimedia elements such as demuxers, decoders etc in a pipeline. The framework then takes care of running the media pipeline and handles the data buffering etc.
Within the framework there are multitudes of plugin packages that contain said elements and many of them are built on top of ffmpeg.
Either you were a head above the rest of the team and had the intellect to produce high quality value adding work, or then you were the "move fast break things" type of guy producing a lot of extra liability and work for others.
Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access?
Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway.
So logically I'd think that the malware would just get piggy bagged into actual non-obvious utility apps and nothing is gained.
Second problem is that the security model hoops make for terrible APIs and user experiences. Just look at the current filesystem browser APIs. It must be mentally challenging to design APIs to Be usable and the nerf them for security purposes to make them "not too usable".
Finally one must note that at least right now the webasm ecosystem is rather immature and the de-facto only tool (emscripten) is an amateur hour hobby project. So it's going to take some decades still before the tooling is really getting there.
In general, what's three point of a link to a sandbox in a conversation about the benefits of sanboxingm
But specifically, this sandbox also kills all interop with your system, other apps/utilities, so way too disruptive for the purpose of isolating just from the network.
Was it "financial gravity" that made the decision at VW to install emission cheat devices?
Was it "financial gravity" that made the decision at Google to cheat at the ad exchange?
Was it "financial gravity" that made the decision at DuPont to dump toxic sludge in the environment and make unsafe products?
Or perhaps was it just a group of immoral people chasing more personal gain and wealth?
Humans are too weak and too easily corrupted by wealth, power and shiny things and our political and economic systems place way too much power in the hands of fallible individuals. I expect it to be our downfall.
By this logic, there are no such thing as psychological forces or institutional structures that affect human behavior unconsciously. I don't think that can quite be right. If you read the book, you can see the much more detailed and (I hope) rigorous argument, and then judge for yourself.
You're right that C++ has a lot of features. But like mentioned elsewhere most projects define their own conventions and the subset of features that they use.
Also the nice thing about having a large set of features is that C,++ allows you to write very nice abstractions (or not) at both very low or at very high level. In other words you can be very low level with online ASM and bit operations and bit and direct memory manipulation or very high level almost like a script language. Whatever the problem domain needs C++ has got you covered.
On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger.
A specialized dynamic array class in a few hundred lines (at most!) and with just the required features is much more useful than the 20kloc monster that's pulled in with `#include <vector>` and which doesn't even do bounds checking in the 'idiomatic' usage.
Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature.
You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time.
NIH implementations are usually grossly inferior because as it turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.
Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).
The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, everything) was somewhere in the 2..3% range, which is fine when budgeted for upfront.
Those asserts probably saved a lot of development costs and increased the robustness of the software, which is worth a lot more than a few percent on a benchmark.
I personally am more conservative on those things. I'll pick the fastest thing that is reliable.
Are we talking about games or medical devices here? I expect different things from them. If a medical device needs to turn off bounds checking to get results I'm concerned enough to not want to let anyone use it. If a game can get a slight performance improvement I'm all for it, who cares if it crashes, it is just a game.
We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.
That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.
You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check
Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game.
The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to figure out what went wrong. With a regular crash that happens without asserts the actual reason of the crash may already be obfuscated enough that a useful bug diagnosis is no longer possible. E.g. an assert is usually triggered very close to the bug, while crashes are usually only the end result of a whole cascade of events triggered by an initial bug.
Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'
And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.
The point is that STL does make you pay for stuff you don't need. In complexity and compile times. There's reasons Jai is being developed, and they're not all that Jonathon Blow is weird. As much as C++ owns the game industry right now, it has observable deficits as a great game programming language.
Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'll be missing features and data structures and then people have to write sub-optimal code to work around it's limitations.
Top tier game orgs are often large enough to have good people write their own library with the correct compromises. They also tend to need micro performance improvements enough to be worth it.
Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL.
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
I find it hard to agree that the stdlib is poorly designed and implemented. In my entire career it has pretty much worked entirely to spec.
Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.
C++ stdlib was barely acceptable in the 1990s but is heavily outdated today and suffers from deeply frustrating design flaws.
The ABI Nightmare - The C++ committee has this extraordinarily weird and strict rule: never break the Application Binary Interface (ABI). If a better algorithm or memory layout is discovered, the standard library cannot adopt it because doing so would change object layouts and break existing binaries. The worst part is that this ABI is never defined, so you always HEAVILY pay for what you DON'T use.
std::regex - the Programming Language Joke of the millennium. Even an interpreted language regex engine runs faster.
std::map, std::unordered_map - outdated, badly-designed and slow crap that is beaten even by high-school coders writing map data-structures.
No bounds checking. And Undefined Behavior by Default for operators like std::vector::operator[]
std::iostream - bloated, expensive design, std::vector<bool> - another joke.
No deprecation strategy. There are FOUR callable wrappers. At-least, have the courage to say @DEPRECATED.
No Standard Networking.
Missing System Utilities - nothing for process management, standard cryptography, or basic command-line argument parsing, etc.
To be honest, this is just the common complaints - if you run through all the stdlib features, there are dozens of severe problems. Which all the smart people know about, but are forbidden to fix - because of ABI!
some of the STL is easy to improve on. For example, std::unordered_map performs poorly due to pointer stability requirements in the standard. Most performance sensitive C++ codebases will use something like abseil's hash maps instead.
Just a heads-up: if you're already using boost, boost::unordered now has open addressing containers (unordered_flat_map and unordered_flat_map) and they are among the fastest.
The STL is not good if you want performance or predictable behavior. The issue is in the specification and the requirements placed on certain algorithms and data structures. It’s easy to beat unordered_map for example with an open addressing hash map, small vector optimization can’t be implemented in vector due to standard requirements, etc.
So, a few things (aside from the whole nomenclature argument already in another reply)
1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea.
2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++) implementations and so other implementations are often better, because they've learned from experience
3. As well as pretty good generic algorithms, the STL also provides a lot of container types (what Rust would call collection types) and these vary not between "excellent" and "mediocre" but between "mediocre" and "inexplicably terrifying". The most charitable explanation is that they're just intended for teaching. If you teach DS&A to a Computer Science class you want the Extrusive Doubly Linked List to teach in class. If you write software you almost certainly never need this type, but it's front an centre in the C++ STL.
There's a single "I guess I would use this" container type, std::vector. It has an insane special case for bool, because WG21 are idiots, but it's otherwise a good enough growable array type and it's not worth building your own instead given the constraints.
Everything else is silly, or bad, or both. std::unordered_map feels like a hash table I made in class in the mid 1990s, but it's actually the provided standard hash table container in C++ 11 onwards. std::list is just that extrusive linked list for some insane reason. The Microsoft standard library maintainer STL could not offer me any justification for what std::deque is actually supposed to be for.
I would argue that even the basic concept behind STL is misguided. The rationale I often see is "you only need N algorithms for M container type, instead of N*M". This ignores the fact that algorithms and data structures are not independent of each other, and also that most of the time these days you're operating on vectors, so M ~= 1.
Case in point: list::sort. You don't want to try running quicksort on a linked list. Or remove_if: great we've abstracted the difficult task of removing things without erasing them, except we can't do it on maps. (C++20 seems to add an erase_if, apparently admitting that the two-step remove/erase is silly).
Then there's the fact that C++ iterators are basically pointers into the data structure, where for vectors (your common case) you'd do much better with index/container pairs, both for stability and bounds checking.
> There's a single "I guess I would use this" container type, std::vector.
About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy.
Agree with your takes on most of the containers. I also dislike how optionals are never used with containers as they were standardized later (and even then, problematically w.r.t. references). Thus, for example, if I lookup an object in a map of T's, the result should IMNSHO be an optional reference to a T.
std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)
But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.
> If you want to get f cy you can also give it a custam allocator
And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.
Well, if you want to, I can write you a forwarder-wrapper around a std::vector that would inhibit allocation-inducing operations. Now, getting it into stdlib, that's a different matter entirely...
Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?
The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.
But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.
This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.
AFAIK, std::map is also OK for what it is: an ordered, node-based (tree) map. These are (almost) always slower than hash tables. Of course, std::unordered_map, the std hash table, sucks because of unforced errors. For that, there is boost::unordered_flat_map.
std::map will be a Red Black Tree, as with most of the other container types this really likes pointer chasing
Unlike in std::unordered_map you are getting some value here, the RB tree is able to achieve meaningful efficiency gains from its use of pointers. The trouble is that your computer isn't a PDP-11, a hybrid which does fewer dereferences but has more locality will trade well here on a real computer built this century.
So, I'm torn, it's not awful but it's a problem that std::map is basically obliged to be a Red Black Tree even though that's not a good fit for today's machines.
It has some very useful principles, but also some super-annoying gaffes and mis-design aspects. One example: Allocators. What a mess! Or the fact that if a map lookup fails, an exception is thrown. I can't count the times I've had some app just bail out on me with an at() exception, because the author neglected to handle it (and the map/unordered map interface did not force them to). That does not detract from Stepanov's important work.
The kind of programmer who don't check (or think through so that they can't fail) their map lookups is also the kind of programmer who don't bother with const. What a non-const unchecked map lookup gives you is a default-constructed value that has just been inserted for the only reason that operator[] returns a reference, which must "point" to something. That's bad and can be confusing, but it doesn't crash.
I see that problem much more often than crashes due to unchecked map lookups in production, which are very rare for me. Less than once a year.
It's not about removing meaning. A normal thoughtful person can surely come up with things to do and occopy their lives with. In fact for most of people work just gets in the way of that.
What's it about is once you remove the paycheck that all proletariats need when things get "interesting".
I hear this all the time but where is the explosion in people learning art, music, increased time with friends and family, etc… instead it’s all the opposite. We’re using all our extra free time to doomscroll.
What extra free time? Have we gotten more of that in the last years? From what I can see, everyone is still working full time jobs, needing to make more money than ever in recent history to survive.
What it took was social democracy and unions and other social movements.
Saying that "it's happened before, it'll be alright" is a bit naive and short-sighted.
reply