On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu
wrote:
On 3/16/15 9:29 AM, Baz wrote:
On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
Walter Bright:
Unfortunately, it needs to be a dropin replacement for
x"...", which
returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a
string/wstring/dstring
out of a hex string:
https://issues.dlang.org/show_bug.cgi?id=10454
https://issues.dlang.org/show_bug.cgi?id=5909
Bye,
bearophile
this is the API that's about to be proposed, it named as
suggested by
A.A., and it handles the two issues you point out:
---
public string hexString(string hexData, bool putWhites =
false)()
public string hexString(dstring hexData, bool putWhites =
false)()
public string hexString(wstring hexData, bool putWhites =
false)()
public ubyte[] hexBytes(string hexData)()
public ubyte[] hexBytes(dstring hexData)()
public ubyte[] hexBytes(wstring hexData)()
---
(Drop the "public", this ain't Java.)
I don't see a necessity for the input string having different
widths; string is enough. There may be a necessity to choose
the width of the output with changes in function name, e.g.
hexWString and hexDString.
That opens the question whether we want only ubyte[] for hex
bytes or all integral types.
additionally to x string, a template parameter allows to put
raw whites,
e.g
---
assert(hexString!("30 30", true) == "0 1");
assert(hexString!("30 31") == "01"); // standard x string
---
I don't see a need for this.
Andrei
I'd like to propose this:
http://dpaste.dzfl.pl/044958878fd9
But after reading D.Nadlinger mind about the whole thing i
realize that's the opposite the things should be done in the
opposite way.
