1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2<html><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 3<title>Limitations - Boost.Outcome documentation</title> 4<link rel="stylesheet" href="../../css/boost.css" type="text/css"> 5<meta name="generator" content="Hugo 0.52 with Boostdoc theme"> 6<meta name="viewport" content="width=device-width,initial-scale=1.0"/> 7 8<link rel="icon" href="../../images/favicon.ico" type="image/ico"/> 9<body><div class="spirit-nav"> 10<a accesskey="p" href="../../experimental/c-api.html"><img src="../../images/prev.png" alt="Prev"></a> 11 <a accesskey="u" href="../../experimental/c-api.html"><img src="../../images/up.png" alt="Up"></a> 12 <a accesskey="h" href="../../index.html"><img src="../../images/home.png" alt="Home"></a><a accesskey="n" href="../../experimental/c-api/example.html"><img src="../../images/next.png" alt="Next"></a></div><div id="content"> 13 <div class="titlepage"><div><div><h1 style="clear: both">Limitations</h1></div></div></div> 14 <p>C++ has excellent two-way compatibility with the C ABI, but there are some 15limitations you must observe to write C++ code which C code can call without 16marshalling at the ABI boundary:</p> 17 18<ol> 19<li><p>A C++ function may not throw exceptions if it is safe to call from C, and 20so should always be marked <code>noexcept</code>.</p></li> 21 22<li><p>A C++ function should be annotated with <code>extern "C"</code> to prevent its symbol 23being mangled, and thus give it the C rather than C++ ABI.</p></li> 24 25<li><p>You cannot use overloading in your <code>extern "C"</code> functions.</p></li> 26 27<li><p>You may only use types in your C++ function declaration for which these traits are both true:</p> 28 29<ul> 30<li><a href="http://en.cppreference.com/w/cpp/types/is_standard_layout"><code>std::is_standard_layout_v<T></code></a></li> 31<li><a href="http://en.cppreference.com/w/cpp/types/is_trivially_copyable"><code>std::is_trivially_copyable_v<T></code></a></li> 32</ul> 33 34<p>(Note that <code>std::is_trivially_copyable_v<T></code> requires trivial destruction, 35but NOT trivial construction. This means that C++ can do non-trivial construction 36of otherwise trivial types)</p></li> 37</ol> 38 39<hr /> 40 41<p>The above is what the standard officially requires for <em>well defined</em> C and C++ interop. 42However, all of the three major compilers MSVC, GCC and clang are considerably more relaxed. 43In those three major compilers, “almost-standard-layout” C++ types work fine in C.</p> 44 45<p>“Almost-standard-layout” C++ types have these requirements:</p> 46 47<ol> 48<li>No virtual functions or virtual base classes i.e. 49<a href="http://en.cppreference.com/w/cpp/types/is_polymorphic"><code>std::is_polymorphic_v<T></code></a> 50must be false. This is because the vptrs offset the proper front of the data layout 51in an unknowable way to C.</li> 52<li>Non-static data members of reference type appear to C as pointers. You 53must never supply from C to C++ a non-null pointer which is seen as a reference in C++.</li> 54<li>C++ inheritance is seen in C data layout as if the most derived class has nested 55variables of the inherited types at the top, in order of inheritance.</li> 56<li>Types with non-trivial destructors work fine so long as at least move construction 57and assignment is the same as 58copying bits like <code>memcpy()</code>. You just need to make sure instances of the type return 59to C++, and don’t get orphaned in C. This was referred to in previous pages in this 60section as “move relocating” types.</li> 61</ol> 62 63<p>Experimental Outcome’s support for being used from C does not meet the current strict 64requirements, and thus relies on the (very common) implementation defined behaviour just 65described (it is hoped that future C++ standards can relax the requirements to those 66just described).</p> 67 68<p>Specifically, proposed <code>status_code</code> is an almost-standard-layout type, 69and thus while it can’t be returned from <code>extern "C"</code> functions as the compiler 70will complain, it is perfectly safe to return from C++ functions to C code on the 71three major compilers, as it is an “almost-standard-layout” C++ type if <code>T</code> is 72an “almost-standard-layout” C++ type.</p> 73 74 75 </div><p><small>Last revised: February 05, 2019 at 17:14:18 UTC</small></p> 76<hr> 77<div class="spirit-nav"> 78<a accesskey="p" href="../../experimental/c-api.html"><img src="../../images/prev.png" alt="Prev"></a> 79 <a accesskey="u" href="../../experimental/c-api.html"><img src="../../images/up.png" alt="Up"></a> 80 <a accesskey="h" href="../../index.html"><img src="../../images/home.png" alt="Home"></a><a accesskey="n" href="../../experimental/c-api/example.html"><img src="../../images/next.png" alt="Next"></a></div></body> 81</html> 82
