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.

So, generic code with a loop, which, depending on parameters, sometimes has side effects and sometimes doesn't, and in the case that it doesn't have side effects it is still not easy to recognize if the loop terminates?

I suppose that is possible, although I'm having a hard time coming up with any reasonable examples.

>You'll often be stuck with code that you know is flawed, that you want to fix, but the organisation won't give you time to fix it until it's too late.

This has unfortunately been my experience as well. Although in some sense I can understand it now. When only ~10k normal people per year use something, the chances of one of them trying to kill it are apparently pretty low. Although I'm still convinced at some point it is going to happen.

What point is there in deleting side-effect free loops though? Literally the only use for those is to trap the control flow.

Okay and which optimization does this allow for? What's the difference in the emitted binary?

Is there even a case where the compiler can optimize a terminating loop better when it is allowed to assume that it will terminate at some point?

"Really keeping things secure" has a lot of definitions. If your threat model is some guy on the other half of the planet half-heartedly trying out leaked passwords, 2FA is great. If your threat model is someone local specifically targeting you, 2FA kinda sucks, while a good password might do the trick. If your threat model is you getting abducted and hit with a wrench, then you should probably make some sort of shared key with multiple people where you need x% of all parts + invest if physical security.

The problem with doing that as a library writer is that exceptions, used well, generally change the entire interface and to some extent programming model. It starts with simple things like returning values instead of an error code (and setting value by reference) and goes through having to make "factory" functions for classes (if you want to use error codes) and ends with all sorts of considerations like copy constructors in C++.

So in many cases, if you don't want to compromise on design and architecture, you essentially need to write the entire library twice, or at least the entire interface. Not really a great state.

>discussing "Low-cost Deterministic C++ Exceptions for Embedded Systems"

This exact reason is why I think that paper is great and also how exceptions should have been implemented in C++ in the first place.

When your main argument for not using exceptions for every kind of error handling is performance instead of architecture, then maybe it is a sign that exceptions should simply be constructed to be more performant instead of giving people advice that isn't and can't ever be consistent.

As the writer of a library (or just other utility functions), you simply cannot know whether something is an exceptional situation or not, because that is a property of the program and the environment, not the function. Being unable to parse a string to a number, or to create a socket, or to even allocate memory can all be exceptional or not exceptional depending on the context, and often you simply do not know the context this code will run in, or the code will actually run in multiple directly contradictory contexts.

>Should everybody be incentivized to relocate to a developing country or tax haven because of the internet and your equality rule?

Yes, actually. Well, tax havens shouldn't be legal in the first place, but getting people with good salaries into poorer countries is good, because they pay taxes there.

Of course, the vast majority of people would actually not go to poor countries, they would simply leave cities. Which is also something that should definitely be incentivized.

Reminder that the MySQL Timestamp type is still 32-bit. And probably will be until 2037, if we're lucky.

If she's not in high school I wouldn't worry too much. I essentially missed half of third grade, all of 4th and 5th grade and half of 6th grade, and by 8th-90th grade I was pretty much caught up completely without even a real catch up program. A lot of the stuff your learn at that age simply becomes trivial or at least much much easier just from getting older. In that case, I'd just give her some puzzles to solve or something.

If she is in high school the only answer is probably a bunch of "homework", good books on the subject, and there are also hundreds of video courses online.

I could imagine that not causing symptoms would probably be ideal if the virus could survive endlessly and not get eventually killed by our immune system.

But anything that does get killed by our immune system is kind of on the clock and needs to spread relatively quickly.

Considering the base idea isn't that DDG's search is better, but that their privacy is better, it's kinda the opposite. The people not using DDG would have to provide clear examples. (Or just say that they don't care enough about Google's privacy issues to switch.)

> You threw out $1000 a month, any reason?

Well I think it needs to at least be high enough that other social spending can largely be cut (except for healthcare maybe), and that seemed like a reasonable value.

Unfortunately I can't read the link you posted since I don't have an account there.

Well, the thing in Germany is that (1) there is actually a decent amount of new housing being built in cities but (2) there are often strict limits around where you're allowed to build, what you're allowed to demolish, and how high you're allowed to build. And during the past 5 years, demand has vastly outpaced supply. Property prices and rents in cities are absolutely insane, and there is no indication that that is going to stop.

And the reaction to it from people is quite... shortsighted? From my perspective. Often the exact people who would benefit from a better housing market vote for parties who are more restrictive in terms of new buildings. There's this perception that new buildings are only being built for "rich" people, which is true, but it also means the rich people aren't competing for your shitty apartment anymore. But somehow, people don't really think about that.