Re: ImportC: Windows.h
Minimum thing to reproduce bug:
main.d:
```d
import test;
void main() {
auto a = FILE_MAP_READ;
}
```
test.c
```c
#define SECTION_MAP_READ 0x0004
#define FILE_MAP_READ SECTION_MAP_READ
```
build with ```"D:\dmd.2.105.3.windows\dmd2\windows\bin64\dmd.exe"
-c test.c -vcg-ast```.
test.c.cg (```FILE_MAP_READ``` doesn't show up):
```d
extern (C)
{
enum int __IMPORTC__ = 1;
enum int _M_X64 = 100;
enum int _MSC_EXTENSIONS = 1;
enum int _MSC_BUILD = 0;
enum int _WIN64 = 1;
// ...
enum int SECTION_MAP_READ = 4;
// ...
}
```
Re: struct initializer
Hi All,
I feel lonely, just as those who come from C++ find it strange,
because I think it makes it difficult to read code.
On Friday, 1 December 2023 at 14:53:16 UTC, Paul Backus wrote:
Technically you don't *have* to repeat the type. You can write
the return type as `auto`:
```d
auto fun() { return S(5, 2); }
```
Or you can use `typeof(return)`:
```d
SomeReallyLongReturnType fun()
{
return typeof(return)(5, 2);
}
```
Paul's example is very readable and short so it's nice. Moreover,
when there are named parameters in D, what is the need for them.
While there is so much convenience in D, getting stuck on a very
simple option...
You decide:
```d
struct Point
{
int x, y;
auto opBinary(string op : "-")(Point that)
=> Point(this.x - that.x, this.y - that.y);
auto opBinary(string op : "+")(Point that)
=> Point(this.x + that.x, this.y + that.y);
auto opBinary(string op : "*")(Point that)
=> Point(this.x * that.x, this.y * that.y);
// Moreover, it was possible to do this trio
// at once with mixin...
}
void main()
{
auto upperRightCorner = Point(y:768);
Point x = { 10, 268 };
import std.stdio : dout = writeln;
dout(upperRightCorner - x);
dots(a: upperRightCorner, b: x).dout;
}
alias dots = differenceOfTwoSquares;
auto differenceOfTwoSquares(Point a, Point b)
=> (a - b)*(a + b);
/*
* dmd -run "namedParameters.d"
* Point(-10, 500)
* Point(-100, 518000)
*/
```
SDB@79
now I need -allinst when dmd compiles the unittest
If I not use -allinst the linker complains when using the current msgpack-d v1.0.5, e.g. [...]msgpack-d/src/msgpack/package.d:203: undefined reference to `pure nothrow @nogc @safe immutable(char)[] core.internal.dassert._d_assert_fail!(int)._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), scope ref const(int), scope ref const(int))' [...]msgpack-d/src/msgpack/packer.d:1326: undefined reference to `pure nothrow @nogc @safe immutable(char)[] core.internal.dassert._d_assert_fail!(const(int))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), scope ref const(int), scope const(int))' [...]/msgpack-d/src/msgpack/unpacker.d:1505: undefined reference to `pure nothrow @nogc @safe immutable(char)[] core.internal.dassert._d_assert_fail!(int)._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), scope ref const(int), scope ref const(int))'
"using `in ref` is deprecated" in client code while the module's unittest does not warn
After switching to dmd v2.105.3 I get this warnings almost everywhere. Do I really have to fork msgpack-d in order to get rid of these warnings? Now I replaced every "in ref" with "in" in my own code but I do not add that preview flag to the compiler invocation. Is that safe?
Re: struct initializer
I completely agree with the OP, and I want to illustrate this by
another example which I find quite bizarre:
```
struct S { int a; int b; }
S[] s_list = new S[0];
// this works
S s = { a:1, b:2 };
s_list ~= s;
// this does not
s_list ~= { a:1, b:2 };
```
I'm a C++ programmer in my day job and the very first instinct
I'd have is to replace the first version by the second to reduce
verbosity and eliminate an unnecessary copy.
However, for some reason the compiler is not able to deduce the
type in the second case, so I'm out of luck.
I'm glad to hear that, with a compiler update, I will at least be
able to do
```
s_list ~= S( a:1, b:2 );
```
instead of
```
s_list ~= S( 1, 2 );
```
but it still seems very inconsistent.
vibe-d REST API: POSTing a struct
Hey everyone,
I'm looking into vibe-d, particularly how to build a REST API
server.
Given this struct:
```
struct Project
{
string project_id;
string name;
}
```
I could write a GETter like this:
```
@path("projects/:project_id")
Project getProject(string _project_id);
```
and a POST could look like this:
```
Project postProjects(string project_id, string name);
```
So far so good, this works.
What I don't like about the POST, though, is that I have to
repeat `struct Project`'s members in the parameter list. This is
redundant and will be inconvenient every time the struct changes,
especially on ones with many members.
What I would prefer to have is something like this:
```
Project postProjects(Project project);
```
This is possible, the problem is that the POST request body now
must look like this
```
{
project: {
"project_id": "dummy_id",
"name": "dummy"
}
}
```
rather than simply this
```
{
"project_id": "dummy_id",
"name": "dummy"
}
```
So my question is, is it possible to have vibe-d parse the
request body into a struct "implicitly"?
I hope the explanation was understandable. :)
Any help would be much appreciated.
Cheers,
bomat
Re: struct initializer
On Wednesday, 29 November 2023 at 16:48:09 UTC, Paul Backus wrote:
[...]
If you're using a new enough compiler, it even supports named
arguments:
S3 fun2() { return S3(b: 2, a: 5); }
Indeed. Seems to be in dmd since 2.103.0 (2.102.2 didn't support
this syntax). Alas, the Change Log [1] remain silent about it.
```
commit 42609ae98e0f72a8d2154da50865bc5182c4b6b3
Author: Dennis https://dlang.org/changelog/2.103.0.html
Re: struct initializer
On Friday, 1 December 2023 at 13:02:06 UTC, Dom DiSc wrote:
```d
S Fun(){ return { 5, 2 }; }
```
This IS an initialization and the type is known. Requiring the
repetition of the type is also here annoying.
Technically you don't *have* to repeat the type. You can write
the return type as `auto`:
```d
auto fun() { return S(5, 2); }
```
Or you can use `typeof(return)`:
```d
SomeReallyLongReturnType fun()
{
return typeof(return)(5, 2);
}
```
Re: struct initializer
On Friday, 1 December 2023 at 13:02:06 UTC, Dom DiSc wrote:
```d
S Fun(){ return { 5, 2 }; }
```
This IS an initialization and the type is known. Requiring the
repetition of the type is also here annoying.
Right.
The `{}` initialization method in C++ is very useful,I like it
very much.
Re: struct initializer
On Friday, 1 December 2023 at 13:02:06 UTC, Dom DiSc wrote: Either allow it for all initializations, or get rid of it, like DIP 1031 suggested. I thought the decision actually was made to just get rid of it.
Re: struct initializer
On Thursday, 30 November 2023 at 12:15:04 UTC, Dennis wrote:
The syntax was inherited from C. The 'special place' is called
initialization, and it's special because the target type of the
initializer is known in advance
This is no different from `S fun(){ return { 5, 2 }; }` It
creates a new instance of a struct, and the type is known in
advance (it's the return type). So it's not an expression. But
this place of initialization is not allowed. Therefor I think
calling `S s = { 5, 2 };` 'special' is justified.
Re: struct initializer
On Thursday, 30 November 2023 at 14:10:35 UTC, zjh wrote:
On Wednesday, 29 November 2023 at 16:38:36 UTC, Dom DiSc wrote:
```d
struct S { int a; int b; }
S2 fun3() { return S2( 5, 2 ); }
```
Here,`S2( 5, 2 );` violeit `DRY` principle.
Yes. I think if we have the brackets form, it should be allowed
here:
```d
S Fun(){ return { 5, 2 }; }
```
This IS an initialization and the type is known. Requiring the
repetition of the type is also here annoying.
So it is not a syntax reserved for initialization, but only for
initialization with equals operator. I think this is inconsequent.
Either allow it for all initializations, or get rid of it, like
DIP 1031 suggested.
Re: Advent of Code 2023
On Friday, 1 December 2023 at 01:01:31 UTC, Siarhei Siamashka wrote: Advent of Code 2023 starts in a few hours from now. I suggest to discuss D language solutions here. But to avoid spoilers, it's best to do this with a 24h delay after each puzzle is published. Hi Siarhei. Nice to see that you are still around D forums. I thought you moved to Crystall.
Re: ImportC: Windows.h
On Friday, 1 December 2023 at 10:23:08 UTC, Kagamin wrote: In C macros can be defined to any expression, so ImportC interprets these parentheses as arbitrary expression macros and skips them thinking they are helper macros that can't be always translated. But does that explain why using ```FILE_MAP_READ``` (in "memoryapi.h") also produces ```Error: undefined identifier `FILE_MAP_READ` ```?
Re: ImportC: Windows.h
So, uh, I tried deleting the parens off GENERIC_READ's value: winnt.h: ```c // // These are the generic rights. // #define GENERIC_READ 0x8000L #define GENERIC_WRITE(0x4000L) #define GENERIC_EXECUTE (0x2000L) #define GENERIC_ALL (0x1000L) ``` And... that's what works. Uhh, why?
Re: ImportC: Windows.h
On Friday, 1 December 2023 at 08:45:30 UTC, Kagamin wrote:
Is GENERIC_WRITE awailable?
No, it's not.
I tried building with LDC 1.35.0:
```"D:\ldc2-1.35.0-windows-x64\bin\ldc2.exe" main.d -i
-vcg-ast```.
winnt.h:
```c
// begin_wdm
// begin_ntoshvp
typedef DWORD ACCESS_MASK;
typedef ACCESS_MASK *PACCESS_MASK;
// end_ntoshvp
// begin_access
//
//
// ACCESS TYPES
//
//
//
// begin_wdm
//
// The following are masks for the predefined standard access
types
//
#define DELETE (0x0001L)
#define READ_CONTROL (0x0002L)
#define WRITE_DAC(0x0004L)
#define WRITE_OWNER (0x0008L)
#define SYNCHRONIZE (0x0010L)
#define STANDARD_RIGHTS_REQUIRED (0x000FL)
#define STANDARD_RIGHTS_READ (READ_CONTROL)
#define STANDARD_RIGHTS_WRITE(READ_CONTROL)
#define STANDARD_RIGHTS_EXECUTE (READ_CONTROL)
#define STANDARD_RIGHTS_ALL (0x001FL)
#define SPECIFIC_RIGHTS_ALL (0xL)
//
// AccessSystemAcl access type
//
#define ACCESS_SYSTEM_SECURITY (0x0100L)
//
// MaximumAllowed access type
//
#define MAXIMUM_ALLOWED (0x0200L)
//
// These are the generic rights.
//
#define GENERIC_READ (0x8000L)
#define GENERIC_WRITE(0x4000L)
#define GENERIC_EXECUTE (0x2000L)
#define GENERIC_ALL (0x1000L)
//
// Define the generic mapping array. This is used to denote the
// mapping of each generic access right to a specific access
mask.
//
typedef struct _GENERIC_MAPPING {
ACCESS_MASK GenericRead;
ACCESS_MASK GenericWrite;
ACCESS_MASK GenericExecute;
ACCESS_MASK GenericAll;
} GENERIC_MAPPING;
typedef GENERIC_MAPPING *PGENERIC_MAPPING;
```
wintest.c.cg:
```d
alias ACCESS_MASK = uint;
alias PACCESS_MASK = uint*;
align struct _GENERIC_MAPPING
{
uint GenericRead = void;
uint GenericWrite = void;
uint GenericExecute = void;
uint GenericAll = void;
}
alias GENERIC_MAPPING = _GENERIC_MAPPING;
alias PGENERIC_MAPPING = _GENERIC_MAPPING*;
```
It ended up not producing any enums inbetween...
Re: ImportC: Windows.h
Is GENERIC_WRITE awailable?
