Re: Derived type
On Tuesday, 30 March 2021 at 21:53:34 UTC, Basile B. wrote:
struct Typedef(TBase)
{
TBase payload;
alias payload this;
}
alias Xobj = Typedef!(void*);
This is how std.typecons.Typedef made, IMHO.
The problem is this code generate struct with name
"Typedef!(void*)",
then compiler show this name (not "Xobj") in messages:
https://run.dlang.io/is/eEI2yC
void* bad;
foo(bad);
Error: function foo(Typedef!(void*) obj) is not callable using
argument types (void*)
cannot pass argument bad of type void* to parameter
Typedef!(void*) obj
Re: Derived type
On Tuesday, 30 March 2021 at 19:33:31 UTC, novice2 wrote: On Tuesday, 30 March 2021 at 19:12:29 UTC, Ali Çehreli wrote: "Derived type" is used in the context of object oriented programming at least in D Sorry, i use wrong termin. I just want create new type Tnew, based on exist type Tbase. Tnew have same allowed values, same properties, same allowed operations as Tbase. Compiler should distinguish New from Tbase. Allowed implicit cast Tnew to Tbase. Prohibited implicit cast Tbase to Tnew. Allowed exlicit cast Tbase to Tnew. That's precisely what the alias this feature is intended to do. https://dlang.org/spec/class.html#alias-this Thanks, this is what i want. I just think that Typedef do it for me, hide this boilerplait code. That's not the intended purpose of the Typedef template. Its documentation explicitly says it "allows the creation of a unique type which is based on an existing type". The keyword there is *unique*.
Re: Derived type
On Tuesday, 30 March 2021 at 19:47:41 UTC, novice2 wrote:
My tries to make template for struct and alias this:
// variant 1
template Typedef(alias Tnew, Tbase)
{
struct Tnew
{
Tbase payload;
alias payload this;
}
}
you must give a name to the template specialization, using alias
[1], also the TypeDef declaration can be highly simplified:
---
struct Typedef(TBase)
{
TBase payload;
alias payload this;
}
alias Xobj = Typedef!(void*);
void foo (Xobj obj) {}
---
[1]: https://dlang.org/spec/declaration.html#alias
Re: Derived type
My tries to make template for struct and alias this:
// variant 1
template Typedef(alias Tnew, Tbase)
{
struct Tnew
{
Tbase payload;
alias payload this;
}
}
Typedef!(Xobj, void*);
void foo (Xobj obj) {} //compiler Error: no identifier for
declarator Typedef!(Xobj, void*)
// variant 2
mixin template Typedef(alias Tnew, Tbase)
{
struct Tnew
{
Tbase payload;
alias payload this;
}
}
mixin Typedef!(Xobj, void*); //compiler Error: undefined
identifier Xobj
Re: Derived type
On Tuesday, 30 March 2021 at 19:12:29 UTC, Ali Çehreli wrote: "Derived type" is used in the context of object oriented programming at least in D Sorry, i use wrong termin. I just want create new type Tnew, based on exist type Tbase. Tnew have same allowed values, same properties, same allowed operations as Tbase. Compiler should distinguish New from Tbase. Allowed implicit cast Tnew to Tbase. Prohibited implicit cast Tbase to Tnew. Allowed exlicit cast Tbase to Tnew. but your examples indicate you need something else. How about the 'alias this' feature? Thanks, this is what i want. I just think that Typedef do it for me, hide this boilerplait code.
Re: Derived type
On 3/30/21 6:28 AM, novice3 wrote:
> I want create derived type in D
"Derived type" is used in the context of object oriented programming at
least in D but your examples indicate you need something else. How about
the 'alias this' feature?
import std.stdio;
struct Xobj {
void* value;
alias value this;
}
void main() {
int i;
auto var = Xobj();
writeln(var);
int j;
var =
}
alias this is for implicit conversions, from Xobj to void* in this case.
Ali
Re: Derived type
On Tuesday, 30 March 2021 at 14:45:12 UTC, WebFreak001 wrote: Xobj can then be used interchangeably with void*, so all void* arguments accept Xobj and all Xobj arguments accept void*. yes, i understand alias, and i dont want such behaviour If you want a type-safe alias that makes all void* arguments accept Xobj but not Xobj arguments to accept void* yes, this is that i search you can use `Typedef` like you linked. Problem with Typedef template - code alias Xobj = Typedef!(void*) not generate type named "Xobj", but type named "Typedef!(void*, null, null)". This makes compiler error messages unusable. enum Xobj : void*; ``` This allows explicit conversion in both ways using cast, but only allows implicit conversion from Xobj to void*, not from void* to Xobj: Strange syntax. Behavour exactly what i want, but this code not works for me :( enum Xobj : void*; Xobj var; //DMD Error: enum test7.Xobj forward reference of Xobj.init
Re: Derived type
On Tuesday, 30 March 2021 at 13:43:52 UTC, Mike Parker wrote:
the straightforward way is just to use an alias.
i cant use alias - compiler cannot distinguish base type and
alias, and cannot catch programmer errors
Buf if you need a more concrete type, you can use alias this in
a struct:
I think Typedef template should do this struct for me.
Thanks Mike, this way is what i wanted
struct Xobj {
private void* payload;
alias payload this;
}
Xobj good;
foo(good);//nice
foo(cast(Xobj)null); //explicit cast allowed - nice
foo(null);//no implicit cast disallowed - compiler
error - nice
void* bad;
foo(bad); //compiler distinguish type - error - nice
I think Typedef template should do this struct for me.
Problem with Typedef template - code
alias Xobj = Typedef!(void*)
not generate struct named "Xobj",
but struct named "Typedef!(void*, null, null)".
This makes compiler error messages unusable.
I will try to make template for struct. But template is black
magic for me :)
Re: Windows Console and writing Unicode characters
On Tuesday, 30 March 2021 at 13:19:02 UTC, Adam D. Ruppe wrote: On Tuesday, 30 March 2021 at 08:31:02 UTC, Luhrel wrote: I have been used this trick in C++, so it might also work in D: If you follow through the link that's what I mention as being a bad idea and provide the code given as a more correct alternative. It changes a global (well to the console) setting that persists after your program terminates, which can break other programs later, it can trigger font changes, and it doesn't actually always work anyway. You're much better off calling the correct functions. Oh okay, I never had those issues, strangely enough. It's a good website BTW.
Re: Derived type
On Tuesday, 30 March 2021 at 14:45:12 UTC, WebFreak001 wrote: When i adapt C code, i see new type creation: The typedef in C in D is just an alias: ``` alias Xobj = void*; ``` I totally overlooked the part about porting from C. Yes, this is the way to go in that case.
Re: Derived type
On Tuesday, 30 March 2021 at 13:28:55 UTC, novice3 wrote: Hello. When i adapt C code, i see new type creation: typedef void* Xobj; Or code like this: struct _Xobj; typedef struct _Xobj *Xobj; I want create derived type in D, found std.typecons.Typedef template, and write: alias Xobj = Typedef!(void*, (void*).init); But compiler use long type name in error messages, like this: Error: function test6.foo(Typedef!(void*, null, null) obj) is not callable using argument types (void*) cannot pass argument bad of type void* to parameter Typedef!(void*, null, null) obj This messages dont help me understand, which type should i use. What i should change? Or Typedef template should be changes? Any Typedef alternatives? The typedef in C in D is just an alias: ``` alias Xobj = void*; ``` Xobj can then be used interchangeably with void*, so all void* arguments accept Xobj and all Xobj arguments accept void*. If you want a type-safe alias that makes all void* arguments accept Xobj but not Xobj arguments to accept void* you can use `Typedef` like you linked. However using this language built-in feature is much simpler and cheaper in terms of resource usage and compile time + always results in the fastest code: (there is no conversions at all) ``` enum Xobj : void*; ``` This allows explicit conversion in both ways using cast, but only allows implicit conversion from Xobj to void*, not from void* to Xobj: ``` void* x = someValue; Xobj y = cast(Xobj)x; // ok x = y; // ok y = x; // error (need explicit cast) ```
Re: Derived type
On Tuesday, 30 March 2021 at 13:28:55 UTC, novice3 wrote:
This messages dont help me understand, which type should i use.
What i should change?
Or Typedef template should be changes?
From the docs:
"Unlike the alias feature, Typedef ensures the two types are not
considered as equals.
Parameters:"
https://dlang.org/phobos/std_typecons.html#Typedef
Any Typedef alternatives?
If you want your new type to be interchangeable with another, the
straightforward way is just to use an alias. Buf if you need a
more concrete type, you can use alias this in a struct:
import std.stdio;
struct MyType {
void* wrapped;
alias wrapped this;
}
void doSomething(void* t) {
writeln(*(cast(int*)t));
}
void main() {
int i = 20;
MyType mt = MyType();
doSomething(mt);
}
Re: How to parse JSON in D?
On 3/30/21 3:05 AM, Imperatorn wrote: On Monday, 29 March 2021 at 18:19:35 UTC, Steven Schveighoffer wrote: On 3/29/21 1:48 PM, Imperatorn wrote: On Monday, 29 March 2021 at 17:21:25 UTC, tastyminerals wrote: [...] https://youtu.be/un-bZdyumog?t=27m25s FYI that package is here: https://code.dlang.org/packages/jsoniopipe I really want to start using it, but priorities. It should be pretty functional, but it's a bit hard to use at the moment (unless you just want serialization). I need to work on the parsing API. The benefit is it allows parsing the JSON without constructing some tree-like representation of the data. The serializer uses this directly, which makes it fast. Probably not as fast as asdf, but I could maybe get it there with some tricks. Omg asdf gets ~300 MB/s, I thought iopipe's 200 MB/s was fast It's important to compare apples to apples (or in this case, my macbook to my macbook, and doing similar functions) when showing raw numbers, but I haven't thought about performance for jsoniopipe since that talk really ;) I assume it would not be much more difficult to match or possibly exceed asdf's speed, it seems we have similar design goals. I'll have to at some point build asdf and run some benchmarks to see what my targets should be. At the time I used rapidjson, I got jsoniopipe to be comparable with not much effort. -Steve
Derived type
Hello. When i adapt C code, i see new type creation: typedef void* Xobj; Or code like this: struct _Xobj; typedef struct _Xobj *Xobj; I want create derived type in D, found std.typecons.Typedef template, and write: alias Xobj = Typedef!(void*, (void*).init); But compiler use long type name in error messages, like this: Error: function test6.foo(Typedef!(void*, null, null) obj) is not callable using argument types (void*) cannot pass argument bad of type void* to parameter Typedef!(void*, null, null) obj This messages dont help me understand, which type should i use. What i should change? Or Typedef template should be changes? Any Typedef alternatives?
Re: Windows Console and writing Unicode characters
On Tuesday, 30 March 2021 at 08:31:02 UTC, Luhrel wrote: I have been used this trick in C++, so it might also work in D: If you follow through the link that's what I mention as being a bad idea and provide the code given as a more correct alternative. It changes a global (well to the console) setting that persists after your program terminates, which can break other programs later, it can trigger font changes, and it doesn't actually always work anyway. You're much better off calling the correct functions.
Re: Windows Console and writing Unicode characters
On Tuesday, 30 March 2021 at 08:31:02 UTC, Luhrel wrote:
I have been used this trick in C++, so it might also work in D:
```
import core.stdc.stdlib;
import std.stdio;
void main()
{
version(Windows)
system("chcp 65001 > NUL".ptr);
writeln("çéäö");
}
```
Works like a charm in Cmder. But it displayed some squares in CMD.
Re: Windows Console and writing Unicode characters
On Monday, 29 March 2021 at 02:12:57 UTC, Brad wrote:
I am new here so I will post this in Learn.
I have been doing a bit of reading on printing unicode
characters in the Windows Console. Specifically W10 command
prompt. I ran across a post by Adam Ruppe in a thread created
a couple years ago which links a short bit of code and a quick
discussion that Adam presents on his blog. Here is a link to
the specific reply I refer to:
https://forum.dlang.org/post/sjsqqhwvlonohvwyq...@forum.dlang.org
[...]
I have been used this trick in C++, so it might also work in D:
```
import core.stdc.stdlib;
import std.stdio;
void main()
{
version(Windows)
system("chcp 65001 > NUL".ptr);
writeln("çéäö");
}
```
Re: Creating a .di file for a custom C library
On Tuesday, 30 March 2021 at 04:01:12 UTC, Brad wrote: I would like to use an updated version of the Termbox library (written in C) with D. I have the .h file. This is new territory for me (why try something easy - right?). I think I need to create a .di file that corresponds to the .h file. I also suspect that I need to put the library file (C code) into the project as a file somehow. I am probably just not looking in the right place for the documentation, but I cannot seem to find a lot of guidance in this area. Thanks in advance. I never needed or used .di files. Dstep[1] can create d modules containing c header definitions. Recently, I used to create a d binding [2] for shapelib[3]. I just added "module shapelib;" at the beginning of the file, nothing else. Some c headers may require extra steps IMO. 1: https://github.com/jacob-carlborg/dstep 2: https://github.com/aferust/shapelib-d/blob/main/shapelib.d 3: https://github.com/OSGeo/shapelib
Re: Creating a .di file for a custom C library
On Tuesday, 30 March 2021 at 04:01:12 UTC, Brad wrote: I would like to use an updated version of the Termbox library (written in C) with D. I have the .h file. This is new territory for me (why try something easy - right?). I think I need to create a .di file that corresponds to the .h file. I also suspect that I need to put the library file (C code) into the project as a file somehow. I am probably just not looking in the right place for the documentation, but I cannot seem to find a lot of guidance in this area. Thanks in advance. Hi Brad I used dstep https://code.dlang.org/packages/dstep to help me with this process. Though I ended up checking the output and fixing a couple oddities in the "extern (C):" line, it was *huge* time saver. The result was a D module file (i.e. thing.d, not thing.di) that I could include like any other, so long as the C library was specified on the compiler command line. In addition, you might want to check out https://wiki.dlang.org/Deimos where standard patterns are discussed for D prototypes of C libraries. I ended up using the command line: dub init --format=deimos to start off the wrapper lib package, then copied in the C header, and then ran dstep. Cheers,
Re: Creating a .di file for a custom C library
On Tuesday, 30 March 2021 at 04:01:12 UTC, Brad wrote: I would like to use an updated version of the Termbox library (written in C) with D. I have the .h file. This is new territory for me (why try something easy - right?). I think I need to create a .di file that corresponds to the .h file. I also suspect that I need to put the library file (C code) into the project as a file somehow. I am probably just not looking in the right place for the documentation, but I cannot seem to find a lot of guidance in this area. Thanks in advance. No just convert C signatures to corresponding D signatures in regular .d file. Then you need to build original C library, and then when building D program you link(pass produced .lib/.a files to compiler/linker) this stuff with C library. After all your binaries is just language agnostic bytes, however there is calling conventions that exist for interop, your .h contains definitions (aka contract) of what it does, and produced binaries (.exe, .a, .lib, .dll, .so) contains actual machine code, so on D side you must match that contract and then tell the linker to embed the machine code from .a/.lib in your final executable/DLL.
Re: How to parse JSON in D?
On Monday, 29 March 2021 at 18:19:35 UTC, Steven Schveighoffer wrote: On 3/29/21 1:48 PM, Imperatorn wrote: On Monday, 29 March 2021 at 17:21:25 UTC, tastyminerals wrote: [...] https://youtu.be/un-bZdyumog?t=27m25s FYI that package is here: https://code.dlang.org/packages/jsoniopipe I really want to start using it, but priorities. It should be pretty functional, but it's a bit hard to use at the moment (unless you just want serialization). I need to work on the parsing API. The benefit is it allows parsing the JSON without constructing some tree-like representation of the data. The serializer uses this directly, which makes it fast. Probably not as fast as asdf, but I could maybe get it there with some tricks. -Steve Omg asdf gets ~300 MB/s, I thought iopipe's 200 MB/s was fast
