Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
On Sunday, 31 May 2020 at 00:46:09 UTC, Paul Backus wrote:
You can simplify this considerably using a mixin template [1]:
---
mixin template RW(T, string name) {
private T var;
public T get() { return var; }
public typeof(this) set(T val) { var = val; return this; }
mixin("private alias _", name, " = var;");
// two aliases with the same name create an overload set
mixin("public alias ", name, " = get;");
mixin("public alias ", name, " = set;");
}
class Point {
mixin RW!(int, "x");
mixin RW!(int, "y");
mixin RW!(string, "z"); // add
}
---
This is better, ... but it breaks std.traits:
void main() {
auto fields = FieldNameTuple!(Point);
writeln(fields);
}
$ ./b
varvarvar
And normally, we cannot define 2 fields with different types:
class P {
int x;
double x; // b.d(45): Error: variable b.P.x conflicts with
variable b.P.x at b.d(44)
}
With the above template we somehow tricked the compiler to be
able to do this?
Is this a loop-hole we should file a bug?
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 16:14:34 UTC, Steven Schveighoffer
wrote:
This is not about const or not, it's about lifetime management.
For example, this would return a pointer to a stack frame that
is about to go away:
const(char)* foo()
{
ErrorInfo info;
return info.message;
}
I know that you have already fixed the problem, but I wanted to
make sure you understood why the compiler is complaining.
Yes, that was me having never actually read DIP 25 and
misunderstanding what it was about. I've since been educated.
Thanks!
Garbage Collection Issue
I am encountering a strange problem with the GC on a specific platform: at the first attempt to clear the current memory pool to make room for a new allocation, the GC considers that the page in which the main thread resides (the one created in the init function of the GC) can be freed.. therefore, frees the entire pool and reallocates at the same location; later, when accessing thread's address, it stumbles upon garbage data. The question is: where does the GC expects the address of the thread to be found so that it takes it into consideration? A relevant mention would be that the platform doesn't support TLS so it won't find anything when trying to access that data. Could it be related to this?
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
On Saturday, 30 May 2020 at 23:39:31 UTC, mw wrote:
Thank you all for the reply.
I hate to write boilerplate code:
class Point {
private int _x;
publicint x() {return _x;}
public Point x(int v) {_x=v; return this;}
...
// ... y, z
}
this is what I've got:
$ cat b.d
// dmd -unittest -vcg-ast -c b.d
import std.format;
enum RW(string T, string name) =
format(q{
private %1$s _%2$s;
public %1$s %2$s(){return _%2$s;}
public auto %2$s(%1$s v) {_%2$s = v; return this;}
}, T, name);
class Point {
mixin(RW!("int", "x"));
mixin(RW!("double", "y"));
mixin(RW!("string", "z"));
}
[...]
Is there a better way to achieve this? esp. for the type `int`,
is there any way I don't have to quote it as string?
Thanks.
You can simplify this considerably using a mixin template [1]:
---
mixin template RW(T, string name) {
private T var;
public T get() { return var; }
public typeof(this) set(T val) { var = val; return this; }
mixin("private alias _", name, " = var;");
// two aliases with the same name create an overload set
mixin("public alias ", name, " = get;");
mixin("public alias ", name, " = set;");
}
class Point {
mixin RW!(int, "x");
mixin RW!(int, "y");
// etc.
}
---
You still need string mixins to make the names work, but the rest
can be done without them. Large string mixins tend to be
error-prone and difficult to debug, so it's usually a good idea
to make them as small as you reasonably can [2].
[1] https://dlang.org/spec/template-mixin.html
[2] http://www.arsdnet.net/this-week-in-d/2016-feb-21.html
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
On Saturday, 30 May 2020 at 23:39:31 UTC, mw wrote:
On Saturday, 30 May 2020 at 22:21:14 UTC, Paul Backus wrote:
[...]
Thank you all for the reply.
I hate to write boilerplate code:
[...]
import std.stdio : writeln;
mixin template f(T, string name, T value = T.init)
{
mixin("T _" ~ name ~ " = value;");
}
void main()
{
mixin f!(int, "x", 3);
_x.writeln; // prints 3
mixin f!(float, "y", 1.23f);
_y.writeln; // prints 1.23
mixin f!(string, "z");
_z.writeln; // prints an empty string (== string.init)
}
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
On Saturday, 30 May 2020 at 22:21:14 UTC, Paul Backus wrote:
enum f(string x) = "_" ~ x;
int main() {
mixin("int ", f!"x", " = 3;");
return _x;
}
This uses a templated [1] manifest constant [2] to generate the
variable name at compile time, and a mixin statement [3] to
insert the definition of `_x` into the program.
[1] https://dlang.org/spec/template.html#variable-template
[2] https://dlang.org/spec/enum.html#manifest_constants
[3] https://dlang.org/spec/statement.html#mixin-statement
Thank you all for the reply.
I hate to write boilerplate code:
class Point {
private int _x;
publicint x() {return _x;}
public Point x(int v) {_x=v; return this;}
...
// ... y, z
}
this is what I've got:
$ cat b.d
// dmd -unittest -vcg-ast -c b.d
import std.format;
enum RW(string T, string name) =
format(q{
private %1$s _%2$s;
public %1$s %2$s(){return _%2$s;}
public auto %2$s(%1$s v) {_%2$s = v; return this;}
}, T, name);
class Point {
mixin(RW!("int", "x"));
mixin(RW!("double", "y"));
mixin(RW!("string", "z"));
}
$ dmd -unittest -vcg-ast -c b.d
$ head -n 24 b.d.cg
import object;
import std.format;
enum RW(string T, string name) = format("\x0aprivate %1$s
_%2$s;\x0apublic %1$s %2$s(){return _%2$s;}\x0a
public auto %2$s(%1$s v) {_%2$s = v; return this;}\x0a ", T,
name);
class Point : Object
{
mixin(RW!("int", "x")
{
enum string RW = ['\x0a', ' ', ' ', ' ', ' ',
'p', 'r', 'i', 'v', 'a', 't', 'e', ' ', 'i', 'n', 't', ' ', '_',
'x', ';', '\x0a', ' ', ' ', ' ', ' ', 'p', 'u', 'b', 'l', 'i',
'c', ' ', ' ', 'i', 'n', 't', ' ', ' ', 'x', '(', ')', ' ', ' ',
' ', ' ', ' ', ' ', ' ', ' ', '{', 'r', 'e', 't', 'u', 'r', 'n',
' ', '_', 'x', ';', '}', '\x0a', ' ', ' ', ' ', ' ', 'p', 'u',
'b', 'l', 'i', 'c', ' ', ' ', 'a', 'u', 't', 'o', ' ', ' ', 'x',
'(', 'i', 'n', 't', ' ', 'v', ')', ' ', ' ', '{', '_', 'x', ' ',
'=', ' ', 'v', ';', ' ', ' ', 'r', 'e', 't', 'u', 'r', 'n', ' ',
't', 'h', 'i', 's', ';', '}', '\x0a', ' ', ' '];
}
);
mixin(RW!("double", "y")
{
enum string RW = ['\x0a', ' ', ' ', ' ', ' ',
'p', 'r', 'i', 'v', 'a', 't', 'e', ' ', 'd', 'o', 'u', 'b', 'l',
'e', ' ', '_', 'y', ';', '\x0a', ' ', ' ', ' ', ' ', 'p', 'u',
'b', 'l', 'i', 'c', ' ', ' ', 'd', 'o', 'u', 'b', 'l', 'e', ' ',
' ', 'y', '(', ')', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', '{',
'r', 'e', 't', 'u', 'r', 'n', ' ', '_', 'y', ';', '}', '\x0a', '
', ' ', ' ', ' ', 'p', 'u', 'b', 'l', 'i', 'c', ' ', ' ', 'a',
'u', 't', 'o', ' ', ' ', 'y', '(', 'd', 'o', 'u', 'b', 'l', 'e',
' ', 'v', ')', ' ', ' ', '{', '_', 'y', ' ', '=', ' ', 'v', ';',
' ', ' ', 'r', 'e', 't', 'u', 'r', 'n', ' ', 't', 'h', 'i', 's',
';', '}', '\x0a', ' ', ' '];
}
);
mixin(RW!("string", "z")
{
enum string RW = ['\x0a', ' ', ' ', ' ', ' ',
'p', 'r', 'i', 'v', 'a', 't', 'e', ' ', 's', 't', 'r', 'i', 'n',
'g', ' ', '_', 'z', ';', '\x0a', ' ', ' ', ' ', ' ', 'p', 'u',
'b', 'l', 'i', 'c', ' ', ' ', 's', 't', 'r', 'i', 'n', 'g', ' ',
' ', 'z', '(', ')', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', '{',
'r', 'e', 't', 'u', 'r', 'n', ' ', '_', 'z', ';', '}', '\x0a', '
', ' ', ' ', ' ', 'p', 'u', 'b', 'l', 'i', 'c', ' ', ' ', 'a',
'u', 't', 'o', ' ', ' ', 'z', '(', 's', 't', 'r', 'i', 'n', 'g',
' ', 'v', ')', ' ', ' ', '{', '_', 'z', ' ', '=', ' ', 'v', ';',
' ', ' ', 'r', 'e', 't', 'u', 'r', 'n', ' ', 't', 'h', 'i', 's',
';', '}', '\x0a', ' ', ' '];
}
);
}
Am I doing the right thing in D? any improvement you'd suggest?
e.g. I don't quite like have to put the type and var name in the
quotes as string:
mixin(RW!("int", "x"));
Is there a better way to achieve this? esp. for the type `int`,
is there any way I don't have to quote it as string?
Thanks.
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
Using a mixin:
string f(string x) { return "_" ~ x; }
int main() {
mixin("int "~f("x")~" = 3;");
return _x;
}
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
On Saturday, 30 May 2020 at 22:06:30 UTC, mw wrote:
I want to generate a new symbol (new variable name) from
existing one: e.g. in C:
$ cat t.c
#define f(x) _##x
int main() {
int f(x) = 3;
return _x;
}
$ make t
cc t.c -o t
$ ./t
$ echo $?
3
I wonder how to do this in D? using template / mixin? traits?
Can you show me an example?
Thanks.
enum f(string x) = "_" ~ x;
int main() {
mixin("int ", f!"x", " = 3;");
return _x;
}
This uses a templated [1] manifest constant [2] to generate the
variable name at compile time, and a mixin statement [3] to
insert the definition of `_x` into the program.
[1] https://dlang.org/spec/template.html#variable-template
[2] https://dlang.org/spec/enum.html#manifest_constants
[3] https://dlang.org/spec/statement.html#mixin-statement
how to achieve C's Token Pasting (##) Operator to generate variable name in D?
I want to generate a new symbol (new variable name) from existing
one: e.g. in C:
$ cat t.c
#define f(x) _##x
int main() {
int f(x) = 3;
return _x;
}
$ make t
cc t.c -o t
$ ./t
$ echo $?
3
I wonder how to do this in D? using template / mixin? traits?
Can you show me an example?
Thanks.
Re: Logging best practices
On Saturday, 30 May 2020 at 18:17:21 UTC, mw wrote: On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm wrote: Hello. Is there a current "Best Practices" for logging in D? For the actual logging, I know of `std.experimental.logger`. However, the `experimental` has kept me away from it. Is it good, or are there any better alternatives? A related question: how to log to multiple destinations? e.g. both console & log file? any examples? Thanks. Please have a look at the unittest in line 108 here https://www.github.com/dlang/phobos/tree/384d0427936fc8846b633ac08e212e5107c37d16/std%2Fexperimental%2Flogger%2Fmultilogger.d Kind regards Andre
Re: Logging best practices
On Monday, 29 April 2019 at 16:02:25 UTC, Arun Chandrasekaran wrote: std.experimental.logger is perfectly thread safe. However printing the logging thread ID is still pending with this PR https://github.com/dlang/phobos/pull/6978 Also is any file logger thread safe?
Re: Logging best practices
On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm wrote: Hello. Is there a current "Best Practices" for logging in D? For the actual logging, I know of `std.experimental.logger`. However, the `experimental` has kept me away from it. Is it good, or are there any better alternatives? A related question: how to log to multiple destinations? e.g. both console & log file? any examples? Thanks.
Re: DMD 2.092 and DIP 25
On 5/30/20 3:00 AM, Mike Parker wrote:
The following declarations now give a deprecation warning:
```d
struct ErrorInfo {
private:
char[32] _error;
char[96] _message;
public @nogc nothrow @property:
/**
Returns the string "Missing Symbol" to indicate a symbol load
failure, and
the name of a library to indicate a library load failure.
*/
const(char)* error() const { return _error.ptr; }
/**
Returns a symbol name for symbol load failures, and a
system-specific error
message for library load failures.
*/
const(char)* message() const { return _message.ptr; }
}
```
I find it rather annoying, as I'm returning `const(char)*` and not
`char*`, but it is what it is. My question is, if I add `return` to the
function declarations, will this compile all the way back to DMD 2.067
*without* `-preview=dip25`? It works on 2.091.0. I always assumed a
preview feature's syntax wasn't supported without the preview switch.
I had to run the code to see the warning to understand what you meant.
Here is the warning:
onlineapp.d(11): Deprecation: returning &this._error escapes a reference
to parameter this, perhaps annotate with return
onlineapp.d(17): Deprecation: returning &this._message escapes a
reference to parameter this, perhaps annotate with return
This is not about const or not, it's about lifetime management.
For example, this would return a pointer to a stack frame that is about
to go away:
const(char)* foo()
{
ErrorInfo info;
return info.message;
}
I know that you have already fixed the problem, but I wanted to make
sure you understood why the compiler is complaining.
-Steve
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 07:30:17 UTC, Max Samukha wrote: On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote: https://run.dlang.io/is/aOZqww Since 2.067.1: Success and no output Thanks, Max (and you, too, Seb). I had forgotten that run.dlang.io supports compilers going so far back.
Re: How to pre build vibe-d dub package
On Saturday, 30 May 2020 at 00:12:20 UTC, kookman wrote: On Friday, 29 May 2020 at 11:45:24 UTC, Andre Pany wrote: André I do it by defining a configuration “build-deps” in my dub.sdl with target type “none” and then doing the build as two steps in the dockerfile: ``` dockerfile ... WORKDIR /build COPY dub.s* ./ RUN dub build -v —config=build-deps COPY src ./src RUN dub build -v —config=executable ... Fantastic, thanks a lot. Kind regards Andre
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 07:30:17 UTC, Max Samukha wrote: On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote: https://run.dlang.io/is/aOZqww Since 2.067.1: Success and no output Thanks! I forgot that run.dlang.io supports all those old compilers.
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote:
The following declarations now give a deprecation warning:
```d
struct ErrorInfo {
private:
char[32] _error;
char[96] _message;
public @nogc nothrow @property:
/**
Returns the string "Missing Symbol" to indicate a
symbol load failure, and
the name of a library to indicate a library load
failure.
*/
const(char)* error() const { return _error.ptr; }
/**
Returns a symbol name for symbol load failures, and a
system-specific error
message for library load failures.
*/
const(char)* message() const { return _message.ptr; }
}
```
I find it rather annoying, as I'm returning `const(char)*` and
not `char*`, but it is what it is. My question is, if I add
`return` to the function declarations, will this compile all
the way back to DMD 2.067 *without* `-preview=dip25`? It works
on 2.091.0. I always assumed a preview feature's syntax wasn't
supported without the preview switch.
Return is actually pretty old, so it will compile:
https://run.dlang.io/is/DgbYU9
Typically -preview flags are just looked at during the semantic
phases.
Another solution could be to turn the functions into templates
and let the compiler do its attribute inference.
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote: I find it rather annoying, as I'm returning `const(char)*` and not `char*`, but it is what it is. My question is, if I add `return` to the function declarations, will this compile all the way back to DMD 2.067 *without* `-preview=dip25`? It works on 2.091.0. I always assumed a preview feature's syntax wasn't supported without the preview switch. https://run.dlang.io/is/aOZqww Since 2.067.1: Success and no output
DMD 2.092 and DIP 25
The following declarations now give a deprecation warning:
```d
struct ErrorInfo {
private:
char[32] _error;
char[96] _message;
public @nogc nothrow @property:
/**
Returns the string "Missing Symbol" to indicate a symbol
load failure, and
the name of a library to indicate a library load failure.
*/
const(char)* error() const { return _error.ptr; }
/**
Returns a symbol name for symbol load failures, and a
system-specific error
message for library load failures.
*/
const(char)* message() const { return _message.ptr; }
}
```
I find it rather annoying, as I'm returning `const(char)*` and
not `char*`, but it is what it is. My question is, if I add
`return` to the function declarations, will this compile all the
way back to DMD 2.067 *without* `-preview=dip25`? It works on
2.091.0. I always assumed a preview feature's syntax wasn't
supported without the preview switch.
