<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>P1040R6: std::embed</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) and (display:contents) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge {
		/* Magic to create good table positioning:
		   "content column" is 50ems wide at max; less on smaller screens.
		   Extra space (after ToC + content) is empty on the right.

		   1. When table < content column, centers table in column.
		   2. When content < table < available, left-aligns.
		   3. When table > available, fills available + scroll bar.
		*/ 
		display: grid;
		grid-template-columns: minmax(0, 50em);
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
<style type="text/css">
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }

    del { background: #fcc; color: #000; text-decoration: line-through; }
    ins { background: #cfc; color: #000; }
    blockquote .highlight:not(.idl) { background: initial; margin: initial; padding: 0.5em }
    blockquote ul { background: inherit; }
    blockquote code.highlight:not(.idl) { padding: initial; }
    blockquote c-[a] { color: inherit; } /* Keyword.Declaration */
    blockquote c-[b] { color: inherit; } /* Keyword.Type */
    blockquote c-[c] { color: inherit; } /* Comment */
    blockquote c-[d] { color: inherit; } /* Comment.Multiline */
    blockquote c-[e] { color: inherit; } /* Name.Attribute */
    blockquote c-[f] { color: inherit; } /* Name.Tag */
    blockquote c-[g] { color: inherit; } /* Name.Variable */
    blockquote c-[k] { color: inherit; } /* Keyword */
    blockquote c-[l] { color: inherit; } /* Literal */
    blockquote c-[m] { color: inherit; } /* Literal.Number */
    blockquote c-[n] { color: inherit; } /* Name */
    blockquote c-[o] { color: inherit; } /* Operator */
    blockquote c-[p] { color: inherit; } /* Punctuation */
    blockquote c-[s] { color: inherit; } /* Literal.String */
    blockquote c-[t] { color: inherit; } /* Literal.String.Single */
    blockquote c-[u] { color: inherit; } /* Literal.String.Double */
    blockquote c-[cp] { color: inherit; } /* Comment.Preproc */
    blockquote c-[c1] { color: inherit; } /* Comment.Single */
    blockquote c-[cs] { color: inherit; } /* Comment.Special */
    blockquote c-[kc] { color: inherit; } /* Keyword.Constant */
    blockquote c-[kn] { color: inherit; } /* Keyword.Namespace */
    blockquote c-[kp] { color: inherit; } /* Keyword.Pseudo */
    blockquote c-[kr] { color: inherit; } /* Keyword.Reserved */
    blockquote c-[ld] { color: inherit; } /* Literal.Date */
    blockquote c-[nc] { color: inherit; } /* Name.Class */
    blockquote c-[no] { color: inherit; } /* Name.Constant */
    blockquote c-[nd] { color: inherit; } /* Name.Decorator */
    blockquote c-[ni] { color: inherit; } /* Name.Entity */
    blockquote c-[ne] { color: inherit; } /* Name.Exception */
    blockquote c-[nf] { color: inherit; } /* Name.Function */
    blockquote c-[nl] { color: inherit; } /* Name.Label */
    blockquote c-[nn] { color: inherit; } /* Name.Namespace */
    blockquote c-[py] { color: inherit; } /* Name.Property */
    blockquote c-[ow] { color: inherit; } /* Operator.Word */
    blockquote c-[mb] { color: inherit; } /* Literal.Number.Bin */
    blockquote c-[mf] { color: inherit; } /* Literal.Number.Float */
    blockquote c-[mh] { color: inherit; } /* Literal.Number.Hex */
    blockquote c-[mi] { color: inherit; } /* Literal.Number.Integer */
    blockquote c-[mo] { color: inherit; } /* Literal.Number.Oct */
    blockquote c-[sb] { color: inherit; } /* Literal.String.Backtick */
    blockquote c-[sc] { color: inherit; } /* Literal.String.Char */
    blockquote c-[sd] { color: inherit; } /* Literal.String.Doc */
    blockquote c-[se] { color: inherit; } /* Literal.String.Escape */
    blockquote c-[sh] { color: inherit; } /* Literal.String.Heredoc */
    blockquote c-[si] { color: inherit; } /* Literal.String.Interpol */
    blockquote c-[sx] { color: inherit; } /* Literal.String.Other */
    blockquote c-[sr] { color: inherit; } /* Literal.String.Regex */
    blockquote c-[ss] { color: inherit; } /* Literal.String.Symbol */
    blockquote c-[vc] { color: inherit; } /* Name.Variable.Class */
    blockquote c-[vg] { color: inherit; } /* Name.Variable.Global */
    blockquote c-[vi] { color: inherit; } /* Name.Variable.Instance */
    blockquote c-[il] { color: inherit; } /* Literal.Number.Integer.Long */
  </style>
  <meta content="Bikeshed version ae6def1cbca03b321b2ad730ac2f51eeba21ed81" name="generator">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="0dbd64902bbf5ac82b934da28560aca08091e42f" name="document-revision">
<style>
pre {
  margin-top: 0px;
  margin-bottom: 0px;
}
.ins, ins, ins *, span.ins, span.ins * {
  background-color: rgb(200, 250, 200);
  color: rgb(0, 136, 0);
  text-decoration: underline;
}
.del, del, del *, span.del, span.del * {
  background-color: rgb(250, 200, 200);
  color: rgb(255, 0, 0);
  text-decoration: line-through;
  text-decoration-color: rgb(255, 0, 0);
}
math, span.math {
  font-family: serif;
  font-style: italic;
}
ul {
  list-style-type: "— ";
}
blockquote {
  counter-reset: paragraph;
}
div.numbered, div.newnumbered {
  margin-left: 2em;
  margin-top: 1em;
  margin-bottom: 1em;
}
div.numbered:before, div.newnumbered:before {
  position: absolute;
  margin-left: -2em;
  display-style: block;
}
div.numbered:before {
  content: counter(paragraph);
  counter-increment: paragraph;
}
div.newnumbered:before {
  content: "�";
}
div.numbered ul, div.newnumbered ul {
  counter-reset: list_item;
}
div.numbered li, div.newnumbered li {
  margin-left: 3em;
}
div.numbered li:before, div.newnumbered li:before {
  position: absolute;
  margin-left: -4.8em;
  display-style: block;
}
div.numbered li:before {
  content: "(" counter(paragraph) "." counter(list_item) ")";
  counter-increment: list_item;
}
div.newnumbered li:before {
  content: "(�." counter(list_item) ")";
  counter-increment: list_item;
}
</style>
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P1040R6<br>std::embed</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2020-02-17">2020-02-17</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>Author:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:phdofthehouse@gmail.com">JeanHeyd Meneide</a>
     <dt>Audience:
     <dd>EWG, SG7
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Latest:
     <dd><a href="https://thephd.github.io/vendor/future_cxx/papers/d1040.html">https://thephd.github.io/vendor/future_cxx/papers/d1040.html</a>
     <dt>Implementation:
     <dd><a href="https://github.com/ThePhD/embed">https://github.com/ThePhD/embed</a>
     <dt>Reply To:
     <dd><a href="phdofthehouse@gmail.com">JeanHeyd Meneide</a>, <a href="https://twitter.com/thephantomderp">@thephantomderp</a>
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>A proposal for a function that allows pulling resources at compile-time into a program.</p>
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li>
     <a href="#changelog"><span class="secno">1</span> <span class="content">Revision History</span></a>
     <ol class="toc">
      <li><a href="#changelog-r6"><span class="secno">1.1</span> <span class="content">Revision 6 - March 2nd, 2020</span></a>
      <li><a href="#changelog-r5"><span class="secno">1.2</span> <span class="content">Revision 5 - January 13th, 2020</span></a>
      <li><a href="#changelog-r4"><span class="secno">1.3</span> <span class="content">Revision 4 - November 26th, 2018</span></a>
      <li><a href="#changelog-r3"><span class="secno">1.4</span> <span class="content">Revision 3 - November 26th, 2018</span></a>
      <li><a href="#changelog-r2"><span class="secno">1.5</span> <span class="content">Revision 2 - October 10th, 2018</span></a>
      <li><a href="#changelog-r1"><span class="secno">1.6</span> <span class="content">Revision 1 - June 10th, 2018</span></a>
      <li><a href="#changelog-r0"><span class="secno">1.7</span> <span class="content">Revision 0 - May 11th, 2018</span></a>
     </ol>
    <li><a href="#polls"><span class="secno">2</span> <span class="content">Relevant Polls</span></a>
    <li><a href="#motivation"><span class="secno">3</span> <span class="content">Motivation</span></a>
    <li><a href="#scope"><span class="secno">4</span> <span class="content">Scope and Impact</span></a>
    <li>
     <a href="#design"><span class="secno">5</span> <span class="content">Design Decisions</span></a>
     <ol class="toc">
      <li>
       <a href="#design-practice"><span class="secno">5.1</span> <span class="content">Implementation Experience &amp; Current Practice</span></a>
       <ol class="toc">
        <li><a href="#design-practice-speed"><span class="secno">5.1.1</span> <span class="content">Speed Results</span></a>
        <li><a href="#design-practice-memory"><span class="secno">5.1.2</span> <span class="content">Memory Size Results</span></a>
        <li><a href="#design-practice-analysis"><span class="secno">5.1.3</span> <span class="content">Results Analysis</span></a>
        <li><a href="#design-practice-manual"><span class="secno">5.1.4</span> <span class="content">Manual Work</span></a>
        <li><a href="#design-practice-tools"><span class="secno">5.1.5</span> <span class="content">Processing Tools</span></a>
        <li><a href="#design-practice-vendor"><span class="secno">5.1.6</span> <span class="content"><code class="highlight"><c- n>ld</c-></code>, resource files, and other vendor-specific link-time tools</span></a>
        <li><a href="#design.practice.incbin"><span class="secno">5.1.7</span> <span class="content">The <code class="highlight"><c- n>incbin</c-></code> tool</span></a>
       </ol>
      <li>
       <a href="#design-prior"><span class="secno">5.2</span> <span class="content">Prior Art</span></a>
       <ol class="toc">
        <li><a href="#design-prior-literal"><span class="secno">5.2.1</span> <span class="content">Literal-Based, constexpr</span></a>
        <li><a href="#design-prior-null"><span class="secno">5.2.2</span> <span class="content">Literal-Based, Null Terminated (?)</span></a>
        <li><a href="#design-prior-encoding"><span class="secno">5.2.3</span> <span class="content">Encoding</span></a>
       </ol>
      <li>
       <a href="#design-goals"><span class="secno">5.3</span> <span class="content">Design Goals</span></a>
       <ol class="toc">
        <li><a href="#design-goals-impldefn"><span class="secno">5.3.1</span> <span class="content">Implementation Defined</span></a>
        <li><a href="#design-goals-binary"><span class="secno">5.3.2</span> <span class="content">Binary Only</span></a>
        <li><a href="#design-goals-constexpr"><span class="secno">5.3.3</span> <span class="content">Constexpr Compatibility</span></a>
        <li><a href="#design-goals-dependencies"><span class="secno">5.3.4</span> <span class="content">Dependency-Scanning Friendly with <code class="highlight"><c- cp>#depend</c-></code></span></a>
        <li><a href="#design-goals-modules"><span class="secno">5.3.5</span> <span class="content">Modules</span></a>
        <li><a href="#design-goals-templated"><span class="secno">5.3.6</span> <span class="content">Statically Polymorphic</span></a>
        <li><a href="#design-goals-limit"><span class="secno">5.3.7</span> <span class="content">Optional Limit</span></a>
        <li><a href="#design-goals-utf8"><span class="secno">5.3.8</span> <span class="content">UTF-8 Only</span></a>
       </ol>
     </ol>
    <li>
     <a href="#previous"><span class="secno">6</span> <span class="content">Previous Implementations</span></a>
     <ol class="toc">
      <li><a href="#previous-#depend"><span class="secno">6.1</span> <span class="content"><code class="highlight"><c- cp>#depend</c-></code> Soft Warnings, Hard Errors?</span></a>
      <li><a href="#previous-virtual"><span class="secno">6.2</span> <span class="content">String Table / Virtual File System</span></a>
     </ol>
    <li>
     <a href="#wording"><span class="secno">7</span> <span class="content">Changes to the Standard</span></a>
     <ol class="toc">
      <li><a href="#wording-intent"><span class="secno">7.1</span> <span class="content">Intent</span></a>
      <li><a href="#wording-feature"><span class="secno">7.2</span> <span class="content">Proposed Feature Test Macro</span></a>
      <li><a href="#wording-proposed"><span class="secno">7.3</span> <span class="content">Proposed Wording</span></a>
     </ol>
    <li>
     <a href="#appendix"><span class="secno">8</span> <span class="content">Appendix</span></a>
     <ol class="toc">
      <li>
       <a href="#appendix-Alternative"><span class="secno">8.1</span> <span class="content">Alternative</span></a>
       <ol class="toc">
        <li><a href="#appendix-tools"><span class="secno">8.1.1</span> <span class="content">Pre-Processing Tools Alternative</span></a>
        <li><a href="#appendix-mongo"><span class="secno">8.1.2</span> <span class="content"><code class="highlight"><c- n>python</c-></code> Alternative</span></a>
        <li><a href="#appendix-ld"><span class="secno">8.1.3</span> <span class="content"><code class="highlight"><c- n>ld</c-></code> Alternative</span></a>
       </ol>
     </ol>
    <li><a href="#acknowledgements"><span class="secno">9</span> <span class="content">Acknowledgements</span></a>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="changelog"><span class="secno">1. </span><span class="content">Revision History</span><a class="self-link" href="#changelog"></a></h2>
   <h3 class="heading settled" data-level="1.1" id="changelog-r6"><span class="secno">1.1. </span><span class="content">Revision 6 - March 2nd, 2020</span><a class="self-link" href="#changelog-r6"></a></h3>
   <ul>
    <li data-md>
     <p>Add new section <a href="#polls">§ 2 Relevant Polls</a>.</p>
    <li data-md>
     <p>Add new section <a href="#design-goals-dependencies">§ 5.3.4 Dependency-Scanning Friendly with #depend</a>.</p>
    <li data-md>
     <p>Add new section <a href="#design-goals-modules">§ 5.3.5 Modules</a>.</p>
    <li data-md>
     <p>Improve section <a href="#design-goals-templated">§ 5.3.6 Statically Polymorphic</a>.</p>
    <li data-md>
     <p>Add new section <a href="#design-goals-limit">§ 5.3.7 Optional Limit</a>.</p>
    <li data-md>
     <p>Add new section <a href="#design-goals-utf8">§ 5.3.8 UTF-8 Only</a>.</p>
    <li data-md>
     <p>Add new section <a href="#previous">§ 6 Previous Implementations</a>.</p>
    <li data-md>
     <p>Improve wording and add static version (thanks, @lichray).</p>
   </ul>
   <h3 class="heading settled" data-level="1.2" id="changelog-r5"><span class="secno">1.2. </span><span class="content">Revision 5 - January 13th, 2020</span><a class="self-link" href="#changelog-r5"></a></h3>
   <ul>
    <li data-md>
     <p>Split <code class="highlight"><c- cp>#embed</c-></code> into a new paper.</p>
    <li data-md>
     <p>Add memory and time benchmarks from various implementation strategies in the <a href="#design-practice">new Current Practice section</a>.</p>
    <li data-md>
     <p>Address concerns for a generic API and similar in the <a href="#design-practice-analysis">new Results Analysis section</a>.</p>
    <li data-md>
     <p>Retarget to EWG and SG 7.</p>
   </ul>
   <h3 class="heading settled" data-level="1.3" id="changelog-r4"><span class="secno">1.3. </span><span class="content">Revision 4 - November 26th, 2018</span><a class="self-link" href="#changelog-r4"></a></h3>
   <ul>
    <li data-md>
     <p>Wording is now relative to <a data-link-type="biblio" href="#biblio-n4778">[n4778]</a>.</p>
    <li data-md>
     <p>Minor typo and tweak fixes.</p>
   </ul>
   <h3 class="heading settled" data-level="1.4" id="changelog-r3"><span class="secno">1.4. </span><span class="content">Revision 3 - November 26th, 2018</span><a class="self-link" href="#changelog-r3"></a></h3>
   <ul>
    <li data-md>
     <p>Change to using <code class="highlight"><c- n>consteval</c-></code>.</p>
    <li data-md>
     <p>Discuss potential issues with accessing resources after full semantic analysis is performed. Prepare to poll Evolution Working Group. Reference new paper, <a data-link-type="biblio" href="#biblio-p1130">[p1130]</a>, about resource management.</p>
   </ul>
   <h3 class="heading settled" data-level="1.5" id="changelog-r2"><span class="secno">1.5. </span><span class="content">Revision 2 - October 10th, 2018</span><a class="self-link" href="#changelog-r2"></a></h3>
   <ul>
    <li data-md>
     <p>Destroy <code class="highlight"><c- n>embed_options</c-></code> and <code class="highlight"><c- n>alignment</c-></code> options: if the function is materialized only at compile-time through <code class="highlight"><c- k>constexpr</c-></code> or the upcoming "immediate functions" (<code class="highlight"><c- k>constexpr</c-><c- o>!</c-></code>), there is no reason to make this part of the function. Instead, the user can choose their own alignment when they pin this down into a std::array or some form of C array / C++ storage.</p>
   </ul>
   <h3 class="heading settled" data-level="1.6" id="changelog-r1"><span class="secno">1.6. </span><span class="content">Revision 1 - June 10th, 2018</span><a class="self-link" href="#changelog-r1"></a></h3>
   <ul>
    <li data-md>
     <p>Create future directions section, follow up on Library Evolution Working Group comments.</p>
    <li data-md>
     <p>Change <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed_options</c-><c- o>::</c-><c- n>null_terminated</c-></code> to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed_options</c-><c- o>::</c-><c- n>null_terminate</c-></code>.</p>
    <li data-md>
     <p>Add more code demonstrating the old way and motivating examples.</p>
    <li data-md>
     <p>Incorporate LEWG feedback, particularly alignment requirements illuminated by Odin Holmes and Niall Douglass. Add a feature macro on top of having <code class="highlight"><c- n>__has_include</c-><c- p>(</c-> <c- o>&lt;</c-><c- n>embed</c-><c- o>></c-> <c- p>)</c-></code>.</p>
   </ul>
   <h3 class="heading settled" data-level="1.7" id="changelog-r0"><span class="secno">1.7. </span><span class="content">Revision 0 - May 11th, 2018</span><a class="self-link" href="#changelog-r0"></a></h3>
   <p>Initial release.</p>
   <h2 class="heading settled" data-level="2" id="polls"><span class="secno">2. </span><span class="content">Relevant Polls</span><a class="self-link" href="#polls"></a></h2>
   <p>The following polls are shaping the current design. Votes are in the form of SF (Strongly in Favor), F (in Favor), N (Neutral), A (Against), SA (Strongly Against).</p>
   <p><code class="highlight"><c- cp>#depend</c-></code> - We would like to have this feature in C++(Something) and spend time figuring out the details.</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>SF</c-> <c- n>F</c-> <c- n>N</c-> <c- n>A</c-> <c- n>SA</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- mi>14</c-> <c- mi>13</c-> <c- mi>2</c-> <c- mi>0</c-> <c- mi>0</c-></code></p>
    <li data-md>
     <p>Consensus: Do more work.</p>
   </ul>
   <p><code class="highlight"><c- cp>#depend &lt;foo/**></c-></code> - We want recursive globs (recursively searching through directories) for #depend.</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>SF</c-> <c- n>F</c-> <c- n>N</c-> <c- n>A</c-> <c- n>SA</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- mi>2</c-> <c- mi>3</c-> <c- mi>9</c-> <c- mi>12</c-> <c- mi>4</c-></code></p>
    <li data-md>
     <p>Consensus: Do not want.</p>
    <li data-md>
     <p>Vote Commentary:</p>
    <li data-md>
     <p>A: Complexity?</p>
    <li data-md>
     <p>SA: Windows is slow with recursive globs.</p>
   </ul>
   <p>It should be mandatory that EVERY file for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> is specified by a <code class="highlight"><c- cp>#depend</c-></code>.</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>SF</c-> <c- n>F</c-> <c- n>N</c-> <c- n>A</c-> <c- n>SA</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- mi>4</c-> <c- mi>12</c-> <c- mi>5</c-> <c- mi>6</c-> <c- mi>3</c-></code></p>
    <li data-md>
     <p>Consensus: Split, no consensus. Add why/why not.</p>
    <li data-md>
     <p>Vote Commentary:</p>
    <li data-md>
     <p>SF: This MUST exist. Both compiler and build system authors. (Implementers.)</p>
    <li data-md>
     <p>SA: Can make user experience sad face for common case. Build system should scream at you for making the mistake instead.</p>
   </ul>
   <p><code class="highlight"><c- cp>#depend</c-></code> should form a Virtual File System / String Table State that constrains the search and should be passed to std::embed.</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>SF</c-> <c- n>F</c-> <c- n>N</c-> <c- n>A</c-> <c- n>SA</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- mi>3</c-> <c- mi>11</c-> <c- mi>7</c-> <c- mi>2</c-> <c- mi>2</c-></code></p>
    <li data-md>
     <p>Consensus: Do it.</p>
    <li data-md>
     <p>Vote Commentary:</p>
    <li data-md>
     <p>SA: Hell to implement. (This was the author.)</p>
   </ul>
   <p>Make std::embed ill-formed inside of a module interface (with a plan to revisit later).</p>
   <ul>
    <li data-md>
     <p>SF  F  N  A SA</p>
    <li data-md>
     <p>4  2  7  1  1</p>
    <li data-md>
     <p>Consensus: Yes, but Meh.</p>
    <li data-md>
     <p>Vote Commentary:</p>
    <li data-md>
     <p>SA: Modules are important we should make sure it interacts well with modules (figure it out now).</p>
    <li data-md>
     <p>SF: How does this work with #depend ?</p>
    <li data-md>
     <p>SF: std::embed is basically a #include -- why would we want it in interface? Just focus on getting feature working and doing it well.</p>
    <li data-md>
     <p>A: Jumping the gun. Space needs more exploration.</p>
    <li data-md>
     <p>N: We are highly undecided - need to answer more questions (especially about Modules).</p>
   </ul>
   <h2 class="heading settled" data-level="3" id="motivation"><span class="secno">3. </span><span class="content">Motivation</span><a class="self-link" href="#motivation"></a></h2>
   <blockquote>
    <p>I’m very keen on std::embed. I’ve been hand-embedding data in executables for NEARLY FORTY YEARS now. — <cite>Guy "Hatcat" Davidson, June 15, 2018</cite></p>
   </blockquote>
   <table>
    <tbody>
     <tr>
      <th>Currently
      <th>With Proposal
     <tr>
      <td>
<pre class="highlight"><c- n>se</c-><c- o>-</c-><c- n>shell</c->@<c- n>virt</c-><c- o>-</c-><c- n>deb</c-><c- o>></c-> <c- n>python</c-> <c- n>strfy</c-><c- p>.</c-><c- n>py</c-> \
	<c- n>fxaa</c-><c- p>.</c-><c- n>spirv</c-> \
	<c- n>stringified_fxaa</c-><c- p>.</c-><c- n>spirv</c-><c- p>.</c-><c- n>h</c->
</pre>
<pre class="language-c++ highlight"><c- cp>#include</c-> &lt;span>

<c- n>constexpr</c-> <c- kr>inline</c-> 
<c- k>const</c-> <c- k>auto</c-><c- o>&amp;</c-> <c- n>fxaa_spirv_data</c-> <c- o>=</c->
<c- cp>#include</c-> "stringified_fxaa.spirv.h"
<c- p>;</c->

<c- c1>// prevent embedded nulls from</c->
<c- c1>// ruining everything with </c->
<c- c1>// char_traits&lt;char>::length</c->
<c- c1>// or strlen</c->
<c- n>template</c-> <c- o>&lt;</c-><c- kr>typename</c-> <c- n>T</c-><c- p>,</c-> <c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>N</c-><c- o>></c->
<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>size_t</c-> 
<c- n>string_array_size</c-><c- p>(</c-><c- k>const</c-> <c- n>T</c-> <c- p>(</c-><c- o>&amp;</c-><c- p>)[</c-><c- n>N</c-><c- p>])</c-> <c- p>{</c->
    <c- k>return</c-> <c- n>N</c-> <c- o>-</c-> <c- mi>1</c-><c- p>;</c->
<c- p>}</c->

<c- b>int</c-> <c- n>main</c-> <c- p>(</c-><c- b>int</c-> <c- b>char</c-><c- o>*</c-><c- p>[])</c-> <c- p>{</c->
	<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>std</c-><c- o>::</c-><c- n>byte</c-><c- o>></c-> 
	<c- n>fxaa_binary</c-><c- p>{</c-> 
		<c- n>fxaa_spirv_data</c-><c- p>,</c-> 
		<c- n>string_array_size</c-><c- p>(</c-><c- n>fxaa_spirv_data</c-><c- p>)</c->
	<c- p>};</c->

	<c- c1>// assert this is a SPIRV </c->
	<c- c1>// file, at compile-time	</c->
	<c- n>static_assert</c-><c- p>(</c-><c- n>fxaa_binary</c-><c- p>[</c-><c- mi>0</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x03</c-> 
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>1</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x02</c->
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>2</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x23</c-> 
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>3</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x07</c-><c- p>,</c-> 
		<c- s>"given wrong SPIRV data, "</c->
		<c- s>"check rebuild or check "</c->
		<c- s>"the binaries!"</c-><c- p>)</c->

	<c- k>auto</c-> <c- n>context</c-> <c- o>=</c-> <c- n>make_vulkan_context</c-><c- p>();</c->

	<c- c1>// data kept around and made</c->
	<c- c1>// available for binary</c->
	<c- c1>// to use at runtime</c->
	<c- k>auto</c-> <c- n>fxaa_shader</c-> <c- o>=</c-> <c- n>make_shader</c-><c- p>(</c-> 
		<c- n>context</c-><c- p>,</c-> <c- n>fxaa_binary</c-> <c- p>);</c->

	<c- k>for</c-> <c- p>(;;)</c-> <c- p>{</c->
		<c- c1>// ...</c->
		<c- c1>// and we’re off!</c->
		<c- c1>// ...</c->
	<c- p>}</c->

	<c- k>return</c-> <c- mi>0</c-><c- p>;</c->
<c- p>}</c->
</pre>
      <td>
        ‏‏<br> ‏‏<br> ‏‏<br> ‏‏<br> 
<pre class="language-c++ highlight"><c- cp>#include</c-> &lt;embed>
















<c- b>int</c-> <c- nf>main</c-> <c- p>(</c-><c- b>int</c-><c- p>,</c-> <c- b>char</c-><c- o>*</c-><c- p>[])</c-> <c- p>{</c->
	<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>std</c-><c- o>::</c-><c- n>byte</c-><c- o>></c-> 
	<c- n>fxaa_binary</c-> <c- o>=</c-> 
		<c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-> <c- s>"fxaa.spirv"</c-> <c- p>);</c->
	


	<c- c1>// assert this is a SPIRV </c->
	<c- c1>// file, at compile-time	</c->
	<c- n>static_assert</c-><c- p>(</c-><c- n>fxaa_binary</c-><c- p>[</c-><c- mi>0</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x03</c-> 
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>1</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x02</c->
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>2</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x23</c-> 
		<c- o>&amp;&amp;</c-> <c- n>fxaa_binary</c-><c- p>[</c-><c- mi>3</c-><c- p>]</c-> <c- o>==</c-> <c- mh>0x07</c-><c- p>,</c-> 
		<c- s>"given wrong SPIRV data, "</c->
		<c- s>"check rebuild or check "</c->
		<c- s>"the binaries!"</c-><c- p>)</c->

	<c- k>auto</c-> <c- n>context</c-> <c- o>=</c-> <c- n>make_vulkan_context</c-><c- p>();</c->

	<c- c1>// data kept around and made</c->
	<c- c1>// available for binary</c->
	<c- c1>// to use at runtime</c->
	<c- k>auto</c-> <c- n>fxaa_shader</c-> <c- o>=</c-> <c- n>make_shader</c-><c- p>(</c-> 
		<c- n>context</c-><c- p>,</c-> <c- n>fxaa_binary</c-> <c- p>);</c->

	<c- k>for</c-> <c- p>(;;)</c-> <c- p>{</c->
		<c- c1>// ...</c->
		<c- c1>// and we’re off!</c->
		<c- c1>// ...</c->
	<c- p>}</c->

	<c- k>return</c-> <c- mi>0</c-><c- p>;</c->
<c- p>}</c->
</pre>
     <tr>
      <td>
<pre class="highlight"><c- n>se</c-><c- o>-</c-><c- n>shell</c->@<c- n>virt</c-><c- o>-</c-><c- n>deb</c-><c- o>></c-> <c- n>python</c-> <c- n>gen_cxx_random_data</c-><c- p>.</c-><c- n>py</c-> \
	<c- o>-</c-><c- n>o</c-> <c- n>include</c-><c- o>/</c-><c- n>gen</c-><c- o>/</c-><c- n>random_data</c-><c- p>.</c-><c- n>h</c->
</pre>
<pre class="language-c++ highlight"> 
<c- cp>#include</c-> &lt;cstdint>
<c- cp>#include</c-> &lt;utility>


<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>val_64_const</c-> 
	<c- o>=</c-> <c- mh>0xcbf29ce484222325u</c-><c- p>;</c->
<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>prime_64_const</c-> 
	<c- o>=</c-> <c- mh>0x100000001b3u</c-><c- p>;</c->

<c- kr>inline</c-> <c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c->
<c- n>hash_64_fnv1a_const</c-><c- p>(</c-><c- k>const</c-> <c- b>char</c-><c- o>*</c-> <c- k>const</c-> <c- n>ptr</c-><c- p>,</c-> 
	<c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>ptr_size</c-><c- p>,</c-> 
	<c- k>const</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>value</c-> <c- o>=</c-> <c- n>val_64_const</c->
<c- p>)</c-> <c- n>noexcept</c-> <c- p>{</c->
	<c- k>return</c-> <c- p>(</c-><c- n>ptr_size</c-> <c- o>==</c-> <c- mi>1</c-><c- p>)</c-> 
	  <c- o>?</c-> <c- nl>value</c-> 
	  <c- p>:</c-> <c- n>hash_64_fnv1a_const</c-><c- p>(</c->
		<c- o>&amp;</c-><c- n>ptr</c-><c- p>[</c-><c- mi>1</c-><c- p>],</c->
		<c- n>ptr_size</c-> <c- o>-</c-> <c- mi>1</c-><c- p>,</c-> 
		<c- p>(</c-><c- n>value</c-> <c- o>^</c-> <c- n>static_cast</c-><c- o>&lt;</c-><c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-><c- o>></c-><c- p>(</c-><c- o>*</c-><c- n>ptr</c-><c- p>))</c-> 
		<c- o>*</c-> <c- n>prime_64_const</c->
		<c- p>);</c->
<c- p>}</c->

<c- cp>#include</c-> &lt;gen/random_data.h>

<c- b>int</c-> <c- n>main</c-> <c- p>()</c-> <c- p>{</c->


	<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>actual</c->
		<c- o>=</c-> <c- n>hash_64_fnv1a_const</c-><c- p>(</c-><c- o>&amp;</c-><c- n>random_data</c-><c- p>[</c-><c- mi>0</c-><c- p>],</c->
			<c- n>std</c-><c- o>::</c-><c- n>size</c-><c- p>(</c-><c- n>random_data</c-><c- p>));</c->

	<c- k>return</c-> <c- n>static_cast</c-><c- o>&lt;</c-><c- b>int</c-><c- o>></c-><c- p>(</c-><c- n>actual</c-><c- p>);</c->
<c- p>}</c->
</pre>
      <td>
<pre class="highlight"> 
 
</pre>
<pre class="language-c++ highlight"><c- cp>#include</c-> &lt;embed>
<c- cp>#include</c-> &lt;cstdint>



<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>val_64_const</c->
	<c- o>=</c-> <c- mh>0xcbf29ce484222325u</c-><c- p>;</c->
<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>prime_64_const</c->
	<c- o>=</c-> <c- mh>0x100000001b3u</c-><c- p>;</c->

<c- kr>inline</c-> <c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c->
<c- n>hash_64_fnv1a_const</c-><c- p>(</c-><c- k>const</c-> <c- b>char</c-><c- o>*</c-> <c- k>const</c-> <c- n>ptr</c-><c- p>,</c-> 
	<c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>ptr_size</c-><c- p>,</c-> 
	<c- k>const</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>value</c-> <c- o>=</c-> <c- n>val_64_const</c->
<c- p>)</c-> <c- n>noexcept</c-> <c- p>{</c->
	<c- k>return</c-> <c- p>(</c-><c- n>ptr_size</c-> <c- o>==</c-> <c- mi>1</c-><c- p>)</c-> 
	  <c- o>?</c-> <c- nl>value</c-> 
	  <c- p>:</c-> <c- n>hash_64_fnv1a_const</c-><c- p>(</c->
		<c- o>&amp;</c-><c- n>ptr</c-><c- p>[</c-><c- mi>1</c-><c- p>],</c->
		<c- n>ptr_size</c-> <c- o>-</c-> <c- mi>1</c-><c- p>,</c-> 
		<c- p>(</c-><c- n>value</c-> <c- o>^</c-> <c- n>static_cast</c-><c- o>&lt;</c-><c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-><c- o>></c-><c- p>(</c-><c- o>*</c-><c- n>ptr</c-><c- p>))</c-> 
		<c- o>*</c-> <c- n>prime_64_const</c->
		<c- p>);</c->
<c- p>}</c->




<c- b>int</c-> <c- n>main</c-> <c- p>()</c-> <c- p>{</c->
	<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- b>char</c-><c- o>></c-> <c- n>art_data</c-> 
		<c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"/dev/urandom"</c-><c- p>,</c-> <c- mi>32</c-><c- p>);</c->
	<c- n>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>uint64_t</c-> <c- n>actual</c-> 
		<c- o>=</c-> <c- n>hash_64_fnv1a_const</c-><c- p>(</c-><c- n>art_data</c-><c- p>.</c-><c- n>data</c-><c- p>(),</c-> 
			<c- n>art_data</c-><c- p>.</c-><c- n>size</c-><c- p>());</c->

	<c- k>return</c-> <c- n>static_cast</c-><c- o>&lt;</c-><c- b>int</c-><c- o>></c-><c- p>(</c-><c- n>actual</c-><c- p>);</c->
<c- p>}</c->
</pre>
       (<a href="https://godbolt.org/z/zqsvWD">Works here.</a>) 
   </table>
   <p>A very large amount of C and C++ programmer -- at some point -- attempts to <code class="highlight"><c- cp>#include</c-></code> large chunks of non-C++ data into their code. Of course, <code class="highlight"><c- cp>#include</c-></code> expects the format of the data to be source code, and thusly the program fails with spectacular lexer errors. Thusly, many different tools and practices were adapted to handle this, as far back as 1995 with the <code class="highlight"><c- n>xxd</c-></code> tool. Many industries need such functionality, including (but hardly limited to):</p>
   <ul>
    <li data-md>
     <p>Financial Development</p>
     <ul>
      <li data-md>
       <p>representing coefficients and numeric constants for performance-critical algorithms;</p>
     </ul>
    <li data-md>
     <p>Game Development</p>
     <ul>
      <li data-md>
       <p>assets that do not change at runtime, such as icons, fixed textures and other data;</p>
      <li data-md>
       <p>Shader and scripting code;</p>
     </ul>
    <li data-md>
     <p>Embedded Development</p>
     <ul>
      <li data-md>
       <p>storing large chunks of binary, such as firmware, in a well-compressed format;</p>
      <li data-md>
       <p>placing data in memory on chips and systems that do not have an operating system or file system;</p>
     </ul>
    <li data-md>
     <p>Application Development</p>
     <ul>
      <li data-md>
       <p>compressed binary blobs representing data</p>
      <li data-md>
       <p>non-C++ script code that is not changed at runtime;</p>
     </ul>
    <li data-md>
     <p>Server Development</p>
     <ul>
      <li data-md>
       <p>configuration parameters which are known at build-time and are baked in to set limits and give compile-time information to tweak performance under certain loads;</p>
      <li data-md>
       <p>SSL/TLS Certificates hard-coded into your executable (requiring a rebuild and potential authorization before deploying new certificates), and;</p>
     </ul>
    <li data-md>
     <p>Static Analyzers</p>
     <ul>
      <li data-md>
       <p>Static analyzers suffer -- much like their binary code generating friends -- from having to parse extremely large array literals;</p>
      <li data-md>
       <p>Reduces memory pressure and enables better information tracking and potential sanitization (file source is not lost in build system).</p>
     </ul>
   </ul>
   <p>In the pursuit of this goal, these tools have proven to have inadequacies and contribute poorly to the C++ development cycle as it continues to scale up for larger and better low-end devices and high-performance machines, bogging developers down with menial build tasks and trying to cover-up disappointing differences between platforms. It also absolutely destroys state-of-the-art compilers due to the extremely high memory overhead of producing an Abstract Syntax Tree for a braced initializer list of several tens of thousands of integral constants with numeric values at 255 or less.</p>
   <p>The request for some form of <code class="highlight"><c- cp>#include</c->_string</code> or similar dates back quite a long time, with one of the oldest stack overflow questions asked-and-answered about it dating back nearly 10 years. Predating even that is a plethora of mailing list posts and forum posts asking how to get script code and other things that are not likely to change into the binary.</p>
   <p>This paper proposes <code class="highlight"><c- o>&lt;</c-><c- n>embed</c-><c- o>></c-></code> to make this process much more efficient, portable, and streamlined.</p>
   <h2 class="heading settled" data-level="4" id="scope"><span class="secno">4. </span><span class="content">Scope and Impact</span><a class="self-link" href="#scope"></a></h2>
   <p><code class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c-> <c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>string_view</c-> <c- n>resource_identifier</c-> <c- p>)</c-></code> is an extension to the language proposed entirely as a library construct. The goal is to have it implemented with compiler intrinsics, builtins, or other suitable mechanisms. It does not affect the language. The proposed header to expose this functionality is <code class="highlight"><c- o>&lt;</c-><c- n>embed</c-><c- o>></c-></code>, making the feature entirely-opt-in by checking if either the proposed feature test macro or header exists.</p>
   <h2 class="heading settled" data-level="5" id="design"><span class="secno">5. </span><span class="content">Design Decisions</span><a class="self-link" href="#design"></a></h2>
   <p><code class="highlight"><c- o>&lt;</c-><c- n>embed</c-><c- o>></c-></code> avoids using the preprocessor or defining new string literal syntax like its predecessors, preferring the use of a free function in the <code class="highlight"><c- n>std</c-></code> namespace. This gives <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> a greater degree of power and advantage over <code class="highlight"><c- o>&lt;</c-><c- n>embed</c-><c- o>></c-></code>'s design is derived heavily from community feedback plus the rejection of the prior art up to this point, as well as the community needs demonstrated by existing practice and their pit falls.</p>
   <h3 class="heading settled" data-level="5.1" id="design-practice"><span class="secno">5.1. </span><span class="content">Implementation Experience &amp; Current Practice</span><a class="self-link" href="#design-practice"></a></h3>
   <p>Here, we examine current practice, their benefits, and their pitfalls. There are a few cross-platform (and not-so-cross-platform) paths for getting data into an executable. We also scrutinize the performance, with numbers for both <a href="https://github.com/ThePhD/embed#memory-size-results">memory overhead</a> and <a href="https://github.com/ThePhD/embed#speed-results">speed overhead</a> available at the repository that houses the <a href="https://github.com/ThePhD/embed">current implementation</a>. For ease of access, the numbers as of January 2020 with the latest versions of the indicated compilers and tools are replicated below.</p>
   <p>All three major implementations were explored, plus an early implementation of this functionality in GCC. A competing implementation in a separate C++-like meta language called <a href="https://www.circle-lang.org/">Circle</a> was also looked at by the behest of Study Group 7.</p>
   <h4 class="heading settled" data-level="5.1.1" id="design-practice-speed"><span class="secno">5.1.1. </span><span class="content">Speed Results</span><a class="self-link" href="#design-practice-speed"></a></h4>
   <p>Below are timing results for a file of random bytes using a specific strategy. The file is of the size specified at the top of the column. Files are kept the same between strategies and tests.</p>
   <ul>
    <li data-md>
     <p>Intel Core i7-6700HQ @ 2.60 GHz</p>
    <li data-md>
     <p>24.0 GB RAM 2952 MHz</p>
    <li data-md>
     <p>Debian Sid or Windows 10</p>
    <li data-md>
     <p>Method: Gather timings from <code class="highlight"><c- n>time</c-></code> *nix program or <code class="highlight"><c- n>Measure</c-><c- o>-</c-><c- n>Command</c-> <c- p>{</c-> <c- p>...</c-> <c- p>}</c-></code> PowerShell, compute mean</p>
   </ul>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>4 bytes
      <th>40 bytes
      <th>400 bytes
      <th>4 kilobytes
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>0.201 s
      <td>0.208 s
      <td>0.207 s
      <td>0.218 s
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>0.709 s
      <td>0.724 s
      <td>0.711 s
      <td>0.715 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>0.225 s
      <td>0.215 s
      <td>0.237 s
      <td>0.247 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>0.272 s
      <td>0.275 s
      <td>0.272 s
      <td>0.272 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>0.204 s
      <td>0.229 s
      <td>0.209 s
      <td>0.232 s
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>0.353 s
      <td>0.359 s
      <td>0.361 s
      <td>0.361 s
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>0.199 s
      <td>0.208 s
      <td>0.204 s
      <td>0.368 s
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>0.501 s
      <td>0.482 s
      <td>0.519 s
      <td>0.527 s
   </table>
   <p></p>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>40 kilobytes
      <th>400 kilobytes
      <th>4 megabytes
      <th>40 megabytes
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>0.236 s
      <td>0.231 s
      <td>0.300 s
      <td>1.069 s
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>0.705 s
      <td>0.713 s
      <td>0.772 s
      <td>1.135 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>0.406 s
      <td>2.135 s
      <td>23.567 s
      <td>225.290 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>0.366 s
      <td>1.063 s
      <td>8.309 s
      <td>83.250 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>0.552 s
      <td>3.806 s
      <td>52.397 s
      <td>Out of Memory
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>0.353 s
      <td>0.363 s
      <td>0.421 s
      <td>0.585 s
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>0.238 s
      <td>0.199 s
      <td>0.219 s
      <td>0.368 s
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>0.500 s
      <td>0.497 s
      <td>0.555 s
      <td>2.183 s
   </table>
   <p></p>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>400 megabytes
      <th>1 gigabyte
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>9.803 s
      <td>26.383 s
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>4.170 s
      <td>11.887 s
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>2.655 s
      <td>6.023 s
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>1.886 s
      <td>4.762 s
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>22.654 s
      <td>58.204 s
   </table>
   <p></p>
   <h4 class="heading settled" data-level="5.1.2" id="design-practice-memory"><span class="secno">5.1.2. </span><span class="content">Memory Size Results</span><a class="self-link" href="#design-practice-memory"></a></h4>
   <p>Below is the peak memory usage (heap usage) for a file of random bytes using a specific strategy. The file is of the size specified at the top of the column. Files are kept the same between strategies and tests.</p>
   <ul>
    <li data-md>
     <p>Intel Core i7-6700HQ @ 2.60 GHz</p>
    <li data-md>
     <p>24.0 GB RAM 2952 MHz</p>
    <li data-md>
     <p>Debian Sid or Windows 10</p>
    <li data-md>
     <p>Method: <code class="highlight"><c- o>/</c-><c- n>usr</c-><c- o>/</c-><c- n>bin</c-><c- o>/</c-><c- n>time</c-> <c- o>-</c-><c- n>v</c-></code> or Execute command hundreds of times, stare at Task Manager</p>
   </ul>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>4 bytes
      <th>40 bytes
      <th>400 bytes
      <th>4 kilobytes
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>17.26 MB
      <td>17.26 MB
      <td>17.26 MB
      <td>17.27 MB
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>38.82 MB
      <td>38.77 MB
      <td>38.80 MB
      <td>38.80 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>17.26 MB
      <td>17.26 MB
      <td>17.26 MB
      <td>17.27 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>35.12 MB
      <td>35.22 MB
      <td>35.31 MB
      <td>35.88 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>&lt; 30.00 MB
      <td>&lt; 30.00 MB
      <td>&lt; 33.00 MB
      <td>&lt; 38.00 MB
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>53.56 MB
      <td>53.60 MB
      <td>53.53 MB
      <td>53.88 MB
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>33.35 MB
      <td>33.34 MB
      <td>33.34 MB
      <td>33.35 MB
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>17.32 MB
      <td>17.31 MB
      <td>17.31 MB
      <td>17.31 MB
   </table>
   <p></p>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>40 kilobytes
      <th>400 kilobytes
      <th>4 megabytes
      <th>40 megabytes
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>17.26 MB
      <td>17.96 MB
      <td>53.42 MB
      <td>341.72 MB
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>38.80 MB
      <td>40.10 MB
      <td>59.06 MB
      <td>208.52 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>24.85 MB
      <td>134.34 MB
      <td>1,347.00 MB
      <td>12,622.00 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>41.83 MB
      <td>103.76 MB
      <td>718.00 MB
      <td>7,116.00 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>~48.60 MB
      <td>~477.30 MB
      <td>~5,280.00 MB
      <td>Out of Memory
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>53.69 MB
      <td>54.73 MB
      <td>65.88 MB
      <td>176.44 MB
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>33.34 MB
      <td>33.34 MB
      <td>39.41 MB
      <td>113.12 MB
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>17.31 MB
      <td>17.31 MB
      <td>17.31 MB
      <td>57.13 MB
   </table>
   <p></p>
   <p></p>
   <table>
    <tbody>
     <tr>
      <th>Strategy
      <th>400 megabytes
      <th>1 gigabyte
     <tr>
      <td><code class="highlight"><c- cp>#embed</c-></code> GCC
      <td>3,995.34 MB
      <td>9,795.31 MB
     <tr>
      <td><code class="highlight"><c- n>phd</c-><c- o>::</c-><c- n>embed</c-></code> GCC
      <td>1,494.66 MB
      <td>5,279.37 MB
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated GCC
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated Clang
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td><code class="highlight"><c- n>xxd</c-></code>-generated MSVC
      <td>Out of Memory
      <td>Out of Memory
     <tr>
      <td>Circle <code class="highlight">@<c- n>array</c-></code>
      <td>1,282.34 MB
      <td>3,199.28 MB
     <tr>
      <td>Circle <code class="highlight">@<c- n>embed</c-></code>
      <td>850.40 MB
      <td>2,128.36 MB
     <tr>
      <td><code class="highlight"><c- n>objcopy</c-></code> (linker)
      <td>425.77 MB
      <td>1,064.74 MB
   </table>
   <p></p>
   <h4 class="heading settled" data-level="5.1.3" id="design-practice-analysis"><span class="secno">5.1.3. </span><span class="content">Results Analysis</span><a class="self-link" href="#design-practice-analysis"></a></h4>
   <p>The above clearly demonstrates the superiority of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> over latest optimized trunk builds of various compilers. It is also notable that originally the Circle language did not have an <code class="highlight">@<c- n>embed</c-></code> keyword, but it was added in December 2019. When the compiler author was spoken to about Study Group 7’s aspirations for a more generic way of representing data from a file, the ultimate response was this:</p>
   <blockquote>
    <p>I’ll add a new @embed keyword that takes a type and a file path and loads the file and embeds it into an array prvalue of that type. This will cut out the interpreter and it’ll run at max speed. Feed back like this is good. This is super low-hanging fruit.</p>
    <p><a data-link-type="biblio" href="#biblio-circle-embed-tweet">– Sean Baxter, December 12th, 2019</a></p>
   </blockquote>
   <p>It was Circle’s conclusion that a generic API was unsuitable and suffered from the same performance pitfalls that currently plagued current-generation compilers today. And it was SG7’s insistence that a more generic API would be suitable, modeled on Circle’s principles. Given that thorough exploration of the design space in Circle led to the same conclusion this proposal is making, and given the wide variety of languages providing a similar interface (D, Nim, Rust, etc.), it is clear that a more generic API is not desirable for functionality as fundamental and simple as this. This does not preclude a more generic solution being created, but it does prioritize the "Bird in the Hand" approach that the Direction Group and Bjarne Stroustrup have advocated for many times.</p>
   <p>Furthermore, inspecting compiler bug reports around this subject area reveal that this is not the first time GCC has suffered monumental memory blowup over unoptimized representation of data. In fact, this is a <a data-link-type="biblio" href="#biblio-gcc-large-init-bug-c">16+ year old problem that GCC has been struggling with for a long time now</a> (C++ version <a data-link-type="biblio" href="#biblio-gcc-large-init-bug-cpp">here</a>). That the above numbers is nearing the best that can be afforded by some of the most passionate volunteers and experts curating an extremely large codebase should be testament to how hard the language is this area for compiler developers, and how painful it is for regular developers using their tools.</p>
   <p>Clang, while having a better data representation and more optimized structures at its disposal, is similarly constrained. With significant implementation work, they are deeply constrained in what they can do:</p>
   <blockquote>
    <p>It might be possible to introduce some sort of optimized representation specifically for initializer lists.  But it would be a big departure from existing AST handling.  And it wouldn’t really open up new use cases, given that string literal handling is already reasonably efficient.</p>
    <p>– <a data-link-type="biblio" href="#biblio-clang-large-init-bug">Eli Friedman, December 29th 2019</a></p>
   </blockquote>
   <p>Is this really the best use of compiler developer energy?</p>
   <p>To provide a backdrop against which a big departure from current AST handling in can be compared, an implementation of the built-in necessary for this proposal is -- for an experienced developer -- at most a few day’s work in either GCC or Clang. Other compiler engineers have reported similar ease of implementation and integration. Should this really be delegated to Quality of Implementation that will be need to be solved N times over by every implementation in their own particularly special way? Chipping away at what is essentially a fundamental inefficiency required by C++'s inescapable tokenization model from the preprocessor plus the sheer cost of an ever-growing language that makes simple constructs like a brace initializer list of integer constants expensive is, in this paper’s demonstrated opinion, incredibly unwise.</p>
   <h4 class="heading settled" data-level="5.1.4" id="design-practice-manual"><span class="secno">5.1.4. </span><span class="content">Manual Work</span><a class="self-link" href="#design-practice-manual"></a></h4>
   <p>Many developers also hand-wrap their files in (raw) string literals, or similar to massage their data -- binary or not -- into a conforming representation that can be parsed at source code:</p>
   <ol start="0">
    <li data-md>
     <p>Have a file <code class="highlight"><c- n>data</c-><c- p>.</c-><c- n>json</c-></code> with some data, for example:</p>
   </ol>
<pre class="highlight"><c- p>{</c-> <c- s>"Hello"</c-><c- o>:</c-> <c- s>"World!"</c-> <c- p>}</c->
</pre>
   <ol>
    <li data-md>
     <p>Mangle that file with raw string literals, and save it as <code class="highlight"><c- n>raw_include_data</c-><c- p>.</c-><c- n>h</c-></code>:</p>
   </ol>
<pre class="highlight">R<c- s>"</c->json(<c- s>{ "Hello": "World!" }</c->)json<c- s>"</c->
</pre>
   <ol>
    <li data-md>
     <p>Include it into a variable, optionally made <code class="highlight"><c- k>constexpr</c-></code>, and use it in the program:</p>
   </ol>
<pre class="language-cpp highlight"><c- cp>#include</c-> &lt;iostream>
<c- cp>#include</c-> &lt;string_view>

<c- b>int</c-> <c- nf>main</c-><c- p>()</c-> <c- p>{</c->
	<c- k>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>string_view</c-> <c- n>json_view</c-> <c- o>=</c->
<c- cp>#include</c-> "raw_include_data.h"
		<c- p>;</c->
		
	<c- c1>// { "Hello": "World!" }</c->
	<c- n>std</c-><c- o>::</c-><c- n>cout</c-> <c- o>&lt;&lt;</c-> <c- n>json_view</c-> <c- o>&lt;&lt;</c-> <c- n>std</c-><c- o>::</c-><c- n>endl</c-><c- p>;</c->
	<c- k>return</c-> <c- mi>0</c-><c- p>;</c->
<c- p>}</c->
</pre>
   <p>This happens often in the case of people who have not yet taken the "add a build step" mantra to heart. The biggest problem is that the above C++-ready source file is no longer valid in as its original representation, meaning the file as-is cannot be passed to any validation tools, schema checkers, or otherwise. This hurts the portability and interop story of C++ with other tools and languages.</p>
   <p>Furthermore, if the string literal is too big vendors such as VC++ will hard error <a data-link-type="biblio" href="#biblio-nonius-visual-c-error">the build (example from Nonius, benchmarking framework)</a>.</p>
   <h4 class="heading settled" data-level="5.1.5" id="design-practice-tools"><span class="secno">5.1.5. </span><span class="content">Processing Tools</span><a class="self-link" href="#design-practice-tools"></a></h4>
   <p>Other developers use pre-processors for data that can’t be easily hacked into a C++ source-code appropriate state (e.g., binary). The most popular one is <code class="highlight"><c- n>xxd</c-> <c- o>-</c-><c- n>i</c-> <c- n>my_data</c-><c- p>.</c-><c- n>bin</c-></code>, which outputs an array in a file which developers then include. This is problematic because it turns binary data in C++ source. In many cases, this results in a larger file due to having to restructure the data to fit grammar requirements. It also results in needing an extra build step, which throws any programmer immediately at the mercy of build tools and project management. An example and further analysis can be found in the <a href="#appendix-tools">§ 8.1.1 Pre-Processing Tools Alternative</a> and the <a href="#appendix-mongo">§ 8.1.2 python Alternative</a> section.</p>
   <h4 class="heading settled" data-level="5.1.6" id="design-practice-vendor"><span class="secno">5.1.6. </span><span class="content"><code class="highlight"><c- n>ld</c-></code>, resource files, and other vendor-specific link-time tools</span><a class="self-link" href="#design-practice-vendor"></a></h4>
   <p>Resource files and other "link time" or post-processing measures have one benefit over the previous method: they are fast to perform in terms of compilation time. A example can be seen in the <a href="#appendix-ld">§ 8.1.3 ld Alternative</a> section.</p>
   <h4 class="heading settled" data-level="5.1.7" id="design.practice.incbin"><span class="secno">5.1.7. </span><span class="content">The <code class="highlight"><c- n>incbin</c-></code> tool</span><a class="self-link" href="#design.practice.incbin"></a></h4>
   <p>There is a tool called <a data-link-type="biblio" href="#biblio-incbin">[incbin]</a> which is a 3rd party attempt at pulling files in at "assembly time". Its approach is incredibly similar to <code class="highlight"><c- n>ld</c-></code>, with the caveat that files must be shipped with their binary. It unfortunately falls prey to the same problems of cross-platform woes when dealing with VC++, requiring additional pre-processing to work out in full.</p>
   <h3 class="heading settled" data-level="5.2" id="design-prior"><span class="secno">5.2. </span><span class="content">Prior Art</span><a class="self-link" href="#design-prior"></a></h3>
   <p>There has been a lot of discussion over the years in many arenas, from Stack Overflow to mailing lists to meetings with the Committee itself. The latest advancements that had been brought to WG21’s attention was <a data-link-type="biblio" href="#biblio-p0373r0">p0373r0 - File String Literals</a>. It proposed the syntax <code class="highlight"><c- n>F</c-><c- s>"my_file.txt"</c-></code> and <code class="highlight"><c- n>bF</c-><c- s>"my_file.txt"</c-></code>, with a few other amenities, to load files at compilation time. The following is an analysis of the previous proposal.</p>
   <h4 class="heading settled" data-level="5.2.1" id="design-prior-literal"><span class="secno">5.2.1. </span><span class="content">Literal-Based, constexpr</span><a class="self-link" href="#design-prior-literal"></a></h4>
   <p>A user could reasonably assign (or want to assign) the resulting array to a <code class="highlight"><c- k>constexpr</c-></code> variable as its expected to be handled like most other string literals. This allowed some degree of compile-time reflection. It is entirely helpful that such file contents be assigned to constexpr: e.g., string literals of JSON being loaded at compile time to be parsed by Ben Deane and Jason Turner in their CppCon 2017 talk, <a data-link-type="biblio" href="#biblio-constexpr-all-the-things">constexpr All The Things</a>.</p>
   <h4 class="heading settled" data-level="5.2.2" id="design-prior-null"><span class="secno">5.2.2. </span><span class="content">Literal-Based, Null Terminated (?)</span><a class="self-link" href="#design-prior-null"></a></h4>
   <p>It is unclear whether the resulting array of characters or bytes was to be null terminated. The usage and expression imply that it will be, due to its string-like appearance. However, is adding an additional null terminator fitting for desired usage? From the existing tools and practice (e.g., <code class="highlight"><c- n>xxd</c-> <c- o>-</c-><c- n>i</c-></code> or linking a data-dumped object file), the answer is no: but the syntax <code class="highlight"><c- n>bF</c-><c- s>"hello.txt"</c-></code> makes the answer seem like a "yes". This is confusing: either the user should be given an explicit choice or the feature should be entirely opt-in.</p>
   <h4 class="heading settled" data-level="5.2.3" id="design-prior-encoding"><span class="secno">5.2.3. </span><span class="content">Encoding</span><a class="self-link" href="#design-prior-encoding"></a></h4>
   <p>Because the proposal used a string literal, several questions came up as to the actual encoding of the returned information. The author gave both <code class="highlight"><c- n>bF</c-><c- s>"my_file.txt"</c-></code> and <code class="highlight"><c- n>F</c-><c- s>"my_file.txt"</c-></code> to separate binary versus string-based arrays of returns. Not only did this conflate issues with expectations in the previous section, it also became a heavily contested discussion on both the mailing list group discussion of the original proposal and in the paper itself. This is likely one of the biggest pitfalls between separating "binary" data from "string" data: imbuing an object with string-like properties at translation time provide for all the same hairy questions around source/execution character set and the contents of a literal.</p>
   <h3 class="heading settled" data-level="5.3" id="design-goals"><span class="secno">5.3. </span><span class="content">Design Goals</span><a class="self-link" href="#design-goals"></a></h3>
   <p>Because of the aforementioned reasons, it seems more prudent to take a "compiler intrinsic"/"magic function" approach. The function overload takes the form:</p>
<pre class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> 
  <c- n>u8string_view</c-> <c- n>resource_identifier</c->
<c- p>);</c->

<c- k>template</c-> <c- o>&lt;</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> 
  <c- n>u8string_view</c-> <c- n>resource_identifier</c->
<c- p>);</c->

<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> 
  <c- n>u8string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c->
<c- p>);</c->

<c- k>template</c-> <c- o>&lt;</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> 
  <c- n>u8string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c->
<c- p>);</c->
</pre>
   <p><code class="highlight"><c- n>resource_identifier</c-></code> is a <code class="highlight"><c- n>string_view</c-></code> processed in an implementation-defined manner to find and pull resources into C++ at constexpr time. <code class="highlight"><c- n>limit</c-></code> is the maximum number of elements the function call can produce (but it may produce less). The most obvious source will be the file system, with the intention of having this evaluated as a core constant expression. We do not attempt to restrict the <code class="highlight"><c- n>string_view</c-></code> to a specific subset: whatever the implementation accepts (typically expected to be a relative or absolute file path, but can be other identification scheme), the implementation should use. The <code class="highlight"><c- n>N</c-></code> template parameter is for specifying that the returned span has _at least_ <code class="highlight"><c- n>N</c-></code> elements (to fit in the statically-sized <code class="highlight"><c- n>span</c-></code>).</p>
   <h4 class="heading settled" data-level="5.3.1" id="design-goals-impldefn"><span class="secno">5.3.1. </span><span class="content">Implementation Defined</span><a class="self-link" href="#design-goals-impldefn"></a></h4>
   <p>Calls such as <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-> <c- s>"my_file.txt"</c-> <c- p>);</c-></code>, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-> <c- s>"data.dll"</c-> <c- p>);</c-></code>, and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- o>&lt;</c-><c- n>vertex</c-><c- o>></c-><c- p>(</c-> <c- s>"vertices.bin"</c-> <c- p>);</c-></code> are meant to be evaluated in a <code class="highlight"><c- k>constexpr</c-></code> context (with "core constant expressions" only), where the behavior is implementation-defined. The function has unspecified behavior when evaluated in a non-constexpr context (with the expectation that the implementation will provide a failing diagnostic in these cases). This is similar to how include paths work, albeit <code class="highlight"><c- cp>#include</c-></code> interacts with the programmer through the preprocessor.</p>
   <p>There is precedent for specifying library features that are implemented only through compile-time compiler intrinsics (<code class="highlight"><c- n>type_traits</c-></code>, <code class="highlight"><c- n>source_location</c-></code>, and similar utilities). Core -- for other proposals such as <a data-link-type="biblio" href="#biblio-p0466r1">p0466r1 - Layout-compatibility and Pointer-interconvertibility Traits </a> -- indicated their preference in using a <code class="highlight"><c- k>constexpr</c-></code> magic function implemented by intrinsic in the standard library over some form of <code class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>auto</c-> <c- n>X</c-><c- o>></c-> <c- n>thing</c-> <c- p>{</c-> <c- d>/* implementation specified */</c-> <c- n>value</c-><c- p>;</c-> <c- p>};</c-></code> construct. However, it is important to note that <a data-link-type="biblio" href="#biblio-p0466r1">[p0466r1]</a> proposes type traits, where as this has entirely different functionality, and so its reception and opinions may be different.</p>
   <p>Finally, we use "implementation defined" so that compilers can produce implementation-defined search path for their translation units and modules during compilation with flags. The current implementation uses <code class="highlight"><c- o>-</c-><c- n>fembed</c-><c- o>-</c-><c- n>path</c-><c- o>=</c-><c- n>some</c-><c- o>/</c-><c- n>path</c-><c- o>/</c-><c- n>here</c-><c- o>/</c-></code> to indicate this, but when it is standardized there will probably be an <code class="highlight"><c- o>-</c-><c- n>RI</c-></code> or <code class="highlight"><c- o>-</c-><c- n>resource</c-><c- o>-</c-><c- n>include</c-></code> flag instead. It is up to the implementation to pick what works for their platform.</p>
   <h4 class="heading settled" data-level="5.3.2" id="design-goals-binary"><span class="secno">5.3.2. </span><span class="content">Binary Only</span><a class="self-link" href="#design-goals-binary"></a></h4>
   <p>Creating two separate forms or options for loading data that is meant to be a "string" always fuels controversy and debate about what the resulting contents should be. The problem is sidestepped entirely by demanding that the resource loaded by <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> represents the bytes exactly as they come from the resource. This prevents encoding confusion, conversion issues, and other pitfalls related to trying to match the user’s idea of "string" data or non-binary formats. Data is received exactly as it is from the resource as defined by the implementation, whether it is a supposed text file or otherwise. <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-> <c- s>"my_text_file.txt"</c-> <c- p>)</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-> <c- s>"my_binary_file.bin"</c-> <c- p>)</c-></code> behave exactly the same concerning their treatment of the resource.</p>
   <h4 class="heading settled" data-level="5.3.3" id="design-goals-constexpr"><span class="secno">5.3.3. </span><span class="content">Constexpr Compatibility</span><a class="self-link" href="#design-goals-constexpr"></a></h4>
   <p>The entire implementation must be usable in a <code class="highlight"><c- k>constexpr</c-></code> context. It is not just for the purposes of processing the data at compile time, but because it matches existing implementations that store strings and huge array literals into a variable via <code class="highlight"><c- cp>#include</c-></code>. These variables can be <code class="highlight"><c- k>constexpr</c-></code>: to not have a constexpr implementation is to leave many of the programmers who utilize this behavior without a proper standardized tool.</p>
   <h4 class="heading settled" data-level="5.3.4" id="design-goals-dependencies"><span class="secno">5.3.4. </span><span class="content">Dependency-Scanning Friendly with <code class="highlight"><c- cp>#depend</c-></code></span><a class="self-link" href="#design-goals-dependencies"></a></h4>
   <p>One of the biggest hurdles to generating consensus was the deep-seated issues with dependency scanning. The model with only dealing with <code class="highlight"><c- cp>#include</c-></code> as a way of adding extra code or data-as-code means that all dependencies -- at the time of compiler invocation -- can be completely and statically known by the end of Phase 4 of compilation. This greatly aided in speedy dependency pulling. <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> throws a wrench in that model as it can affect the generation of code at Phase 7 time, which is when <code class="highlight"><c- k>constexpr</c-></code> is evaluated. By taking a <code class="highlight"><c- n>std</c-><c- o>::</c-><c- p>(</c-><c- n>u8</c-><c- p>)</c-><c- n>string_view</c-></code>, it makes it impossible to know all files which may be used by a translation or module unit.</p>
   <p>For this purpose, a new <code class="highlight"><c- cp>#depend</c-></code> preprocessor directive was introduced. It is intended to inform the compiler which translation units it depends on in order to make it simpler to retrieve all necessary dependencies. An advanced implementation can also replace all <code class="highlight"><c- cp>#depend</c-></code> directives with magical compiler builtins which instruct the compiler to cache the file’s data as part of the translation unit.</p>
   <p>This makes it possible to send minimal compiler reproductions and test cases for bug vetting, as well as allow distributed systems to continue to use the <code class="highlight"><c- o>-</c-><c- n>fdirectives</c-><c- o>-</c-><c- n>only</c-></code> or <code class="highlight"><c- o>-</c-><c- n>frewrite</c-><c- o>-</c-><c- n>includes</c-></code> flags (or similar preprocessor flags). For example, the GCC and Clang implementations linked above have <code class="highlight"><c- n>__builtin_init_array</c-></code> and <code class="highlight"><c- n>__builtin_cache_array</c-></code> methods that allow single translation units to be self-sufficient, while the compiler built-ins <code class="highlight"><c- n>__builtin_embed</c-></code> will search the internally populated data cache from these entries in order to furnish data. This allows a complete system that keeps current tools working exactly as expected without any issues at all.</p>
   <p>The <code class="highlight"><c- cp>#depend</c-></code> directive works by allowing a user to specify a <em>single-dependency</em> or a <em>family-dependency</em>. They are analogous to a single resource name or a "glob" resource name. These would, in file system terms, name a single file or all the files in a directory (subject to pattern matching). There used to also be a "<em>recursive-family-dependency</em>" for specifying searching for files in a directory, recursively. They looked like this:</p>
<pre class="language-cpp highlight"><c- c1>// single-dependency directives</c->
<c- cp>#depend &lt;config/graph.bin></c->
<c- cp>#depend &lt;foo.txt></c->
<c- c1>// family-dependencies</c->
<c- c1>// do not "recurse" into directories</c->
<c- cp>#depend "art</c-><c- d>/*"</c->
<c- d>#depend "art/mocks/*.json"</c->
<c- d>// recursive-family-dependency</c->
<c- d>// recurse through directories and similar</c->
<c- d>#depend "assets/**"</c->
<c- d>// mixed: all resources starting with</c->
<c- d>// "translation/", with all files that end in ".po",</c->
<c- d>// that have at least one "/" (one directory)</c->
<c- d>// after the "translation/", found recursively</c->
<c- d>#depend "translation/**/</c-><c- cp>*.po"</c->
</pre>
   <p>Due to Windows being a pile of garbage for <code class="highlight"><c- n>FindFirstFile</c-></code>-style directory iteration, it was voted to remove <code class="highlight"><c- o>**</c-></code> as the recursive-family-dependency (see <a href="#polls">§ 2 Relevant Polls</a>). Benchmarks for different styles of iteration may prove helpful here to convince others to maybe not do this.</p>
   <p><code class="highlight"><c- cp>#depend</c-></code> uses both the chevron-delimited <code class="highlight"><c- o>&lt;</c-><c- n>foo</c-><c- p>.</c-><c- n>txt</c-><c- o>></c-></code> and the quote-delimited <code class="highlight"><c- s>"foo.txt"</c-></code> formats. This is because one is for resources that are found only on the system / implementation paths similar to <code class="highlight"><c- o>-</c-><c- n>I</c-></code> and <code class="highlight"><c- o>-</c-><c- n>isystem</c-></code>, and then one that uses local look up plus the aforementioned resource paths. This can be useful for e.g. files that get embedded from system SDKs, like icons from Windows or Android build-time graphical resources or similar.</p>
   <h4 class="heading settled" data-level="5.3.5" id="design-goals-modules"><span class="secno">5.3.5. </span><span class="content">Modules</span><a class="self-link" href="#design-goals-modules"></a></h4>
   <p>Modules front-load and bring front-and-center one of the largest problems not with <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>, but with <code class="highlight"><c- cp>#depend</c-></code>. <code class="highlight"><c- cp>#depend</c-></code> is a Compilation Phase 4 entity: that is, it does not exist beyond the preprocessor. In the world of <code class="highlight"><c- cp>#include</c-></code>, preprocessor commands were resolved that would not exist in the traditional <code class="highlight"><c- cp>#include</c-></code> world, or at least would not have to need immediate answers. In particular, the fact that modules can "save" Phase 4 information before proceeding with the rest of compilation opens interesting questions for Module Interface Units (AKA, the public-facing portion of modules). Module implementation units and other module-related bits are, thankfully, entirely unaffected.</p>
   <p>The problem is illustrated most powerfully by the following snippet:</p>
   <p><code class="highlight"><c- n>m0</c-><c- p>.</c-><c- n>c</c-><c- o>++</c-><c- n>m</c-></code>:</p>
<pre class="language-cpp highlight"><c- k>export</c-> <c- n>module</c-> <c- n>m0</c-><c- p>;</c->

<c- cp>#depend "header.bin"</c->

<c- n>import</c-> <c- o>&lt;</c-><c- n>embed</c-><c- o>></c-><c- p>;</c->
<c- n>import</c-> <c- n>combine</c-><c- p>;</c->

<c- k>export</c-> <c- n>consteval</c-> <c- k>auto</c-> <c- nf>f0</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>string_view</c-> <c- n>f</c-><c- p>)</c-> <c- p>{</c->
	<c- k>const</c-> <c- k>auto</c-> <c- n>h</c-> <c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"header.bin"</c-><c- p>);</c->
	<c- k>const</c-> <c- k>auto</c-> <c- n>t</c-> <c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- n>f</c-><c- p>);</c->
	<c- k>return</c-> <c- n>combine</c-><c- p>(</c-><c- n>h</c-><c- p>,</c-> <c- n>t</c-><c- p>);</c->
<c- p>}</c->
</pre>
   <p><code class="highlight"><c- n>m1</c-><c- p>.</c-><c- n>c</c-><c- o>++</c-><c- n>m</c-></code>:</p>
<pre class="language-cpp highlight"><c- k>export</c-> <c- n>module</c-> <c- n>m1</c-><c- p>;</c->

<c- cp>#depend "default.stuff"</c->

<c- n>import</c-> <c- n>m0</c-><c- p>;</c->

<c- k>export</c-> <c- n>consteval</c-> <c- k>auto</c-> <c- nf>f1</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>string_view</c-> <c- n>f</c-> <c- o>=</c-> <c- s>"default.stuff"</c-><c- p>)</c-> <c- p>{</c->
	<c- k>return</c-> <c- n>f0</c-><c- p>(</c-><c- n>f</c-><c- p>);</c->
<c- p>}</c->

<c- k>export</c-> <c- n>consteval</c-> <c- k>auto</c-> <c- nf>getpath</c-><c- p>()</c-> <c- p>{</c->
	<c- k>return</c-> <c- s>"default.stuff"</c-><c- p>;</c->
<c- p>}</c->
</pre>
   <p><code class="highlight"><c- n>translation_unit0</c-><c- p>.</c-><c- n>c</c-><c- o>++</c-></code>:</p>
<pre class="language-cpp highlight"><c- n>import</c-> <c- n>m1</c-><c- p>;</c->
<c- n>import</c-> <c- n>print</c-><c- p>;</c->
<c- n>import</c-> <c- o>&lt;</c-><c- n>embed</c-><c- o>></c->

<c- cp>#depend "coolstuff.bin"</c->

<c- b>int</c-> <c- n>main</c-><c- p>()</c-> <c- p>{</c->
	<c- n>print</c-><c- p>(</c-><c- n>f1</c-><c- p>());</c->                <c- c1>// [0] OK, fine</c->
	<c- n>print</c-><c- p>(</c-><c- n>f1</c-><c- p>(</c-><c- s>"coolstuff.bin"</c-><c- p>));</c-> <c- c1>// [1] OK, good</c->
	<c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"header.bin"</c-><c- p>);</c->   <c- c1>// [2] Should this work?</c->
	<c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- n>getpath</c-><c- p>());</c->      <c- c1>// [3] What about this?	</c->
<c- p>}</c->
</pre>
   <p>In the line marked <code class="highlight"><c- p>[</c-><c- mi>0</c-><c- p>]</c-></code>, everything is fine because the eventual call to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> originates from <code class="highlight"><c- n>m0</c-></code>'s module interface unit, which can find <code class="highlight"><c- n>header</c-><c- p>.</c-><c- n>bin</c-></code> and has an explicit dependency on <code class="highlight"><c- n>header</c-><c- p>.</c-><c- n>bin</c-></code>. This is straight forward. Line <code class="highlight"><c- p>[</c-><c- mi>1</c-><c- p>]</c-></code> is fine as well, because there is an explicit <code class="highlight"><c- cp>#depend</c-></code> which makes the <code class="highlight"><c- n>coolstuff</c-><c- p>.</c-><c- n>bin</c-></code> resource available from the current translation unit, which works with the <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> call. The real problem arises, however, when we get to lines <code class="highlight"><c- p>[</c-><c- mi>2</c-><c- p>]</c-></code> and lines <code class="highlight"><c- p>[</c-><c- mi>3</c-><c- p>]</c-></code>.</p>
   <p>The way modules and macros work right now means macros do not go in (save from special implementation places, such as the command line/response file) and do not come out (unless explicitly exported). What, then, should happen to <code class="highlight"><c- cp>#depend</c-></code> and its preprocessor directives? Are the dependencies identified by <code class="highlight"><c- cp>#depend</c-></code> supposed to cascade through into translation units / modules that import them? This goes against the idea that modules can successfully isolate the preprocessor and suppress its stateful effects on downstream code.</p>
   <p>Because the Committee voted to create a strong correlation between <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> -- a Phase 7, regular C++ entity -- and <code class="highlight"><c- cp>#depend</c-></code> -- a Phase 4, preprocessor entity -- what used to be a compiler hint that the compiler can treat in any manner it so pleases and could instead gently warn on must now provide semantic meaning. Saying that lines <code class="highlight"><c- p>[</c-><c- mi>2</c-><c- p>]</c-></code> and <code class="highlight"><c- p>[</c-><c- mi>3</c-><c- p>]</c-></code> should work means acknowledging that <code class="highlight"><c- cp>#depend</c-></code> is a stateful preprocessor macro, which is something we have been trying to get rid of and reduce the usage of since the push for C++11. It also opens up the door to these questions in general regarding the usage, and requires compilers to have to answer these questions. If the answer becomes "yes", then programmers are back where we started several years ago with <code class="highlight"><c- cp>#include</c-></code> files and spending many people-months of time advocating for "<code class="highlight"><c- cp>#depend</c-></code> what you use". But even then, the answer to that question is even harder than before: because <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> is a "real C++ entity" that exists outside of the preprocessor, things like default arguments and call location begin to start mattering a lot more than it should.</p>
   <p>There are 4 ways to go about fixing this problem for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>:</p>
   <ol start="0">
    <li data-md>
     <p>Keep <code class="highlight"><c- cp>#depend</c-></code> as a requirement for finding files. Ban usage of the feature in module interface units. This makes it impossible to leak outside of implementation units or translation units because it is a <code class="highlight"><c- n>consteval</c-></code> entity.</p>
    <li data-md>
     <p>Keep <code class="highlight"><c- cp>#depend</c-></code> as a requirement for finding files. Answer "no" to lines <code class="highlight"><c- p>[</c-><c- mi>2</c-><c- p>]</c-></code> and <code class="highlight"><c- p>[</c-><c- mi>3</c-><c- p>]</c-></code> above. This means that code that imports modules can no longer take an accidental dependency on things previous modules declared as their dependencies. It becomes less convenient if a path is provided by a library that needs to be used by <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>, because then the user may have to duplicate <code class="highlight"><c- cp>#depend</c-></code> information.</p>
    <li data-md>
     <p>Keep <code class="highlight"><c- cp>#depend</c-></code> as a requirement for finding files. Answer "yes" to lines <code class="highlight"><c- p>[</c-><c- mi>2</c-><c- p>]</c-></code> and <code class="highlight"><c- p>[</c-><c- mi>3</c-><c- p>]</c-></code> above. This means the <code class="highlight"><c- cp>#depend</c-></code> directive becomes entirely stateful and someone may accidentally rely on a dependency declaration in a module interface unit they use, and those module interface units an break downstream code by changing their <code class="highlight"><c- cp>#depend</c-></code> dependencies.</p>
    <li data-md>
     <p>Remove the normative teeth of <code class="highlight"><c- cp>#depend</c-></code> for finding files. Do not let <code class="highlight"><c- cp>#depend</c-></code> leak out of modules. This follows the current module rules and does not create accidental library-user dependencies, while not impacting the usability of users who specify both <code class="highlight"><c- o>-</c-><c- n>resource</c-><c- o>-</c-><c- n>path</c-><c- o>=</c-></code> flags and such appropriately.</p>
   </ol>
   <p>#0 is way too big of a hammer to swing at this problem and drastically reduces the friendliness of the feature. It also taints the usability of both modules and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>, which is nowhere near a desirable outcome.</p>
   <p>#1 seems like a decent solution, but still requires an excessive amount of client-side verbosity for individuals who write wrapper functions around <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>. If a user relies on a function outside of their code to retrieve the path at <code class="highlight"><c- k>constexpr</c-></code>-time, then they would need to duplicate whatever dependency-finding code the client has written as the user. Choosing this option makes the case for the string table / virtual file system approach in <a href="#previous-virtual">§ 6.2 String Table / Virtual File System</a> more useful, since the fixed set of strings can be presented to the user in some fashion. (That is, if we conveniently ignore that recursive dependency specifications in any form still make this untenable.)</p>
   <p>#2 introduces a heinous problem where users can be broken by library developers who rely on things local to their library but other developers "happen" to catch a hold of, making things miserable for both users and library developers. But, it does create a world in which simple things logically work even if a <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> call is hidden inside of another <code class="highlight"><c- n>consteval</c-></code> function.</p>
   <p>#3 makes it so a library and a user can have code that does not force a user to properly give all dependencies to outside build tools in this corner case in particular (at least, portably: warnings, warnings as errors, etc.). It does not require a strong coupling between the Phase 4 entity and the Phase 7 entity, eliminating the need for this question at all (and making it a matter of "can I, the compiler, find the file, or not").</p>
   <p>This paper chooses #3. It takes the normative teeth out of <code class="highlight"><c- cp>#depend</c-></code> and leaves it to an implementation to warn when files are not explicitly depended upon. This means that a Phase 4 entity no longer has a tight coupling with a Phase 7 entity, keeping things separate. The modules space beyond Phase 4 is no longer complicated. Note that recompilation due to a change in any of the dependencies under this model still works without creating breaking problems in the program of a library user. If a used library’s module interface unit has a <code class="highlight"><c- cp>#depend</c-></code> and a user changes the file that the module interface unit depends on, it triggers a recompile for that module interface unit. By triggering that recompilation, _any down-stream importer that depends on that module_ now must recompile. Now, how the compiler handles the <code class="highlight"><c- cp>#depend</c-></code> remains up to its implementation but it still has full reign to get that work done.</p>
   <h4 class="heading settled" data-level="5.3.6" id="design-goals-templated"><span class="secno">5.3.6. </span><span class="content">Statically Polymorphic</span><a class="self-link" href="#design-goals-templated"></a></h4>
   <p>While returning <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>byte</c-></code> is valuable, it is impossible to <code class="highlight"><c- k>reinterpret_cast</c-></code> or <code class="highlight"><c- n>bit_cast</c-></code> certain things at compile time. This makes it impossible in a <code class="highlight"><c- k>constexpr</c-></code> context to retrieve the actual data from a resource without tremendous boilerplate and work that every developer will have to do. While compile-time serialization is an important facet of this feature, there are many types where developers will end up just doing their own <code class="highlight"><c- n>bit_cast</c-></code>-style <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>memcpy</c-></code> of the bits to the target bits: to save on boilerplate, we instead offer the ability to do <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- o>&lt;</c-><c- n>TYPE</c-><c- o>></c-></code>, where <code class="highlight"><c- n>TYPE</c-></code> can be anything that satisfies trivial destructibility (e.g., <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_trivial_v</c-><c- o>&lt;</c-><c- n>TYPE</c-><c- o>></c-></code> is <code class="highlight">true</code>). This allows all C types and many types which are mirrored almost exactly in binary form to be pulled effortlessly into code.</p>
   <h4 class="heading settled" data-level="5.3.7" id="design-goals-limit"><span class="secno">5.3.7. </span><span class="content">Optional Limit</span><a class="self-link" href="#design-goals-limit"></a></h4>
   <p>Consider some file-based resources that are otherwise un-sizeable and un-seek/tellable in various implementations such as <code class="highlight"><c- o>/</c-><c- n>dev</c-><c- o>/</c-><c- n>urandom</c-></code>. Telling the compiler to go fetch data from this resource infinitely can result in compiler lockups or worse: therefore, the user can specify an additional parameter to the function call such as <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"/dev/infinity"</c-><c- p>,</c-> <c- mi>32</c-><c- p>);</c-></code>. The <code class="highlight"><c- mi>32</c-></code> here is a <code class="highlight"><c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>limit</c-></code> parameter in <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>, and allows users to ask for up to but not more than <code class="highlight"><c- n>limit</c-></code> elements in the returned <code class="highlight"><c- n>span</c-></code>.</p>
   <p>Note that as per <a href="#design-goals-templated">§ 5.3.6 Statically Polymorphic</a>, the limit is specified in terms of <code class="highlight"><c- n>T</c-></code>s, not bytes. This means <code class="highlight"><c- k>sizeof</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- o>*</c-> <c- n>CHAR_BIT</c-></code> bits are required, and the implementation is mandated to require up to but not more than that many.</p>
   <p>Additionally, a user can provide a template argument <code class="highlight"><c- n>N</c-></code> of type <code class="highlight"><c- n>std</c-><c- o>::</c-><c- b>size_t</c-></code> to return a <code class="highlight"><c- n>span</c-><c- o>&lt;</c-><c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-></code>. This requires at _least_ <code class="highlight"><c- n>N</c-></code> elements, but maybe more can exist. One can use both of these to request "exactly this many" elements, e.g. a call <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- o>&lt;</c-><c- mi>32</c-><c- o>></c-><c- p>(</c-><c- s>"/dev/infinity"</c-><c- p>,</c-> <c- mi>32</c-><c- p>);</c-></code> requires up to but not more than 32 elements (the <code class="highlight"><c- n>limit</c-></code> parameter passed to the function) and that the returned span has at least 32 elements (the template parameter passed between the <code class="highlight"><c- o>&lt;</c-></code> and the <code class="highlight"><c- o>></c-></code>). Similarly, one could use <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"/dev/infinity"</c-><c- p>,</c-> <c- mi>32</c-><c- p>).</c-><c- n>first</c-><c- o>&lt;</c-><c- mi>32</c-><c- o>></c-><c- p>();</c-></code>. This fully covers the design space for what making a subset of the data is currently used for (e.g., prefixed data in a common model format that then has "back references" to the data contained in the first <code class="highlight"><c- n>n</c-></code> elements).</p>
   <h4 class="heading settled" data-level="5.3.8" id="design-goals-utf8"><span class="secno">5.3.8. </span><span class="content">UTF-8 Only</span><a class="self-link" href="#design-goals-utf8"></a></h4>
   <p>This is related to a serious problem for string literals, particularly those of Translation Phase 7. When a user types a string literal such as <code class="highlight"><c- s>"Fáuncy.softłer"</c-></code>, that string literal -- at Phase 5 of compilation -- gets translated from an idealized internal compiler character set to the "Execution Source Character Set". What this means is that the compiler is allowed to perform an implementation-defined translation from the string literal’s ideal compiler representation to the execution character set (often, the presumed target execution character set). While this is not a problem for Clang -- which always uses UTF-8 -- and GCC -- which always uses UTF-8 unless someone specifically passes <code class="highlight"><c- o>-</c-><c- n>fexec</c-><c- o>-</c-><c- n>charset</c-><c- o>=</c-><c- p>{</c-><c- n>something</c-><c- p>}</c-></code> -- other compilers will take the string <code class="highlight"><c- s>"Fáuncy.softłer"</c-></code> and mangle it. This mangling does not have to come with warnings: in fact, MSVC will often times replace characters it cannot translate to the execution character set with either Mojibake or <code class="highlight"><c- s>"?"</c-></code>.</p>
   <p>The solution that Study Group 16 recommended was to allow <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>u8string_view</c-></code> and ONLY <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>u8string_view</c-></code> as the parameter type. Others in SG-16 voiced concern that this would hamper general usability, but <code class="highlight"><c- n>u8</c-></code> string literals and <code class="highlight"><c- n>char8_t</c-></code> were put in the standard for reasons exactly such as this. The execution character set is an unknown and often lossy encoding on legacy systems: requiring UTF-8 with <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>u8string_view</c-></code> matches most internal compiler representations of idealized text storage and provides a lossless way to work with the resource system.</p>
   <p>We note that it would be "maximally nice" to provide all of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- p>[</c-><c- n>w</c-><c- o>|</c-><c- n>u8</c-><c- o>|</c-><c- n>u16</c-><c- o>|</c-><c- n>u32</c-><c- p>]</c-><c- n>string_view</c-></code> overloads to the table which would allow individuals working in the <code class="highlight"><c- k>constexpr</c-></code> space their choice of presumed encoding to work in, but deem that the additional flexibility is likely not worth the additional overloads (even if those overloads are cheap to implement).</p>
   <h2 class="heading settled" data-level="6" id="previous"><span class="secno">6. </span><span class="content">Previous Implementations</span><a class="self-link" href="#previous"></a></h2>
   <p>This section is primarily to address feedback from polls wherein different forms and implementation strategies were asked for by the Evolution Working Group and other implementers. A tour of the design and implementation these cases helps show what has been considered.</p>
   <h3 class="heading settled" data-level="6.1" id="previous-#depend"><span class="secno">6.1. </span><span class="content"><code class="highlight"><c- cp>#depend</c-></code> Soft Warnings, Hard Errors?</span><a class="self-link" href="#previous-%23depend"></a></h3>
   <p>The current specification makes it a hard error if a file has not been identified previously by a <code class="highlight"><c- cp>#depend</c-></code> directive. This makes the simple case of including a single file a bit more annoying than it needs to be, but also makes the case of general development with a non-distributed build system a pain. To be perfectly transparent, the author of this paper and almost 100% of the author’s clients do not use distributed anything to build their code: errors at "file not found" are generally useful enough. Making the lack of matching <code class="highlight"><c- cp>#depend</c-></code> a hard error seems like pushing an important but nevertheless Committee-over-represented concern (i.e. distributed build tool users) onto all C++ users.</p>
   <p>While the author feels a lot better about it being a soft warning that can be turned into a hard error by use of <code class="highlight"><c- o>-</c-><c- n>Werror</c-><c- o>-</c-><c- n>depend</c-></code> for distributed build users, we leave the specification to strongly encourage implementations to hard error on an inability to not only find the resource but match it with a previous <code class="highlight"><c- cp>#depend</c-></code> declaration.</p>
   <h3 class="heading settled" data-level="6.2" id="previous-virtual"><span class="secno">6.2. </span><span class="content">String Table / Virtual File System</span><a class="self-link" href="#previous-virtual"></a></h3>
   <p>This implementation idea was floated twice, once during SG-7 discussion at the November 2019 Belfast meeting and again during the February 2020 Prague meeting. The crux of this version of <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> is that it does not take resource identifiers related to e.g. the file system directly: a directive is used to build a "String Table" or "Translation Table" from system-specific paths to "friendly" names:</p>
<pre class="language-cpp highlight"><c- c1>// map "foo.txt" to file name "foo"</c->
<c- cp>#depend_name "foo.txt" "foo"</c->

<c- cp>#ifdef _WIN32</c->
  <c- c1>// map Windows-specific resource</c->
  <c- c1>// "win/bazunga.bin" to file name "baz"</c->
  <c- cp>#depend_name "win/bazunga.bin" "baz"</c->
<c- cp>#else</c->
  <c- c1>// map Unix-specific resource</c->
  <c- c1>// "nix/bazinga.bin" to file name "baz"</c->
  <c- cp>#depend_name "nix/bazooka.bin" "baz"</c->
<c- cp>#endif</c->

<c- cp>#include</c-> &lt;embed>

<c- b>int</c-> <c- nf>main</c-> <c- p>()</c-> <c- p>{</c->
  <c- c1>// pulls foo.txt</c->
  <c- k>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>span</c-><c- o>&lt;</c-><c- n>std</c-><c- o>::</c-><c- n>byte</c-><c- o>></c-> <c- n>foo</c-> <c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"foo"</c-><c- p>);</c->
  <c- c1>// pulls either bazunga or bazooka</c->
  <c- k>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- n>span</c-><c- o>&lt;</c-><c- n>std</c-><c- o>::</c-><c- n>byte</c-><c- o>></c-> <c- n>baz</c-> <c- o>=</c-> <c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"baz"</c-><c- p>);</c->
  <c- k>return</c-> <c- n>foo</c-><c- p>[</c-><c- mi>0</c-><c- p>]</c-> <c- o>==</c-> <c- sc>'f'</c-> <c- o>&amp;&amp;</c-> <c- n>baz</c-><c- p>[</c-><c- mi>2</c-><c- p>]</c-> <c- o>==</c-> <c- sc>'\x3'</c-><c- p>;</c->
<c- p>}</c->
</pre>
   <p>On the tin, this seems to bring nice properties to the table. We get to "erase" platform-specific paths and give them common names, we have a static list of names that we always pull from, and more. However, there are several approaches to this problem. Consider one of the primary use cases for <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> as a <code class="highlight"><c- k>constexpr</c-></code> function: reading a resource and, based on its contents, <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code>-ing other resources.</p>
   <p>This becomes a problem: if <code class="highlight"><c- n>foo</c-><c- p>.</c-><c- n>txt</c-></code> has a <code class="highlight"><c- nl>get</c-><c- p>:</c-> <c- n>bar</c-><c- p>.</c-><c- n>doc</c-></code> line of text in it, we read that line from <code class="highlight"><c- n>foo</c-><c- p>.</c-><c- n>txt</c-></code>, and then attempt to <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-><c- p>(</c-><c- s>"bar.doc"</c-><c- p>)</c-></code>, we get an error because we did not give <code class="highlight"><c- n>bar</c-><c- p>.</c-><c- n>doc</c-></code> a string table name. This means we need to go back and not only mark it as a dependency with <code class="highlight"><c- cp>#depend</c-></code>, but also give it a static string-table based name.</p>
   <p>Even conquering that problem, we face another: resource files -- JSON, SPIR-V, Wavefront OBJ, HLSL/GLSL, python, Lua, HSAIL, whatever -- do not speak "C++ String Table" to name their identifiers. Generally, these speak "File System": we are adding a level of indirection that makes it _impossible_ to keep working with the file system, especially when it comes to working with external resources. Most tools communicate and traffic interchange information VIA URIs or relative / local file paths. Forcing users to either adapt their code to play nice with the C++ file system or maintaining a translation table to and from "C++ String Table" to "C++ File System" is an order of magnitude additional complexity that is not both unnecessary and also painful.</p>
   <p>There is absolutely room for a (potentially <code class="highlight"><c- k>constexpr</c-></code>) Virtual File System in C++. This is not the feature that should bring us there. As the current implementation does, manipulating <code class="highlight"><c- o>-</c-><c- n>fembed</c-><c- o>-</c-><c- n>path</c-><c- o>=</c-></code> similar to the way <code class="highlight"><c- cp>#include</c-></code> is handled alongside <code class="highlight"><c- o>-</c-><c- n>I</c-></code> flags is a much better use of not only implementer time, but user time. It fits perfectly into the mental model ("include, but for resources") and lets users keep their file names as the unit of interchange as far as names go.</p>
   <p>C++ does not need to make for itself a reputation of trying to be an extremely unique snowflake at the cost of usability and user friendliness.</p>
   <h2 class="heading settled" data-level="7" id="wording"><span class="secno">7. </span><span class="content">Changes to the Standard</span><a class="self-link" href="#wording"></a></h2>
   <p>Wording changes are relative to <a data-link-type="biblio" href="#biblio-n4842">[n4842]</a>.</p>
   <h3 class="heading settled" data-level="7.1" id="wording-intent"><span class="secno">7.1. </span><span class="content">Intent</span><a class="self-link" href="#wording-intent"></a></h3>
   <p>The intent of the wording is to provide a function that:</p>
   <ul>
    <li data-md>
     <p>handles the provided resource identifying <code class="highlight"><c- n>string_view</c-></code> in an implementation-defined manner;</p>
    <li data-md>
     <p>and, returns the specified constexpr <code class="highlight"><c- n>span</c-></code> representing either the bytes of the resource or the bytes view as the type <code class="highlight"><c- n>T</c-></code>.</p>
   </ul>
   <p>The wording also explicitly disallows the usage of the function outside of a core constant expression by marking it <code class="highlight"><c- n>consteval</c-></code>, meaning it is ill-formed if it is attempted to be used at not-constexpr time (<code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> calls should not show up as a function in the final executable or in generated code). The program may pin the data returned by <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>embed</c-></code> through the span into the executable if it is used outside a core constant expression.</p>
   <h3 class="heading settled" data-level="7.2" id="wording-feature"><span class="secno">7.2. </span><span class="content">Proposed Feature Test Macro</span><a class="self-link" href="#wording-feature"></a></h3>
   <p>The proposed feature test macros are <code class="highlight"><c- n>__cpp_lib_embed</c-></code> for the library and <code class="highlight"><c- n>__cpp_pp_depend</c-></code> for the preprocessor functionality.</p>
   <h3 class="heading settled" data-level="7.3" id="wording-proposed"><span class="secno">7.3. </span><span class="content">Proposed Wording</span><a class="self-link" href="#wording-proposed"></a></h3>
   <p>Append to §14.8.1 Predefined macro names [<strong>cpp.predefined</strong>]'s <strong>Table 16</strong> with one additional entry:</p>
   <blockquote>
    <table>
     <tbody>
      <tr>
       <th>Macro name
       <th>Value
      <tr>
       <td>
        <ins>__cpp_pp_depend</ins>
       <td>
        <ins>202006L</ins>
    </table>
   </blockquote>
   <p>Add a new section §15.4 Dependency [<strong>cpp.depend</strong>]:</p>
   <blockquote>
    <ins>
      <strong>15.4 Dependency</strong> [<strong>cpp.depend</strong>] 
     <p><sup>1</sup> A <code class="highlight"><c- cp>#depend</c-></code> directive establishes inputs or family of inputs upon which a translation unit depends.</p>
     <p><sup>2</sup> A preprocessing directive of the form</p>
     <p>    <code class="highlight"><c- cp>#</c-></code> <code class="highlight"><c- n>depend</c-></code> <code class="highlight"><c- o>&lt;</c-></code> <i>h-char-sequence</i> <code class="highlight"><c- o>></c-></code> <i>new-line</i></p>
     <p>or</p>
     <p>    <code class="highlight"><c- cp>#</c-></code> <code class="highlight"><c- n>depend</c-></code> <code class="highlight"><c- s>"</c-></code> <i>q-char-sequence</i> <code class="highlight"><c- s>"</c-></code> <i>new-line</i></p>
     <p>provides a dependency name. If an implementation does not find meaning in the quote-delimited <i>q-char-sequence</i>, it may reprocess this directive and treat it as a <code class="highlight"><c- cp>#depend</c-></code> <code class="highlight"><c- o>&lt;</c-></code> <i>h-char-sequence</i> <code class="highlight"><c- o>></c-></code> <i>new-line</i> directive using the same <i>q-char-sequence</i>, including any <code class="highlight"><c- o>&lt;</c-></code> or <code class="highlight"><c- o>></c-></code>.</p>
     <p><sup>3</sup> The <i>q-char-sequence</i> or <i>h-char-sequence</i> may have one of 3 meanings, depending on the use of <code class="highlight"><c- o>*</c-></code> or <code class="highlight"><c- o>**</c-></code> within the sequence.</p>
     <p></p>
     <dl>
      <dd>– If the sequence contains a <code class="highlight"><c- o>*</c-></code> it denotes a <i>dependency-family</i>. 
      <dd>– Otherwise, it denotes a <i>single-dependency</i>. 
     </dl>
     <p></p>
     <p><sup>4</sup> [ <i>Example—</i> </p>
<pre class="language-cpp highlight"><c- cp>#depend "art.png" </c-><c- c1>// this translation unit depends on 'art.png'</c->

<c- cp>#depend &lt;config</c-><c- d>/*.json> // this translation unit depends on all resources</c->
<c- d>                         // the implementation can find that</c->
<c- d>                         // end in ".json" and start with "config/".</c->

<c- d>#depend &lt;data/*/</c-><c- cp>*.bin> </c-><c- c1>// this translation unit depends on all resources</c->
                        <c- c1>// the implementation can find that</c->
                        <c- c1>// end in ".bin", start with "data/"</c->
                        <c- c1>// and contain a single "/" in-between.</c->
</pre>
     <i>— end Example</i> ].
     <p></p>
     <p><sup>5</sup> Each of the <i>dependency-family</i> and <i>single-dependency</i> shall have an implementation-defined meaning which establishes search information for implementation-defined <i>resources</i> (e.g., for 19.20 [const.res]).</p>
    </ins>
   </blockquote>
   <p>Append to §16.3.1 General [<strong>support.limits.general</strong>]'s <strong>Table 35</strong> one additional entry:</p>
   <blockquote>
    <table>
     <tbody>
      <tr>
       <th>Macro name
       <th>Value
      <tr>
       <td>
        <ins>__cpp_lib_embed</ins>
       <td>
        <ins>202006L</ins>
    </table>
   </blockquote>
   <p>Append to §19.1 General [<strong>utilities.general</strong>]'s <strong>Table 38</strong> one additional entry:</p>
   <blockquote>
    <table>
     <tbody>
      <tr>
       <th>
       <th>Subclause
       <th>Header(s)
      <tr>
       <td>
        <ins>19.20</ins>
       <td>
        <ins>Constant Resources</ins>
       <td>
        <ins>&lt;embed></ins>
    </table>
   </blockquote>
   <p>Add a new section §19.20 Constant Resources [<strong>const.res</strong>]:</p>
   <blockquote>
    <ins>
      <strong>19.20 Constant Resources</strong> [<strong>const.res</strong>] 
     <p><strong>19.20.1</strong> In general [<strong>const.res.general</strong>]</p>
     <p>Constant resources allow the implementation to retrieve data from a variety of sources -- including implementation-defined places -- and allows their processing during constant evaluation.</p>
     <p><strong>19.20.2</strong> Header <code class="highlight"><c- o>&lt;</c-><c- n>embed</c-><c- o>></c-></code> synopsis [<strong>embed.syn</strong>]</p>
<pre class="highlight"><c- k>namespace</c-> <c- n>std</c-> <c- p>{</c->

	<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>string_view</c-> <c- n>resource_identifier</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;::</c-><c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>string_view</c-> <c- n>resource_identifier</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;::</c-><c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

<c- p>}</c->
</pre>
     <p><strong>19.20.3</strong> Function template <code class="highlight"><c- n>embed</c-></code> [<strong>const.embed</strong>]</p>
<pre class="highlight"><c- k>namespace</c-> <c- n>std</c-> <c- p>{</c->
	<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>u8string_view</c-> <c- n>resource_identifier</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>u8string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>u8string_view</c-> <c- n>resource_identifier</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->

	<c- k>template</c-> <c- o>&lt;</c-><c- b>size_t</c-> <c- n>N</c-><c- p>,</c-> <c- k>typename</c-> <c- n>T</c-> <c- o>=</c-> <c- n>byte</c-><c- o>></c->
	<c- n>consteval</c-> <c- n>span</c-><c- o>&lt;</c-><c- k>const</c-> <c- n>T</c-><c- p>,</c-> <c- n>N</c-><c- o>></c-> <c- n>embed</c-><c- p>(</c-> <c- n>u8string_view</c-> <c- n>resource_identifier</c-><c- p>,</c-> <c- b>size_t</c-> <c- n>limit</c-> <c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->
<c- p>}</c->
</pre>
     <p><sup>1</sup> Mandates: the implementation-defined bit size of the resource is a multiple of <code class="highlight"><c- k>sizeof</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- o>*</c-> <c- n>CHAR_BIT</c-></code> and <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_trivial_v</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> is <code class="highlight">true</code>. If the <code class="highlight"><c- n>limit</c-></code> parameter is specified for the second or fourth overload, then then implementation-defined bit size of the resource must be less than or equal <code class="highlight"><c- n>limit</c-> <c- o>*</c-> <c- k>sizeof</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- o>*</c-> <c- n>CHAR_BIT</c-></code> and must be a multiple of <code class="highlight"><c- k>sizeof</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- o>*</c-> <c- n>CHAR_BIT</c-></code>. For the third and fourth overload, the implementation-defined bit size of the resource must be at least <code class="highlight"><c- k>sizeof</c-><c- p>(</c-><c- n>T</c-><c- p>)</c-> <c- o>*</c-> <c- n>CHAR_BIT</c-> <c- o>*</c-> <c- n>N</c-></code>.</p>
     <p><sup>3</sup> [ <i>Note—</i> <code class="highlight"><c- n>std</c-><c- o>::</c-><c- n>is_trivial_v</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> being true provides that types with non-trivial destructors do not need to be run for the implementation-provided static storage duration objects. <i>— end Note</i> ].</p>
     <p><sup>4</sup> If the implementation cannot find the resource specified after exhausting the sequence of implementation-defined search locations, or if the implementation finds the resource specified but that same resource was not named by a previous <code class="highlight"><c- cp>#depend</c-></code> directive in some manner, then the program is ill-formed.</p>
     <p><sup>5</sup> <i>Returns</i>: A read-only view to a unique resource identified by the <code class="highlight"><c- n>resource_identifier</c-></code> over a contiguous sequence of <code class="highlight"><c- n>T</c-></code> objects with static storage duration. The mapping from the contents of the resource to the contiguous sequence of <code class="highlight"><c- n>T</c-></code> objects is implementation-defined.</p>
     <p><sup>6</sup> <i>Ensures</i>: For the second overload, let <code class="highlight"><c- n>r</c-></code> denote the result of the function call. <code class="highlight"><c- n>r</c-><c- p>.</c-><c- n>size</c-><c- p>()</c-> <c- o>&lt;=</c-> <c- n>limit</c-></code> is true.</p>
     <p><sup>7</sup> <i>Remarks</i>: The value of <code class="highlight"><c- n>resource_identifier</c-></code> is used to search a sequence of implementation-defined places for a <i>resource</i> identified uniquely by <code class="highlight"><c- n>resource_identifier</c-></code>. The mapping of the resource to the sequence of <code class="highlight"><c- n>T</c-></code> is implementation-defined. [ <i>Note—</i> Implementations should provide a mechanism similar but not identical to <code class="highlight"><c- cp>#include</c-></code> (15.3 [cpp.include]) for finding the specified resource and in coordination with <code class="highlight"><c- cp>#depend</c-></code> (15.4 [cpp.depend]). <i>— end Note</i> ]</p>
    </ins>
   </blockquote>
   <h2 class="heading settled" data-level="8" id="appendix"><span class="secno">8. </span><span class="content">Appendix</span><a class="self-link" href="#appendix"></a></h2>
   <h3 class="heading settled" data-level="8.1" id="appendix-Alternative"><span class="secno">8.1. </span><span class="content">Alternative</span><a class="self-link" href="#appendix-Alternative"></a></h3>
   <p>Other techniques used include pre-processing data, link-time based tooling, and assembly-time runtime loading. They are detailed below, for a complete picture of today’s sad landscape of options.</p>
   <h4 class="heading settled" data-level="8.1.1" id="appendix-tools"><span class="secno">8.1.1. </span><span class="content">Pre-Processing Tools Alternative</span><a class="self-link" href="#appendix-tools"></a></h4>
   <ol>
    <li data-md>
     <p>Run the tool over the data (<code class="highlight"><c- n>xxd</c-> <c- o>-</c-><c- n>i</c-> <c- n>xxd_data</c-><c- p>.</c-><c- n>bin</c-> <c- o>></c-> <c- n>xxd_data</c-><c- p>.</c-><c- n>h</c-></code>) to obtain the generated file (<code class="highlight"><c- n>xxd_data</c-><c- p>.</c-><c- n>h</c-></code>):</p>
   </ol>
<pre class="language-cpp highlight"><c- b>unsigned</c-> <c- b>char</c-> <c- n>xxd_data_bin</c-><c- p>[]</c-> <c- o>=</c-> <c- p>{</c->
  <c- mh>0x48</c-><c- p>,</c-> <c- mh>0x65</c-><c- p>,</c-> <c- mh>0x6c</c-><c- p>,</c-> <c- mh>0x6c</c-><c- p>,</c-> <c- mh>0x6f</c-><c- p>,</c-> <c- mh>0x2c</c-><c- p>,</c-> <c- mh>0x20</c-><c- p>,</c-> <c- mh>0x57</c-><c- p>,</c-> <c- mh>0x6f</c-><c- p>,</c-> <c- mh>0x72</c-><c- p>,</c-> <c- mh>0x6c</c-><c- p>,</c-> <c- mh>0x64</c-><c- p>,</c->
  <c- mh>0x0a</c->
<c- p>};</c->
<c- b>unsigned</c-> <c- b>int</c-> <c- n>xxd_data_bin_len</c-> <c- o>=</c-> <c- mi>13</c-><c- p>;</c->
</pre>
   <ol>
    <li data-md>
     <p>Compile <code class="highlight"><c- n>main</c-><c- p>.</c-><c- n>cpp</c-></code>:</p>
   </ol>
<pre class="highlight"><c- cp>#include</c-> &lt;iostream>
<c- cp>#include</c-> &lt;string_view>

<c- c1>// prefix as constexpr,</c->
<c- c1>// even if it generates some warnings in g++/clang++</c->
<c- k>constexpr</c->
<c- cp>#include</c-> "xxd_data.h"
<c- p>;</c->

<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- n>T</c-><c- p>,</c-> <c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>N</c-><c- o>></c->
<c- k>constexpr</c-> <c- n>std</c-><c- o>::</c-><c- b>size_t</c-> <c- n>array_size</c-><c- p>(</c-><c- k>const</c-> <c- n>T</c-> <c- p>(</c-><c- o>&amp;</c-><c- p>)[</c-><c- n>N</c-><c- p>])</c-> <c- p>{</c->
    <c- k>return</c-> <c- n>N</c-><c- p>;</c->
<c- p>}</c->

<c- b>int</c-> <c- n>main</c-><c- p>()</c-> <c- p>{</c->
    <c- k>static_assert</c-><c- p>(</c-><c- n>xxd_data_bin</c-><c- p>[</c-><c- mi>0</c-><c- p>]</c-> <c- o>==</c-> <c- sc>'H'</c-><c- p>);</c->
    <c- k>static_assert</c-><c- p>(</c-><c- n>array_size</c-><c- p>(</c-><c- n>xxd_data_bin</c-><c- p>)</c-> <c- o>==</c-> <c- mi>13</c-><c- p>);</c->

    <c- n>std</c-><c- o>::</c-><c- n>string_view</c-> <c- n>data_view</c-><c- p>(</c->
        <c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- k>const</c-> <c- b>char</c-><c- o>*></c-><c- p>(</c-><c- n>xxd_data_bin</c-><c- p>),</c->
        <c- n>array_size</c-><c- p>(</c-><c- n>xxd_data_bin</c-><c- p>));</c->
    <c- n>std</c-><c- o>::</c-><c- n>cout</c-> <c- o>&lt;&lt;</c-> <c- n>data_view</c-> <c- o>&lt;&lt;</c-> <c- n>std</c-><c- o>::</c-><c- n>endl</c-><c- p>;</c-> <c- c1>// Hello, World!</c->
    <c- k>return</c-> <c- mi>0</c-><c- p>;</c->
<c- p>}</c->
</pre>
   <p>Others still use python or other small scripting languages as part of their build process, outputting data in the exact C++ format that they require.</p>
   <p>There are problems with the <code class="highlight"><c- n>xxd</c-> <c- o>-</c-><c- n>i</c-></code> or similar tool-based approach. Lexing and Parsing data-as-source-code adds an enormous overhead to actually reading and making that data available.</p>
   <p>Binary data as C(++) arrays provide the overhead of having to comma-delimit every single byte present, it also requires that the compiler verify every entry in that array is a valid literal or entry according to the C++ language.</p>
   <p>This scales poorly with larger files, and build times suffer for any non-trivial binary file, especially when it scales into Megabytes in size (e.g., firmware and similar).</p>
   <h4 class="heading settled" data-level="8.1.2" id="appendix-mongo"><span class="secno">8.1.2. </span><span class="content"><code class="highlight"><c- n>python</c-></code> Alternative</span><a class="self-link" href="#appendix-mongo"></a></h4>
   <p>Other companies are forced to create their own ad-hoc tools to embed data and files into their C++ code. MongoDB uses a <a href="https://github.com/mongodb/mongo/blob/master/site_scons/site_tools/jstoh.py">custom python script</a>, just to get their data into C++:</p>
<pre class="language-python highlight"><c- kn>import</c-> <c- nn>os</c->
<c- kn>import</c-> <c- nn>sys</c->

<c- k>def</c-> <c- nf>jsToHeader</c-><c- p>(</c-><c- n>target</c-><c- p>,</c-> <c- n>source</c-><c- p>):</c->
    <c- n>outFile</c-> <c- o>=</c-> <c- n>target</c->
    <c- n>h</c-> <c- o>=</c-> <c- p>[</c->
        <c- t>'#include "mongo/base/string_data.h"'</c-><c- p>,</c->
        <c- t>'#include "mongo/scripting/engine.h"'</c-><c- p>,</c->
        <c- t>'namespace mongo {'</c-><c- p>,</c->
        <c- t>'namespace JSFiles{'</c-><c- p>,</c->
    <c- p>]</c->
    <c- k>def</c-> <c- nf>lineToChars</c-><c- p>(</c-><c- n>s</c-><c- p>):</c->
        <c- k>return</c-> <c- t>','</c-><c- o>.</c-><c- n>join</c-><c- p>(</c->str<c- p>(</c->ord<c- p>(</c-><c- n>c</c-><c- p>))</c-> <c- k>for</c-> <c- n>c</c-> <c- ow>in</c-> <c- p>(</c-><c- n>s</c-><c- o>.</c-><c- n>rstrip</c-><c- p>()</c-> <c- o>+</c-> <c- t>'</c-><c- se>\n</c-><c- t>'</c-><c- p>))</c-> <c- o>+</c-> <c- t>','</c->
    <c- k>for</c-> <c- n>s</c-> <c- ow>in</c-> <c- n>source</c-><c- p>:</c->
        <c- n>filename</c-> <c- o>=</c-> str<c- p>(</c-><c- n>s</c-><c- p>)</c->
        <c- n>objname</c-> <c- o>=</c-> <c- n>os</c-><c- o>.</c-><c- n>path</c-><c- o>.</c-><c- n>split</c-><c- p>(</c-><c- n>filename</c-><c- p>)[</c-><c- mi>1</c-><c- p>]</c-><c- o>.</c-><c- n>split</c-><c- p>(</c-><c- t>'.'</c-><c- p>)[</c-><c- mi>0</c-><c- p>]</c->
        <c- n>stringname</c-> <c- o>=</c-> <c- t>'_jscode_raw_'</c-> <c- o>+</c-> <c- n>objname</c->

        <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- t>'constexpr char '</c-> <c- o>+</c-> <c- n>stringname</c-> <c- o>+</c-> <c- u>"[] = {"</c-><c- p>)</c->

        <c- k>with</c-> open<c- p>(</c-><c- n>filename</c-><c- p>,</c-> <c- t>'r'</c-><c- p>)</c-> <c- k>as</c-> <c- n>f</c-><c- p>:</c->
            <c- k>for</c-> <c- n>line</c-> <c- ow>in</c-> <c- n>f</c-><c- p>:</c->
                <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- n>lineToChars</c-><c- p>(</c-><c- n>line</c-><c- p>))</c->

        <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- u>"0};"</c-><c- p>)</c->
        <c- c1># symbols aren’t exported w/o this</c->
        <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- t>'extern const JSFile </c-><c- si>%s</c-><c- t>;'</c-> <c- o>%</c-> <c- n>objname</c-><c- p>)</c->
        <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- t>'const JSFile </c-><c- si>%s</c-><c- t> = { "</c-><c- si>%s</c-><c- t>", StringData(</c-><c- si>%s</c-><c- t>, sizeof(</c-><c- si>%s</c-><c- t>) - 1) };'</c-> <c- o>%</c->
                 <c- p>(</c-><c- n>objname</c-><c- p>,</c-> <c- n>filename</c-><c- o>.</c-><c- n>replace</c-><c- p>(</c-><c- t>'</c-><c- se>\\</c-><c- t>'</c-><c- p>,</c-> <c- t>'/'</c-><c- p>),</c-> <c- n>stringname</c-><c- p>,</c-> <c- n>stringname</c-><c- p>))</c->

    <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- u>"} // namespace JSFiles"</c-><c- p>)</c->
    <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- u>"} // namespace mongo"</c-><c- p>)</c->
    <c- n>h</c-><c- o>.</c-><c- n>append</c-><c- p>(</c-><c- u>""</c-><c- p>)</c->

    <c- n>text</c-> <c- o>=</c-> <c- t>'</c-><c- se>\n</c-><c- t>'</c-><c- o>.</c-><c- n>join</c-><c- p>(</c-><c- n>h</c-><c- p>)</c->

    <c- k>with</c-> open<c- p>(</c-><c- n>outFile</c-><c- p>,</c-> <c- t>'wb'</c-><c- p>)</c-> <c- k>as</c-> <c- n>out</c-><c- p>:</c->
        <c- k>try</c-><c- p>:</c->
            <c- n>out</c-><c- o>.</c-><c- n>write</c-><c- p>(</c-><c- n>text</c-><c- p>)</c->
        <c- k>finally</c-><c- p>:</c->
            <c- n>out</c-><c- o>.</c-><c- n>close</c-><c- p>()</c->


<c- k>if</c-> __name__ <c- o>==</c-> <c- u>"__main__"</c-><c- p>:</c->
    <c- k>if</c-> len<c- p>(</c-><c- n>sys</c-><c- o>.</c-><c- n>argv</c-><c- p>)</c-> <c- o>&lt;</c-> <c- mi>3</c-><c- p>:</c->
        <c- k>print</c-> <c- u>"Must specify [target] [source] "</c->
        <c- n>sys</c-><c- o>.</c-><c- n>exit</c-><c- p>(</c-><c- mi>1</c-><c- p>)</c->
    <c- n>jsToHeader</c-><c- p>(</c-><c- n>sys</c-><c- o>.</c-><c- n>argv</c-><c- p>[</c-><c- mi>1</c-><c- p>],</c-> <c- n>sys</c-><c- o>.</c-><c- n>argv</c-><c- p>[</c-><c- mi>2</c-><c- p>:])</c->
</pre>
   <p>MongoDB were brave enough to share their code with me and make public the things they have to do: other companies have shared many similar concerns, but do not have the same bravery. We thank MongoDB for sharing.</p>
   <h4 class="heading settled" data-level="8.1.3" id="appendix-ld"><span class="secno">8.1.3. </span><span class="content"><code class="highlight"><c- n>ld</c-></code> Alternative</span><a class="self-link" href="#appendix-ld"></a></h4>
   <p>A full, compilable example (except on Visual C++):</p>
   <ol start="0">
    <li data-md>
     <p>Have a file ld_data.bin with the contents <code class="highlight"><c- n>Hello</c-><c- p>,</c-> <c- n>World</c-><c- o>!</c-></code>.</p>
    <li data-md>
     <p>Run <code class="highlight"><c- n>ld</c-> <c- o>-</c-><c- n>r</c-> <c- n>binary</c-> <c- o>-</c-><c- n>o</c-> <c- n>ld_data</c-><c- p>.</c-><c- n>o</c-> <c- n>ld_data</c-><c- p>.</c-><c- n>bin</c-></code>.</p>
    <li data-md>
     <p>Compile the following <code class="highlight"><c- n>main</c-><c- p>.</c-><c- n>cpp</c-></code> with <code class="highlight"><c- n>c</c-><c- o>++</c-> <c- o>-</c-><c- n>std</c-><c- o>=</c-><c- n>c</c-><c- o>++</c-><c- mi>17</c-> <c- n>ld_data</c-><c- p>.</c-><c- n>o</c-> <c- n>main</c-><c- p>.</c-><c- n>cpp</c-></code>:</p>
   </ol>
<pre class="language-cpp highlight"><c- cp>#include</c-> &lt;iostream>
<c- cp>#include</c-> &lt;string_view>

<c- cp>#ifdef __APPLE__</c->
<c- cp>#include</c-> &lt;mach-o/getsect.h>

<c- cp>#define DECLARE_LD(NAME) extern const unsigned char _section$__DATA__##NAME[];</c->
<c- cp>#define LD_NAME(NAME) _section$__DATA__##NAME</c->
<c- cp>#define LD_SIZE(NAME) (getsectbyname("__DATA", "__" #NAME)->size)</c->

<c- cp>#elif (defined __MINGW32__) </c-><c- d>/* mingw */</c->

<c- cp>#define DECLARE_LD(NAME)                                 \</c->
<c- cp>	extern const unsigned char binary_##NAME##_start[]; \</c->
<c- cp>	extern const unsigned char binary_##NAME##_end[];</c->
<c- cp>#define LD_NAME(NAME) binary_##NAME##_start</c->
<c- cp>#define LD_SIZE(NAME) ((binary_##NAME##_end) - (binary_##NAME##_start))</c->

<c- cp>#else </c-><c- d>/* gnu/linux ld */</c->

<c- cp>#define DECLARE_LD(NAME)                                  \</c->
<c- cp>	extern const unsigned char _binary_##NAME##_start[]; \</c->
<c- cp>	extern const unsigned char _binary_##NAME##_end[];</c->
<c- cp>#define LD_NAME(NAME) _binary_##NAME##_start</c->
<c- cp>#define LD_SIZE(NAME) ((_binary_##NAME##_end) - (_binary_##NAME##_start))</c->
<c- cp>#endif</c->

<c- n>DECLARE_LD</c-><c- p>(</c-><c- n>ld_data_bin</c-><c- p>);</c->

<c- b>int</c-> <c- nf>main</c-><c- p>()</c-> <c- p>{</c->
	<c- c1>// impossible</c->
	<c- c1>//static_assert(xxd_data_bin[0] == 'H');</c->
	<c- n>std</c-><c- o>::</c-><c- n>string_view</c-> <c- n>data_view</c-><c- p>(</c->
		<c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- k>const</c-> <c- b>char</c-><c- o>*></c-><c- p>(</c-><c- n>LD_NAME</c-><c- p>(</c-><c- n>ld_data_bin</c-><c- p>)),</c-> 
		<c- n>LD_SIZE</c-><c- p>(</c-><c- n>ld_data_bin</c-><c- p>)</c->
	<c- p>);</c->
	<c- n>std</c-><c- o>::</c-><c- n>cout</c-> <c- o>&lt;&lt;</c-> <c- n>data_view</c-> <c- o>&lt;&lt;</c-> <c- n>std</c-><c- o>::</c-><c- n>endl</c-><c- p>;</c-> <c- c1>// Hello, World!</c->
	<c- k>return</c-> <c- mi>0</c-><c- p>;</c->
<c- p>}</c->
</pre>
   <p>This scales a little bit better in terms of raw compilation time but is shockingly OS, vendor and platform specific in ways that novice developers would not be able to handle fully. The macros are required to erase differences, lest subtle differences in name will destroy one’s ability to use these macros effectively. We omitted the code for handling VC++ resource files because it is excessively verbose than what is present here.</p>
   <p>N.B.: Because these declarations are <code class="highlight"><c- k>extern</c-></code>, the values in the array cannot be accessed at compilation/translation-time.</p>
   <h2 class="heading settled" data-level="9" id="acknowledgements"><span class="secno">9. </span><span class="content">Acknowledgements</span><a class="self-link" href="#acknowledgements"></a></h2>
   <p>A big thank you to Andrew Tomazos for replying to the author’s e-mails about the prior art. Thank you to Arthur O’Dwyer for providing the author with incredible insight into the Committee’s previous process for how they interpreted the Prior Art.</p>
   <p>A special thank you to Agustín Bergé for encouraging the author to talk to the creator of the Prior Art and getting started on this. Thank you to Tom Honermann for direction and insight on how to write a paper and apply for a proposal.</p>
   <p>Thank you to Arvid Gerstmann for helping the author understand and use the link-time tools.</p>
   <p>Thank you to Tony Van Eerd for valuable advice in improving the main text of this paper.</p>
   <p>Thank you to Lilly (Cpplang Slack, @lillypad) for the valuable bikeshed and hole-poking in original designs, alongside Ben Craig who very thoroughly explained his woes when trying to embed large firmware images into a C++ program for deployment into production. Thank you to Elias Kounen and Gabriel Ravier for wording review.</p>
   <p>For all this hard work, it is the author’s hope to carry this into C++. It would be the author’s distinct honor to make development cycles easier and better with the programming language we work in and love. ♥</p>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-circle-embed-tweet">[CIRCLE-EMBED-TWEET]
   <dd>Sean Baxter. <a href="https://twitter.com/seanbax/status/1205195567003045888">@embed added to Circle</a>. URL: <a href="https://twitter.com/seanbax/status/1205195567003045888">https://twitter.com/seanbax/status/1205195567003045888</a>
   <dt id="biblio-clang-large-init-bug">[CLANG-LARGE-INIT-BUG]
   <dd>LLVM Foundation. <a href="https://bugs.llvm.org/show_bug.cgi?id=44399">Memory Consumption Reduction for Large Array Initialization?</a>. URL: <a href="https://bugs.llvm.org/show_bug.cgi?id=44399">https://bugs.llvm.org/show_bug.cgi?id=44399</a>
   <dt id="biblio-constexpr-all-the-things">[CONSTEXPR-ALL-THE-THINGS]
   <dd>Ben Deane; Jason Turner. <a href="https://www.youtube.com/watch?v=PJwd4JLYJJY">constexpr All The Things: CppCon 2017</a>. September 25th, 2017. URL: <a href="https://www.youtube.com/watch?v=PJwd4JLYJJY">https://www.youtube.com/watch?v=PJwd4JLYJJY</a>
   <dt id="biblio-gcc-large-init-bug-c">[GCC-LARGE-INIT-BUG-C]
   <dd>GCC. <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245">[8/9/10 regression] Uses lots of memory when compiling large initialized arrays</a>. URL: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245</a>
   <dt id="biblio-gcc-large-init-bug-cpp">[GCC-LARGE-INIT-BUG-CPP]
   <dd>GCC. <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179">[8/9/10 regression] Uses lots of memory when compiling large initialized arrays</a>. URL: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179</a>
   <dt id="biblio-incbin">[INCBIN]
   <dd>Dale Weiler (graphitemaster). <a href="https://github.com/graphitemaster/incbin">incbin: load files at 'assembly' time</a>. URL: <a href="https://github.com/graphitemaster/incbin">https://github.com/graphitemaster/incbin</a>
   <dt id="biblio-n4778">[N4778]
   <dd>Richard Smith. <a href="https://wg21.link/n4778">Working Draft, Standard for Programming Language C++</a>. 8 October 2018. URL: <a href="https://wg21.link/n4778">https://wg21.link/n4778</a>
   <dt id="biblio-n4842">[N4842]
   <dd>ISO/IEC JTC1/SC22/WG21 - The C++ Standards Committee; Richard Smith. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4842.pdf">N4778 - Working Draft, Standard for Programming Language C++</a>. November 27th, 2019. URL: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4842.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4842.pdf</a>
   <dt id="biblio-nonius-visual-c-error">[NONIUS-VISUAL-C-ERROR]
   <dd>R. Martinho Fernandes. <a href="https://github.com/libnonius/nonius/blob/devel/include/nonius/reporters/html_reporter.h%2B%2B#L42">nonius generated HTML Reporter</a>. September 1st, 2016. URL: <a href="https://github.com/libnonius/nonius/blob/devel/include/nonius/reporters/html_reporter.h%2B%2B#L42">https://github.com/libnonius/nonius/blob/devel/include/nonius/reporters/html_reporter.h%2B%2B#L42</a>
   <dt id="biblio-p0373r0">[P0373R0]
   <dd>Andrew Tomazos. <a href="https://wg21.link/p0373r0">Proposal of File Literals</a>. 21 May 2016. URL: <a href="https://wg21.link/p0373r0">https://wg21.link/p0373r0</a>
   <dt id="biblio-p0466r1">[P0466R1]
   <dd>Lisa Lippincott. <a href="https://wg21.link/p0466r1">Layout-compatibility and Pointer-interconvertibility Traits</a>. 12 February 2018. URL: <a href="https://wg21.link/p0466r1">https://wg21.link/p0466r1</a>
   <dt id="biblio-p1130">[P1130]
   <dd>JeanHeyd Meneide. <a href="https://thephd.github.io/vendor/future_cxx/papers/d1130.html">Module Resource Requirement Propagation</a>. November 26th, 2018. URL: <a href="https://thephd.github.io/vendor/future_cxx/papers/d1130.html">https://thephd.github.io/vendor/future_cxx/papers/d1130.html</a>
  </dl>