Replies: 5 comments 13 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.
-
|
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.
-
|
not a bad solution but there is yet a better one, since the namespaces complain in C++20 what you want is to start with the previous.. but to detach the errors all together define them in seperate translation units (files) namely you want to include raylib in it's own header and only call that from a cpp that includes another with windows. This sufficiently decouples most of the calls that cause the errors in the first place. |
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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