On Monday, 26 June 2023 at 12:28:15 UTC, Jonathan M Davis wrote:
On Monday, June 26, 2023 5:08:06 AM MDT Cecil Ward via
Digitalmars-d-learn wrote:
On Monday, 26 June 2023 at 08:26:31 UTC, Jonathan M Davis
wrote:
> On Sunday, June 25, 2023 4:08:19 PM MDT Cecil Ward via
>
> Digitalmars-d-learn wrote:
>> I recently had some problems
>>
>> dchar[] arr = [ ‘ ‘, TAB, CR, LF … ];
>>
>> and I got errors from the compiler which led to me having to
>> count the elements in the initialiser and declare the array
>> with
>> an explicit size. I don’t want the array to be mutable so I
>> later
>> added immutable to it, but that didn’t help matters. At one
>> point, because the array was quite long, I got the arr[
>> n_elements ] number wrong, it was too small and the
>> remainder
>> of
>> the array was full of 0xffs (or something), which was good,
>> helped me spot the bug.
>>
>> Is there any way to get the compiler to count the number of
>> elements in the initialiser and set the array to that size
>> ? And it’s immutable.
>
> Without seeing the errors, I can't really say what the
> problem was, but most character literals are going to be
> char, not dchar, so you may have had issues related to the
> type that the compiler was inferring for the array literal.
> I don't recall at the moment how exactly the compiler
> decides the type of an array literal when it's given values
> of differing types for the elements.
>
> Either way, if you want a static array, and you don't want
> to have to count the number of elements, then
> https://dlang.org/phobos/std_array.html#staticArray should
> take care of that problem.
>
> - Jonathan M Davis
Where I used symbolic names, such as TAB, that was defined as
an
int (or uint)
enum TAB = 9;
or
enum uint TAB = 9;
I forget which. So I had at least one item that was typed
something wider than a char.
I tried the usual sizeof( arr )/ sizeof dchar, compiler
wouldn’t
have that for some reason, and yes I know it should be D
syntax,
god how I long for C sizeof()!
sizeof is a property in D. So, you can do char.sizeof or
varName.sizeof. But regardless, there really is no reason to
use sizeof with D arrays under normal circumstances. And in the
case of dynamic arrays, sizeof will give you the size of the
dynamic array itself, not the slice of memory that it refers
to. You're essentially using sizeof on
struct DynamicArray(T)
{
size_t length;
T* ptr;
}
which is not going to tell you anything about the memory it
points to. The length property of an array already tells you
the length of the array (be it static or dynamic), so using
sizeof like you're talking about really does not apply to D.
And I wouldn't advise using uint for a character in D. That's
what char, wchar, and dchar are for. Depending on the
circumstances, you get implicit conversions between character
and integer types, but they are distinct types, and mixing and
matching them willy-nilly could result in compilation errors
depending on what your code is doing.
- Jonathan M Davis
No, point taken, a sloppy example. I don’t in fact do that in the
real code. I use dchar everywhere appropriate instead of uint. In
fact I have aliases for dstring and dchar and successfully did an
alternative build with the aliases renamed to use 16-bits wchar /
w string instead of 32-bits and rebuilt and all was well, just to
test that it is code word size-independent. I would need to do
something different though if I ever decided to change to use
16-bit code words in memory because I would still be wanting to
manipulate 32-bit values for char code points when they are being
handled in registers, for efficiency too as well as code
correctness, as 16-bit ‘partial words’ are bad news for
performance on x86-64. I perhaps ought to introduce a new alias
called codepoint, which is always 32-bits, to distinguish dchar
in registers from words in memory. It turns out that I can get
away with not caring about utf16, as I’m merely _scanning_ a
string. I couldn’t ever get away with changing the in-memory code
word type to be 8-bit chars, and then using utf8 though, as I do
occasionally deal with non-ASCII characters, and I would have to
either preconvert the Utf8 to do the decoding, or parse 8-bit
code words and handle the decoding myself on the fly which would
be madness. If I have to handle utf8 data I will just preconvert
it.
