General statistics
List of Youtube channels
Youtube commenter search
Distinguished comments
About

George Albany
ThePrimeTime
comments

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

Especially C++20, concepts absolutely fix the template problems way too well,, shame that modules still don't work properly on any compilers though.
26
Lot of people forget that C++ is second to none with performance against safety, its safety is opt-in but heavily advised while being a trivial interop with C, I don't see anything supplanting that functionality for the simple fact that C++ provides something that literally does not exist anywhere else.
24
Most people that complain about security problems don't actually understand security in my experience, granted I'm not great with it either, but there are people I know personally who do know security because they work in high risk engineering environments, (like aeronautics and defense) they still use C and C++, most of them preferred C++, and I've been told a few times they'll never switch to something like Rust. Its quite likely the Rust developers don't actually understand security either and haven't actually worked in a field where security is vital. When the US government starts imposing something technical, its usually because it completely misunderstood the problem and developed the worst fix possible to said problem. They do it repeatedly in defense contracting and I know of people who've directly suffered and died of such things in the military.
21
I've experienced a number of cases where that happened with MSVC as well, I'm not sure there is any compiler that doesn't suffer from it.
10
Honestly C++20 concepts and constraints solve the metaprogramming issue completely by erasing the compile time type while preserving a type contract, and the compiler flat out tells you why something failed, it can also perform constraint overloading and allows you to perform compile-time conditional type introspection with if constexpr, all major compilers support most of the major C++20 concept feature set (least that matters) and as someone who has personally used it in a codebase with excessive template metaprogramming its been a godsend to protect the templates from massive nonsense statements of problems I have no way to understand, and even better it gives you a clear understanding of how a template works from an interface perspective. Next thing I'm waiting for is properly functioning modules in all major compilers.
8
Honestly I despise a lot of the Rust community, it doesn't serve an original purpose, it co-opts the purposes of other languages, sometimes without good justification compared to the alternatives, and then it gets injected everywhere like "replace everything with Rust" no matter how unsuitable it would be for that. Aside from despising the language for numerous reasons (its ideas are nice, but its implementation is the worst way you could've done it) the community is absolutely horrible for Rust, I've been in regular non-rust programming places, but as soon as you criticize Rust for anything, they absolutely lose their crap and call you names. I can't stand Rust, and even more I can't stand its community, its no wonder its representatives are so crap.
7
I hate Rust's syntax as a hobbyist in syntax design and parser development, you could not have made a much worse language syntax then Rust, Lisp makes more sense. Rust has interesting ideas, but I can't see a good reason to use it over C++, every protection it has can be just as well handled in C++ since C++11, C++ has been capable of memory safety since C++98, the problem is people keep assigning C programmers to C++ and then you're surprised when they open the C memory hole? We've had static analyzers for years telling people to stop doing that, and Rust has plenty of holes in its "sound type system" that people will abuse just the same as they did in C once anyone becomes competent in it, with competence mixed with time and performance constraints always brings a lack of safety even in "safe" code. "Safe Rust" can still perform buffer overflows and people will eventually rely on the existence of that behavior too. Course they might also just completely disregard "Safe Rust" which inherently produces bugs because it is impossible to understand Rust's overprotective behavior well enough to account for it in unsafe code, its the same as just writing straight C, all you did was move the problem down the line, if you keep pushing C developers over to Rust, and they keep struggling with the borrow checker, lifetimes, and the traits system to do even simple things people will just do what they did in C and C++ and disable the safety checks because they got in the way, and now you just fell right back to square one except now you get to claim "memory safety". That aside the ability to write and read the syntax easily determines the maintenance cost, Rust is not a maintainable language because of its verbosity, I don't foresee anyone wanting to keep any legacy Rust, (its enough of a pain maintaining legacy C when its readable, now imagine legacy Rust) which makes it questionable to try and replace C with, at least Zig is better for this.
7
Can also determine if you're in a consteval state of the function now too.
6
@ThePrimeTimeagen Not if you don't need the atomic counter, weak references should only be used when you absolutely need the atomic reference counter.
6
Thing is the elimination of UB as a concept kinda misunderstands why it exists in the first place, it exists so you know what the software promises to do, its just a contract, and its a useful contract for optimization, C is ubiquitous specifically because of this, I think the writer of this article grossly misunderstands that C evolving as the a multi-platform language is what inherently allowed every other language following it to exist. If I have to write C, I'd like to have a linter inform me about UB, then I can choose when and when not to use it. (as I do in fact take advantage of UB even in C++ because it actually is a very useful tool) Cool thing about UB is that you can access implementation defined behavior that transcends a library, reaching the hardware, which is all on its own useful functionality too. (like messing with the vtables, there are no vtables in C++, their existence is completely implementation defined so any way to access them is inherently UB) Personally I'd prefer if we could have optional UB, the core standard has no UB but then the standard requires the standard machine to disable certain defined behavior that it deems useful without having to modify the language, this is definitely a gripe I have with the "no UB" languages because they treat UB as if it never served a purpose instead of only being poorly implemented. Even more helpful if we had categories of UB.
6
@joseoncrack Been doing C++ for over a decade, still prefer it to anything else, though I do wish it were better but that's just cause everything else sucks.
5
You're talking to one right now, I hate Rust and don't find Zig compelling, and I'll always love C++ over C. I also spend some of my free time reading the C++ proposal papers for fun.
5
Not everything in the kernel needs speed, but as for those that do, Rust actually will almost never be preferred.
5
If you know how to use RAII, it protects you from memory leaks by forgetting to free the memory because you returned in an unexpected place.
5
Not to mention since C++11 its been very memory safe, (technically auto_ptr was C++98, RAII was capable to do it since at least C++98, but good inbuilt smart pointers have been in C++ since C++11) and when you have spans and ranges/range-views and C++23's adding things like out_ptr and inout_ptr negating the need to manually manage memory even with C functions, to say C++ can't accomplish the same things as Rust or Zig is just dumb.
5
public and private functions have nothing to do with security, that's purely about API encapsulation, even if they're private you can still call them
5
Its the same for their standard library, it seems to me that Rust devs don't understand anything about ABI breakage or API contract violations. Kinda makes me wonder if the "experienced devs" in Rust actually have any real software experience. Or perhaps they're taken hold by some utopian dream of Rust where the common software concerns don't matter completely forgetting that changing a language doesn't fix most of the suffering of software development, most of software suffering is an inherent technology issue.
5
All move constructors do is swap the data, they never need to allocate, they're literally the fastest way to assign something that isn't immediately constructed, this would be the same in Rust as in C++, copy constructors mostly function for making immutable data or duplicate data you wish to modify, which I might add, you could just use CoW containers and that'll happen automatically only when you modify the data, you can also control allocations better in C++. Also gonna point out, all compilers can optimize objects out just as well as Rust, that's not really a Rust specific thing (technically there are no objects in C++, it also produces glorified strange C binaries) that's kinda inherent to how compilation (to assembly) is supposed to work, and for languages that get compiled to a binary without a bytecode, that's pretty much what always happens. Also you can just disable exceptions in C++ and now you don't need to throw, C++23 is also getting std::expected to enable library ease of use for this case.
4
I can't think of a case where using modern C++ has ever resulted in losing memory safety that wouldn't have needed to be lost in Rust anyway. Every time I've ever run into this its specifically because I used C over relying on C++.
4
@tiranito2834 Doesn't help that move semantics pretty much replicate that behavior in a way that is easier to track and intuitively understand, obviously with the cost of it being less safe, which honestly I'm totally fine with the theoretical lack of safety because it kinda requires deliberate action to cause such problems, and C++ is actually pretty good with move semantics, the annoying thing is duplication of code to write out move semantics for your classes.
4
I guess you can restrict access to the reflection system, but that requires more work and almost nobody actually does it.
4
C++ doesn't copy data by default, it depends on the type, if you implement a copy constructor and don't use references, sure it'll probably perform a copy, but move semantics are a natural part of the language and the language will defer to using that which is almost as cheap (and in most cases is just as cheap) as a direct reference. (so long as it has a trivial destructor) Now if you simply make classes and don't use references without a constructor, (and aggregator type) the expectation is that it will try to perform copy construction, unless your types contained in the object are not themselves default constructible in which case that may also not be the case.
4
@Resurr3ction UB tends to fall into one of two big camps, it gets optimized out in some manner, or it does something kinda like what you would expect strangely, it depends on what specific behavior you're asking of the compiler as to what it will do, and there are some manners to actually force UB optimizations, 95% of which are compiler intrinsics (like std::unreachable is implemented via compiler intrinsics and is guaranteed to trigger optimizations that either trap or remove the unreachable case)
4
Honestly with C++20 and C++23, even going back to C++17, its already immensely safe, if you don't use stick to the C way of doing things, it pretty much solves the same problems as Rust without forcing you into a paradigm that has you wrestling with the borrow checker or the language in general.
4
The memory security concerns aren't anywhere as significant as people make them out to be either since you can compile the address and data stacks to be distinct places, and even then unsafe memory exploits aren't the most commonly exploited types, so memory safety won't actually negate the exploits in the wild.
4
@ Rust's desire to mandate runtime costs for memory safety and elimination of undefined behavior prevents a lot of optimizations that make C++ really fast. (granted its fast, one of the faster compiled languages when you don't consider build times, but C and C++ will still have it beat)
4
@ That which is fast can have safety integrated on top of it, that which is safe can't have speed integrated on top of it, its a one way street, if you need memory bounds checking, you can do it in C++, its always been part of the standard, but majority of the time its not needed/wanted, you don't want runtime bounds checking when you already know the bounds at runtime can't violate, that's a needless waste of performance the compiler is incapable to optimize.
4
Majority of the time a vector (dynamic array) with a pool, SBO, and/or static buffer are just as good as a fixed size array, unless you have some reason you need to avoid heap allocations.
4
@rusi6219 Spoken as the lingua franca in much of Europe, East Asia, and even through a large part of the Middle East, its about as universal as can be right now, it has more popularity for communication then French had in the medieval period, which is where we get the very definition of lingua franca from. (its literally in the name)
3
@ Its formally used and recognized as such in the Philippines, South Korea, Japan, India and China. As well as anywhere that's had moderate internet access for around two decades. And lingua franca literally translates to "language of the Franks".
3
@ "Removing reachable code is not an optimization. It is arbitrariness." That's objectively false, it absolutely is an optimization.
3
I don't really get the point of claiming to have a better language when the language will deliberately get in your way for almost everything. I don't like any of these new language syntaxes with the postfix type declarations for example, but at least Zig is actually capable to be a replacement for C, Rust doesn't really do anything better then C++, the ABI is guaranteed to be compatible just as it is in C allowing shared libraries and fast compilations.
3
I still don't see Rust's borrow checker solving any problems that RAII in C++ didn't solve better. Could've overhauled the concept of RAII instead, the borrow check is simply the worst choice, especially in claiming to be simple, its only "simple" when you don't come against something that makes you have to think about it, systematically RAII is a lot simpler and easier to wrap your head around, and if you want to violate it, you can do so without breaking the language.
3
That's also C, there are better alternatives in the standard library to scanf for C++ unless you need absolute speed, though there is a library that does what fmt did for printf but for scanf. Its called scnlib, its performance alongside safety should be better then any other alternative.
3
@ A number of the compile-time safety features also prevent the compiler from properly performing optimizations that are comparatively easy for a compiler to do in C++.
3
@thekwoka4707 Its demonstrably still slower then C and C++ in every case, there isn't a single a case where Rust beats C and C++ in performance because Rust makes numerous runtime cost decisions for safety concerns, safety and performance are a tradeoff, if you can't understand that then you don't actually understand any of the languages or anything about language design, and there are plenty of cases where you can't get around that and Rust does not permit you such. I've said nothing untrue, if you don't understand tradeoffs, you aren't a software engineer.
3
@yapdog 99% of the time its because people completely ignore the standard, while UB may or may not work in some version of GCC, there isn't a version where lack of UB failed, that's supposed to be one of the reasons for a linter. And that's why I deliberately try to avoid UB unless I am required to use it.
2
C++ works specifically because you can use C when you need to and then output a C linkable elements using extern "C", so you can use no cost abstractions in C++, like unique_ptr is a no cost abstraction so long as the destructor is trivial and so long as you use the default delete function. There is no reason not to use unique_ptr in such code because it costs you even less then nothing in C-like C++, which honestly you should just be using good C++ practices, but whatever.
2
@ "It is my program, my responsibility. Nobody dare to remove or omit code I wrote from MY program." Follow the standard and that's guaranteed with the as-is rule. No matter the language if you don't follow the standard, no compiler has the obligation to produce expected results. Its pretty simple and easy to follow the standard so you're without excuse especially when we have linters for this.
2
@ "Compiler MUST compile every my command, as is. Otherwise it is bad compiler." That's not remotely true in any language. That's only true in an assembler, stop writing in a programming language if you want that.
2
To be fair, also presumes that you're iterating the list, if you aren't, they aren't as bad, but in most cases when you make a container of elements that isn't like a map/dictionary, you're usually iterating it, hence why lists tend not to be a great container to resort to.
2
@minneelyyyy "Although I do have to disagree with OP, while I do recognize that a lot of memory bugs don't end up being actually able to be exploited, there are a number of actual major exploits that have happened." For some of the big ones sure, but most of the blame for those already lies in legacy support anyway, (in a legacy C syntax too) and Rust wouldn't fix that either. Like had they written those sections in even proper C++98 with RAII, they wouldn't have happened either, Rust wouldn't have solved it anymore then C++ should have, and the reason C++ didn't solve it was because it wasn't written in C++, and you wouldn't have been able to replace it because people still rely on the C functionality as it was written for compatibility. A lot of Rust developers don't understand legacy and maintainable code, what was first written will be relied upon to never change else you will brick systems. and Rust has enough holes in even its "safe" system that it will absolutely be abused to accomplish similar things, its just a matter of people getting good and learning the esoteric things like they did with C++.
2
Pretty sure its an Option<Box>
2
@virgodem Rust's desire to mandate runtime costs for memory safety and elimination of undefined behavior prevents a lot of optimizations that make C++ really fast. (granted its fast, one of the faster compiled languages when you don't consider build times, but C and C++ will still have it beat) A number of the compile-time safety features also prevent the compiler from properly performing optimizations that are comparatively easy for a compiler to do in C++. That which is fast can have safety integrated on top of it, that which is safe can't have speed integrated on top of it, its a one way street, if you need memory bounds checking, you can do it in C++, its always been part of the standard, but majority of the time its not needed/wanted, you don't want runtime bounds checking when you already know the bounds at runtime can't violate, that's a needless waste of performance the compiler is incapable to optimize.
2
@ And what if I told you I was in Turkey? What becomes of your argument then?
1
@ Don't ask fallacious dumb questions and you won't get a smartass answer.
1
@ That's still not a refutation, you really love your fallacious deflections.
1
@rusi6219 And how would you respond if I wasn't American?
1
@ In the former Soviet bloc that be true, but outside that it most certainly isn't.
1
@ "Yeah, compiler MUST NOT optimize via UB and via removing reachable code, written by programmer." As a C++ developer who has used it to handle optimization, this is a terrible take, it is the only way to take advantage of performance improvements that are per-platform or per-compiler in many cases.
1
@ "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