On Sunday, 19 September 2021 at 02:18:20 UTC, Steven
Schveighoffer wrote:
```d
// option 1
output[p++] = (ulong(w - e) + 3) % 40;
// option 2
output[p++] = cast(char)(((w - e) + 3) % 40);
```
Remember also, `char` is C's only way to say "byte". So this
may just be data, and not unicode
On 9/18/21 5:16 PM, frame wrote:
On Saturday, 18 September 2021 at 18:48:07 UTC, Steven Schveighoffer wrote:
Did you mean "long to char" cast? In that case, yes, you have to cast it.
Note, `out` is a keyword, it can't be used as a variable, but you
probably already figured that out. But if
On 9/18/21 5:20 PM, frame wrote:
On Saturday, 18 September 2021 at 21:16:13 UTC, frame wrote:
On Saturday, 18 September 2021 at 18:48:07 UTC, Steven Schveighoffer
wrote:
Are you defining the prototype for strchr yourself instead of
importing it from core.stdc.string?
Not really :D but
On Saturday, 18 September 2021 at 21:16:13 UTC, frame wrote:
On Saturday, 18 September 2021 at 18:48:07 UTC, Steven
Schveighoffer wrote:
Are you defining the prototype for strchr yourself instead of
importing it from core.stdc.string?
Not really :D but without cast it complains:
```
Error:
On Saturday, 18 September 2021 at 18:48:07 UTC, Steven
Schveighoffer wrote:
Are you defining the prototype for strchr yourself instead of
importing it from core.stdc.string?
Not really :D but without cast it complains:
```
Error: cannot implicitly convert expression strchr(e, cast(int)c)
of
On 9/18/21 12:52 PM, frame wrote:
There were also parts where the pointer is used in calculations - which
is accepted by the compiler - it just complains about implicitly `long`
to `char*` cast:
```
// const char *e
// char *w
out[p++] = ((w - e) + 3) % 40;
```
Did you mean "long to char"
On 9/18/21 12:52 PM, frame wrote:
On Saturday, 18 September 2021 at 11:47:52 UTC, Steven Schveighoffer wrote:
Have you tried:
```d
const(char)* s2 = "...";
```
This will work because string literals are zero terminated and
implicitly castable to `immutable(char)*`, which will also
On Saturday, 18 September 2021 at 11:47:52 UTC, Steven
Schveighoffer wrote:
Have you tried:
```d
const(char)* s2 = "...";
```
This will work because string literals are zero terminated and
implicitly castable to `immutable(char)*`, which will also
implicitly cast to `const(char)*`.
That
On 9/18/21 5:40 AM, frame wrote:
On Friday, 17 September 2021 at 14:29:23 UTC, Steven Schveighoffer wrote:
Looking at that signature, it does not appear that it uses
zero-termination at all, as it takes a length. So using `dup` and
therefore the gc is totally unnecessary.
I'm assuming that
On Friday, 17 September 2021 at 14:29:23 UTC, Steven
Schveighoffer wrote:
Looking at that signature, it does not appear that it uses
zero-termination at all, as it takes a length. So using `dup`
and therefore the gc is totally unnecessary.
I'm assuming that string is the barcode argument?
On 9/17/21 2:27 AM, frame wrote:
On Thursday, 16 September 2021 at 18:02:44 UTC, Steven Schveighoffer wrote:
Are you sure? Be very pedantic about what C functions do with the data
you send it. Sometimes they store it somewhere to use later. Sometimes
they expect it to be allocated by the C
On Friday, 17 September 2021 at 06:58:01 UTC, jfondren wrote:
On Friday, 17 September 2021 at 06:27:40 UTC, frame wrote:
Thanks, I'm just careful with casting.
Does it really allocate from a literal if it's used on the
stack only? Is `-vgc` switch reliable?
looks to me like it calls
...
On Friday, 17 September 2021 at 06:27:40 UTC, frame wrote:
Thanks, I'm just careful with casting.
Does it really allocate from a literal if it's used on the
stack only? Is `-vgc` switch reliable?
looks to me like it calls
```d
// object
private U[] _dup(T, U)(scope T[] a) pure nothrow
On Thursday, 16 September 2021 at 18:02:44 UTC, Steven
Schveighoffer wrote:
Are you sure? Be very pedantic about what C functions do with
the data you send it. Sometimes they store it somewhere to use
later. Sometimes they expect it to be allocated by the C heap,
etc.
Without seeing how
On 9/16/21 1:08 PM, frame wrote:
On Thursday, 16 September 2021 at 15:34:25 UTC, Steven Schveighoffer wrote:
`dup` is a GC allocation. Are you using that in your C code? the GC
might be collecting that string.
The compiler doesn't show that lines with -vgc. Maybe it knows that it
is only
On Thursday, 16 September 2021 at 15:34:25 UTC, Steven
Schveighoffer wrote:
`dup` is a GC allocation. Are you using that in your C code?
the GC might be collecting that string.
The compiler doesn't show that lines with -vgc. Maybe it knows
that it is only stack allocated?
Technically, the
On 9/16/21 6:28 AM, frame wrote:
I have C-code translated in D that acts sometimes incorrect if the GC
has made some collect. I would like to know why.
- Code runs correct if the GC collections are off
- There are no allocations within the C-translated-code except `throw
new` (but they are
On Thursday, 16 September 2021 at 11:35:27 UTC, frame wrote:
On Thursday, 16 September 2021 at 11:11:56 UTC, bauss wrote:
On Thursday, 16 September 2021 at 11:06:04 UTC, frame wrote:
On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:
Use toStringz and not .ptr.
Or append \0 to
On Thursday, 16 September 2021 at 11:11:56 UTC, bauss wrote:
On Thursday, 16 September 2021 at 11:06:04 UTC, frame wrote:
On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:
Use toStringz and not .ptr.
Or append \0 to your string.
Stupid me should really know that already, thanks
On Thursday, 16 September 2021 at 11:06:04 UTC, frame wrote:
On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:
Use toStringz and not .ptr.
Or append \0 to your string.
Stupid me should really know that already, thanks =)
Of course I have dup'ed the \0 from the string away...
On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:
Use toStringz and not .ptr.
Or append \0 to your string.
Stupid me should really know that already, thanks =)
Of course I have dup'ed the \0 from the string away...
But still I don't know why it works if the GC is off?
On Thursday, 16 September 2021 at 10:48:19 UTC, bauss wrote:
On Thursday, 16 September 2021 at 10:28:37 UTC, frame wrote:
I have C-code translated in D that acts sometimes incorrect if
the GC has made some collect. I would like to know why.
- Code runs correct if the GC collections are off
-
On Thursday, 16 September 2021 at 10:28:37 UTC, frame wrote:
I have C-code translated in D that acts sometimes incorrect if
the GC has made some collect. I would like to know why.
- Code runs correct if the GC collections are off
- There are no allocations within the C-translated-code except
I have C-code translated in D that acts sometimes incorrect if
the GC has made some collect. I would like to know why.
- Code runs correct if the GC collections are off
- There are no allocations within the C-translated-code except
`throw new` (but they are not called)
- All allocations made
24 matches
Mail list logo
