On 2/8/18 1:10 AM, Walter Bright wrote:
On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code generated by the hex literals.  hexString!"deadbeef" stores the null-terminated string in the data section of the object file, while x"deadbeef" only stores 4 bytes in the data section.

   string s = x"deadbeef";

stores a null terminated string, too.

If you want only 4 bytes,

   __gshared immutable char[4] = hexString!"deadbeef";

just as you'd do for any string literal.

The extra data in the object file comes from the inclusion of the hexStringImpl function, and from the template parameter (the symbol _D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well, which will always be larger than the actual string passed to hexString).

I also see the data in there twice for some reason.


Reply via email to