Replies: 5 comments 12 replies
-
|
fctr recommended the following... #define WIN32_LEAN_AND_MEAN
#if defined(_WIN32)
#define WIN32
#endif
#if defined(_WIN64)
#define WIN64
#define _AMD64_
#undef _X86_
#else
#undef _AMD64_
#define _X86_
#endif
#include <minwindef.h>
#include <stdio.h>
#include <stdlib.h>And change int main()to int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, char* pCmdLine, int nCmdShow) |
Beta Was this translation helpful? Give feedback.
-
|
This only works in some cases though. I don't know what cases that would be though. |
Beta Was this translation helpful? Give feedback.
-
|
Availleight had a C++ solution... namespace raylib{ #include "raylib.h" }And then use... raylib::BeginDrawing();
raylib::ClearBackground(raylib::Color{255,255,255,255});
raylib::EndDrawing(); |
Beta Was this translation helpful? Give feedback.
-
|
@orcmid The use of a prefix and the use of a namespace serve a similar purpose. Also, winapi is an api designed 38 years ago and is used by every single application with windows support. Raylib on the other hand is not a system api and was designed 10 years ago and has far less of a user base. To point the finger at winapi for naming conflicts seems a little odd. Although I would agree that winapi should've probably used a prefix, that doesn't justify the lack of prefix for Raylib. Not that I want to continue this argument considering Raysan seems set in his design choice. I just wanted to comment on the idea that it's somehow winapi's fault or responsibility. |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible to prefix the structs and functions beforehand? #define Rectangle winapiIsSoOldAndGrossSoMangleIt_Rectangle
#include "windows.h"
#undef RectangleI have no insight into this though, as I don't use Windows 🤷 ... Optimally though, it would likely be best to use portable libraries. |
Beta Was this translation helpful? Give feedback.
-
I will look into this later, thanks. |
Beta Was this translation helpful? Give feedback.
-
This actually fixes those naming conflicts (assuming the function isn't being used). thank you so much! Edit: sorry for the typos. |
Beta Was this translation helpful? Give feedback.
-
|
This can help for for some of the problems faced, but not all of them. And it doesn't help if you actually need to call one of the conflicting functions. I know from some of my experiments with:
test.cpp:2:16: error: stray ‘#’ in program
2 | namespace rl { #include "raylib.h" }
| ^
test.cpp:2:17: error: ‘include’ does not name a type
2 | namespace rl { #include "raylib.h" }
| ^~~~~~~Lets fix that, and try again: #include <windows.h>
namespace rl {
#include "raylib.h"
}
int main(void)
{
rl::InitWindow(0, 0, 0);
}so far so good... this compiles #include <windows.h>
namespace rl {
#include "raylib.h"
}
int main(void)
{
rl::InitWindow(0,0,nullptr);
CloseWindow(0);
}Results in linker errors: It can help in some circumstances - but not all. The primary problem this solves is "I like to prefix library functions". Which is fine, if that's a style goal you have. |
Beta Was this translation helpful? Give feedback.
-
So, 38 years ago would be in the Win16 days of 1986 and in a form unrecognizable now. Did you miss the part where raylib is a descendant of the Borland Graphical Interface available for MS-DOS (and under the covers in Turbo Pascal) before Windows was established to any degree. I do not suggest that Microsoft should change anything or should have done so. They have legacy just as raylib does (on a much smaller scale). |
Beta Was this translation helpful? Give feedback.
-
|
They keep around legacy that even breaks perfectly normal uses, not just raylib. I'd respect this if were solving a real legacy need, but visual studio today doesn't support any 16 bit system. Why does this need to exist? A lot of the decisions they make are bizarre and somewhat baseless. You don't need to defend a megacorp worth trillions, it's fine to admit the technical decisions they make are sometimes poor. I suggest we get to practical discussions of workarounds, which is what this thread is for. |
Beta Was this translation helpful? Give feedback.
-
|
If you only have limited surface of the windows API that you want to call, it is very feasible to just expose what you need manually. (extern "C") __declspec(dllimport) int MessageBoxA(void* hWND, const char* lpText, const char* lpCaption, unsigned int uType);The hardest part is peeling away the ugly macros and typedefs from the declarations, which can be tough, sometimes. This will also greatly improve compile times, a lone windows.h takes about ~0.9s to compile on my system with WIN32_LEAN_AND_MEAN, without it, it's even worse (~1.6s). Yes, precompiled headers help, but they add more build complexity. https://nullprogram.com/blog/2023/05/31/ |
Beta Was this translation helpful? Give feedback.
-
The "company bad open source project good" argument is silly. |
Beta Was this translation helpful? Give feedback.
-
|
It is only a problem if you're using winapi, so I'm fine blaming winapi 😉 |
Beta Was this translation helpful? Give feedback.
-
That's not true, check rcore_desktop_rgfw.c. It's a problem on every API. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, libX11 has a Font struct that conflicts with raylib's, that's the #2 source of conflicts. It's still not as bad as just dumping every single possible OS functionality you may or may not want in a single enormous header, but it could be better. Even then you can still encounter some strange ones - I saw someone who created a global variable "select" that caused glfw to crash when trying to make that syscall later. |
Beta Was this translation helpful? Give feedback.
-
Winapi's
windows.hcan have name conflicts with raylib.h . This is a space to talk about workarounds for it. While you are still able to compile raylib on windows, some people still want to use the winapi directly. This is a discussion space to discuss workarounds.Name Conflicts
References
Beta Was this translation helpful? Give feedback.
All reactions