Re: Extract base type of any array?
On Sunday, 19 September 2021 at 03:58:41 UTC, Kirill wrote:
How can I get the base type of any
(multidimensional/static/dynamic/associative) array?
Example:
```
void main() {
int[][] intArr;
double[4][] doubleArr;
string[string][] strArr;
intArr.example; // T = int
doubleArr.example; // T = double
strArr.example; // T = string
}
void example(T)(<...> data) {
// extract the base of data (inside func's body or in <...>)
// preferably, T must become data's base type
}
```
This almost works, but as `string` is an array type it needs some
kind of rule to stop there:
```d
unittest {
int[] intArr;
double[4][] doubleArr;
string[string][][] strArr;
assert(is(BaseType!(typeof(intArr)) == int));
assert(is(BaseType!(typeof(doubleArr)) == double));
assert(is(BaseType!(typeof(strArr)) == immutable(char)));
}
template BaseType(T) {
static if (__traits(isStaticArray, T))
alias BaseType = BaseType!(typeof(T.init[0]));
else static if (is(T == U[], U))
alias BaseType = BaseType!U;
else static if (is(T == V[K], K, V))
alias BaseType = BaseType!V;
else
alias BaseType = T;
}
```
mix of BaseType!T from core.internal.array.equality and rank!T
from Philippe Sigaud's D Templates Tutorial at
https://github.com/PhilippeSigaud/D-templates-tutorial
Extract base type of any array?
How can I get the base type of any
(multidimensional/static/dynamic/associative) array?
Example:
```
void main() {
int[][] intArr;
double[4][] doubleArr;
string[string][] strArr;
intArr.example; // T = int
doubleArr.example; // T = double
strArr.example; // T = string
}
void example(T)(<...> data) {
// extract the base of data (inside func's body or in <...>)
// preferably, T must become data's base type
}
```
Re: GC seems to crash my C-code function
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 `out` here is a `char *`, then yes, you need a cast there. Yes, of course. `out(put)` is a `char[6]` here. So here is why you need a cast: First, the code is doing math on 2 pointers, which returns a `ptrdiff_t`, a.k.a. `long` in 64-bits. Second, you are using mod 40, which is great, because D will recognize that the range of values must be within 40! However, since it's signed, that's -40 to 40. Which doesn't fit in a `char` (which is unsigned). D does not allow an implicit narrowing conversion. Since -40 to -1 won't fit into a char (dubious anyway for char to be an integer IMO), you need a cast. So my recommendation is shoehorn it into ulong to take away the sign before the mod, or cast to char at the end. Is there any chance that `w` is less than `e`? if so, do NOT use the first option. ```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 data. You may want to consider using `ubyte` in your translation instead of `char`. But wait until your code is compiling and working as it did in C. -Steve
Re: GC seems to crash my C-code function
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 without cast it complains: ``` Error: cannot implicitly convert expression strchr(e, cast(int)c) of type const(char)* to char* ``` But I guess it's because it tries to assign to a `char*` therefore inout() doesn't work. Well, the variable you are assigning it to should be a `const char *` if the source variable is a `const char *`. Possibly, the C code didn't mark it as `const char *`, because I'm pretty sure C has `strchr` being: `char * strchr(const char *, int)` Because, you know, const doesn't matter in C ;) If that doesn't work, then you *may* need to start allocating. But I'd try that first. -Steve
Re: How to do "C++ classes"?
On Saturday, 18 September 2021 at 15:38:38 UTC, rempas wrote:
I'm seeing in the page about "BeterC" and in the part about the
[retained
features](https://dlang.org/spec/betterc.html#retained), the
#11 says about "COM classes and C++ classes". What are the "C++
classes"? I tried to create a class using "extern(C++)" but
this didn't worked. Can someone make an example on that?
extern(C++)
class Foo {}
void main() {
scope Foo foo = new Foo();
}
Re: GC seems to crash my C-code function
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: cannot implicitly convert expression strchr(e, cast(int)c) of type const(char)* to char* ``` But I guess it's because it tries to assign to a `char*` therefore inout() doesn't work.
Re: MobI? Really?
El 18/9/21 a les 22:40, Chris_D via Digitalmars-d-learn ha escrit: The "D Programming Language Specification" seems to be the most important documentation for D. Is it really only available as Mobi? That is the most bizarre choice of format I've ever seen. Chris https://d-apt.sourceforge.io/
Re: GC seems to crash my C-code function
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 type const(char)* to char* ``` 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 `out` here is a `char *`, then yes, you need a cast there. -Steve Yes, of course. `out(put)` is a `char[6]` here.
Re: MobI? Really?
On Saturday, 18 September 2021 at 20:40:56 UTC, Chris_D wrote: The "D Programming Language Specification" seems to be the most important documentation for D. Is it really only available as Mobi? That is the most bizarre choice of format I've ever seen. Chris No, it's not *only* available as mobi. It's also right here: https://dlang.org/spec/spec.html
MobI? Really?
The "D Programming Language Specification" seems to be the most important documentation for D. Is it really only available as Mobi? That is the most bizarre choice of format I've ever seen. Chris
Re: GC seems to crash my C-code function
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" 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 `out` here is a `char *`, then yes, you need a cast there. -Steve
Re: GC seems to crash my C-code function
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 implicitly cast to `const(char)*`. That should allow s2 to be reassigned but not modify the data. IIRC, string literal data even in C is put into a read-only section by many compilers, so the code shouldn't be changing it. ... The first rule of porting -- just translate, don't change anything. I would try to do exactly what C does without using the GC at all. Continue to use malloc/free. If you have issues with type representation, you may need to adjust for that. This is what I try to achieve - not to change much. But I see there is a mistake by me, s2 __is__ const in the original C-code too. Unfortunately, with `const(char)*`, `strchr()` did complain and then I would have to cast it to `char*` - so I didn't used it in first place because I really thought `.dup` wouldn't allocate here. `dup` definitely allocates. But when I look at the [dlang docs for strchr](https://dlang.org/phobos/core_stdc_string.html#.strchr), it properly adds the `inout` type modifier which should correct that problem. Are you defining the prototype for `strchr` yourself instead of importing it from `core.stdc.string`? 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; ``` Why doesn't the compiler complain about `char* - const(char)*`? `long` doesn't implicitly cast to `char *`. But of course, subtracting two pointers works for the same base type. Note that `long` in C is *not the same* as `long` in D. You should take a look at https://dlang.org/spec/interfaceToC.html#data_type_compat -Steve
Re: GC seems to crash my C-code function
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 should allow s2 to be reassigned but not modify the data. IIRC, string literal data even in C is put into a read-only section by many compilers, so the code shouldn't be changing it. ... The first rule of porting -- just translate, don't change anything. I would try to do exactly what C does without using the GC at all. Continue to use malloc/free. If you have issues with type representation, you may need to adjust for that. This is what I try to achieve - not to change much. But I see there is a mistake by me, s2 __is__ const in the original C-code too. Unfortunately, with `const(char)*`, `strchr()` did complain and then I would have to cast it to `char*` - so I didn't used it in first place because I really thought `.dup` wouldn't allocate here. 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; ``` Why doesn't the compiler complain about `char* - const(char)*`?
How to do "C++ classes"?
I'm seeing in the page about "BeterC" and in the part about the [retained features](https://dlang.org/spec/betterc.html#retained), the #11 says about "COM classes and C++ classes". What are the "C++ classes"? I tried to create a class using "extern(C++)" but this didn't worked. Can someone make an example on that?
Re: yet another segfault - array out of bound is not caught by try catch
Double check in your dub.json file and see if you haven't changed your buildoptions DEBUG: it's caught: https://run.dlang.io/is/F8HkD8 RELEASE: segfault as expected: https://run.dlang.io/is/oLU2M3 And make sure to use latest version of ldc
Re: What is the meaning of @future ?
On 9/18/21 1:27 AM, evilrat wrote: > IIRC they went out of business for inability to compete Yes, but not Sociomantic but Dunhumby[1], who had acquired Sociomantic, shut down that business because of changes in the ad market. Ali
Re: What is the meaning of @future ?
On 9/18/21 7:49 AM, Steven Schveighoffer wrote: add buys "ad buys" of course :P -Steve
Re: GC seems to crash my C-code function
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 string is the barcode argument? No, the string appears inside the C-function. I'm calling the function with .ptr and the .length property as it expects. Oh wow, I totally misunderstood what you are doing. I thought you were *calling* that function, but you are *reimplementing* that code in D. 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 should allow s2 to be reassigned but not modify the data. IIRC, string literal data even in C is put into a read-only section by many compilers, so the code shouldn't be changing it. Now that I understand what you are doing, it becomes clear that this isn't a situation of C code being called. Or are you calling other parts of the C library with that translated function? The first rule of porting -- just translate, don't change anything. I would try to do exactly what C does without using the GC at all. Continue to use malloc/free. If you have issues with type representation, you may need to adjust for that. -Steve
Re: What is the meaning of @future ?
On 9/18/21 4:02 AM, Dylan Graham wrote: On Friday, 17 September 2021 at 14:37:29 UTC, Meta wrote: On Friday, 17 September 2021 at 10:31:34 UTC, bauss wrote: On Thursday, 16 September 2021 at 20:53:34 UTC, Elmar wrote: [...] It's just another "useless" attribute that the language has added before fixing any of the real problems :) Basically it reserves a symbol for the future. It's similar to creating ex. an empty function that throws an error or something like "Not implemented" While I understand why it was added and what purpose it serves then I fail to see why that was prioritized over actual issues. It's solving an almost non-existing issue. I think the main reason it was added is because Sociomantic asked for it, but they are of course not around anymore. Off topic: what happened to them, out of curiosity? Google changed the rules for add buys. Which either killed their business model, or made them far less competitive than they were originally. -Steve
Re: Program crash: GC destroys an object unexpectedly
On Saturday, 18 September 2021 at 09:39:24 UTC, eugene wrote: The definition of this struct was taken from /usr/include/dmd/druntime/import/core/sys/linux/epoll.d ... If the reason for crash was in EpollEvent alignment, programs would segfaults always very soon after start, just right after the very first return from epoll_wait(). The struct's fine as far as libc and the kernel are concerned. epoll_wait is not even using those 64 bits or interpreting them as containing any kind of data, it's just moving them around for the caller to use. It's also not a hardware error to interpret those bits where they are as a pointer. They are however not 64-bit aligned so D's GC is collecting objects that only they point to.
Re: GC seems to crash my C-code function
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? No, the string appears inside the C-function. I'm calling the function with .ptr and the .length property as it expects. The `-vgc` switch appears to only identify allocations that the compiler invokes via hooks, not ones that other functions invoke (or ones that are direct calls into the GC). ... The docs for `-vgc` should really be updated to clarify. It currently just says "List all gc allocations including hidden ones". -Steve Thanks for clarification!
Re: Program crash: GC destroys an object unexpectedly
On Tuesday, 14 September 2021 at 20:59:14 UTC, Ali Çehreli wrote:
On 9/14/21 9:56 AM, eugene wrote:
> On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
>> The misaligned pointer and the
>> reference-containing struct that vanishes on the return of
your
>> corresponding function are both problems for this.
>
> where did you find 'misaligned pointer'?...
I think it's the align(1) for EpollEvent.
The definition of this struct was taken from
/usr/include/dmd/druntime/import/core/sys/linux/epoll.d
```d
version (X86_Any)
{
align(1) struct epoll_event
{
align(1):
uint events;
epoll_data_t data;
}
}
```
I am using my own definition, because data field
has not any special meaning for the Linux kernel,
it is returned as is by epoll_wait().
I am always using this field as pointer to EventSource.
This struct has to be 12 bytes for x86 arch,
in /usr/include/linux/eventpoll.h it looks like this:
```c
struct epoll_event {
__u32 events;
__u64 data;
} EPOLL_PACKED;
```
At some moment I had different definition (align is only inside):
```d
struct EpollEvent {
align(1):
uint event_mask;
EventSource es;
/* just do not want to use that union, epoll_data_t */
}
```
But it's appeared:
1) relatively fresh gdc (from Linux Mint 19) does the right
thing, the structure is packed and has 12 bytes size.
2) old gdc (from Debian 8) produces 16 bytes EventEpoll and both
programs
gets SIGSEGV right after first return from epoll_wait(), hence
this check:
```d
static assert(EpollEvent.sizeof == 12);
```
If the reason for crash was in EpollEvent alignment,
programs would segfaults always very soon after start,
just right after the very first return from epoll_wait().
Re: What is the meaning of @future ?
On Saturday, 18 September 2021 at 08:02:13 UTC, Dylan Graham wrote: On Friday, 17 September 2021 at 14:37:29 UTC, Meta wrote: On Friday, 17 September 2021 at 10:31:34 UTC, bauss wrote: On Thursday, 16 September 2021 at 20:53:34 UTC, Elmar wrote: [...] It's just another "useless" attribute that the language has added before fixing any of the real problems :) Basically it reserves a symbol for the future. It's similar to creating ex. an empty function that throws an error or something like "Not implemented" While I understand why it was added and what purpose it serves then I fail to see why that was prioritized over actual issues. It's solving an almost non-existing issue. I think the main reason it was added is because Sociomantic asked for it, but they are of course not around anymore. Off topic: what happened to them, out of curiosity? IIRC they went out of business for inability to compete OR it was consumed by a another advertising company, there was a thread on a forum from Sonke about that event.
Re: What is the meaning of @future ?
On Friday, 17 September 2021 at 14:37:29 UTC, Meta wrote: On Friday, 17 September 2021 at 10:31:34 UTC, bauss wrote: On Thursday, 16 September 2021 at 20:53:34 UTC, Elmar wrote: [...] It's just another "useless" attribute that the language has added before fixing any of the real problems :) Basically it reserves a symbol for the future. It's similar to creating ex. an empty function that throws an error or something like "Not implemented" While I understand why it was added and what purpose it serves then I fail to see why that was prioritized over actual issues. It's solving an almost non-existing issue. I think the main reason it was added is because Sociomantic asked for it, but they are of course not around anymore. Off topic: what happened to them, out of curiosity?
