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

Solution for C vulnerabilities: Use modern C++ People complain about C vulnerabilities, then claim "C++ has them too" except every example I know of where they claim this, they just use cstdlib, if you're an idiot using printf I don't know what the hell you were expecting, even if its slower you can't get those problems with iostreams, they're inherently safe, if you want something faster use std::format or fmt, literally faster, safer, and by default is compile-time checked. For pointers we have unique_ptr, shared_ptr, span, string_view, string depending on your specific needs, you'll never get an exploit if you use these.
1
Anyone gonna mention you can pass unique_ptr by reference? Unless you need raw pointer behavior too, with unique_ptr you should prefer passing a unique pointer by reference, if you need nullability otherwise use raw pointers, else use references.
1
@notaboutit3565 What? When did I say anything about real world use case? All I said was that C most certainly isn't safe outside a dev environment, and honestly even within one undefined behavior is most certainly still not safe, in which is the only case I was wrong on.
1
@notaboutit3565 Oh absolutely not, when I say its unsafe, I mean it doesn't have all that many systems to help keep the developer's work safe, in part because that was all C could afford to have at the time the systems it does have were as safe as one could make a good machine compiled language at the time, (most prominently being its typing system) unfortunately including UB as well. I don't fault it for its flaws and greatly appreciate it for what its done (without C we wouldn't have some of the best language syntaxs yet devised I'd say, that is C's fault entirely derived of ALGOL) and I know that it still has its uses to this day, (after all I know both C and C++ and have used them in many places before) though I would say I'd prefer a more suitable grandparent of C derived of C++ then to see C to still be the most prominently used, but I don't see any good ones that don't piss me off.
1
You need to keep in mind that historically C++ vtables were better on older systems then they are now, modern systems have made it harder to justify their current existence except when the inner elements of your virtual table functions is the hotpath. Also final pretty much makes them almost as fast as the function call because they get "devirtualized" by the compiler.
1
@softwarelivre2389 I find it reads backwards and adds unnecessary symbols, like the type is more important and you're defining the variable by the type, the only reason I can see to not follow ALGOL is if you have a typescript "needs to be a subset" problem, which is why I get so frustrated, it doesn't even follow the mathematic standard for typing either which is the only reasonable justification I can see anyone making for doing it.
1
@MaxNaumchik "let (x, y, z) = fn_that_returns_tuple()" C# already does this (since C# 7) and C++ could already support this syntactically even if it currently doesn't. (C++ would need some way to define a tuple in the language, not just in the standard library) I don't see why you need that syntax to support it given I can already do var (x,y,z) = FuncThatReturnsTuple(); with C#. "That is if you do need to explicitly type those in the first place. I find this to be a very rare case." All library development requires it, every single library I've ever seen explicitly forbids the use of auto or any other implicit typing in its style guide, it becomes near impossible to read without an intellisense to render the information and plenty of contributors don't use a full IDE, and those projects aren't purely made by folks who use IDEs. Plus its a nightmare to do code review when you do that. "Also, I think that some older languages like C/C++ have the type going first because historically they just required the type definition (no `auto` for inferring the type)." No, multiple languages before C did it,some with a form of implicit type and some without, but C is based on ALGOL, which doesn't, that's the reason, it was intentionally developed in that manner. The position of the specifier has nothing to do with implicit typing, its based on a specific math syntax, but the problem is that types in math can't be implicit. And honestly the only reason anyone did it in more recent languages is because subset languages like Typescript did it because it was the only way to retain the subset, as an example you don't see the same thing pop up in Dart which despite trying to equal Typescript is not remotely close to a subset. The reason functional languages do it is because of the math syntax where functional programming is heavily inspired from. I still say that's stupid because the type is more important then the variable even in functional cases, and its less verbose, but apparently people don't care how things read still. We didn't back then and we're just doing it again. "So the syntax C/C++ come up with without any additional unnecessary keywords or symbols for the case worked just fine." While the keyword of auto was useless and obsolete, that was just a cleanup of the syntax, better to use up an existing keyword then to make a new one, and it describes what its doing in contextually. "But since in modern world the concept of auto-inferring is widely accepted and used," If you're not building a library or something that doesn't need to be well documented maybe, this is a generally foolish statement, there are too many good reasons not to imply types that forcing it and only adhocing an afterthought solution is retarded, especially when you have a cleaner, less verbose, integral declaration that does not take any more work on the parser. "modern languages have this style because all of them have the type declaration optional." If I saw Linux, Godot, or Blender constantly using type inference I would be angry and would the rip the developers a new one, you can't have a large project that relies on type inference and expect it to read decently at all. It only works decently for projects that don't leave your environment. And even in C# code formatters by default will tell you not to use type inference ever. "Having this `let` (or other keyword) allows to explicitly separate variable definitions from just simple assignments to the existing vars." And why does separating them matter? You never gave me a good reason to do that. Its a type declaration, why shouldn't it be associated with a type? "For consistency, `let` goes always first," For consistency the type goes first, how is let anymore consistent? And why does that matter? The parser doesn't need it and its a literal wasted symbol for the developer because it means nearly nothing to be read. "variable name goes always second and any optional stuff (like type or actual assignment) goes afterwards." Types are not optional though, even in dynamically/loose typed languages, the type is still of vital importance, and in library development its so vital that you will routinely get in trouble if you don't provide explicit types. And the only reason everyone hates explicit types in C++ has nothing to do with the types, (languages like Rust grossly misunderstood that problem and solved the actual issue anyway, it didn't need to implicit type anything to fix it) it has everything to do with how C++ includes work, you can't declare a using in header files without polluting every global scope that uses the header, C++ modules this issue dies entirely and just do what C# does with using. (which doesn't pollute the global scope because it ignores the concept of files entirely) Why the solution for that was consider implicit typing is beyond me, there were a lot simpler solutions for this. (you don't need the full modules system, just a subset of it corrects this issue entirely, its only because #include is a macro that expands its reference to a file that we even have this problem in C/C++)
1