Thats my view as well, but I do believe that pointers are really difficult up until they click, and then they are easy

@@pxolqopt3597 Initially it seems redundant to have an indirection to your variable when you could just use your variable because your first pointer lesson is int a = 42; int* aPtr = &a; // do stuff in the same scope with aPtr instead of a for some unexplained reason. Then you find out about dynamic allocation needing somewhere to store the address memory was allocated and it makes sense for that, then you see the benefits of pass by reference instead of by value for large objects and realise that's actually passing a pointer too. Then it make sense.

@@pxolqopt3597 I think its just because they're explained badly, the concept that everything in C is really just memory needs to sink in for new users

@@pxolqopt3597 Yeah, the challenging thing is the concept, which really isn't about the coding. Once you piece it all together that variables also point to places in memory, it makes a lot of sense.

​@@burnttoast111as soon as my professor spent 10 minutes drawing a memory diagram it clicked for most of the class

This. I wouldn't call it illusion though. It's just that you need a humongous amount of knowledge to do it right.

@@artxiom and you'd have the same problem with any language, except most other languages don't let you do that.

You dont need move semantics. It's optional. I don't use it at all.

And if you're less careful, there are "hidden" copy constructors and stuff behind a simple statement, like A = B + C + D;

@@Vitorian That's silly, almost everything is optional, but move semantics are one of the most useful concepts in C++. If you don't use it you are doing it wrong.

they are

Amen

Yeah, the problem is when you forget to call "free" or accidentally use the freed memory, or dereference the null pointer... By itself it's not that hard, but sometimes you just forget that precisely BECAUSE it is easy(kinda like forgetting a minus sign in whilst solving a Calculus problem)

​@@user-hh7kt4le3q Those are all a solved problem in C++, and has been for a long time.

​@@user-hh7kt4le3q Well, don't forget.

After reading... Thank god, it was a horrible argument

​@@thebrowhodoesntlift9613 I mean, you don't expect us to just take your word for it, do you? Are you willing to take a shot at giving a synopsis for why you feel that way?

​​@@mkvalorI don't, I just gave my opinion... But, I'll expand: he's equating 'unsafe' rust to writing assembly in C++... but unsafe rust is still rust, valid rust, assembly isn't C++. The real equivalent would be assembly in Rust vs C++. Unsafe it's very much a part of the language, it's just removes some of the EXTRA guarantees that rust compiler gives you. It's much more similar to templates in C++, it's a dirty way to hack around things but it is still the language itself. The rest of the article was really good though! Anyways, I might be misrepresenting him so here is the segment from the article for you to decide: "The “unsafe” excuse Upon reading this, some pundits will throw the recurring excuse “oh but Rust has unsafe mode where you can do yada yada”, so let me preface this article with this analogy. Calling “unsafe” as an escape for Rust’s rigid system is the same as saying that C++ can do inline assembly so you can copy/paste infinite optimizations done outside the compiler infrastructure. That defeats the purpose. We are analyzing what the language can do in normal operation is, not the backdoors that it allows to open when it gives in to operational pressure."

@@mkvalor ​ I mean, it is a pretty bad argument. Sometimes you really need to do some inline assembly (this is supported in both rust and c++). One case that comes to mind is byte comparison for cryptography purposes. Often times you _really_ need to compare bytes in a constant amount of time to avoid timing attacks and make sure the compiler doesn't optimize the code and return early on the first differing byte. If you have a need for it, why would you not use this feature? then you might say "then why don't you just use assembly?" well, c++ and rust are still _much_ safer to use than raw assembly, and containing the hand written assembly code into small pieces where needed is better than throwing your hands in the air and porting your entire project to assembly. honestly, I'll probably point to this example for people that make the similar argument against rust of "but you have to use unsafe sometimes, so just use c++".

@@mkvalor He says unsafe Rust == assembly in C++ which isn't remotely true. Rust has inverted defaults to C++, it is safe by default and if you want you can slide back to C++-style wild west with no safety via unsafe {}. It will still be valid Rust, which is crucial to understand, but it is your responsibility to make sure it is correct & safe as you explicitly asked the compiler not to check it (e.g. using borrow checker). But the syntax and most rules will still apply as normal with some additional rules specific to unsafe blocks. Completely orthogonal to the inline assembly which can be used in both C++ and Rust.

they

it

just to be more specific: "implementation-defined behaviour means that the compiler must choose and document a consistent behaviour. unspecified behaviour means that from a given set of possibilities, the compiler chooses one (or different ones within the same program). undefined behaviour means arbitrary behaviour from the compiler."

in c++ and probably in c, the "int" type doesn't have explicit memory allocation value, it can be 1 byte, 2 byte or 4 byte, that depends on compiler. So probably in his case compiler turn that numbers i8 under the hood and because in rust there is no implicit memory allocation on integers, compiler basically makes that operations with 4 byte values.

that case with the multiplication seems more like an unspecified rather than undefined behavior situation imo

I mean it just is

Ditto. C-flavored C++ all the way

Why I think x86 ASM is better than C

Why I think

Why I think VHDL for FPGA is better than x86 asm

I partially agree with that. C++ as a language is a middling experience, but dependency management is god-awful, and it accentuates the annoyances of having decentralized build systems.

also rust libraries tent to have 0 documentation, or some auto-generated garbage

@@qeqsiquemechanical9041yes because C++ libraries are the hallmark of documentation

@@qeqsiquemechanical9041 "rust libraries tend to have 0 documentation" you sure about that? usually rust documentation is pretty great.

Whether or not "[Technology X] allows you to rely on code that you don't control" is an advantage... well, that's up for debate. Just ask NPM.

Like Prime said, it works for the authors use case. They can check all compilers and find the one that works for their hardware. HST developers pay so much attention to the smallest parts of the trade path that they sometimes write their own routers because itll save a couple of nanoseconds. Its crazy world out there, and they Know what the compiler does because they check. There is a good talk on yt about the level of optimisations they do and its mindblowing.

@@TrueHolarctic Except it is not guaranteed. I work in high frequency trading too and relying on stuff like this is stupid. One day it holds and the next day compiler just deleted your code (because it's UB, it can do whatever, especially Clang is super trigger happy and deletes most UBs it detecs). So yeah, crazy optimizations are done but this is beyond crazy. It's called "undefined" for a reason.

@@TrueHolarctic At that point shouldn't you just use the compiler as an intermediate and then just hand tune the assembly to perfection?

@@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)

compiler assumes undefined behavior will never happen. So it can optimize without considering it as an edge case.

I took a C++ class as a junior programmer and hated it so much. Stuck with C# instead and went on to do well. It definitely didn't appeal to me as a beginner, maybe that's just me though

I agree c++ is a language that you can only learn and not teach.

Could you give some examples of C++ expert styles?

What do you mean by programming styles?

prvalues, copy elision, SFINAE etc@@cziwochel3415

A very good point and really the reason I like rust so much compared to C/C++. Once I get a program in rust to compile without errors or (significant) warnings, I can be almost certain that said program will work exactly as I intended (with maybe a few logic bugs and the like) because the rust compiler made sure to check that the code I was writing was correct. This means I only need to be a somewhat decent rust programmer to write good rust code, whereas I would need to be an expert C/C++ programmer to write good C/C++ code. I wish more rust enthusiasts would emphasize that correctness is what the rust compiler really helps you with and that safety is more of a happy side-effect.

All input is malicious, always! Because the final user will always find a way to insert data coming from an unknown origin into the program...

"The truth is that many deployed C++ projects run fine for decades with no stability or security consequences to the contrary of the popular narrative" Until... And that's the hard truth for (to the best of my knowledge) all C and C++ code bases. I say this a Rust programmer with 45 years of C experience and almost 40 years of C++ experience. I have never seen (and nor have I ever known of) a C or C++ project that didn't have stability or security issues in all of that time. I've merely observed that these things hadn't been discovered yet. Until they were.

@@appstratum9747 In your experience, how many of these issues were due to things that Rust fixes? I don't have the experience that you do, so I don't have a reference for the types of issues that usually pop up in large c++ code bases.

@@sweetcornwhiskey The primary categories of issues with C++ that Rust deals with at source are virtually all related to inappropriate memory access beyond that allocated, use of memory when that memory is no longer valid for use, concurrent reading and writing of the same region of memory (by accident: race conditions) and so on. All of this is covered by the Rust language and most of these problems are eliminated before the compiler compiles successfully. Another important class of errors that Rust avoids is the failure to code to cover all the possible states of branching logic. At all points in the codebase. Null pointer issues are another category of errors that are eliminated. There is no null in Rust. In Rust you are forced to deal with the possibility of a value being invalid. In C you're not. In part because what invalid represents is very difficult for the compiler to understand. Software development practices are almost always designed to limit the negative impact of the weakest members of a team. The problem with C++ is that even on the miniscule chance that everything is defect free today, at any point in future someone on the team might break it in a serious way: by introducing a memory-related defect that hasn't been detected during testing. All C++ projects have decades of vulnerability to weaker programmers introducing critical defects similar to those already mentioned. Or corner cases that weren't expected. Rust protects against much of this. Even if the software was apparently free of vulnerabilities when it entered production C++ can have serious vulnerabilities introduced down the line. Another category of errors that Rust eliminates are those related to interchangeable datatypes. Int and char for example. Or relaxed casting from one ordinal type to another. In C++ you can get away with this with possibly very nasty surprises at some point in future when you get unexpected data. Not so with Rust. It's very strict. I wish I could spend more time answering you. But I hope I have given you at least some idea. The reason Rust is so frustrating for many at the outset is that the compiler forces you to address all the things that you would otherwise have forgotten to or didn't even consider. Whereas C++ will simply compile and you will find some of those oversights in testing. It's the ones that you don't find that become security vulnerabilities down the road. The Rust compiler is criticised for being slow. And it is. But it is doing so much more for you that nobody is going to do for you when programming in C++. It annoys you and nags you. But it won't let you build software until you deal with the issues. Rust holds developers to account for their decisions. It's obstructive in that sense. The pay off is that it's much safer. When you want to do something unsafe you're very well aware that it's unsafe.

@@appstratum9747 It's insane to me that anyone thinks that C and C++ devs are all 100x devs who know EXACTLY what they're doing... Code bases are living and organic - they flex and stretch before they collapse and wind up, they are often subject to change and improvement - the speed that you get when you commit to Agile development practices or follow the "Working, Right, Fast" pattern (MVP: get it working, first pass: get it right, last pass: get it fast) ultimately comes at the cost of safety. Shift-left is a real thing, it's a MASSIVE thing, it's hard to get a job without being proficient in unit testing and a red flag when somewhere doesn't do it: Rust shifts memory errors LEFT. It's made it simple to solve these errors, and helps speed up developers to get safe code who might not be as proficient by way of teaching. C++ is NOT as good as Rust in virtually (haha, virtually...) any situation, and in Rust you can just invoke unsafe code to get C-like syntax: Rust wins, every time, to say otherwise is cope lol. Addendum: And there's nothing wrong with C. There's plenty wrong with C++, but at the end of the day, it produces results which fulfill requirements. Rust is a very natural evolution of systems programming languages: it's just better at what C and C++ do. It's just better at what C tries to achieve. It's just better when safety is a requirement, and if you have any respect for your users, then safety is a requirement.

To beat a dead horse: pub fn noop(x: i32) -> i32 { ((x as i64 * 2) / 2) as i32 } gets optimized into an actual noop (as we are proving that overflow can not happen). So, a correct program in Rust gets correctly optimized, and shit program in Rust gets to crash rather than UB your entire production.

As someone learning C++ with some C# experience. I dont like Unique_ptr, its more annoying to remember and use then just slapping * and & symbols. Sure it doesnt look as cute having Unique or ComPtrs and aligning the spacing perfectly. But for learning and do things without a team/personal. RAW all the way

Unique cases are only "not compiled away" in case the object it is holding is not trivially destructible you can check for if the object is non destructible using a cpp concept static assert. Even then it's mostly compiled away for most -flto cases. It's pretty awesome.

In the general case the destructor also incurs an if-not-null check for the delete call or let's delete's internal logic do that check. So pick your poison: redundant if-checks or redundant delete-calls. You are at the mercy of the SSA to get rid of these. Admittedly most programming patterns are amendable to this.

@@freezingcicada6852 unique_ptr is not replacement for & and *, it's meant to be replacement mostly for `new` and `delete` (and other for custom allocators and deallocators) if using `new Class()` and later on `delete obj` rather than just using `std::make_unique()` and letting the compiler handle later on deleting of the objects is annoying for you, then I'm not sure what to tell you. But from what you wrote, it feels more like you're using it wrongly, imo it can be especially useful while being member variable of classes, where you can just omit having to handle destruction of it in the dtor and not having "space" for leaking memory.

See Chander Carruth's talk on cppcon2019 why unique_ptr is not a zero cost abstraction ukposts.info/have/v-deo/qnh6n6imq4moxJc.html

"if you know how to use it well" is always the argument I see thrown around. What if a language would just have these zero-cost abstractions built in where you don't have to "know how to use it well" and it just works? Sounds crazy, I know.

compiler likely will do better job optimizing than you

@@dealloc Maybe you are just very lazy and/or not smart enough?

@@dealloc no language is like that. They will all run like poo if you don’t know the pitfalls.

@@dealloc You are now describing C.

That comparison sounds about right to me! I think *std::shared_ptr* in particular is probably more akin to *Arc* in Rust because, if I'm not mistaken, the internal reference count is itself atomic (please feel free to correct me).

​@@xplinux22 Actually, std::shared_ptr is more akin to Option because in C++, std::shared_ptr can be null, while Arc cannot.

@@white-bunny Right. If we want to get very deep into semantics, we have to remember that Rust references and smart pointers are not nullable unlike C++.

@@xplinux22 C++ references aren't nullable either.

@@spell105 but c++ references aren't smart pointers.

wdym compiled out? the vec size is not known at compile time.

@@hwstar9416 No, but when iterating over every element you don't have to test the length every single access.

@@hwstar9416 Rust bounds checks are minimal. If you have iterator loop , you know it is safe. If known size vs known index - no need for check. If you iterate from 0 to n (n user given) in array of size X, it will do bounds checks, but if you make a line before if(n < X ), the bounds check will be done only 1 time not for every iteration. And even if you do full check, max performance penalty with special loop for bounds check is 10%. typical is 2%.

Yes but likewise if you iterate over every element in C++ with a range for loop / standard algorithms you're also not going to access invalid memory. So yes, Rust incurs no performance penalty but it also has no safety benefit. This case is the same in both languages because there is no tradeoff to make. It's the raw access case where C++ chooses performance and Rust chooses safety.

The checks incur minimal, if not statistically insignificant, performance hits. If anything, it’s code size that you should worry about. In applications where you would worry about the bounds checks, you are already doing unsafe everywhere and likely to (should) use assembly or maybe C.

Pointers are def easy, it's just an index into the 4GB byte array we call RAM. (I say 4GB as I recommend anyone to learn systems programming in 32bit first)

F in the chat for everyone still using matlab

@@isodoubIet F

Did you measure the performance cost of unique_ptr vs raw ptr?

@@vladimir0rusgo to godbolt and check the generated assembly. Most of the cases, the unique ptr is not compiled into the code because it's literally just replaces a manual delete.

​@@vladimir0rus Measure what? It just limits how a pointer can passed. It shouldn't generate different code from a raw pointer.

@@vladimir0rus unique_ptr is just a wrapper for a raw pointer that disallows copying and has some additional functions. Do you honestly think there's a difference in performance for any compiler worth its salt? Adding functions and compile-time checks does not affect runtime performance.

@@greg77389 additional code always affects runtime performance, even if it is code for exception or some additional function (because L1 code cache is small). Even if it just a wrapper it might add code which will be present after optimization stage.

TBF, you can implement Exceptions in Rust using panic hooks, but, I'm too stupid/lazy to dig deeper into the topic (it's also probably unidiomatic and destroys the correctness/soundness of your code).

Erlang assumes the role of both an operating system and a programming language here, though. For long-running processes in most environments, the equivalent of erlangs 'let it crash' is programs just literally crashing and being restarted by something like systemd. Its outside of a more general purpose programming languages scope of responsibility to bother caring about this. But i do agree that using exceptions as control flow is dumb.

​@@sproccoliI disagree it is outside the scope. These general purpose languages are providing concurrency features which lack good error handling making usage far more difficult than needed. They treat concurrency as a 3rd class citizen and it is really harming the space. And the language typically *must* worry about this topic because without language integration they will always be lacking. Which is why every actor model grafted onto other languages always feel incomplete and more fragile than Erlang. Concurrency will only get more important going forward and if languages really need to catch up with Erlang wrt concurrency (and error handling).

I don't see how I can love the fact that Rust is worse language than C++ by literally removing features for no reason whatsoever.

The main issue is not how things are taught, but that so many people get into CS for the money and not for the interest. People who like coding will learn more about it and it's concepts, people that want to make money easily will hit a roadblock

I believe this is an example of survivorship bias. You’re only looking at the people who started off learning assembly and *kept going*. You are not considering the many many people who would start learning assembly get intimidated/ make minimal progress and then quit. Those programmers who started using assembly are likely naturally more talented and would have succeeded regardless of what lang the started with.

@@rkidyalso looking at ppl with a 20+ years of experience since ASM was a thing back then. Kind of like saying ppl who learned to drive on stick shifts are better drivers. btw, I had classes in 6502 and 8088 ASM and I just do Python now ;)

Interesting....Allah bless you my feller. I was thinking about this. Am a ME by trade, struggling w/ employment but have a REALLY nits strong interest in coding including niche stuff...or stuff that is niche so far. I will take this as a sign from God (maybe) that I am on the right track. @@DoctorWhoNow01

Which is a limitation that NOONE competent needs.

@@shinobuoshino5066 Sometimes, it's better to assume everyone is incompetent.

that does not in any way "break ownership". That's just a reference cycle, possible in every language, and perfectly valid in Rust as it's a shared ownership primitive. And since you're pointing this out as if it's specific to Rust, reference cycles apply to C++'s shared_ptr in the same exact way.

@@skeetskeet9403Sorry about the mistake. What I meant is that it is easy to leak memory that way. Rust's compiler will not bother us with it. So implementing the double linked list using two pointers will proceed just like any other language.

The program can only be exploited to get the privilege it has itself. Like if you make a single player offline game, what does the user have to get from compromising your program? Maybe they can get around piracy locks but the user doesn't get admin access if they didn't already have it. Maybe your program can be taken over by a malicious file stupid user got from the internet and loaded, the fault is mainly on the user there. If you install a mod, you have to understand it could break your computer, especially if games allow mods that are compiled libraries and not just scripts.

provided you use the default deleter.

@@khatdubell, unique_ptr with non-default deleter is analogous to Box where Wrapped has custom Drop.

@@mina86 I meat it’s zero overhead if you use the default deleter. I can’t imagine it is if you don’t.

@@khatdubell, if the custom deleter has no state than it’s also zero overhead.

@@khatdubell Actually no, even with a custom deleter on unique_ptr its free. Because its templated, there's no indirection happening at all. There's no function pointer stored or called. The function is written into the type itself and inlined. Templates can really be quite magical. This is the same reason why std::sort is significantly faster than C qsort. No function pointers, no indirection, and no jumps.

Coming from C++ POV, I concur.

Well, it is not a pressing issue until they lose all their money due to some UB they missed. After that it is not important anyway because the company is no more.

Domain dependent. In video games they're not a pressing issue, for example. And the idea that because you can be memory unsafe you will be is overall a stupid point. If you wrote a high-performant game in Rust you would use unsafe a lot. So the end result is the same. If it doesn't cause very many crashes then nobody cares and we all move on. If it does then you get a bug report and fix it.

@@lucass8119 >In video games they're not a pressing issue, for example. Considering that many games nowadays operate with real money, it isn't true. And even without money, it is very hard to debug bugs caused by undefined behavior. Time spent on that bugs better be spent on implementing features. Also, writing correct unsafe code in Rust is easier compared to C++ so the only reason to use C++ over Rust for videogames is the current lack of mature game engines.

@@user-nw8pp1cy8q games don't operate with real money, if they did, I could modify my game to say that I paid the company billions and have all most expensive cosmetics in the game instantly.

Surely, it's a big difference to just explain the concept to someone versus when you're trying to fix a bug in a complex or badly written codebase.

Depends on the context and who's the user. Rust is used to build a lot of tools and libraries in which the language does used has implications and the users usually care.

"many Rust developers" You started biased as this is not a "Rust thing", this is a "programming thing". Just as I saw many, many, many times C++ programmers saying C++ is the unique tool that should be used.

I agree. Although I've seen youtube video where Herb Sutter mentioned how the government put out a report specifically calling out C++ as a unsafe language and that it should be avoided. (Unfortunately I can't remember where that video is now.) So I guess the standards committee might still have to take safety seriously, maybe more seriously than it really should need to.

Finally? This has been the defacto standart since software development started, why do you think we have such a big mess nowadays with safety?

@@diadetediotedio6918 Yeah, it's crazy people are complaining that safety is a high priority for most projects. In fact, safety isn't prioritised nearly enough. I hate this "move fast and break things" attitude, to be honest.

So this might be more a matter that the "plethora of compiler options" just have made them not zero cost?

@@thekwoka4707 Ah, no. It's not about compiler flags. C++ iterators are the thing almost everything uses and those are completely fine. Ranges are built on top of iterators as well. (Well, ranges build on the newer iterator concept that works with a sentinel tags but that is besides the point.) One example of a typical C++20 Ranges problem is that if you have a sized range (which means the length is known) then this sizedness gets lost as soon as you chain any kind of range operation. This size property of the range can not propagate through the chaining pipeline in C++ and that is why its almost impossible to optimize those as effectively as they can for the traditional iterator loops. I think the plan was for compilers to be able to optimize this reliably but it turned out this is not actually possible. If the compiler can inline the entire thing then it can probably optimize it down to zero cost but you simply don't know if your compiler will actually be able to do that and you have to check by hand for every single case.

A little correction. It is essentially Rust's Rc, std::atomic is Arc.

​@@basilefffThe refcounting in Rc is not atomic, or is it? In shared_ptr it is atomic, as in Arc.

@@mario7501shared_ptr has some thread safety but it isn’t actually atomic

Isn't unique_ptr more like Option, but with a lot of implicit `unsafe { x.unwrap_unchecked() }`?

@@mario7501 Oh, read a little bit more on this. It seems you are correct, and I was wrong.

That's simply the price you pay for having a language that is actually useful, allows you to do what you need to, and doesn't constantly get in the way. If you don't need the features of C++, feel free to use something else.

another skill issue. to write good c++ you have to know c++. what's the problem with that?

C++ is not difficult to grasp, it just has an enormous amount of details you need to know, to write it properly. Sb unironically said when teaching it don't use this, that's a design flaw

If that is a problem then just write C, the complexity of C++ is just there for when you need it, but nobody is forcing you to use it and instead you can write proper C code that is more simple.

@@ColinBroderickMaths uh, the high number of miniscule details is constantly getting in the way, that's the point

This has nothing to do with C++, go ask microsoft to fix their retarded compiler if you need your code to work on windows. I personally use it as excuse to not support windows at all, windows users don't respect themselves and don't respect me either, I don't care about them.

/r/suddenlycaralho

-fno-exceptions -fno-rtti for major embedded compilers(GCC and clang)

@@uis246 nooo, you cannot just do this...

yet.

The gap is closing year to year

C++ had 30+ years to develop, so obviously there is a gap to close.

GCC is full of shit that isn't in the ISO standard

It's a compiler extension, you can turn it off.

I mean it is out of standards. why use it? Nothing outside the standard is guaranteed by C++ compilers. I haven't used scanf in ages lol.

​@@sids911compiler can guarantee whatever they want

@@sids911 It's not about out of standards or inside standards. The thing is, it is part of one compiler but not of other and is allowed. It can happen for other things and does happen.

Agree but it need testcase to capture error case. In rust you get as part of compiler.

I am better and smarter programmer.

@@anon_y_mousse Overqualified for life 🤣

It's possibly archaic from what I've read and 'predecessor' would be more common.

Nope,destructor still has some overhead because of non-destructive move in C++, check out the video „there are no zero cost abstractions“

@@TRex266 Trivial destructors are optimized out. I would not be surprised if unique_ptr has special optimizations to complete remove the function call on a moved-from unique_ptr.

In Rust, leaking is considered safe, so I guess they don't even factor freeing into the cost. What a safe language. Typical 0 cost abstraction. Now that I took my jab at Rust, let me try to reply with something that is actually serious: I think what they are talking about is the fact that the borrow checker is something done by the compiler but not something done during runtime. In the case of cpp smart pointers, some of their variants do perform runtime checks. This argument is kind of braindead tho because Rust still has to perform runtime checks for pointers and array bounds, but I guess that the Crab sect took saint NoBoilerplate's words too literally and they really do think that Rust is "just magic".

@@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.

@@Spartan322 Just command chatgpt to do it. I'm not writing that boilerplate myself nowadays.

@@tiranito2834 " leaking is considered safe" That goalpost move is so BS though seriously. "We can't solve the problem so we define it as non-existent".

​​​​@@isodoubIetwell, not really. leaking memory is considered safe because leaking memory on a fundamental level can be a desirable thing! For example, if you have a resource that you know will exist until the program exits. And memory leaks are fundamentally impossible to solve, you can always have a global value, or just put a thread with the value into an infinite loop. The reason it's not a problem in Rust is because the only times it happens are: you called Box::leak, explicitly leaking a value you called std::mem::forget, explicitly avoiding running the destructor of the value you have created a reference-counted cycle(which is a problem fundamental to reference counting as a shared ownership system, and exists in the same way in C++ with shared_ptr)

... but doesn't that defeat the purpose of a shared pointer?

@@ThePrimeTimeagen Not if you don't need the atomic counter, weak references should only be used when you absolutely need the atomic reference counter.

@@ThePrimeTimeagen No. Sometimes, all you want is the object itself, and don't really care who owns it as long as it lives "long enough" to complete whatever operation you're doing. For example, if you pass the object to a function (and that function won't place a reference to that object into another structure, which should be the case for the vast majority of free functions). In that case, the lifetime of the shared_ptr is guaranteed to exceed whatever lifetime the callee requires, so you can just pass a reference to the shared_ptr (or, as is my preference, to the owned object itself -- I care about what the object is, not the implementation detail of how it's allocated in memory). I pass a shared_ptr by value only when it makes sense for two entities to own a given object, for example in a concurrent cache. If my cache holds shared_ptrs I get to evict items from it with complete abandon because whoever picked up stuff from the cache will get a shared_ptr which won't get deleted until they're done with it. A lot of it is also down to what is idiomatic. Rust, seems to me, uses a lot of Arc and Rc where a C++ programmer would just use values instead.

you do the same thing in rust btw

​@@ThePrimeTimeagen Depends if its meant to be an owner of it or a thread-safe view. Shared-pointer is multi-owner, its okay to pass around raw-dog pointers as non-owning views of the data. You wouldn't write void foo(const std::shared_ptr k) { std::println("K's value is {}", *k); }, instead prefer void foo(const T*) { std::println("K's value is {}", *k); }. Because you're just taking a peek at the data, even if you were mutating it, you're not taking ownership of it. If you might need to check for nullptr, then you need to do that with the raw pointer and smart pointer either way.

The fact that the author has provided no code examples repro cases or benchmarks for their performance claims just shows to me that they are using the ancient technique of just making stuff up.

Literally just dedicated shelf space...pointers do take a bit of getting used to but there is absolutely nothing difficult or complicated about them.

The freeing/deletion is required to not have memory leaks everywhere. Any decent compiler will inline the function calls no problem.

@@Lttlemoi yes, but you have the Destructor function call of the unique_ptr, the Destructor function call of whatever its pointing to and the freeing if you do it manually you only have the Destructor function call of the data and the freeing

yes and it's especially annoying considering how simple it would be to remove the arrow syntax (->). The compiler already knows if things are pointers. It doesn't need the arrow. It could have used dot syntax for everything from the beginning!

@@sciencedude22 This is actually what D already does.

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++.

@@Spartan322 Gladly, the world is larger than your imagination.

@@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.

that* has

I suppose functional languages come close to the hypothetical language you were talking about, only adding things like monads in the part of the program that has to interface with the outside world..

*there are languages that force you to turn runtime errors into logical errors, or give up on the program ever running

@@Lttlemoi he's not talking about a hypothetical language. dependently typed languages exist and let you do this. they just aren't very useful for writing programs. but they are still cool. My favorite language in this family is F*

That's a long-winded way of saying you don't know how to write good code.

I don't think there's a language that can help with those kind of issues. As far as c++(or rust or any other language) is concerned, there's no GPU. And don't even get me started on GPU hangs.

It sounds like OSX GPU driver

skill issue

@@khatdubell If we go that route we can assume most of the world doesn't know how to write good code. Statistically speaking, chance of you belonging in that set of programmers is higher than other set. So we are either in the presence of a demigod, your highness, or a talking donkey; decide for yourself...

Do you have an opinion on which one of those scales better with increasing project size?

I'm not sure but wouldn't there already such an overhead in latency that you might as well just use a higher level, safe, simple language? But maybe you could orchestrate at the process level, not containers, but then we're just going back closer to metal anyway and the micorservice is just the smaller scaling unit conceptually.

C++ do not brings any benefit. Extremely hard to learn and use it well. Then your super fast microservice is packaged into a docker image, uploaded into kubernetes where it runs in a pod.

Acording to jetbrains survey from 2021, 8% of people who work on microservices use C++ and C. Most of them use java, javascript, python. Can you trust this survey? Duno

@@anon_y_mousse the ADD I talked about was not in relation to c++. Just an ekspansion of the lea. Wrt. Syntax the author could’ve normalised it. But no biggie

The main difference is that leal (%rdi, %rdi), %eax doesn't touch the flags, while add does.

Exactly my experience. Switched to C++ after 4 years of Rust.

@KayOScode I am sure you work at Nasa and you search ultimate frontier or real time operating system which can kill people if error happens... Like Airbus embedded system ? No kidding you are produce useless programs in a giant entreprise which produce useless programs ....

@@jumpman120k well newsflash bud NASA isnt the only place programmers work.

wake me up when your program is millions of lines of code

I'm sorry you have to work with such substandard coders that a "small bug-free program on their first try" seems like a milestone to you.

How many Rust projects have millions of lines of code? How can you be so sure its excellent at this use case when there are so few examples of it being done?

Have you tested out C++ expected... In my testing is has god awful performance compared to asserts and even exception but I would like to know your thoughts.

You're clearly a terrible programmer because performance doesn't mean shit when exception is std::bad_alloc and you only need to dump crash report and tell user that they should stop being poor, 2GB RAM isn't enough in 2024.

You're simply wrong? Exceptions produce faster executing code than return error types.

No. Bound checking does happen. It will get optimized away if the compiler can infer all indexes are valid. But if you get the index from a server or user input, that optimization can never happen. If rust didn't perform mandatory bounds checking, it too would fall victim of the SegFaults

What's the analogy then for incrementing a pointer?

​​​​@@TonyDiCroceIf a house address has the house number 1, and you incremental the house number, you get house number 2, the next house over. If pointer A points to memory address 1, then pointer A + 1 points to memory address 2.

@quc522 the part it's missing is that the amount the pointer changes when you increment it is determined by type of the pointer.

@@TonyDiCroce that would be like the yard size of the house. Btw, yes there is nuance to pointers, sure. I've basically never *needed* to increment a pointer while working in Tech Art or as a Game Developer, despite knowing how to do so. You don't have to use every feature of a language - and with C++ that would just actively harm you at this point, lol. My original point is that the basic concept of pointers isn't complicated. They get treated like viewing Cthulhu is a walk in the park compared to thinking about pointers though.