pingyong

>When you explain floating point numbers you also put them into boxes?

That makes no sense. If I was explaining floating point numbers with boxes, for whatever reason, I'd put the values inside the boxes, yes. The analogy just doesn't work here, but the analogy for memory makes perfect sense.

>This is an unnecessary recursivity.

No, it's not. Think of a linked list for example. Traversing it makes perfect sense with my analogy: You open the first box, look at the number that's inside, open the box corresponding to that number, look at what number is inside that box, open the next corresponding box, etc. - it all makes immediate and intuitive sense.

If you just start with "open box x" (because x you somehow already know magically because it's already in a register), you haven't really explained much.

Or think of pointers to pointers. With my analogy: Easy! It's just another box which contains the value of the next box. If this concept isn't explained, a pointer to a pointer makes no sense because the pointer value has no corresponding box, hence no address.

>There's something in here that's specific to SWE. I don't know exactly what it is but, I think we should figure it out.

It's changing requirements. When you build a house, people don't come in 6 months later and ask you if you could make one small change by placing some jet engines on the walls so the house can fly somewhere else during the summer. It's just a small change, right?

The problem is that in code, it often is a small change. Or at least, it is possible to make one quick adjustment to satisfy this new use-case. But often, these small changes are also a hack which doesn't fit into the previous overall design and which would've been implemented in a completely different way had the requirement been designed for in the first place. Now, one of these "small changes" don't tend to kill the product, but years or even decades do. That's why refactoring exists in software engineering, but not really in home building. Well, in some sense it does exist by renovating. But nobody thinks it's a good idea to completely renovate a house 25 times around an architecture that just doesn't work anymore for what it's being used for.

If you build a piece of software for exactly one well specified use case and only use it for that, it'll probably run really well forever. But (almost) nobody does that.

Because usually if I want to store something I put it inside the box? Not sure how that is contrived.

I've always explained it to people like this: Imagine a big cabinet, like a bunch of safe-deposit boxes in a bank. Each box has an unique number written on it, and the boxes are simply numbered 0 to 99. Now when you open a box, you find a piece of paper in it with a number between 0 to 99. It tells you which box to open next - so it points to another box. That's a pointer.

Seems to work pretty well, at least for conveying the basic idea of pointers and dereferencing.

>Defaults aren't permitted.

So, what happens if a bank goes bankrupt?

The housing market will never, ever crash again in any western country unless there's an economic turn that is incomparable to even what a 10 times more deadly COVID-19 could do.

I've been almost completely alone for about 3 months now, at least physically. And honestly... I couldn't feel much happier in that regard. It's been great. Maybe I'm broken or something.

>You'd have to define an empty class with a destructor, then instantiate the class at the appropriate place in your code. The point of Boost.ScopeExit is to handle that boilerplate for you.

I would argue that every time you want to execute something on scope exit, that essentially models a resource or lock of some kind. Which means the constructor wouldn't be empty (it would acquire the resource), and writing the class wouldn't really be "boilerplate", it would be clean design.

>This strikes me as hijacking a memory-management facility, using it for a different purpose than its intent. That's bad for readability. I'd prefer either ScopeExit or the dummy object pattern I described.

I think it is much better for readability, because it usually models the thing you want to do much more precisely. Although it is a shame that only unique_ptr is standard and not unique_handle, but you could write that yourself relatively quickly. This case doesn't just model that you want to execute something at the end of a scope, but that you have a handle to a resource that you can std::move around and that will get destroyed at the appropriate time (if you model your data correctly).

Because the C++ compiler accepts an absolutely insane variety of code styles. I say this as someone who mainly writes C++. If I write my own project, or a project where I only have to work with a small number of people all of whom I know have extensive C++ experience, or a project that is so large that I can afford to consistently rewrite parts, educate contributors and maintain style guides, I choose C++. But anything that doesn't hit these bells, I'd rather use C (or something else). People mixing completely different styles in C++ is a nightmare.

Well it can't really get much higher than 95% of the time!

Some absolutely will. That's not really what I'm trying to argue against, people who would become homeless or starve should absolutely be helped.

However, a lot of people seem to be under the impression that this would boost the economy (because the idea is that almost everyone gets money so they can spend it instead of specifically helping with rent or food), which I don't think it will currently, or at least it won't in a meaningful way that helps the businesses who need it.

Hmm. A lot of businesses will get into big trouble over the coming weeks and potentially months. Bars, event organizers, even shopping malls. They're all going to go down to almost zero profit for a while.

The problem is if you just give people money right now, they literally can't spend it on those things because they are or will be closed during that time. Money isn't the reason they're not going, Corona is.

The money would be spent on things that are doing well now anyway (rent, food and netflix/videogames/etc.).

Maybe right now the focus should be on not making people homeless, but then giving people money after the crisis so they can spend it in the industries that are suffering right now.

I'm not entirely sure how that is an example I asked for. In this case, it seems like the compiler in both cases was able to see that the loop always terminates, either by hitting 0 directly, or by wrapping around and then hitting 0, or by simply assuming integer underflow to be UB.

My point is that if a loop

- doesn't terminate, doesn't have side effects -> optimization doesn't matter

- doesn't terminate, has side effects -> optimization isn't valid

- does terminate, doesn't has side effects -> optimization would be valid, but why would such a loop exist? One example that was brought up was generic code, but I'm not entirely convinced yet.

They did that last gen already, PS4 and XB1 are just PC laptop hardware.