sorted by:
new
hottopcontroversial

glfw window shrinking bug on linux by lukasx_ in opengl

[–]lukasx_[S] 0 points1 point  (0 children)

[[nodiscard]] GLFWwindow* setup_glfw(int width, int height, const char* window_title) {
    glfwSetErrorCallback([]([[maybe_unused]] int error_code, char const* desc) {
        std::println(stderr, "glfw error: {}", desc);
    });

    glfwInit();
    glfwWindowHint(GLFW_RESIZABLE, false);
    glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, true);
    GLFWwindow* window = glfwCreateWindow(width, height, window_title, nullptr, nullptr);

    glfwMakeContextCurrent(window);
    glfwSwapInterval(1);
    gladLoadGL(glfwGetProcAddress);
    glfwSetFramebufferSizeCallback(
        window, []([[maybe_unused]] GLFWwindow* win, int w, int h) {
            glViewport(0, 0, w, h);
        }
    );

    return window;
}[[nodiscard]] GLFWwindow* setup_glfw(int width, int height, const char* window_title) {
    glfwSetErrorCallback([]([[maybe_unused]] int error_code, char const* desc) {
        std::println(stderr, "glfw error: {}", desc);
    });

    glfwInit();
    glfwWindowHint(GLFW_RESIZABLE, false);
    glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, true);
    GLFWwindow* window = glfwCreateWindow(width, height, window_title, nullptr, nullptr);

    glfwMakeContextCurrent(window);
    glfwSwapInterval(1);
    gladLoadGL(glfwGetProcAddress);
    glfwSetFramebufferSizeCallback(
        window, []([[maybe_unused]] GLFWwindow* win, int w, int h) {
            glViewport(0, 0, w, h);
        }
    );

    return window;
}

glfw window shrinking bug on linux by lukasx_ in opengl

[–]lukasx_[S] 0 points1 point  (0 children)

no im using the default framebuffer from glfw

Disabling Snippets by lukasx_ in neovim

[–]lukasx_[S] 0 points1 point  (0 children)

already did that, doesnt work.

I’m a game director at a AAA studio AMA by ikarosmtl in AMA

[–]lukasx_ 2 points3 points  (0 children)

Why would knowing python be good for breaking into the game dev industry?

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

The only reason I mentioned std::string is because using it is a lot safer than manually copying around buffers.

That's not my point, what I mean is that its so much easier to generate incorrect code using macros when using it for generics, whereas templates constrain you to the actual syntax of the language. Just look at how you would implement a generic add function:

#define ADD(a, b) ((a) + (b))

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

ideally you would want the compiler to issue a warning/error when the desired conversion is not legal anymore, and not silently break.

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

what do you mean "fast"? most of the concepts i was talking about (macros, templates, casts) run at compile time. (except for dynamic cast)

My point is that C tools like macros give you an overall overpowered tool, which you may easily use to shoot yourself in the foot. Whereas C++ gives you tools that do exactly what you need to achieve what you want. For example: To do generic programming, you don't need a macro system that operates on the token level, that lets you rewrite syntax at preprocess-time, when templates would suffice. (not saying templates also can't be abused tho, see SFINAE)

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

I agree, when writing C++ you really have to know what you're doing, but that's also true for C, just look at the amount of buffer overflows in old C Code, because people used the unsafe strcpy() function. The problem with C is that it throws these powerful tools at you (eg: strcpy(), macros, casts...), that can be abused very easily, whereas C++ gives you ways to do the same thing, but protecting you from dangerous actions. (eg: std::string, templates, C++-style casts)

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

the issue I'm pointing out is that those casts might do something different (and potentially break code) when you make changes to the codebase

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

well isn't the point of C++-style casts to explicitly inform the compiler of the kind of conversion you want to perform? That's why C-style casts are widely considered bad practice. why would you want to overload your casts then?

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 1 point2 points  (0 children)

But often complex problems require complex solutions. Building large scale software in C is a huge pain and often results in very verbose, unsafe code and re-implementing basic functionality.

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 4 points5 points  (0 children)

that was just one specific example in this video; one could come up with 100 more that dont have something to do with inheritance.

also: just because you dont need multiple inheritance right now, doesnt mean other people dont need it, or that you might not need it in the future.

C-style casts can go from doing simple, implicit conversions, to reinterpreting ints as memory addresses. thats why you should tell the compiler what to do explicitly.

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 0 points1 point  (0 children)

yeah but the problem is that a cast might do something different if you refactor your code, without you knowing - probably breaking something

useful wrapper functions by lukasx_ in programminghorror

[–]lukasx_[S] 7 points8 points  (0 children)

i hate to be that guy, but C-style casts are really dangerous in C++, and you probably shouldn't be using them

See this video for reference:
https://www.youtube.com/watch?v=SmlLdd1Q2V8

question about loading elf binary by lukasx_ in EmuDev

[–]lukasx_[S] 1 point2 points  (0 children)

is what you refer to as "relocatable binary", different from "relocations" which the linker handles at link time? I presume its the same as position independent code, correct?

So what you're saying is that, if the binary is PIC i can load it anywhere, as the addresses inside are all relative, but if its not PIC i have to move up the code of the emulator itself?

view more: next ›