>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.
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.
But why do you need to mention that this number is inside a box? It seems strangely contrived. Even if the number was outside the box it would be a pointer, it has nothing to do with being in the box.
Because usually a pointer is stored in memory in exactly the same way as the things it points to.
Another useful feature of this abstraction is that if you open a box and find a number you don't know whether it's a pointer to another box or whether the number means something else. This demonstrates how, at least in C, your types aren't stored in memory along with the values and you need something else to tell you how to interpret the value you find at an address.
When you explain floating point numbers you also put them into boxes? No need for that, you can explain them intrinsically, just like pointers.
Moreover, in practice, it is clear to think that you already have your pointer in your hands (e.g. in a register), no need for your pointer to come from the RAM that it is used refers to. This is an unnecessary recursivity.
>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.
If a bank is in danger of running out of money, then (in the US, where I work in banking) the federal regulators step in and take over the bank. They sell off assets to other banks and pay depositors their money (up to the EXTREMELY generous limits of FDIC insurance). The funds to pay for the losses come from an insurance system ("FDIC") that all banks pay into. (And in case of a widespread collapse of many banks at once, the federal government underwrites the FIDC insurance program.)
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).
> essentially models a resource or lock of some kind
I agree that proper RAII is generally the way to go. I think of ScopeExit as being for those situations where you have to deal with C-style code. One way is to wrap the C-style code in C++ and leverage C++'s RAII. The alternative is to write C-style code yourself, but you can still use ScopeExit to ensure you didn't miss any edge-cases where cleanup is necessary (multiple points of return, exceptions, etc).
In this way, ScopeExit is for 'C++ as a better C' programming.
> 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
This is going far further down the C++ rabbit-hole than what we started with, though. If I just want to be sure that I didn't miss any places where I need to call free (or similar) in my C-style code, ScopeExit is just the thing.
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.
> People mixing completely different styles in C++ is a nightmare.
This is really not my experience. Any decent-sized program will have parts more in a functional style, others in a more OOP one, others in regular-typed Stepanov bliss, others in template or constexpr metaprograms.... and this causes zero issues in practice once people get past their assumptions about what clean code should look like.
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.
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.
Not yet but businesses are closed. So employees can't work and owners can't make money. Employees still have other bills to pay.
When the businesses open people could be so indebt they aren't able to start spending again quickly. The 1000 dollars won't boost the economy right now but will help recover faster when things start going back to normal.
There are going to be a lot of interesting conversations with landlords in the coming months. "If you make me pay rent, I won't be around when the crisis is over. If you let me off paying rent, I will get back in business and start paying rent again faster than any other way you could fill my space."
> Maybe right now the focus should be on not making people homeless
I think this is the primary motivator for providing money to all Americans. Many people on HN who are salaried and able to work from home might not be worried about making rent but many people who work hourly jobs aren't getting a paycheck this week.
Corona isn't the reason, the government response is. I'd like to keep reminding people of this denotation, even if you currently disagree with the connotations.
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.