Home Explore Help
Register Sign In
devn00b
/
EQ2EMu
9
3
Fork 0
Files Issues 59 Pull Requests 0 Wiki
Tree: ff02b05cfd
Branches Tags
EQ2EMu
/
EQ2
/
source
/
depends
/
boost_1_72_0
/
libs
/
outcome
/
doc
/
html
/
experimental
/
advantages.html

advantages.html 4.1 KB
History Raw

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566 
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    2. 

  2. <html><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    3. 

  3. <title>The main advantages - Boost.Outcome documentation</title>
    4. 

  4. <link rel="stylesheet" href="../css/boost.css" type="text/css">
    5. 

  5. <meta name="generator" content="Hugo 0.52 with Boostdoc theme">
    6. 

  6. <meta name="viewport" content="width=device-width,initial-scale=1.0"/>
    7. 

  7. 

  8. <link rel="icon" href="../images/favicon.ico" type="image/ico"/>
    9. 

  9. <body><div class="spirit-nav">
    10. 

  10. <a accesskey="p" href="../experimental.html"><img src="../images/prev.png" alt="Prev"></a>
    11. 

  11.     <a accesskey="u" href="../experimental.html"><img src="../images/up.png" alt="Up"></a>
    12. 

  12.     <a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="../experimental/map.html"><img src="../images/next.png" alt="Next"></a></div><div id="content">
    13. 

  13.   <div class="titlepage"><div><div><h1 style="clear: both">The main advantages</h1></div></div></div>
    14. 

  14.   <p>The main advantages of choosing <code>&lt;boost/outcome/experimental&gt;</code> over default Outcome:</p>
    15. 

  15. 

  16. <ol>
    17. 

  17. <li><p>Codegen is tighter and less verbose<sup class="footnote-ref" id="fnref:1"><a href="#fn:1">1</a></sup>, sometimes remarkably so.</p></li>
    18. 

  18. 

  19. <li><p>Build time impact is markedly lower, barely above the inclusion of naked
    20. 

  20. <code>&lt;basic_result.hpp&gt;</code>, as the STL allocator machinery and <code>std::string</code> et al
    21. 

  21. is not dragged into inclusion by including <code>&lt;system_error&gt;</code>. Note that
    22. 

  22. <code>&lt;boost/outcome/experimental/status_outcome.hpp&gt;</code> bring in <code>&lt;exception&gt;</code>,
    23. 

  23. however <code>&lt;boost/outcome/experimental/status_result.hpp&gt;</code> brings in no extra system
    24. 

  24. headers.</p></li>
    25. 

  25. 

  26. <li><p>More discipline is imposed on your use of Outcome, leading to
    27. 

  27. less ambiguous code which is easier to optimise by the compiler,
    28. 

  28. lower cost to maintain, and lower cognitive load to audit code based on
    29. 

  29. experimental Outcome for correctness.</p></li>
    30. 

  30. 

  31. <li><p>Code written to <code>&lt;boost/outcome/experimental&gt;</code> can be fairly easily dual
    32. 

  32. targeted, with just a few switching type aliases, to default Outcome.
    33. 

  33. This author has several Outcome-based libraries with identical source code which
    34. 

  34. can target either configuration of Outcome. The experimental Outcome
    35. 

  35. build regularly beats the default Outcome build in benchmarks by 2-3%,
    36. 

  36. and the dual target source code, being written to tighter discipline,
    37. 

  37. is faster and more deterministic in the default target than it was before
    38. 

  38. the (non-trivial) port to <code>&lt;boost/outcome/experimental&gt;</code>.</p></li>
    39. 

  39. </ol>
    40. 

  40. 

  41. <p>If you are building a codebase on top of Outcome expecting long term
    42. 

  42. maintenance, the author&rsquo;s personal recommendation is that you design, write, test and
    43. 

  43. optimise it for <code>&lt;boost/outcome/experimental&gt;</code>. What you ship to your customers
    44. 

  44. ought to be targeted at default Outcome however, so employ type aliases and
    45. 

  45. macros as appropriate to switch the build configuration for production releases.
    46. 

  46. This is what the Outcome author does himself, to date with great success,
    47. 

  47. despite the fundamental architectural differences between <code>&lt;system_error&gt;</code>
    48. 

  48. and proposed <code>&lt;system_error2&gt;</code>.</p>
    49. 

  49. <div class="footnotes">
    50. 

  50. 

  51. <hr />
    52. 

  52. 

  53. <ol>
    54. 

  54. <li id="fn:1">Boost.System&rsquo;s <code>error_code</code> has incorporated some of the design improvements of experimental <code>status_code</code>, and produces codegen somewhere in between experimental <code>status_code</code> and <code>std::error_code</code>.
    55. 

  55.  <a class="footnote-return" href="#fnref:1"><sup>[return]</sup></a></li>
    56. 

  56. </ol>
    57. 

  57. </div>
    58. 

  58. 

  59. 

  60.         </div><p><small>Last revised: February 05, 2019 at 21:41:47 UTC</small></p>
    61. 

  61. <hr>
    62. 

  62. <div class="spirit-nav">
    63. 

  63. <a accesskey="p" href="../experimental.html"><img src="../images/prev.png" alt="Prev"></a>
    64. 

  64.     <a accesskey="u" href="../experimental.html"><img src="../images/up.png" alt="Up"></a>
    65. 

  65.     <a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="../experimental/map.html"><img src="../images/next.png" alt="Next"></a></div></body>
    66. 

  66. </html>
    67.