The Omni library can be compiled for many platforms including many Unix and Linux derivations and the Windows and Apple
lines of OS. Omni makes use of many OS specific API as well as standards conforming API's (like those in the C++ standard
library or in the POSIX.1c specification).
Omni on Windows makes use of the WinAPI. For Unix and Linux variants, most API's used are POSIX.1c compliant and some are OS specific. For Apple platforms the POSIX.1c specification is used, as well as Unix specific API's and depending on the library function, Apple specific C/C++ library functions will be used. For more information on which API's are called throughout the library, visit the API's page.
Part of the goal of the Omni library is to not have to guess what the function or class will do on different systems (i.e. we want to ensure predictable and deterministic behaviour regardless of platform). As the library has morphed into what it is today, there have been caveats and impasses down the road of cross platform compatibility. These issues affect certain design decisions and Omni must make use of certain system level capabilities depending on what is being used or called to ensure proper determinism. For instance, the omni::mutex makes use of of the
The current version has been tested and works with the following platforms:
Please be aware if you are compiling for Windows in MinGW/MSYS or Cygwin your code will be treated and compiled as a
top
Platform Testing
To test a specific platform, a unit test was written utilizing the Omni library and it passed if 3 conditions were met:
Non-portable code does not necessarily mean that it will not work on your platform, it merely means that the output cannot be determined to be the same across all platforms tested.
top
Embedded support
For Microsoft this is the WindowsCE and Windows Embedded line of OS, for Linux this includes any embedded Linux/Unix derivation.
Embedded support cannot be guaranteed as not all system libraries are available among the many embedded environments. However that does not preclude one from using Omni in an embedded environment. For a Microsoft build, the basic WinAPI set need be available and a POSIX compliant environment for a Linux/Unix based build. If your environment does not support exception handling (some Android platforms for example), you can specify the OMNI_NO_THROW preprocessor flag.
For other preprocessor flags that might be useful for your platform (embedded or not), visit the options page.
For system API calls that might affect your decision for using Omni in an embedded environment, see the API's page.
Please note that the Omni library is an object oriented library; one of its priorities is to ensure as small a footprint as feasible. That being said the Omni library can still be heavy in certain classes simply due to object composition and inheritance. To this affect, there is the OMNI_LITE preprocessor define (among others) that can help slim down the library considerably, albeit at the cost of reduced functionality in certain areas. Depending on your needs, reduced functionality may not actually inhibit your ability to take full advantage of the Omni library; visiting the specific help page from the classes portal will give more information and other considerations to be taken.
top
Future support
When Omni was started, the C++11 standard had not be fully defined. The omni::smart_ptr is similar in function to the C++11
The additional C++ specifications (14/17/20+) further extend/amend the C++11 standard, as such Omni aims to be a statically fluid library by allowing users to take advantage of the new C++ features if their compilers support it via compile time flags. We chose to have a user specifically enable C++XX future support because the needs of everyone are different, and sometimes upgrade your compiler/library is not an answer; we want Omni to work for the developer, not the developer to work for Omni.
It should be noted that only the functionality of the additional specifications that make sense to use in the library will be added via the compile times flags; like template extensions for certain portions of the code to make it easier to utilize by the user. We will not add C++XX functionality to any internal code unless it can add a sufficient performance improvement; for example, while adding lambda's might make some portions of the internal function code easier to read, it does not improve the performance of said code.
For specifics on the classes and examples on how to utilize the library, you can check out the individual class sections as well as the examples section.
If you have questions, comments or concerns about the library or would like a further breakdown of a specific aspect please feel free to contact the Omni Q&A email
top
Omni on Windows makes use of the WinAPI. For Unix and Linux variants, most API's used are POSIX.1c compliant and some are OS specific. For Apple platforms the POSIX.1c specification is used, as well as Unix specific API's and depending on the library function, Apple specific C/C++ library functions will be used. For more information on which API's are called throughout the library, visit the API's page.
Part of the goal of the Omni library is to not have to guess what the function or class will do on different systems (i.e. we want to ensure predictable and deterministic behaviour regardless of platform). As the library has morphed into what it is today, there have been caveats and impasses down the road of cross platform compatibility. These issues affect certain design decisions and Omni must make use of certain system level capabilities depending on what is being used or called to ensure proper determinism. For instance, the omni::mutex makes use of of the
CRITICAL_SECTION type on Windows and the pthread_mutex_t type on other platforms.
The mutex object (specifically the CRITICAL_SECTION) on a Windows platform is a recursive
lock by design whereas the POSIX code for the mutex object has to explicitly define if the mutex is to be recursive, that is,
code on POSIX systems will call pthread_mutex_create passing a pthread_mutexattr_t type with the
PTHREAD_MUTEX_RECURSIVE defined so the underlying system mutex will be a recursive mutex. There are even certain
portions of code that have to be explicitly enabled (via compile time flags) due to their non-portable nature;
omni::system::path() is an example of non-portable code.
Any source specific items worth bringing to attention (the omni::mutex, for instance) will be documented
and explained in the corresponding help and source documentation.The current version has been tested and works with the following platforms:
- Windows (Windows 2000 and above)
- Apple OS X (kernel 10.4 and up)
- Sun Solaris (10+)
- Linux kernels 2.4 and above and Unix/BSD kernel bases:
Ubuntu 10.04, Fedora core 17, RHEL/CentOS 6.3, Linux Mint 13, openSUSE 12.3, Slackware 14, Debian 6.0.7, NetBSD 5.1.2, FreeBSD 9.1, OpenBSD 5.1, PC-BSD 10, RoboLinux, QNX 6.4.0, TurboLinux, ArchLinux, CoreOS, Gentoo, PCLinuxOS, PuppyLinux, Mageia, Manjaro, ElementaryOS, Zorin
Please be aware if you are compiling for Windows in MinGW/MSYS or Cygwin your code will be treated and compiled as a
POSIX
platform and not as a Windows platform. It should be noted that the Windows pthread libraries are wrappers
for the appropriate WinAPI calls and certain code will output as if it were compiled for a Windows platform.top
Platform Testing
To test a specific platform, a unit test was written utilizing the Omni library and it passed if 3 conditions were met:
- The unit test compiled successfully with the Omni source and needed libraries (
-pthreador-rtfor instance). - The functionality of the unit test succeeds; the outcome of the test was as expected and without error.
- The functionality of the unit test did not change the expected results on the platform being tested.
Non-portable code does not necessarily mean that it will not work on your platform, it merely means that the output cannot be determined to be the same across all platforms tested.
top
Embedded support
For Microsoft this is the WindowsCE and Windows Embedded line of OS, for Linux this includes any embedded Linux/Unix derivation.
Embedded support cannot be guaranteed as not all system libraries are available among the many embedded environments. However that does not preclude one from using Omni in an embedded environment. For a Microsoft build, the basic WinAPI set need be available and a POSIX compliant environment for a Linux/Unix based build. If your environment does not support exception handling (some Android platforms for example), you can specify the OMNI_NO_THROW preprocessor flag.
For other preprocessor flags that might be useful for your platform (embedded or not), visit the options page.
For system API calls that might affect your decision for using Omni in an embedded environment, see the API's page.
Please note that the Omni library is an object oriented library; one of its priorities is to ensure as small a footprint as feasible. That being said the Omni library can still be heavy in certain classes simply due to object composition and inheritance. To this affect, there is the OMNI_LITE preprocessor define (among others) that can help slim down the library considerably, albeit at the cost of reduced functionality in certain areas. Depending on your needs, reduced functionality may not actually inhibit your ability to take full advantage of the Omni library; visiting the specific help page from the classes portal will give more information and other considerations to be taken.
top
Future support
When Omni was started, the C++11 standard had not be fully defined. The omni::smart_ptr is similar in function to the C++11
std::unique_ptr and the omni::sync::thread object
could also make use of the std::thread, but because not all compilers and platforms support the new
extensions, Omni can be compiled with C++11 support by specifying the
OMNI_ENABLE_CXX preprocessor flag.
This flag enables certain language extensions to be used in the Omni library instead of system specific API calls
as well it changes certain portions of code to handle the new extensions (like the `= delete` function modifier).The additional C++ specifications (14/17/20+) further extend/amend the C++11 standard, as such Omni aims to be a statically fluid library by allowing users to take advantage of the new C++ features if their compilers support it via compile time flags. We chose to have a user specifically enable C++XX future support because the needs of everyone are different, and sometimes upgrade your compiler/library is not an answer; we want Omni to work for the developer, not the developer to work for Omni.
It should be noted that only the functionality of the additional specifications that make sense to use in the library will be added via the compile times flags; like template extensions for certain portions of the code to make it easier to utilize by the user. We will not add C++XX functionality to any internal code unless it can add a sufficient performance improvement; for example, while adding lambda's might make some portions of the internal function code easier to read, it does not improve the performance of said code.
For specifics on the classes and examples on how to utilize the library, you can check out the individual class sections as well as the examples section.
If you have questions, comments or concerns about the library or would like a further breakdown of a specific aspect please feel free to contact the Omni Q&A email
top