FPL - a single header file platform abstraction library

I skimmed your code and there are two (maybe three) things that stuck out to me.

#define FPL_NULL 0

This is not how you should be defining NULL. Either use (void*)0 or nullptr if C++11 is available.

#if !FPL_ENABLE_C_RUNTIME_LIBRARY
void __stdcall WinMainCRTStartup() {
    int result = wWinMain(GetModuleHandleW(0), 0, 0, 0);
    ExitProcess(result);
}
#endif // !FPL_ENABLE_C_RUNTIME_LIBRARY

I read your comment further up the file about how you hate the CRT, but this is clearly taking it too far. I'll quote a section of ExitProcess()'s documentation:

Quote

Calling ExitProcess in a DLL can lead to unexpected application or system errors. Be sure to call ExitProcess from a DLL only if you know which applications or system components will load the DLL and that it is safe to call ExitProcess in this context.

And that's pretty much the point at which I stopped reading your code. Parts of it looked good, other parts looked really, really bad. A more important question to me is: Who needs this? Why does this exist? All of this stuff is already available in other libraries or game frameworks.

As a side note, why are people writing more and more of these "header only" libraries? The preprocessor seems like a flimsy way to configure how your code should compile. A more solid solution is to use a proper build system.

51 minutes ago, TheComet said:

I skimmed your code and there are two (maybe three) things that stuck out to me.

#define FPL_NULL 0

This is not how you should be defining NULL. Either use (void*)0 or nullptr if C++11 is available.

#if !FPL_ENABLE_C_RUNTIME_LIBRARY
void __stdcall WinMainCRTStartup() {
    int result = wWinMain(GetModuleHandleW(0), 0, 0, 0);
    ExitProcess(result);
}
#endif // !FPL_ENABLE_C_RUNTIME_LIBRARY

I read your comment further up the file about how you hate the CRT, but this is clearly taking it too far. I'll quote a section of ExitProcess()'s documentation:

And that's pretty much the point at which I stopped reading your code. Parts of it looked good, other parts looked really, really bad. A more important question to me is: Who needs this? Why does this exist? All of this stuff is already available in other libraries or game frameworks.

As a side note, why are people writing more and more of these "header only" libraries? The preprocessor seems like a flimsy way to configure how your code should compile. A more solid solution is to use a proper build system.

I tried FPL_NULL (void *)0 - but i had trouble with it, so i simply set it to zero. But yes i agree, using nullptr on C++/11 would be better, but how do i detect if C++/11 is available - through preprocessor directives? Btw. FPL_NULL is internal only, so its not meant to be used outside.

That entire no CRT thing - i am not sure about this. Its a experiment to see if it works, because some people dont want to include even the C-Runtime Library at all. Also regards DLL´s and ExitProcess and need to think it more, as a matter of fact i havent created a library project yet - but this will come soon. When i see that no-CRT is support is too complicated, i will drop it. Right know i dont see any benefit disabling CRT, except for smalling out the executable size.

Why header library only? Because its simple and works all the time. No linking madness, no dll´s needed - besides from the standard system operating stuff which is included anyway.

Regards build-systems: I dont like build-systems at all, all i ever used was just awful: Slow, hard to configure, not working -> On any programming language the same bad experience.

But what i will do for sure, is making several simple build scripts (Batch, Shell) which just builds the samples in the simplest possible way for a set of compilers/platforms.

52 minutes ago, Finalspace said:

C++/11 would be better, but how do i detect if C++/11 is available - through preprocessor directives?

You have it in your own code:

	#ifdef __cplusplus
	

Quote

That entire no CRT thing - i am not sure about this. Its a experiment to see if it works, because some people dont want to include even the C-Runtime Library at all.

I do not know a person or a product that does not link with CRT. Starting form small games, 3D DCCs, even some "serious software" uses it.

Quote

Why header library only? Because its simple and works all the time. No linking madness, no dll´s needed - besides from the standard system operating stuff which is included anyway.

A header and a *.cpp is equally simple to me.

#define fpl_globalvar static
#define fpl_inline inline
#define fpl_internal static
#if FPL_API_AS_PRIVATE
#    define fpl_api static
#else
#    define fpl_api extern

This is unnecessary code to me, it doesn't tell much to the reader and these have no functional benefit, actually it is wrong:
if I "fpl_globalvar int x;" in a *.cpp this will actually make the variable "private" to that *.cpp, making it inaccessible to other files.

40 minutes ago, ongamex92 said:

I do not know a person or a product that does not link with CRT. Starting form small games, 3D DCCs, even some "serious software" uses it.

A header and a *.cpp is equally simple to me.

#define fpl_globalvar static
#define fpl_inline inline
#define fpl_internal static
#if FPL_API_AS_PRIVATE
#    define fpl_api static
#else
#    define fpl_api extern

This is unnecessary code to me, it doesn't tell much to the reader and these have no functional benefit, actually it is wrong:
if I "fpl_globalvar int x;" in a *.cpp this will actually make the variable "private" to that *.cpp, making it inaccessible to other files.

Insomniac Games and EA for example do not use the C standard library, they even dont use the STL.

Also there are others people in the industry who do not use the C standard library as well.

For myself, i dont care but its great when you have the option to not need to ship the C Runtime with your game (VC++ redist for example).

Static has more than one meaning, private scope for this file only, local persisting state, global variable, class field in c++, etc. Even though it just mean: Private in this file only. Techniqually there are no differences between all of them, but this way you see right away which scope its meant to be in.

Right, there are no difference between header and source files. C++ has no definition of a file, you just have translation units which gets compiled to object files - thats it. I dont want to force users to have a separate translation unit, just for the library - if they want, they can have one but its not required.

1 hour ago, Finalspace said:

how do i detect if C++/11 is available - through preprocessor directives?

https://stackoverflow.com/a/29407260/4383258

#if defined(__cplusplus) && __cplusplus >= 201103L
#define FPL_NULL nullptr
#endif

1 minute ago, TheComet said:

https://stackoverflow.com/a/29407260/4383258

#if defined(__cplusplus) && __cplusplus >= 201103L
#define FPL_NULL nullptr
#endif

Thanks, i already did that. Will commit that later

- I added C++/11 nullptr support and renamed FPL_NULL to FPL_NULLPTR. Fallback is (void *)0

It seems that this library is mostly useless for most people here, but for me its very useful and educational.

A change of mind:

i will drop C support and change it to a more C++ ish api, but it will not be full blown object oriented. Also C runtime support will be dropped as well.

I will definitely have a look at it but as most other people might, I have those platform specific stuff already build into my game engine from the beginning. Platform detection for PC and propably Console, Threads, Locking, Atomics, Extensions (via LoadLibrary and similar) and even a Window class as same as some graphics API dependent startup code

New version:

- Dropped C support

- Dropped No-C-Runtime support

- Removed all FPL prefixes from functions and types

- Moved to a more c++ ish api (Namespaces, const reference, enum class, constexpr, nullptr)

- Nested namespaces to categorize certain things (window, memory, strings, atomics, threading, etc.)

You need a reference doc

If you add something like this https://github.com/ferreiradaselva/cgdfw/blob/master/REFERENCE.md it will make things much easier.

On 6.10.2017 at 9:04 PM, ferreiradaselva said:

You need a reference doc

If you add something like this https://github.com/ferreiradaselva/cgdfw/blob/master/REFERENCE.md it will make things much easier.

Thanks i will do that - good idea!

Is there a way to export all my api structs and functions into that automatically?

Never mind, i will write a command line tool which does that.

Update:

• Added XInput Support through event structures
• Changed a lot of pointer arguments to reference or const reference

Monster Update:

• Added memory::CopyMemory
• Added fpl::GetLastError and fpl::GetLastErrorCount for proper error handling
• Added files::CreateBinaryFile and files::OpenBinaryFile for wide file paths
• Added basic support for creating a modern opengl rendering context, see VideoCompabilityProfile in VideoSettings
• Added support for enabling opengl vsync through WGL
• Returns char * for all paths:: get like functions
• Returns char/wchar_t * for all strings:: functions
• Fixed files::CreateBinaryFile was never able to overwrite the file.
• Fixed #include was in some namespaces defined
• Fixed files::ClearMemory was wrong
• Replaced all const constants with constexpr
• Removed template code / Replaced it with macros
  

Update:

• All types/structs/fields/functions documented
• [Win32] Fixed legacy opengl (GL_INVALID_OPERATION)
• [Win32] Support for WGL opengl profile selection

Todo:

• Create full reference.md documentation / upload doxygen documentation.
• Win32 audio output + api
• Win32 threading + api
• Win32 clipboard get/set

Update:

• Renamed: All memory/library/threading functions
• Renamed: CopyFile/DeleteFile renamed (Stupid win32!)
• Renamed: All internal opengl defines renamed, so that it wont conflict with other libraries
• Fixed: [Win32] strings::All Wide conversions was not working properly
• Removed: [Win32] All undefs removed
• Changed: [Win32/OpenGL] Check for already included gl.h
• Added: Basic threading creation and handling

Todo:

• Create full reference.md documentation / upload doxygen documentation.
• Win32 audio output + api
• Win32 mutex / condition + api
• Win32 clipboard get/set
• Linux platform support

Update v0.4.0 alpha:

• Changed: All FPL_ENABLE_ defines are internal now, the caller must use FPL_NO_ or FPL_YES_ respectivily.
• Changed: AtomicCompareExchange is now AtomicCompareAndExchange
• Changed: InitFlags::VideoOpenGL is now InitFlags::Video
• Added: Software rendering support
• Added: VideoDriverType enumeration for selecting the active video driver
• Added: video::GetVideoBackBuffer with [Win32] implementation
• Added: video::ResizeVideoBackBuffer with [Win32] implementation
• Added: FPL_PETABYTES macro
• Added: FPL_EXABYTES macro
• Added: FPL_ZETTABYTES macro
• Added: FPL_YOTTABYTES macro
• Added: FPL_MIN macro
• Added: FPL_MAX macro
• Added: MutexCreate with [Win32] implementation
• Added: MutexDestroy with [Win32] implementation
• Added: MutexLock with [Win32] implementation
• Added: MutexUnlock with [Win32] implementation
• Added: SignalCreate with [Win32] implementation
• Added: SignalDestroy with [Win32] implementation
• Added: SignalWait with [Win32] implementation
• Added: SignalWakeUp with [Win32] implementation
• Added: GetClipboardAnsiText with [Win32] implementation
• Added: GetClipboardWideText with [Win32] implementation
• Added: SetClipboardText with [Win32] implementation for ansi and wide strings
• Added [MSVC]: AtomicExchangeS32 (Signed integer)
• Added [MSVC]: AtomicExchangeS64 (Signed integer)
• Added [MSVC]: AtomicAddS32 (Signed integer)
• Added [MSVC]: AtomicAddS64 (Signed integer)
• Added [MSVC]: AtomicCompareExchangeS32 (Signed integer)
• Added [MSVC]: AtomicCompareExchangeS64 (Signed integer)
• Fixed [MSVC]: AtomicExchangeU32 was not using unsigned intrinsic
• Fixed [MSVC]: AtomicExchangeU64 was not using unsigned intrinsic
• Fixed [MSVC]: AtomicAddU32 was not using unsigned intrinsic
• Fixed [MSVC]: AtomicAddU64 was not using unsigned intrinsic
• Fixed [MSVC]: AtomicCompareExchangeU32 was not using unsigned intrinsic
• Fixed [MSVC]: AtomicCompareExchangeU64 was not using unsigned intrinsic
• Implemented [Win32]: GetProcessorCoreCount
• Implemented [Win32]: Main thread infos
• Performance [Win32]: GetProcessorName (3 loop iterations at max)

State:

Its almost feature complete for Win32, only audio output is missing.

Next i will clean up all the ifdef madness to get a more clean code structure - so i have a single ifdef block for each platform/backend. Also i am thinking about removing the sub namespaces, just because its so much useless typing for no reason.