On 2/11/18 4:48 PM, Walter Bright wrote:
I also notice that hex strings are not simply equivalent to strings
with \x in them -- the latter is more constrained, as it must be a
pair of hex digits per \x. hex strings allow spaces between them.
The idea was to be able to cut&paste text from things like hex dumps,
which include whitespace formatting.
I've never seen a hex dump where the individual nibbles were separated
by spaces in odd ways.
In other words, what I was saying is that:
"\x12\x34"
could be written as:
x"1 23 4"
which is... odd. What it does is make it so you can't reuse the parsing
code inside the string escape processor to handle the hex string,
necessitating an extra 80-line function.
I wouldn't call invoking CTFE "no overhead"
It is no overhead in the generated code.
It's overhead that adds up, memory and time-wise. Really, the memory
concerns of using CTFE are a bigger problem than the extra tenths of a
second of compile time.
I tested it out, and generating a hex string of about 600 bytes took
3x as long as using builtin hex strings.
That's only a potential issue if you've got a very, very large number of
hex strings. And if you do, those strings can be put in a separate
module and compiled separately.
Or a very large hex string (very feasible). But very true that there are
mitigating methods that can be used.
Well, nobody asked :) Besides, it's still not "fixed", as it has the
same poor performance as the previous version. And the new version has
broken existing code.
It didn't break code that used x"deadbeef", it broke code that used the
broken hexString.
In the past, we have not broken code, even when it depends on known
bugs, if we can help it. But maybe if we can fix the bug I filed above,
it won't matter.
What the update shows is that you have to jump through incredible
hoops to get the compiler not to include your compile-time only
generation code in the resulting binary.
With a language that supports both templates and separate compilation,
this will always be an issue.
Essentially, you have instantiated the template eagerly, which kind of,
sort of, defeats the purpose of a template. Though, you still do get the
benefit of code generation, it's just not an "open-ended" template that
you can instantiate with any type. Perhaps we should be using this
pattern all throughout phobos where strings are involved, since there
are ever only 3 types you instantiate with.
The solution here is not "incredible", it is just not obvious.
The solution isn't incredible, but the fact that this solution is the
only way to get the CTFE-only code not to creep into your object file is
a bit dissatisfying. You would think the linker/compiler would not
inject the unused function into the object file without having to do this.
And nothing has changed here, it's still a library function, as it was
before.
What's changed is it works now with -betterC, and it doesn't produce
bloat in the executable.
I think this is due to functions-that-aren't-used being included.
In other words, there was nothing inherent in the old library code that
created a requirement for druntime to be included.
The bloat is also a deficiency of the compiler, not the code itself.
But if you already have the compiler feature, I don't see why we
should remove it because a slower library version exists.
It was not an arbitrary and capricious decision, and the rationale
behind it was presented here multiple times. If you are not convinced,
that's cool, but the "why" should be pretty clear.
I missed the discussion (there are times where I can't pay attention to
D for a month or so due to being busy). But in any case, sure I
understand the "why", but the cost/benefit for me was not high enough,
and in some aspects, it is all cost, no benefit.
In any case, it isn't a decision that needs to be reversed, as there is
a workable solution in the library, even if it's sub-optimal. I just
think it's not as beneficial as has been reported.
-Steve
