Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://kokkos.github.io/kokkos-core-wiki/ProgrammingGuide/Compatibility.html below:

12. Backwards & Future Compatibility

Toggle table of contents sidebar

For a sufficiently clever user, effectively any change we make to Kokkos will be a breaking change. The intent of this document is to make it clear about what does and does not constitute supported use of Kokkos, as well as how Kokkos moves forward.

There is a tension between the freedom to make improvements and backward compatibility. We are presenting a set of rules that allows the Kokkos Team to make improvements going forward while maintaining a high level of backward compatibility (which avoids frustration and pain on the part of users). While we do not deliberately set out to break users, we’d like to minimize accidental breakage while still allowing the Kokkos Team a good path forward.

Unless we document otherwise, please:

• Avoid adding into namespace Kokkos

• Avoid adding/removing/modifying macros starting with KOKKOS_

• Avoid creating/removing/modifying files whose names start with Kokkos_

This minimizes the chances that either Kokkos or user code is inadvertently broken by future changes.

We reserve for the private use of the Kokkos Team:

• Any nested namespace Impl inside namespace Kokkos (Kokkos::Impl, Kokkos::Experimental::Impl)

• Any macro starting with KOKKOS_IMPL_

These things contain the implementation details of Kokkos. They are subject to change without notice, either in name or in behavior, even in minor point releases. They should never be referred to directly in user code.

The public supported interface for Kokkos is:

• The top-level namespace Kokkos

• Macros starting with KOKKOS_ (excluding those starting with KOKKOS_IMPL_)

While the implementation details may change, the Kokkos Team puts its best effort into limiting changes to either having no functional behavioral differences (apart from bug fixes) or if they must, are changed with compile-time (preferred) or run-time warning and a suitable deprecation period (if possible).

The experimentally support interface for Kokkos is in

• namespace Kokkos::Experimental

This namespace houses experimental features that are not yet ready for prime time. The feature may be incomplete, and the interface may change between releases. The intent is to eventually move them into the top level namespace Kokkos (with a suitable deprecation period where they are both in namespace Kokkos and namespace Kokkos::Experimental). If you need the functionality (e.g., a new backend), you may use it knowing that you may have to change your code for newer minor releases of Kokkos (and eventually will have to change your code when it moves to the top-level Kokkos namespace).

User defined macros can be particularly problematic, as they change what is lexically seen by the compiler and do not obey the language scoping rules. They could interfere with variable names, functions, etc., including private ones used in Kokkos and other libraries.

In order to minimize the risk of collisions, user defined macros should be prefaced with MYPROJECT_ (or a similar way to disambiguate them) and be in all caps (this informs code readers that macros don’t obey the usual syntactic and semantic rules of C++).

It is the intent of the Kokkos team for minimal C++ support to be one revision behind the latest published C++ standard (they are published every three years starting with C++11). These releases are generally considered major. This drives increasing the minimal supported compiler versions, as well as allowing the Kokkos Team to take advantage of new library and language features, as well removing workarounds for older compiler bugs and limitations. Kokkos may also optionally support later versions of the C++ standard, giving users features should they be compiling in those modes.

It is expected that Kokkos users recompile their code against new releases or builds of Kokkos. There are no ABI (Application Binary Interface) guarantees at this level.

An exception to this are Kokkos Tools, where much care is taken to ensure that already compiled older versions of tools work with newer versions of Kokkos.

Occasionally the Kokkos Team needs to remove things for overall improvements to the Kokkos code base. When doing so, the Kokkos Team puts in a best effort with deprecation warnings as well as a migratory, evolutionary path (ideally both the deprecated version and the new version co-exist for a suitable period of time) for moving to the improved interface and functionality.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4