Shadow of the Erdtree would be my pick. Mostly because I haven’t played that many other games from 2024.
And I think it deserves to be nominated even if it’s DLC. The amount of new content is more than most games.
Shadow of the Erdtree would be my pick. Mostly because I haven’t played that many other games from 2024.
And I think it deserves to be nominated even if it’s DLC. The amount of new content is more than most games.
Not all written science is good science. Often the methodology is flawed. It requires very trained eyes to detect potential flaws in a methodology. It’s common that scientists disagree with each other. Science is the process to resolve these disagreements.
I don’t trust Sabine is able to accurately depict the current state of these topics. Her main expertise is physics. I don’t believe she can determine the quality of the papers she mentioned or make a complete survey of the topic.
And that’s why many are disappointed in her. She should know it’s not her field of expertise. She’s not in a position to make these kind of videos.
I believe it was more the success of the Bourne movies that set the tone of the Craig era.
I think the bigger question is which tone the new films will be in. Are they going to continue on the more grounded tone they’ve been doing recently, or will they do some campy nostalgia bait?
Unfortunately it’s the exciting politics that gets all the attention. Democrats likely lost because they’re just too boring.
Are people forgetting his Dijon Mustard scandal? Unforgivable.
I love it!
I consider it to be the best “detective” game ever made. Other detective games, like Phoenix Wright, can easily be brute forced. Just exhaust all dialogue options, and in the case of game over, just repeat all the correct answers until you’re back on track.
The system where correct answers are revealed after five correct guesses is genius. It discourages brute forcing, while maintaining a short feedback loop so the player knows they’re making progress. I wish more games continued on this idea.
Only thing I don’t like about it is that I can only play it for the first time once. It has almost no replay value.
The type is dynamic. It can be whatever you wish.
For me it’s the opposite. No money no deal.
I agree, and I count that as “key information that’s difficult to understand from the code”.
IMO, comments should be used to provide value to the code. If they’re used too much, then readers of the code will more likely stop reading them altogether. They already got what they need from the code itself and the comments usually don’t add much value.
If they’re sparse, then that’s a good indication they’re important and shouldn’t be missed.
I think comments are good as a last resort when it’s difficult to communicate the intention of the code with other means.
If I find code that’s hard to understand, I’ll first try to find better variable or function names. Often this is enough.
If it’s still too difficult to understand, I try to restructure the code to better communicate the flow of the code.
If that doesn’t help (or is too difficult), then I might add a comment explaining key information that’s difficult to understand from the code.
The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.
In your example, the declaration of ArrayList look like:
public class ArrayList extends AbstractList implements List {
}
The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.
Compare it with my solution:
public class ArrayList implements List {
private AbstractList = new AbstractList();
}
Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.
If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.
I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.
Ask Bjarne to add interfaces enough many times until he gives in.
On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.
In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.
I’m not sure why you would use abstract classes without data. Just use interfaces.
So things like abstract classes are mostly absent from my codebase.
I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.
If there’s a number that’s the most oddball in the multiplication table, it’s 7.
It’s a prime number that doesn’t share any common divisors with 10, and isn’t adjacent to a divisor of 10 either.
2 and 5 are common divisors of 10, so they’re piece of cake.
3 is so small and close to 2, so it’s not too difficult to get.
9 is one off from 10, so it has a very predictable pattern.
4, 6 and 8 are even numbers, so they share common divisors with 10.