Comments by "George Albany" (@Spartan322) on "ThePrimeTime" channel.

@ "UB dorsn't mean that compiler could do nothing or whatever compiler want, UB only mean, that different architecure could get different predictable results because of objective conditoons, like word size and architecture differencies." That's not UB. First off word size and architecture differences are implementation defined, not UB, UB means the standard makes no promises you get predictable results cause the compiler can make presumptions, implementation defined behavior means that the standard guarantees a contract of behavior but how specifically it does so is left for the implementation, like for example in C++ virtual inheritance is implementation defined, however directly accessing and messing with vtables is UB since they aren't part of the standard, C++ only describes that virtual functions may be implemented and gives no requirements as to how. I can also tell you as a fact UB is immensely useful for optimization as someone having over a decade of C++ under his belt.
1
@semibiotic "Compilers must do my code extactly, or must refuse to." There has never been a single compiler that's ever done that.
1
@semibiotic "No compiler shoud be allowed to invent compromized ways to execute my code - with algoritmic corruptions or omiting explicit parts" Follow the standard and that's literally a non-issue, that applies to literally every language.
1
There's two different qualities of respect, one is the manner of being respectful or giving other dignity and the other is granting someone respect for their behavior, those need to be separated, the former is considered a moral given (though why is itself a question nobody bothers to answer) but the latter is absolutely something you have to earn, and you totally deserve to be called out, even perhaps insulted, depending on how poor your behavior is. Linus is extreme but I absolutely say he is a lot less in the wrong then most people try to claim he is.
1
@diadetediotedio6918 Memory safety is trivial in C++, if you use RAII for memory, especially with smart pointers and containers, you won't run into memory safety issues, if you use the C++17 and C++20 type-erasure types like optional, any, and variant, and if you include ref_wrapper, you can do pretty much everything without needing to deal with memory at all.
1
@skeetskeet9403 "well, why did the Android's Binder IPC being rewritten in Rust not lead to a change in performance if Rust is fundamentally slower?" And how was this benchmarked? By what metric have you actually tested this? Further still what techniques were used to attain that speed? Because using the Rust library and Rust infrastructure directly will cost you performance because it is more disconnected from the memory architecture then C++ inherently requiring techniques to recapture these systems which requires way more additional thought. Rust is more abstracted from the memory infrastructure and it absolutely does not believe in no cost abstractions (its memory architecture makes that quite clear) nor does it believe in not paying for what you don't use, it believes in declarations of safety over performance, all safety costs performance of some kind, I'm not even considering the compile-time performance cost, there is inherently a developer disconnect from memory in Rust compared to C++ as a result. Rust is inherently not capable to build as lean by default as C/C++ because of its emphasis on safety over everything else, that doesn't mean it can't be lean at all, that's not the issue. As demonstrated in this example, its requirement that many operations be "safe" absolutely will cost you in the marginal cases that require immense performance. And it doesn't make it remotely easy to escape this, and when you leave that pretty much every capacity to be safe is also lost resulting in those paths being even more bug ridden because Rust is not designed to be easy to intuitively understand once you remove the safety systems it has.
1
[](auto value){}() Immediately invoked lambdas are actually exceedingly useful to get performance and take advantage of compile-time effects.
1
I really want to see prime checkout C3, not necessarily use it as a big thing yet, as its still way more alpha then Zig, but I think given Prime's position on Zig, he'll love C3.
1
semantic names are still massively useful for code review
1
@anonymousalexander6005 Its a mistake to blame the language, and especially to point to C++ on this when the problem has nothing to do with C++, every single safety issue came from people refusing to use basic C++ features and just doing things the C way, (and C devs you put in Rust will just do the same thing in Rust because that's how they work) aside from static analyzers that prevent me from writing code that could introduce the problems claimed in the directive, if I don't use legacy C functions and rely on functionality introduced since C++11, I'll never run into the problem in the first place, even in C++98 I had all the tools necessary to replicate the safety of Rust, and by C++11, it was well ahead of it, static analyzers already tell you to stop doing things the C way and can error out on unsafe memory behaviors, and C++17 and beyond already gives us plenty of tools to deal with the remaining legacy C in a safe fashion.
1
We have a lot of build systems for C++, and all of them have pros and cons, CMake is pretty standard, but Meson is another one that's getting hugely popular.
1
@SVVV97 Never had a problem in C++ with clangd or Visual Studio.
1
Just to point out that the original purpose of GPL is everyone who forks is forced to expose their changed as potential contributions back to upstream. Unfortunately however it doesn't distinguish between library users and forks.
1
Lumping C++ in with the memory safety thing doesn't even make any sense because it carries the exact same memory safety as Rust, static analyzers warn you about doing things the C way (resulting in semantic errors the same as in Rust that don't compile) so attacking C++ is absolute nonsense.
1
Its just generally better to give choice to developers then to restrict their choice so long as it does not come at the cost of something else, and the developer should be able to build choices into their systems without restriction instead. Taking choices away is not a good enough and its the paradigm obsession of modern languages that actually frustrates the hell out of me.
1
@Aexorzist Pattern matching has never been a big deal for languages, its nice to have, but that type of behavior can actually be implemented in C++ with operator overloading if you're really obsessed with it.
1
@rcoder01 std::optional is stupid easy to deal with, std::variant was only annoying because no member visit and the lack of intrinsic function overload, both however can be implemented.
1
Godot is in many ways easier than Unity, and its 3D is not even remotely that bad, console support is also coming.
1
I'd suggest checking out C3 at some point too.
1
@The1RandomFool A lot of them probably shouldn't, its the same as 927: "There are 14 competing standards" "why do we have all these standards, there should be one standard for everyone" "There are 15 competing standards"
1
I'm just thinking if we compare this with the Sony rootkit, this took weeks to discover, that took years and to this day Sony still doesn't admit they did anything wrong nor if it could happen again or not. (though most probably it could)
1
@DylanMatthewTurner Imposing decisions on developers is the worst solution, paradigms should not be imposed on a language, decisions and paradigms should be developer chosen, I can't stand Rust, I never want to use it, the syntax is crap, and the implementation makes low level control impossible without introducing bugs.
1
@ITSecNEO You can't violate the borrow checker without inherently introducing bugs, that's a problem with the language. Rust does not let you violate its safety systems without it being inherently buggy because what Rust's safety systems do is overly complex and how its managed is specifically impossible for a human to follow.
1
Or the Sony rootkit.
1
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off" - Bjarne Stroustrup
1
@ldov6373 It means that C++ has a lot of ways to avoid the problems common in C that blows up the programming, but when you do occasionally find one, its probably worse then what'd happen in C.
1
In the xz case, it took weeks to discover by accident, I know Windows exploits that could backdoor you that resided in it for years that nobody fixed.
1
@FlorianZier Part of the point of UB is specifically because some optimizations are platform, architecture, and compiler specific. Like for example integer overflow is UB because it allows you to eliminate certain checks that cost at runtime when the compiler or CPU knows those checks shouldn't run. What happens with overflow isn't specified so the compiler implementer can decide what is best for them, usually following the platform which is usually wrap around. This is actually why C/C++ UB is so powerful. C++ does this because the standard is focused on performance foremost, any runtime cost is always paid unless you add unsafe functionally, but there are realms in of safety in those "unsafe" cases in C++ that Rust can't naturally provide.
1
@arthurmoore9488 Usually the case for which I'll consider array over vector is when doing constexpr/consteval stuff, as Apple's version of Clang still doesn't like allocations in constexpr/consteval even in C++20, template metaprogramming can get pretty gnarly with everything we have in C++20. (that's not entirely supported by any if not all the compilers) Course you need to never let allocations escape the constant eval environment regardless so you have to return fixed sized objects, but most of the time I just resort to vector if I need a contiguous container unless I need some type of stack advantage, its rarely been useful in my experience to deal with arrays aside from those cases.
1
@pokefreak2112 Pretty sure emscriptem has dlmalloc and emmalloc, so how would wasm not support malloc? Like guess you could set it to run without malloc, but that's not really the same as saying it does not support it, malloc is literally standard C, if it can't use malloc, its not standard C regardless, that's like saying well defined behavior does not need to follow the standard, then you're simply not using C, let alone C++. I can't think of a single platform that doesn't support malloc that can claim to support C.
1
@mek101whatif7 Tell me you don't have any experience in writing parsers without telling me you have no experience in writing parsers.
1
The only reason anyone tends to dunk so hard on C++ is because most people are writing things the C (and never the C++) way or they're only maintaining a pre-C++11, probably even a pre-C++03, project. Most of the reason for why they can complain is specifically because its ubiquitous usage, the king's crown often makes a lot of angry and envious enemies. I could give you a list of crap wrong with C++ as a big C++ developer, none of which relate to safety because that is a solved problem in C++, and for which Rust literally cannot compare to and neither would anyone who goes to Rust would ever consider to complain about because they literally don't care for any other feature because its the only thing really going for Rust, elsewise Rust is one of many languages with similar features. Also the lack of a shared object ABI standard makes it exceedingly unsuitable for many applications, bad compilation times mixed with the lack of a universal ABI, which Rust seems unable to solve make it poorly suited. By the way Sean Baxter has proven with his Circle compiler that C++ can support an opt-in borrow checker, he's also about to submit a proposal to the ISO standard for a borrow checker to be added to the language, the issue on the papers github is 1984. (which is hilarious)
1