u/HappyFruitTree

Not everything needs to be standardized. You standardize what you can agree on. If you cannot agree on something then you don't standardize it.

Yes, PHP is totally fine.

Don’t forget to rely on the other modules when needed for audio, fonts and image handling.

The core SDL library used to only support BMP images so almost all projects used SDL_image, but now SDL3 has built-in support for PNG and JPEG so the projects that need to use SDL_image are probably fewer now.

SDL_mixer and SDL_ttf are still very useful.

This will actually do what you want, i.e. compare each array element and not just the address of the array.

An ==operator that is const is generated by default because the code doesn't declare one.

Is it? If that's the case, why doesn't comparing two Mat3 objects work when the inline definition of the == operator is removed?

Real solution is however as you've already done, to make that a friend function with two parameters.

Why friend?

Member functions that are defined inside the class definition are implicitly inline.

I feel there is some relevant information missing here because the code you have shown shouldn't give that error.

Unrelated: sizeof(Cells) gives you the size of the array in bytes which is not what you want. Try std::size instead.

You are not wrong. There are reasons for it. As for what those reasons are is a different matter.

No, because I usually can't. I keep reminding me I shouldn't eat out though, because I can't trust how they make the food or what they put inside it and other reasons, but I keep "forgetting".

Pasta (because it doesn't smell much).

Accidentally? Flies and other bugs. Grains of sand. Nails and hair.

Har inte hört det uttrycket. Minor är det enda jag tänker på när jag hör det ordet. Men du har naturligtvis rätt.

I don't understand the question.

Contributing to open-source projects is often mentioned as a good way to learn, and it probably is if you manage to do it, but it's hard to just jump into a random unfamiliar project and start "contributing", especially as a beginner.

I think it's more common that people contribute to projects that they use or care strongly about (or are being paid to work on). Writing code is not the only way to contribute. Reporting bugs and taking part in the discussions can also be helpful and could be a way to familiarize yourself with the project before starting to contribute code.

If you find a bug you can try to fix it yourself and supply the bug fix at the same time that you make the bug report. That way you can work on the fix at your own pace and don't need to worry that someone will fix it for you. Just make sure that you use the latest version so that you're not wasting time fixing a bug that has already been fixed (you would probably still learn from it so it wouldn't be a total waste). For larger changes you probably want to communicate first to avoid wasting yours and others' time.

Many projects have written information about how to contribute and what kind of contributions they want. Some projects are more beginner-friendly while others have restrictions on who can contribute. Some personal open-source projects that are made by a single person might not be willing to accept any code contributions at all. Some might be abandoned and need to be forked to move the development forward. It's always up to the project owners to decide what contributions to accept. Don't let a few bad experiences discourage you, instead try to learn from them.

Regardless, as a beginner it's probably a good idea to also work on your own small projects to make sure that you get the amount of practice that you need. It's hard to get it all from open-source contribution.

Does "std colony" sound less scary?

(That's the name that was first proposed)

It uses a "skipfield" instead.

The problem is that people don't do enough "slit" before "släng".

Constant evaluation can also happen when initializing static variables and local const integer variables (if constant evaluation fails it falls back to normal "runtime" evaluation). https://godbolt.org/z/qE8PEq18r

This is roughly what I recommend:

Pass by value if the type is small and cheap to copy. You usually use this for built-in types like int and double.

Pass by const reference if the object cannot be copied or is expensive to copy. You typically use this for class types.

Pass by non-const reference if the function should be able to modify the object.

Use a pointer instead of a reference if the object is optional. Then the caller can pass a null pointer if she doesn't want to pass an object. Don't forget to check for null inside the function.

When constexpr functions were introduced in C++11 there were many more limitations. There could basically just be a single return statement, no variables, no loops, no if statements...

I do agree with the concerns of the guy that you linked to. People need to know that the constexpr is intentional if they should be able to rely on it.

Yes, vec in main is not declared constexpr so it will basically just compile and optimize it the same way as a normal function.

You can, you just won't be able to call it from constexpr contexts (at compile time).

The following compiles and runs just fine (since C++20).

#include <vector>
#include <iostream>

constexpr std::vector<int> f() {
    std::vector<int> vec = {1, 2, 3};
    return vec;
}

int main() {
    std::vector<int> vec = f();
    for (int n : vec) {
        std::cout << n << "\n";
    }
}

https://godbolt.org/z/WzfxYnefG

You only have these guarantees for the set of argument values that you actually call the function with from constexpr contexts.

int bar(int x) {
    return x;
}

constexpr int foo(int x) {
    if (x > 0)
        return bar(x); 
    return 0;
}

int x = foo(5); // OK
constexpr int y = foo(0); // OK
constexpr int z = foo(5); // Error

Then why add it?

My main concern is that it can be confusing for the programmer (code is not only written for compilers). If I see a function marked constexpr I normally assume that it can result in a constant expression for at least some arguments.

That constexpr functions had to be able to produce a constant expression for at least one set of argument values was actually a requirement before C++23 (no diagnostic required).

Even on functions that can not be executed in constexpr contexts?

int bar(int x);

constexpr int foo(int x)
{
    return bar(x);
}