Re: LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
On Saturday, 30 March 2024 at 09:35:24 UTC, Per Nordlöw wrote:
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr
nonnull %rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr
nonnull %284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
You can try to add the flag `--disable-verify` (see
https://github.com/ldc-developers/ldc/issues/4284, that prevents
an internal verification).
The error message indicates that a "parameter-only" attribute is
used as a "call-site" one. Not sure if this is a bug in LDC or in
LLVM but if you're lucky the attribute will be a no-op and the
generated binary will just work.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Friday, 15 March 2024 at 00:00:01 UTC, Richard (Rikki) Andrew Cattermole wrote: On 15/03/2024 12:47 PM, Basile B. wrote: On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray wrote: On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] I tried to rework the functions to use bitwise operations, but it was difficult to figure out the correct logic. I decided that it's not worth the hassle, so I just changed the value storage from `bool[3]` to `ubyte`. Now it works much more like your version. https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d I did a little reading, so now I understand what it means when you have `&= 7`. But I want to ask, is this faster than `%= 8`? If not, I would like to change it to the latter for readability. `%=8` will be codegened using slower intructions w/o optimz enabled but with `&=7` you directly get the right instruction, which does not involves integer division. See https://godbolt.org/z/74vbba5aG Yes, it'll depend upon how smart the compiler is at optimizing and it may not occur in non-optimizing builds. Indeed GDC (so very likely GCC too, or whatever language uses it as backend...) does it without optimz (https://godbolt.org/z/Ke7c54Gqj). That's not very surprising. If you look at LLVM bug tracker, for the tag "missed optimisations", in the report body you'll see a lot of "GDC does that but we dont", even if here it's a bit different, as optimz are not enabled.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray wrote: On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] I tried to rework the functions to use bitwise operations, but it was difficult to figure out the correct logic. I decided that it's not worth the hassle, so I just changed the value storage from `bool[3]` to `ubyte`. Now it works much more like your version. https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d I did a little reading, so now I understand what it means when you have `&= 7`. But I want to ask, is this faster than `%= 8`? If not, I would like to change it to the latter for readability. `%=8` will be codegened using slower intructions w/o optimz enabled but with `&=7` you directly get the right instruction, which does not involves integer division. See https://godbolt.org/z/74vbba5aG
Re: varargs when they're not all the same type?
On Thursday, 14 March 2024 at 20:58:21 UTC, Andy Valencia wrote:
On Thursday, 14 March 2024 at 18:05:59 UTC, H. S. Teoh wrote:
...
The best way to do multi-type varags in D is to use templates:
import std;
void myFunc(Args...)(Args args) {
Thank you. The first parenthetical list is of types, is it
not? I can't find anywhere which says what "type" is inferred
for "Args..."? (gdb pretends like "arg" is not a known
symbol.) Is it basically a tuple of the suitable type?
Andy
Most of the time the variadic template parameters are infered
from the run time parameters. In that case indeed `Args` will be
a type tuple of `args` types.
```d
void myFunc(Args...)(Args args) {}
myFunc(0,0.1); // is like the more verbose
`myFunc!(int,double)(0,0.1)`
```
However explicit instantiation can take whatever is known at
compile time, such as constant expressions or even certain static
variables. So that is rather called an `alias sequence` in D.
That being said and with the signature of `myFunc` that will
effectively only work if `Args` is made of types.
About debugging, each individual runtime arg can be inspected
using a bit of knowledge of D internals.
As you can see the elements are named following this pattern
`__param_[0-9]+`.
So with gdb used as CLI, `$ p __param_0` will (爛爛) print the
first variadic element, and so on.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Tuesday, 12 March 2024 at 05:38:03 UTC, Liam McGillivray wrote:
I am in need of a data type for holding direction information;
one of 8 directions on a single axis. They are named in terms
of compass directions. If D had a 4-bit datatype, I would just
use this and do `+=2` whenever I want to change the datatype,
but it doesn't.
Perhaps this would be a good programming challenge for someone
more experienced than me. Make a data type (probably a struct)
for holding one of 8 directional values using 3 bits. It should
accept the use of increment operators to change the angle.
Ideally (but optionally), it should work as an enum of the same
name; "Direction".
Here's a unittest that it should ideally pass:
```
unittest
{
Direction direction = Direction.N;
direction++;
assert(direction == Direction.NE);
direction+=3;
assert(direction == Direction.S);
direction--;
assert(direction == Direction.SE);
direction-=4;
assert(direction == Direction.NW);
}
```
While there are workarounds (as proposed in the other answers,
using operator overloads) I tend to think that the way currently
enums work with arithmetic operators is a symptom of an
incomplete type-system. Enums made of integer numbers are sub
classes of the parent [integral
sequence](https://en.wikipedia.org/wiki/Integer_sequence).
The semantics of the operators are actually not as clear as that.
What if you define
```d
enum Direction
{
N = 1, NE, S = 45, SW
}
```
?
You directly see that the proposed workarounds dont work anymore.
There are natural numbers, sub-sets of natural numbers, unordered
sequences, etc.
The type system does not represent that. Anyway, I dont blame D,
plenty of languages have the exact same problem.
Re: what was the problem with the old post blit operator already ?
On Thursday, 15 February 2024 at 03:17:11 UTC, Jonathan M Davis wrote: On Wednesday, February 14, 2024 7:17:15 PM MST Basile B. via Digitalmars-d- learn wrote: From what I remember, it was that there was no reference to the source. Things got blitted and you had to fix the copy, already blitted. Was that the only issue ? There were probably some use cases where you needed access to both the source and the destination so that you could do something to the source as well, but the core problem was simply that blitting and then mutating the copy to fix it doesn't work with const or immutable objects, since it would violate the type system to cast away const or immutable to fix the copy. The only way to work properly with const or immutable is to construct the object with the changes in the first place rather than mutating the copy after the fact. - Jonathan M Davis That point was raised by Teoh too, which raises another question. Did the "old" postblit exist before the introduction of type qualifiers ? I think to D1 obviously. That would suggest that the introduction of type qualifiers was not perfectly executed, i.e some aspects were not mastered, until, years after, someone said "wait a minute, there's something wrong".
Re: Safety is not what you think
On Monday, 5 February 2024 at 14:26:45 UTC, Basile B. wrote:
On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote:
[...]
This definitely isn't allowed in C or C++. I wonder what the
rationale is for having this behavior in D?
[1]: https://dlang.org/spec/expression.html
An hypothesis is that this makes codegening the pre and the
post variants almost identical. The only difference is what is
yield.
[Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383).
Now there's not much to say about the topic, I just thought it
was amusing to share that (user1234 is my noname nickname here)
as people might not realize how much certain expressions allows.
In the same vein you have the possibility to select an lvalue
with a conditional expression. Pretty sure nobody knows that
the following is legal
```d
int a,b;
int c = rand();
((c & 3) ? a : b) = 42;
```
BTW, "achtung off topic", that's pretty much how the optional
access can be an lvalue:
```d
struct S {int a};
S* s; // null, by default init
s?.a = 0; // no access violation !! + valgrind is happy
```
You can lower that to a conditional expression:
```d
struct S {int a};
S* s;
typeof(S.a) __fallback; // compiler-generated
(s ? s.a : __fallback) = 0;
```
I've played a lot with that kind of expressions during the two
last years. They're funny but apparently not good enough for D ;)
To conclude.
Re: Safety is not what you think
On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote: [...] This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D? [1]: https://dlang.org/spec/expression.html An hypothesis is that this makes codegening the pre and the post variants almost identical. The only difference is what is yield. [Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383). Now there's not much to say about the topic, I just thought it was amusing to share that (user1234 is my noname nickname here) as people might not realize how much certain expressions allows. In the same vein you have the possibility to select an lvalue with a conditional expression. Pretty sure nobody knows that the following is legal ```d int a,b; int c = rand(); ((c & 3) ? a : b) = 42; ```
Re: Checking path name
On Thursday, 14 December 2023 at 03:58:37 UTC, Joel wrote:
If I get user input, for example, how do I check to see if it's
a valid path, like, file name.
```d
// something like this:
if (getUserInput.isValidPath) {
...
}
```
https://dlang.org/phobos/std_file.html#exists
Re: question
On Wednesday, 13 December 2023 at 12:49:14 UTC, fred wrote: [...] a bug ? thanks anyway Try to define the flag as static ```d static shared(bool) isDone = false; ``` I dont know if that should be a compiler error to have local shared (I tend to think yes as locals are specific to a frame, i.e a thread). At least you know how to fix the issue.
Re: mixin under -betterC
On Thursday, 23 November 2023 at 16:33:52 UTC, DLearner wrote:
Code below is intended to test simple mixin with lambda
function under -betterC.
Works with full-D, but fails with 'needs GC' errors under
-betterC.
Why is this so, bearing in mind the concatenations are executed
at
compile, not run, time?
```
// Test harness
extern(C) void main() {
import core.stdc.stdio : printf;
import testmod;
bool FirstVarGreater;
int Var_A = 4;
int Var_B = 3;
FirstVarGreater = mixin(mxnTest("Var_A", "Var_B"));
if (FirstVarGreater) {
printf("First Var is Greater\n");
} else {
printf("First Var is not Greater\n");
}
}
// testmod
string mxnTest(string strVar1, string strVar2) {
return `(int Var1, int Var2) {
if (Var1 > Var2) {
return true;
} else {
return false;
}
}(` ~ strVar1 ~ `,` ~ strVar2 ~ `)`;
}
```
You've been explained the reason why that does not work, note
however that it's not hopeless see
-
https://forum.dlang.org/thread/ahqnylrdftmmvtyvo...@forum.dlang.org
- https://github.com/dlang/dmd/pull/15636
unfortunately the PR is stalled since two months.
Re: Why can't we use strings in C++ methods?
On Saturday, 4 November 2023 at 13:51:20 UTC, Dadoum wrote:
On Saturday, 4 November 2023 at 13:45:56 UTC, Emmanuel Danso
Nyarko wrote:
[...]
There is a syntax disagreement here that's why the D compiler
is instantly stopping you from doing any symbol generated
interaction with string in C++ interop. C++ doesn't know
'string' and C++ mangles with parameters and so passing string
will make string get involved with the symbol generation and
since string(std::string) in C++ is a template library, the D
compiler stops you from engaging with 'string'
I don't think it's related to the existence of std::string at
all since all dynamic array types are forbidden.
```d
extern (C++) void hello(ubyte[] arg) {
import std.stdio;
writeln(arg);
}
```
also fails to compile while this works:
```d
extern (C) void hello(ubyte[] arg) {
import std.stdio;
writeln(arg);
}
```
The type simply cannot be mangled using the C++ mangler as it
does not exist over there. You might have the impression that
this should be allowed, e.g as an extension, but keep in mind
that `extern(C++)` is firstly designed to link against object
produced by a C++ compiler.
Now why this works in `extern(C)` ? Because C does not mangle the
parameters, a function linkage name is simply its unqualified
name, so linking will work even if the parameter types are
specific to D.
Now there is still the question whether the `extern(C)` code will
work as expected or not.
Re: Function Overloading
On Thursday, 2 November 2023 at 11:17:42 UTC, Salih Dincer wrote:
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote:
Yes. D constructors are not named but the current
implementation adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Yeah, it works! Thanks...:)
SDB@79
I'm no sure how this could be used IRL but keep well in mind that
**this is not nice code**.
My answer should be more interepreted as "yes that is technically
possible". ("can do" -> yes VS "should do" -> no).
You also have the `opCall()` option btw.
Re: Function Overloading
On Tuesday, 31 October 2023 at 20:09:44 UTC, Salih Dincer wrote:
[...]
is it possible to do something like `alias add = this;`?
```d
struct Calculate
{
int memory;
string result;
auto toString() => result;
// alias add = this;
import std.string : format;
this(string str)
{
result ~= str.format!"%s + ";
}
this(int num)
{
memory += num;
add(num.format!"%s");
}
}
```
SDB@79
Yes. D constructors are not named but the current implementation
adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Note that however this kind of internal details should not be
used, even if chances that this name changes are low (old 2014
code that uses it still compiles and have never broke, phobos
uses it too IIRC).
Otherwise take care to copy construction, that wont work with the
alias.
Re: How to use core.vararg to print D variadic arguments and their types without using ! (template instantiation)?
On Thursday, 14 September 2023 at 15:19:29 UTC, BoQsc wrote:
https://dlang.org/phobos/core_vararg.html
The common way to use **va_arg** is `va_arg!(int)(_argptr);`
What would be the alternative way or syntax that behave exactly
the same way, even if more verbose?
`va_arg!(int)(_argptr);` is taken from an example in:
https://dlang.org/spec/function.html#d_style_variadic_functions
here's how
```d
import core.vararg;
void main()
{
foo(.5, 5);
}
void foo(...)
{
int i = void;
va_arg(_argptr, typeid(i), );
assert(i == 5);
double d = void;
va_arg(_argptr, typeid(d), );
assert(d == .5);
}
```
Re: Weird floating point rounding - Bug or how to control it correctly
On Thursday, 14 September 2023 at 03:23:48 UTC, An Pham wrote:
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f",
f));
}
Output
6394763.345 = 6394763.5000
Classic question. The float literal `6394763.345f` is not
representable as IEEE-754 floating point number.
Try https://www.h-schmidt.net/FloatConverter/IEEE754.html for a
short introduction to the issue.
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote: [...] My guess is that you have a double-free somewhere, or there's a buffer overrun. Or maybe some bad interaction with the GC, e.g. if you tried to free a pointer from the GC heap. That cant be a GC problem as rempas project is compiled with `-betterC`
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 18:59:21 UTC, rempas wrote: On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote: Could this be a problem of copy construction ? I don't think so. My idea was that if you dont have defined a copy constructor and if an instance is assigned to another, then that other instance share the same pointer, which can cause memory errors. To eliminate that risk and to detect where default post-blitting may happen you can add ```d @disable this(this); ``` to the struct.
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote: I do have the following struct: [...] Is there any possible that there is a compiler bug? I do use ldc2 and `betterC`! Could this be a problem of copy construction ?
Re: Pointer to environment.get
On Monday, 28 August 2023 at 10:20:14 UTC, Basile B. wrote:
On Monday, 28 August 2023 at 06:38:50 UTC, Vino wrote:
Hi All,
The the below code is not working, hence requesting your
help.
Code:
```
import std.stdio;
import std.process: environment;
void main () {
int* ext(string) = ("PATHEXT");
writeln(*ext);
}
```
Problems is that "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
alias atGet = {return environment.get("PATHEXT");}; //
really lazy
writeln(atGet); // pointer to the lambda
writeln((*atGet)());// call the lambda
}
```
There might be other ways, but less idiomatic (using a struct +
opCall, a.k.a a "functor")
To go further, the correct code for syntax you wanted to use is
actually
```d
alias Ext_T = string (const char[] a, string b); // define a
function type
alias Ext_PT = Ext_T*; // define a function **pointer** type
Ext_PT ext =
```
But as you can see that does not allow to capture the argument.
Also it only work as AliasDeclaration RHS.
Re: Pointer to environment.get
On Monday, 28 August 2023 at 06:38:50 UTC, Vino wrote:
Hi All,
The the below code is not working, hence requesting your help.
Code:
```
import std.stdio;
import std.process: environment;
void main () {
int* ext(string) = ("PATHEXT");
writeln(*ext);
}
```
Problems is that "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
alias atGet = {return environment.get("PATHEXT");}; // really
lazy
writeln(atGet); // pointer to the lambda
writeln((*atGet)());// call the lambda
}
```
There might be other ways, but less idiomatic (using a struct +
opCall, a.k.a a "functor")
Re: Adding to a global AliasSeq
On Tuesday, 15 August 2023 at 12:20:54 UTC, repr_man wrote: On Tuesday, 15 August 2023 at 07:02:45 UTC, Basile B. wrote: You can add a kind of tag with the mixin, that will allow to to test if the type supplied to `f` is well a Base implementor: Firstly, thank you for your help. This is probably the best solution. Secondly, I feel very stupid for not having come up with this by myself. Would you be willing to explain some of the thought process behind your solution? Are there any key factors that I should look for in future template-related problems? Or, if it just comes from experience and seeing this sort of thing repeatedly, that's fair, too. Thanks, once again! This is just classic D. The way this works is tied to overload-sets resolution. You have two functions templates, same name, same count of parameters. The only way to make both exist in the set is "template constraint", one works given certain static conditions, the other not. Also, as it's time for the explanations, one thing about that system and that you should keep in mind is that it's costly, i.e "can cause major slowdown of compilation".
Re: Adding to a global AliasSeq
On Tuesday, 15 August 2023 at 02:30:37 UTC, repr_man wrote:
Consider the following template mixin:
```d
mixin template Base()
{
int x(){ return 10; }
}
```
It could be used in a variety of structs as follows:
```d
struct Child
{
mixin Base!();
}
```
Now, let's suppose we write a function with a parameter that
should only be able to take items that mix in `Base`:
```d
auto f(T)(T arg)
{
return arg.x;
}
```
This works because D uses structural subtyping. However, this
creates a problem: if we make another struct that looks like it
mixes in `Base` and pass it to the function, we could get
unexpected results:
```d
struct Other
{
int x = 5;
}
unittest
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c));
writeln(f(o));
}
```
The output from running `dub test` is as follows:
```
10
5
```
[...]
Is there any template-fu of which I am not aware that would
make the thing I am trying to do possible?
You can add a kind of tag with the mixin, that will allow to to
test if the type supplied to `f` is well a Base implementor:
```d
mixin template Base()
{
enum LookImABase = true;
int x(){ return 10; }
}
struct Child
{
mixin Base!();
}
auto f(T)(T arg)
if (is(typeof(T.LookImABase)))
{
return arg.x;
}
struct Other
{
int x = 5;
}
void main(string[] args)
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c)); // ok
writeln(f(o)); // error
}
```
This is what is called in D the "design by introspection". There
are alternatives way of doing that, notably with UDAs.
```d
mixin template Base()
{
enum Base;
@Base int x(){ return 10; }
}
```
But the introspection code is more complex (std.traits getUDA,
hasUDA)
Finally a different approach, with no introspection, is to use a
named mixin:
```d
mixin template Base()
{
enum Base;
int x(){ return 10; }
}
struct Child
{
mixin Base!() base;
}
auto f(T)(T arg)
{
return arg.base.x;
}
struct Other
{
int x = 5;
}
void main(string[] args)
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c));
writeln(f(o)); // error
}
```
which works but has the same problem as what lead you to ask your
question, for example if it turns out that the supplied argument
has unfortunately a `base` member that itself has a `x` member.
Re: Compiler interoperability
On Friday, 7 July 2023 at 08:19:28 UTC, Chris Katko wrote: For a specific system (Linux, e.g): What is the level of interoperability between the different D compilers; DMD, LDC, and GDC? It appears each one has different benefits, and, different experimental features. Link-time optimization for LDC. GDC offering static analysis. I imagine there are more. If I compile a D program with say, DMD, will every D library I include also have to use that same compiler Yes because of exception handling, the runtime functions are different. You can try and you'll see linking error because of a missing "*personality*", symbol. (and compiler version) from scratch and need recompiled? From version to version of a same vendor that might work but as phobos is not binary compatible (ABI of functions is allowed to change from a version to another) this is a bit the lottery. Or is there a pre-defined ABI that makes everything compatible? If I use shared libraries instead of static linking, does the situation change? Additionally, how do the debuggers GDB vs LLDB behave when compiled using a different brand D compiler? (e.g. demangling) Mangling is identical for each vendor (this is a language spec) but as mentioned, EH functions are different so the breakpoint set to break on `throw` for DMD (i.e `_d_throwdwarf`) will not work for `LDC` (i.e `_d_throw_exception`) I have my own experiences but I'm not sure if there's clear cut "yes, definitely it's [this case]." answers out there. So to conclude there's no interoperability
Re: key membership in multi-dimensional assoc. array
On Thursday, 15 June 2023 at 01:47:45 UTC, Paul wrote:
I found I can check for key membership in a multi-D aa...
```d
byte zKey = someval;
byte[byte][byte][byte] cubelist;
foreach(byte xK, yzcubelist; cubelist) {
foreach(byte yK, zcubelist; yzcubelist) {
foreach(byte zK, val; zcubelist) {
```
with this expression...
```d
if(zKey in cubelist[xK][yK])
```
Is there a way to check for membership in the x & y dimensions?
```d
if(yKey in cubelist[xK] ??? [zK])
```
*Thanks in advance for any ideas or solutions.*
`&&`
Re: assert/static assert message format difference
On Tuesday, 13 June 2023 at 16:46:26 UTC, DLearner wrote:
Only a small thing, but is it intended that:
```
void main() {
// static assert (false, "Static Assert triggered");
assert(false, "Assert triggered");
}
```
produces
```
core.exception.AssertError@staticassertex01.d(4): Assert
triggered
```
but removing the // produces
```
staticassertex01.d(3): Error: static assert: "Static Assert
triggered"
```
ie message surrounded by double-quotes?
internal detail.
Static assert will render the message by formatting an AST node,
i.e the StringExp (as the string has to be statically evaluable),
using a compiler module called the hdrgen, leading to have the
double quotes included, because the hdrgen is supposed to give
back the source code for a particulat node.
Runtime assert only know the string ptr and len, which are
runtime values. So... in that case it's more like a format %s,
that takes another path.
Re: byte and short data types use cases
On Friday, 9 June 2023 at 15:07:54 UTC, Murloc wrote:
On Friday, 9 June 2023 at 12:56:20 UTC, Cecil Ward wrote:
On Friday, 9 June 2023 at 11:24:38 UTC, Murloc wrote:
If you have four ubyte variables in a struct and then
an array of them, then you are getting optimal memory usage.
Is this some kind of property? Where can I read more about this?
Yes, a classsic resource is
http://www.catb.org/esr/structure-packing/
So you can optimize memory usage by using arrays of things
smaller than `int` if these are enough for your purposes,
It's not for arrays, it's also for members
```d
struct S1
{
ubyte a; // offs 0
ulong b; // offs 8
ubyte c; // offs 16
}
struct S2
{
ubyte a; // offs 0
ubyte c; // offs 1
ulong b; // offs 8
}
static assert(S1.sizeof > S2.sizeof); // 24 VS 16
```
this is because you cant do unaligned reads for `b`, but you can
for `a` and `c`.
but what about using these instead of single variables, for
example as an iterator in a loop, if range of such a data type
is enough for me? Is there any advantages on doing that?
Not really the loop variable takes a marginal part of the stack
space in the current function. You can just use `auto` and let
the compiler choose the best type.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Tuesday, 6 June 2023 at 14:23:59 UTC, Steven Schveighoffer
wrote:
On 6/5/23 11:33 AM, Basile B. wrote:
[...]
Ugh, don't do it that way. Always give opDispatch a template
constraint or it will suck to use.
Also, given the problem constraints, you can build the method
automatically using the string.
```d
auto opDispatch(string member, T)(auto ref T t)
if(member.startsWith("set"))
{
mixin(toLower(m[3]), m[4 .. $], " = t;");
}
```
-Steve
yeah I know that opDispatch is disliked because it is tried in a
SFINAE fashion, as citicized by Adam. But on the other side it's
the best opover.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:28:34 UTC, Paul Backus wrote:
Is there a reason you can't just make these fields `public`?
My bet is that OP actually wants to generate something like
```d
void setStrokeWidth(uint value)
{
if (value = strokeWidth) return;
strokeWidth = value;
redraw();
// or maybe...
// needRedraw = true;
}
```
that's a common pattern in 2D graphic libraries.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:28:34 UTC, Paul Backus wrote:
Is there a reason you can't just make these fields `public`?
My bet is that OP actually wants to generate something like
```d
void setStrokeWidth(uint value)
{
if (value = strokeWidth) return;
strokeWidth = value;
redraw();
// or maybe...
// needRedraw = true;
}
```
that's a common pattern in 2D graphics libraries
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:13:43 UTC, Basile B. wrote:
On Monday, 5 June 2023 at 13:57:20 UTC, Ki Rill wrote:
How do I generate `setX` methods for all private mutable
although I did not spent time on the setter body... I suppose
the question was more about the metprogramming technic, and
that you don't want a pre-mashed solution ;)
By the way...an other solution is to use
[opDispatch](https://dlang.org/spec/operatoroverloading.html#dispatch):
```d
class Color {}
class Rectangle {
private Color fillColor;
private Color strokeColor;
private uint strokeWidth;
auto opDispatch(string member, T)(auto ref T t)
{
static if (member == "setStrokeWidth") {}
else static if (member == "setStrokeColor") {}
else static if (member == "setFillColor") {}
else static assert(0, "cannot set " ~ member);
return this;
}
}
void main()
{
(new Rectangle)
.setStrokeWidth(0)
.setStrokeColor(null)
.setFillColor(null);
}
```
Sure the first solution takes advantage of D features but to
generate code that finally looks like C# or Delphi (`Set`, `Get`;
`property`, etc.)
On top of that I tend to prefer the later solution because
self-introspection based on `__traits` has corner issues,
especially when typecons-like structures are used for the members
(e.g sumtype, nullable, etc.).
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 13:57:20 UTC, Ki Rill wrote:
How do I generate `setX` methods for all private mutable
variables in my class? Do I need to use `__traits`?
I need this for my
[tiny-svg](https://github.com/rillki/tiny-svg) project to
generate `setX` methods for all Shapes.
Example:
```D
class Rectangle {
private immutable ...;
private Color fillColor;
private Color strokeColor;
private uint strokeWidth;
this(int x, int y) {...}
mixin(???);
// I need this:
Rectangle setFillColor(Color color) {...}
Rectangle setStrokeColor(Color color) {...}
Rectangle setStrokeWidth(uint color) {...}
}
```
Usage:
```D
new Rectangle(10, 10)
.setFillColor(Colors.white)
.setStrokeColor(Colors.black)
.setStrokeWidth(3);
```
You need to put an user attribute on the fieldd then to use
static introspection to generate the setters.
Very basically that works like that
```d
enum Set;
class Color {}
auto generateSetters(T)()
{
string result;
import std.traits;
static foreach (m; __traits(allMembers, T))
{{
alias member = __traits(getMember, T, m);
static if (hasUDA!(member, Set))
result ~= "void set" ~ m ~ "(" ~
typeof(member).stringof ~ "){}\n";
}}
return result;
}
class Rectangle {
@Set private Color fillColor;
@Set private Color strokeColor;
@Set private uint strokeWidth;
mixin(generateSetters!(Rectangle)());
}
void main()
{
with (new Rectangle) {
setstrokeWidth(0);
setstrokeColor(null);
setfillColor(null);
}
}
```
although I did not spent time on the setter body... I suppose the
question was more about the metprogramming technic, and that you
don't want a pre-mashed solution ;)
Re: Concepts like c++20 with specialized overload resolution.
On Saturday, 27 May 2023 at 13:23:38 UTC, vushu wrote: [...] Is there something equivalent in dlang, doesn't seem like d support specialized overload? D solution is called [template constraints](https://dlang.org/spec/template.html#template_constraints).
Re: Multiple destructors
On Friday, 26 May 2023 at 09:07:07 UTC, Alex Biscotti wrote:
Hello everyone! While researching the phobos library, I
discovered that a class can have multiple destructors if the
destructors are added via mixin injection. Accordingly, the
question is whether a description of such feature should be
added to the documentation, since the current description is a
bit confusing - ["There can be only one destructor per
class"](https://dlang.org/spec/class.html#destructors)?
This is not a compiler bug, mixin templates are allowed to
introduce a dtor; observe the output of
```d
import std;
mixin template AddNewDtor()
{
~this()
{
writeln("Mixin dtor");
}
}
class Foo
{
~this()
{
writeln("Class dtor");
}
mixin AddNewDtor;
}
void main()
{
{
Foo s = new Foo;
writeln("-- dtor effect --");
s.__dtor;
}
{
Foo s = new Foo;
writeln("-- xdtor effect --");
s.__xdtor;
}
writeln("-- auto generated destruction... --");
}
```
as you can see, the internal `__xdtor` function is designed to
call the two destructors, while `__dtor` only the "normal one",
i.e the one that 's not mixed in.
This is more a documentation bug IMO.
Re: D style - member functions
On Wednesday, 26 April 2023 at 18:24:08 UTC, DLearner wrote:
Consider:
```
struct S1 {
int A;
int B;
int foo() {
return(A+B);
}
}
struct S2 {
int A;
int B;
}
int fnAddS2(S2 X) {
return (X.A + X.B);
}
void main() {
import std.stdio : writeln;
S1 Var1 = S1(1, 2);
writeln("Total Var1 = ", Var1.foo());
S2 Var2 = S2(1, 2);
writeln("Total Var2 = ", fnAddS2(Var2));
return;
}
```
Of the two ways shown of producing the total from the same
underlying structure, which is the better style?
To make both version really equivalent you should rather write
int fnAddS2(ref S2 X) {
return (X.A + X.B);
}
the `this` for the member functions is a reference as obviously
you want to eventually mutate the members and not their copy.
What happened in your `fnAddS2` is that the whole stuff was
blitted and mutation of the members would have no effect on the
argument used in the call.
Further, do we care about the situation where there are many
variables of type 'S', which presumably means the function code
generated from S1 gets duplicated many times, but not so with
S2?
Your presumption is wrong. The code generated for a function is
not regenerated per instance. One version is enough to handle all
the instances as the instance is itself a parameter of the
function. What is happening for `foo()`, i.e the member function,
is that there is an hidden parameter. Depending on the language
the way the hidden argument is read might be slightly different
but you really should consider that
struct S1 {
int A;
int B;
int foo() {
return(A+B);
}
}
is like
struct S1 {
int A;
int B;
static int foo(ref S1 that) {
return(that.A+that.B);
}
}
or
struct S1 {
int A;
int B;
}
int foo(ref S1 that) {
return(that.A+that.B);
}
One problem of the hidden parameter is that for example
int foo(const ref S1 that) {
return(that.A+that.B);
}
cannot be expressed (at first glance)... how to qualify `const`
something that is hidden ? It's actually possible using a member
function attribute:
struct S1 {
int A;
int B;
int foo() const /*const is for the hidden parameter*/ {
return(A+B);
}
}
Re: alias Error: need 'this'
On Sunday, 19 March 2023 at 13:49:36 UTC, bomat wrote: Thanks for the suggested workaround, I can live with the `static` solution, I guess. I still don't understand why it's necessary, though. Since a `struct` is a value type and, as I understand it, stack allocated, what difference does it make to the compiler whether I alias `variableWithALongName` or `myStruct.memberWithALongName`? Shouldn't it be the exact same underlying mechanism? Thanks and regards bomat D aliases are for symbols, but what you try to alias is an expression. You might feel that what you request may work, but that's only a very particular case. Generally expressions cannot be aliased because without context they become polymorphic (or erather polysemous).
Re: Difference between using `import` with/without the colon
On Sunday, 19 March 2023 at 07:20:17 UTC, Jeremy wrote: Hello, is there any difference at all between the following lines, as an example: ```d import std.regex; import std.regex : matchFirst; ``` What technical differences does it make (except for having the identifier available), using the colon? Does it make any speed/optimization changes or am I better off just importing the whole module? The colon-form, aka "selective import" has for effect 1. to create a local alias so this can indeed speedup symbol lookups in the sense that search will succeed before looking in the scope of the imports. 2. to make non-selected symbols, i.e not listed in the colon right hand side, in the import not available. Note that using both makes no sense, but I guess you did that to express more clearly what you meant.
Re: const in functions
On Sunday, 12 March 2023 at 15:09:45 UTC, Salih Dincer wrote:
Hi,
[...]
// A, we can get its to guarantee us that parameters
// won't change:
auto inConst(T)(T a, const T b) // const
{ // it's not needed --^ but ^-- why can't this be used
Well you got the great answers to your questions already but I
like to add a comment that is that
**`const` parameters without `ref` are really moot.**
I whish at least that they could give the guarantee to be rvalues
(i.e have no address) but this is actually not the case. All the
D compilers will actually copy `const` parameters to locals,
making them lvalues, unless optimizations are requested(1).
See codegen : https://godbolt.org/z/vev1PGWh3.
This brings the idea that maybe a `rvalue` storage class could be
added to the language.
(1): Actually DMD does not drop the copy **at all**, even with -O.
Re: Using Windbg to debug D applications and unittests
On Saturday, 4 March 2023 at 19:19:26 UTC, Chris Piker wrote: On Monday, 27 February 2023 at 12:09:50 UTC, Basile B. wrote: At least this is what is done for the Dexed GDB widget, so that gdb breaks automatically when an Error or an Exception is new'd (https://gitlab.com/basile.b/dexed/-/blob/master/src/u_gdb.pas#L2072). Glad you mentioned Dexed. I Had been meaning to try it out but forgot about it. I just downloaded the deb and will give it a go. Thanks! The GDB widget wont work on windows I think. The point of my first answer was just to show you how to automatically break when something is thrown.
Re: Using Windbg to debug D applications and unittests
On Saturday, 25 February 2023 at 15:55:33 UTC, solidstate1991 wrote: I had a lot of trouble trying to get Visual Studio to catch handled exceptions, which would have been mandatory for debugging unittests, but I either forgot how to do it, or something have changed in either the newer versions of VS or the D compilers I use (LDC, DMD). [...] You must break on `_d_throwc` (windows), `_d_throwdwarf` (linux), `_d_throw_exception` (ldc). They are defined in - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh.d - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh_win32.d - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh_win64_posix.d At least this is what is done for the Dexed GDB widget, so that gdb breaks automatically when an Error or an Exception is new'd (https://gitlab.com/basile.b/dexed/-/blob/master/src/u_gdb.pas#L2072).
Re: What is the 'Result' type even for?
On Friday, 20 January 2023 at 03:11:33 UTC, Ruby The Roobster
wrote:
Take this example:
[...]
What is the purpose of this 'Result' type? To serve as a
generic range?
Yes this is a lazy input range. Use `.array` to yield directly as
a concrete value,
then you can append using `~=`.
Note that there are special functions to keep the laziness, e.g
`chain` to happen an input range to another element-compatible
input range
```
import std;
void main()
{
auto c = "a|b|c|d|e".splitter("|").chain(["f"]);
string[] e = ["a", "b", "c", "d", "e", "f"];
assert(c.equal(e));
}
```
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:19:49 UTC, Basile B. wrote: [...] It's always a wraparound (think modulo) but your examples with negative number can be explained because there are hidden unsigned to signed implicit convertions. That the only special things D does. forgot to say, you can use the dmd flag -vcg-ast to see the hidden rewrites
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:07:44 UTC, thebluepandabear
wrote:
I am reading through Ali's book about D, and he gives the
following examples for an overflow:
```D
import std.stdio;
void main() {
// 3 billion each
uint number_1 = 30;
uint number_2 = 30;
}
writeln("maximum value of uint: ", uint.max);
writeln("
number_1: ", number_1);
writeln("
number_2: ", number_2);
writeln("
sum: ", number_1 + number_2);
writeln("OVERFLOW! The result is not 6 billion!");
```
writeln((30LU + 30LU) % uint.max);
The result overflows and is 1705032704.
Also for the second example, it overflows and comes up with the
value of 4294967286:
```D
void main() {
uint number_1 = 10;
uint number_2 = 20;
writeln("PROBLEM! uint cannot have negative values:");
writeln(number_1 - number_2);
writeln(number_2 - number_1);
}
```
Also a fun one, the following produces 4294967295:
```D
uint number = 1;
writeln("negation: ", -number);
```
writeln( cast(uint) -(cast(int)1) );
But the book doesn't talk about why the D compiler came up with
these results (and it also goes for division/multiplication)
for the overflow (or maybe it did further down ?), as in it
didn't talk about the formula it used for calculating this
value.
I am curious as to what formula the D compiler uses for
calculating 'overflowed' values, if such thing exists? :)
Regards,
thebluepandabear
It's always a wraparound (think modulo) but your examples with
negative number can be explained because there are hidden
unsigned to signed implicit convertions.
That the only special things D does.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote:
To me, it appears that there are really two (_entirely
separate_) concepts:
A. Supporting the useful concept of variable length (but
otherwise entirely conventional) arrays;
B. Supporting a language feature that acts as a window to an
array, through which that array can be manipulated.
And currently these two concepts are combined.
Suggestion: it would be clearer if the two concepts were
separated:
1. Convert 'int[] VarArr;' so it produces a straightforward
_value-type_ variable array, called 'VarArr';
2. Implement a new concept 'int slice Window;' to produce an
object of type 'int slice', called 'Window'.
'Window' is a 'slice' into an int array, not an array itself
or even a variable.
Opinions?
I have implemented that in
[styx](https://gitlab.com/styx-lang/styx).
1. You have the type for dynamic arrays, called TypeRcArray,
syntax is `Type[+]`
2. You have the type for slices (what you describe as a window),
syntax is `Type[]`
but it is mostly obtained using expressions, e.g `mySlice =
myRcArray[lo .. hi]` or
`myStaticArray[lo .. hi]` or `myPointer[lo .. hi]`.
This sounded like a good idea but it [has appeared very
quickly](https://styx-lang.gitlab.io/styx/type.html#noteonlifetime) that slices are not so useful, especially when management is based on reference counting because then slices requires a form of management too. Here is why:
Main caracteristics of a slice are
- they cannot modify the identity of their sources. The identity
of the source is what makes the integrity of a dynamic array,
what makes their references countable. So it is the content
pointer and the length. In consequence you cannot change the
length of the source, you can only reduce the view. You can
change the elements in the view.
- the length and the pointer are cached as a value on the stack
while for a dynamic array this is stored before that data, on the
heap.
Problems start happening when you escape a slice
```d
struct S
{
var s32[] memberSlice;
}
function f(var S s): auto
{
var s32[+] a = (new s32[+])(2);
// problem 1 : `s` lifetime > `a` lifetime
s = (a[]).tupleof; // note: tuples are used in pace of
struct literals
// problem 2
return a[1 .. $]; // a is automatically decref'd on return
// so the caller pulls a dead heap block.
}
```
Essentially slices are only useful to be consumed locally,
typically
```d
while mySlice.length do
{
slice = slice[1..$];
}
```
And that's it. So at first glance slices are some cool,
simplified, functionally stripped down arrays but they introduce
new problems, at least when management of dynamic arrays is based
on reference counting. Those new problems can only be solved
using lifetime analysis (so a compile-time check... still better
than runtime ref counting however).
Re: What exact debugging information is added to the binary and how to parse it all?
On Friday, 13 May 2022 at 16:11:14 UTC, BoQsc wrote: Haven't used debuggers or debugged a lot just yet, but I've had this question in my mind and I'd like to inspect some debugging information manually. Are there some kind of documentation or specification and are there a lot of information that is hidden in a an average "debuggable" binary? if you're on linux then the debug information are generated in a format that's well specified called DWARF. DWARF essentially contain information about - translation unit filename - call stack - each instruction of the runtime code is associated to a location (allowing to put breakpoints) - the layout of user defined types (allowing to inspect instances) - the inheritance chain of user defined types - the variable types (alowing to inspect variables) That's a lot of information, they non-trivially increase the size of the binary, but this is required to debug a program. [learn more](https://dwarfstd.org/)...
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 15:31:03 UTC, Steven Schveighoffer
wrote:
On 5/12/22 11:18 AM, jmh530 wrote:
On Thursday, 12 May 2022 at 12:13:32 UTC, Basile B. wrote:
[snip]
```
is ( Type : TypeSpecialization , TemplateParameterList )
is ( Type == TypeSpecialization , TemplateParameterList )
is ( Type Identifier : TypeSpecialization ,
TemplateParameterList )
is ( Type Identifier == TypeSpecialization ,
TemplateParameterList )
```
I never remember those variants, because basically you never
need them...
They were required for std.traits and that's it.
What's the difference between a Type and Type Identifier?
Type is a type, Identifier is an identifier.
In general, after such expressions, Identifier is now declared
as an alias to the type, if the is expression was true. But in
special forms, it might be a portion of the type.
So e.g.:
```d
static if(is(Foo Bar == struct))
{
// inside here, it was determined that `Foo` was a type, and
it is a
// struct, and now, `Bar` is aliased to `Foo`
}
```
It's very confusing syntax though.
-Steve
yess that kind of stuff
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 14:06:13 UTC, Arjan wrote:
On Thursday, 12 May 2022 at 11:05:08 UTC, Basile B. wrote:
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
- Operator overloading in certain cases was confusing, I
remember that for one particular form once I had to use your
book instead of the official specs (when opSlice and opIndex
are combined)
I still have the thing :
```d
/**
* CharMap is an helper struct that allows to test
* if a char is within a set of characters.
*/
struct CharMap
{
private bool[] _map;
private dchar _min, _max;
private void setMinMax(dchar value) pure nothrow @safe
{
if (value <= _min) _min = value;
else if (value >= _max) _max = value;
_map.length = _max + 1 - _min;
}
/**
* Used in the construction process.
*
* Params:
* lo = The dchar that defines the range lower bound.
* hi = The dchar that defines the range upper bound
(inclusive).
*
* Examples:
* ---
* CharMap cm = CharMap['0'..'9'];
* ---
*/
static CharRange opSlice(int index)(dchar lo, dchar hi) pure
nothrow @safe @nogc
{
return CharRange(lo, hi);
}
/**
* Used in the construction process.
*
* Params:
* a = A list made of character slices, of single
characters or
*
* any other values whose type is implicitly convertible to
dchar.
*
* Examples:
* ---
* CharMap cm = CharMap['0'..'9', '.', 'f', 'd', 38, 39];
* ---
*/
static CharMap opIndex(A...)(A a) pure nothrow @safe
{
CharMap result;
// bounds
foreach(elem; a)
{
alias T = typeof(elem);
static if (isSomeChar!T ||
isImplicitlyConvertible!(T, dchar))
{
result.setMinMax(elem);
}
else static if (is(T == CharRange))
{
result.setMinMax(elem._min);
result.setMinMax(elem._max);
}
else static assert(0, "unsupported opIndex argument
type: " ~ T.stringof);
}
result._map[] = false;
foreach(elem; a)
{
alias T = typeof(elem);
static if (isSomeChar!T ||
isImplicitlyConvertible!(T, dchar))
result._map[elem - result._min] = true;
else static if (is(T == CharRange))
{
foreach(size_t i; elem._min - result._min ..
elem._max - result._min + 1)
result._map[i] = true;
}
}
return result;
}
/**
* Returns true if a character is within the map.
*
* Params:
* c = A character or any value convertible to a dchar.
*/
bool opBinaryRight(string op = "in", C)(C c) const pure
nothrow @safe @nogc
if (op == "in")
{
static if (isSomeChar!C || isImplicitlyConvertible!(C,
dchar))
{
if (_min > c || c > _max) return false;
else return _map[c - _min];
}
else static assert(0, `invalid argument type for
CharMap.opBinaryRight!"in"(): ` ~ C.stringof);
}
}
///
pure @safe unittest
{
CharMap cm = CharMap['a'..'f', '0'..'9' , 'A'..'F', '_', 9];
assert('a' in cm);
assert('b' in cm);
assert('c' in cm);
assert('d' in cm);
assert('e' in cm);
assert('f' in cm);
assert('g' !in cm);
assert('A' in cm);
assert('B' in cm);
assert('C' in cm);
assert('D' in cm);
assert('E' in cm);
assert('F' in cm);
assert('G' !in cm);
assert('0' in cm);
assert('4' in cm);
assert('9' in cm);
assert('_' in cm);
assert('%' !in cm);
assert('\t' in cm);
}
```
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 12:13:32 UTC, Basile B. wrote: On Thursday, 12 May 2022 at 11:50:59 UTC, Alain De Vos wrote: Some keywords are overloaded and have different meaning when used in a different place. Also some syntactic-sugar is way to much meaning too many different ways to do the same thing. I would prefer one way which is advised. `ptr1 is ptr2` VS `is(T==U)` is ok even if the keyword is reused for two different things. Problem is more (from https://dlang.org/spec/expression.html#is_expression) ``` is ( Type : TypeSpecialization , TemplateParameterList ) is ( Type == TypeSpecialization , TemplateParameterList ) is ( Type Identifier : TypeSpecialization , TemplateParameterList ) is ( Type Identifier == TypeSpecialization , TemplateParameterList ) ``` I never remember those variants, because basically you never need them... They were required for std.traits and that's it. Perfect example of reuse that is never a problem : `final`. what statically does `is` should have been several `__traits` I think.
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 11:50:59 UTC, Alain De Vos wrote: Some keywords are overloaded and have different meaning when used in a different place. Also some syntactic-sugar is way to much meaning too many different ways to do the same thing. I would prefer one way which is advised. `ptr1 is ptr2` VS `is(T==U)` is ok even if the keyword is reused for two different things. Problem is more (from https://dlang.org/spec/expression.html#is_expression) ``` is ( Type : TypeSpecialization , TemplateParameterList ) is ( Type == TypeSpecialization , TemplateParameterList ) is ( Type Identifier : TypeSpecialization , TemplateParameterList ) is ( Type Identifier == TypeSpecialization , TemplateParameterList ) ``` I never remember those variants, because basically you never need them... They were required for std.traits and that's it.
Re: What are (were) the most difficult parts of D?
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: What are you stuck at? What was the most difficult features to understand? etc. To make it more meaningful, what is your experience with other languages? Ali Overhall I think that D was not hard to learn because well designed (i.e intuitive). A few specific points however that I remember - Certain variant forms of the `is` Expression are not obvious (not intuitive), I'm pretty sure I still cant use them without a quick look to the specs. - Operator overloading in certain cases was confusing, I remember that for one particular form once I had to use your book instead of the official specs (when opSlice and opIndex are combined) The main difficulty I had is actually not specific to D. It was to accept that a GC is OK.
Re: Trait for "can be instantiated"?
On Tuesday, 10 May 2022 at 16:10:26 UTC, Ben Jones wrote:
On Tuesday, 10 May 2022 at 16:05:15 UTC, H. S. Teoh wrote:
Using wrapper structs, etc., for this is IMO total overkill.
Just use an enum for your token types. Something like this
would suffice:
That's basically what sumtype is going to do for me, but
(hopefully) more safely. Also, the token types are "user
defined," my lexer just grabs everything annotated with @Token
and passes those types/wrapped enums to sumtype.
How about being more explicit in the UDA ?
The idea would be to associate the enum value to a type or not:
```d
import std.traits;
import std.stdio;
struct Token(T);
struct Token(T...)
if (T.length == 0) { }
@Token!(string) enum str_tok;
@Token!(float) enum float_tok;
@Token!() enum lparen_tok;
void main()
{
alias toks = getSymbolsByUDA!(mixin(__MODULE__), Token);
static foreach (t; toks)
{{
alias U = getUDAs!(t, Token);
alias A = TemplateArgsOf!(U);
static if (A.length)
pragma(msg, "add a `" ~ A[0].stringof ~ "`for `" ~
t.stringof ~ "`");
else
pragma(msg, "no SumType data needed for `" ~
t.stringof ~ "`");
}}
}
```
Re: Make shared static this() encoding table compilable
On Monday, 14 March 2022 at 09:40:00 UTC, zhad3 wrote: Hey everyone, I am in need of some help. I have written this Windows CP949 encoding table https://github.com/zhad3/zencoding/blob/main/windows949/source/zencoding/windows949/table.d which is used to convert CP949 to UTF-16. After some research about how to initialize immutable associative arrays people suggested using `shared static this()`. So far this worked for me, but I recently discovered that DMD cannot compile this in release mode with optimizations. `dub build --build=release` or `dmd` with `-release -O` fails: ``` code windows949 function zencoding.windows949.fromWindows949!(immutable(ubyte)[]).fromWindows949 code table function zencoding.windows949.table._sharedStaticCtor_L29_C1 dmd failed with exit code -11. ``` That's a compiler bug of type "ICE", the compiler crashes. Try reducing to a simple module that does not use phobos and report to bugzilla.
Re: Detecting manifest contants
On Saturday, 12 March 2022 at 18:49:32 UTC, Anonymouse wrote:
I'm introspecting structs, and I ran into an issue where
`__traits(derivedMembers)` includes manifest constant enums in
the returned tuple.
What is the correct way to statically detect these? The
immediate thing that springs to mind is `is(symbol == enum)`,
but it's not it.
Currently I'm testing if a function that takes the address of
the member compiles, and I think it works, but like with
everything `__traits(compiles)` it strikes me as it might not
be the right way to go about things.
```d
struct Foo
{
int i;
enum k = 42;
}
void main()
{
foreach (memberstring; __traits(derivedMembers, Foo))
{
static if (__traits(compiles, { Foo f; auto ptr =
&__traits(getMember, f, memberstring); }))
{
// ...
}
}
}
```
What else can I try?
A way is to try declaring an enum with the value returned by the
`getMember` trait.
```d
/**
* Indicates wether something is a value known at compile time.
*
* Params:
* V = The value to test.
* T = Optional, the expected value type.
*/
template isCompileTimeValue(alias V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isKnown = is(typeof((){enum v = V;}));
static if (!T.length)
enum isCompileTimeValue = isKnown;
else
enum isCompileTimeValue = isKnown && is(typeof(V) ==
T[0]);
}
///
unittest
{
string a;
enum b = "0";
enum c = 0;
static assert(!isCompileTimeValue!a);
static assert(isCompileTimeValue!b);
static assert(isCompileTimeValue!c);
static assert(isCompileTimeValue!(b,string));
static assert(isCompileTimeValue!(c,int));
static assert(!isCompileTimeValue!(c,char));
static assert(!isCompileTimeValue!(char));
}
/// ditto
template isCompileTimeValue(V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isCompileTimeValue = false;
}
```
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Sunday, 27 February 2022 at 16:14:31 UTC, Matheus wrote: Hi, [...] After one minute I think I get: rdmd playground.d Server error: Thanks, Matheus. This was [reported before]. Apparently this would be caused by a timeout. [reported before]: https://forum.dlang.org/post/skc2dd$1o52$1...@digitalmars.com
Re: Set output location for dub --single
On Sunday, 27 February 2022 at 16:58:34 UTC, Chris Piker wrote: Hi D Coming from a python background it's worked well to organize my D projects as a dub `sourceLibrary` and then to put top level programs in a directory named `scripts` that are just dub single file projects. So the layout looks like this: [...] After reading over the dub documentation I don't see a general way to override project options via the command line, but maybe it's there and I couldn't understand what the dub docs were trying to say. That 's not exactly what you ask for but you can define the path in the embedded recipe (targetPath) ```d #!/usr/bin/env dub /+ dub.sdl: dependency "mypackage" version="*" path=".." targetPath "./bin" +/ ```
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 11:12:38 UTC, partypooper wrote: On Monday, 21 February 2022 at 11:07:55 UTC, Basile B. wrote: Yeah there must be another one then. Something actionnable is the documentation. What about Mike Parker answer? if nothrow fails that's because things are checked. We could imagine a second flow analysis leading to better error messages. You see, instead of the generic error message you get now. "If it fails, let's see why"
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 11:05:42 UTC, partypooper wrote: On Monday, 21 February 2022 at 10:58:26 UTC, Basile B. wrote: more likely UTFException actually Additionaly catching UTF and Conv exceptions doesn't help. Yeah there must be another one then. Something actionnable is the documentation.
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I can't
make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
https://issues.dlang.org/show_bug.cgi?id=22800
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:53:56 UTC, Basile B. wrote:
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I
can't make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
more likely UTFException actually
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:53:56 UTC, Basile B. wrote:
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I
can't make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
However you're totally right to open a discussion, the
documentation is innacurate:
in https://dlang.org/phobos/std_stdio.html#.writeln
just StdioException is mentioned ;)
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I can't
make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
Re: keyword as struct field
On Sunday, 20 February 2022 at 11:08:55 UTC, partypooper wrote:
Hello, I'm new to D.
Title is self described, is it possible to use keyword as
struct field?
Maybe it is XYproblem, so here I will describe a little what I
need.
I'm parsing some json currently with
[mir-ion](https://code.dlang.org/packages/mir-ion)
(better/simpler suggestions for only json de/serialization?),
that has "version" as one of it's keys, so I can't use that as
field in my struct. Maybe some annotation in mir library to
parse "version" into other struct field name, can't find though
(its docs pretty concise).
I have a library solution based on opDispatch +
__traits(getMember):
```d
/**
* Mixin template allowing to use a field as if its identifier is
a D keyword.
* Note that this only works with `__traits(getMember)`.
* Params:
* keywordFieldPairs = An array of keyword and field pairs.
*/
template FieldOfKeyword(string[2][] keywordFieldPairs)
{
template opDispatch(string member)
{
static foreach (pair; keywordFieldPairs)
static if (member == pair[0])
mixin("alias opDispatch = ", pair[1], ";" );
}
}
///
unittest
{
struct Foo
{
mixin FieldOfKeyword!([["scope", "scope_"],["class",
"class_"]]);
string scope_;
string class_;
}
Foo foo;
__traits(getMember, foo, "scope") = "The Universe";
assert(__traits(getMember, foo, "scope") == "The Universe");
__traits(getMember, foo, "class") = "Atom";
assert(__traits(getMember, foo, "class") == "Atom");
}
```
never used it TBH.
Re: Declaring a reusable formula and using it in other scopes.
On Saturday, 12 February 2022 at 12:36:06 UTC, BoQsc wrote: `bool nextArgumentDoesNotReachEndOfArray = i + 1 < args.length;` How can I declare it out of scope and reuse it in any scope that has `i` and `args.length` declared? Here is an ugly solution, just to encourage someone else to post better: ```d enum n = "i+1The problem of the initial problem is to have automatic capture of `i` and `args` in any scope... Lost cause ?
Re: Is there an equivavlent to C# boxing in D?
On Saturday, 12 February 2022 at 16:50:16 UTC, H. S. Teoh wrote: Without alias this it would be harder to pull off, yes. I don't see any other way that allows to unbox *implictly*. That would require a new operator. Something like opCast but more permissive, that works without `cast`.
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:51:34 UTC, Basile B. wrote:
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote:
On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh
wrote:
[...]
that explains ldc perhaps (although i don't really get it.
It's cast to mutable and being assigned to mutable.
in any case... ldc doesn't like it, but dmd is fine with this
??
your cast from immutable to mutable is an undefined behavior,
this may work or not.
Note that casting away a const qualifier and then mutating is
undefined behavior, too, even when the referenced data is
mutable. This is so that compilers and programmers can make
assumptions based on const alone. For example, here it may be
assumed that f does not alter x:
(from https://dlang.org/spec/const3.html#removing_with_cast)
the D safe way :
```
void main() @safe
{
char[] palindrome = "able was I ere I saw elba".dup;
writeln(palindrome);
writeln(palindrome.reverse);
}
```
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote: On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh wrote: [...] that explains ldc perhaps (although i don't really get it. It's cast to mutable and being assigned to mutable. in any case... ldc doesn't like it, but dmd is fine with this ?? your cast from immutable to mutable is an undefined behavior, this may work or not. Note that casting away a const qualifier and then mutating is undefined behavior, too, even when the referenced data is mutable. This is so that compilers and programmers can make assumptions based on const alone. For example, here it may be assumed that f does not alter x: (from https://dlang.org/spec/const3.html#removing_with_cast)
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote: On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: As for now, I know no compiler that can do that. GCC can do it. Somewhat notoriously, you meant "infamously" ? LTO can lead to bugs from underspecified asm constraints following cross-TU inlining. I have missed the LTO train TBH, gotta try that once...
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 08:58:43 UTC, rempas wrote: I've seen from [this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case? Yes, this is still the case. A particularity of DMD inliner is that it does its job in the front-end, so inlining asm is totally impossible. Then, even if inlining was done in the backend inlining of asm would not be guaranteed because the byte code is generated at a very late stag, which causes problem with the registry allocator, the preservation of the stack, etc. For example ldc2 does not inline a trival asm func https://godbolt.org/z/1W6r693Tq. As for now, I know no compiler that can do that.
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote: [...] With nothing to the contrary, I'd take "must be terminated by a null pointer" as "can't itself be a null pointer". ah yeah, and thanks, of course ... how would the count of arg be known without the sentinel...
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
The following code, on linux
[...]
What do you think ?
Forgot to say that this change
```diff
- execv("a", null);
+ execv("a", ["whatever".ptr].ptr);
```
makes the problem goes away, so it would be caused by how `null`
args are handled, presumably.
Possible runtime bug in preprocessing of command line arguments passed to the D main
The following code, on linux
```d
module runnable;
extern(C) int execv(const char* p, const char** args);
immutable src = `
import std.getopt;
void main(string[] args)
{
bool c;
getopt(args, "c", );
}
`;
void prepareProgram()
{
import std.process : execute;
import std.file : write;
write("a.d", src);
execute(["dmd", "a.d"]);
}
void main(string[] args)
{
prepareProgram();
execv("a", null);
}
```
results in a std.getopt exception:
object.Exception@/usr/include/dmd/phobos/std/getopt.d(423):
Invalid arguments string passed: program name missing
Context is a program not written in D that uses execv to call a D
program that uses getopt.
What do you think ?
Re: How to make a function that accepts optional struct but can accept struct literal too
On Friday, 15 October 2021 at 20:33:33 UTC, JN wrote: Is there some nice way of achieving something like this C99 code in D? [...] The [literal](https://www.ibm.com/docs/sr/xl-c-and-cpp-aix/13.1.0?topic=operators-compound-literal-expressions) in the C version creates an alloca too but it's hidden.
Re: Better debugging?
On Sunday, 3 October 2021 at 22:21:45 UTC, Tim wrote:
Hi all,
I am currently using GDB within VScode with the -gc DMD2
compiler switch and my debugging is not amazing. Whenever I
inspect a struct/object it just shows me the pointer rather
than the object information and strings come up as a gross
array of the characters. Does anybody happen to know whether
LDB is better or how I can have a nicer debug environment?
Thanks in advance
1. LDC2 generate better debug infos, especially for classes,
although this might change from the next DMD version (it will
include the inherited fields, just like LDC2).
2. to inspect objects you must evluate the dereference of an
instance.
for example for a project, if i eval `d`, a class instance VS
`*d`, the pointed chunk of memory.
| name| value
| ---| ---
d | 0x77b4b480
s | 0x77b506c0
locParentAggr | 0x0
symParentAggr | 0x0
thisParentAggr | 0x0
needInheritance | false
this | 0x77b506c0
loc | 0x77b43ea0
evaluation of `d` | 0x77b4b480
evaluation of `*d` | { = {
= {}, startPos = {line = 18, column = 1}, ir =
0x0}, name = 0x77b4e5e0, symbol = 0x77b506c0, attributes
= 0x0, asTypeDeclared = 0x77b50720, kind = 34 '\"',
protection = 0 '\\000', progress = 0 '\\000'}
I don't know how the debugger gui you use works, here this is
just a paste of dexed-ide table for locals and custom
expressions. More often I use a debug popup:
[A similar feature seems possible in
vscode](https://github.com/microsoft/vscode-java-debug/issues/444), maybe post a feature request to the extension developpers, as the debug popup is often very handy (no need to type expressions, as they are already there in the code !)
Re: Mutually recursive template expansion
On Saturday, 2 October 2021 at 08:48:24 UTC, Stephen wrote:
Is this by design?
No but it's easily explainable.
## without mixins
```d
struct Ar { Br b; ubyte a; }
struct Br { ubyte b; }
```
`Ar` semantic starts, members are analyzed, that begins with the
variable declaration `Br b`. `Br` type needs to be resolved. `Br`
can be found in the AST as it is declared manually. Now `Br` is
run and finally `Ar` sema continues.
## with mixins
```d
mixin(q{struct Ar { Br b; ubyte a; }});
mixin(q{struct Br { ubyte b; }});
```
The first mixin is compiled (`compileIt()` in dmd code base).
The AST is now the same as obtained by parsing
```d
struct Ar { Br b; ubyte a; }
mixin(q{struct Br { ubyte b; }});
```
`Ar` semantic starts, members are analyzed, that begins with the
variable declaration`Br b`. But `Br` cannot be resolved because
**it is not yet in the AST** and the symbol tables.
Re: 0 cost template instantiation
On Thursday, 30 September 2021 at 02:02:19 UTC, Hipreme wrote:
On Thursday, 30 September 2021 at 01:56:42 UTC, Basile B. wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a
symbol, it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSymbol(_dll, (s.stringof~"\0").ptr);
else
s = cast(typeof(s))_loadSymbol(_dll, (symName~"\0").ptr);
}
```
The main problem is that this function is costing 2KB per
instantiation, which is something pretty high. Specially if I
inline, there is almost no cost when compared to its inline
version. Trying to use pragma(inline, true) didn't do
anything too.
cant you just use a regular functions ? loading happens at
runtime right ?
The entire reason to having that function is having that syntax
which would pretty much do the monkey's job for me:
Instead of writing
myFunction = cast(typeof(myFunction))_loadSymbol(_dll,
"myFunction");
I could write
loadSymbol!myFunction;
But if no other way is found of doing that, I will do the
massive rewriting.
Anyway, I don't think the problem is not in the way I'm doing,
but the output, as that template could easily be inlined
well ok. Maybe try to see if overloads
void loadSymbol(alias s)()
void loadSymbol(alias s, string symName)()
helps. That save the static if. In addition there's the null
sentinel that can save a bit of memory, as you've been suggested.
Re: 0 cost template instantiation
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSymbol(_dll, (s.stringof~"\0").ptr);
else
s = cast(typeof(s))_loadSymbol(_dll, (symName~"\0").ptr);
}
```
The main problem is that this function is costing 2KB per
instantiation, which is something pretty high. Specially if I
inline, there is almost no cost when compared to its inline
version. Trying to use pragma(inline, true) didn't do anything
too.
cant you just use a regular functions ? loading happens at
runtime right ?
Re: Which operators cannot be overloaded and why not?
On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote:
On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote:
- condition al expression ` cond ? exp : exp `
And many other boolean operators, unary !, binary && and ||
https://dlang.org/spec/operatoroverloading.html lists all the
overloadable operators, and
https://dlang.org/spec/expression.html has all the operators,
so "which operators" is a matter of close comparison. "why not"
is much harder to answer.
Oh! I have never noticed that `&&` and `||`, despite of being
quite "ordinary" binary ops are not overloadable.
In
[styx](https://styx-lang.gitlab.io/styx/attribute.html#operatorattribute) that works because, although inspired by the D way, in the sense that overloads are implemented in custom types, the selection is done using an expression template
```d
struct S {
@operator(a && b) function andAnd(T other): auto {return
false}
}
```
So as long as the expression in the attribute argument looks like
a valid expression the stuff is found (and the supprot code in
the compiler is super simple), e.g with code in a body:
```d
e1 && e2; // look if e1 is an aggregate and if it contains
@operator(a && b)
e1 + e2; // look if e1 is an aggregate and if it contains
@operator(a && b)
```
While D uses specific identifier + templates value param for
strings.
(note that only the equivalent of D opBinary**Right** works...)
anyway. zorry for this off-topic.
Re: GDC - program runs in one thread, DMD - in 4 threads, why?
On Friday, 10 September 2021 at 09:27:49 UTC, eugene wrote: Here is test program (which is using DList aggressively) [...] Can this (really unwanted) behavior be disabled in DMD? I do not want to have multiple threads, a program (real program, not the test above) has to be single-threaded. system used: @dexp ~ $ cat /etc/debian_version 8.11 most recent dmd has a GC that collect in threads. it can be tuned but I dont find the documentation for this right now.
Re: Absence of isAllocator trait
On Saturday, 4 September 2021 at 19:43:27 UTC, Per Nordlöw wrote: Is there a reason for the absence of an `isAllocator` trait under `std.experimental.allocator`? I had ask a similar Q once and I've been told that (more or less): It's because the clients of an allocator should rather statically check for specific traits of an allocator, there are too many possible permutations of capabilities possible, not all can allocate and deallocate, not all can reallocate, and so on. actually I'm 100% sure that what you want is `isMallocator` and not `isAllocator` ;)
Re: issue with static foreach
On Thursday, 22 July 2021 at 05:57:02 UTC, jfondren wrote:
On Thursday, 22 July 2021 at 03:43:44 UTC, someone wrote:
... it compiles no-more: Error: found `End of File` when
expecting `}` following compound statement
... what I am doing wrong ?
You'll get the same error from this code:
```d
unittest {
mixin("{");
mixin("}");
}
```
https://dlang.org/spec/statement.html#mixin-statement
The text contents of the string must be compilable as a valid
StatementList, and is compiled as such.
Each individual string has to compile on its own. You'll have
to concatenate strings and then mixin them.
There was a similar issue on bugzilla, and the consensus for
closing is that mixins are not supposed to introduce scopes (or
unmatched scopes, let's say).
See https://issues.dlang.org/show_bug.cgi?id=3858#c4
However the specs are indeed not up to date with that.
Re: LLVM asm with constraints, and 2 operands
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote: On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote: - **=x** says "returns in whatever is has to" - **x** (1) is the constraint for input `a`, which is passed as operand **$0** - **x** (2) is the constraint for input `b`, which is passed as operand **$1** $0 is actually the output operand, $1 is `a`, and $2 is `b`. [...] Note: inline asm syntax and resulting asm in AT syntax, *not* Intel syntax. yeah thnaks for the precision, I totally forgot about that. And what about the `extern(C)` issue ? Does it make sense to be used when the parameters are int4 ?
Re: LLVM asm with constraints, and 2 operands
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote: On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote: [...] Thanks. Indeed that seems to work even when inline and optimized. Registers are spilled to stack. A minor concern is what happens when the enclosing function is extern(C) => https://d.godbolt.org/z/s6dM3a3de I need to check that more... I think this should be rejected just like when you use D arrays in the interface of an `extern(C)` func, as C has no equivalent of __vector (afaik).
Re: LLVM asm with constraints, and 2 operands
On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote: On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote: On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote: [...] Thanks. Indeed that seems to work even when inline and optimized. Registers are spilled to stack. A minor concern is what happens when the enclosing function is extern(C) => https://d.godbolt.org/z/s6dM3a3de I need to check that more... I think this should be rejected just like when you use D arrays in the interface of an `extern(C)` func, as C has no equivalent of __vector (afaik). but in any case there's a bug.
Re: LLVM asm with constraints, and 2 operands
On Sunday, 18 July 2021 at 11:42:24 UTC, Guillaume Piolat wrote:
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4("paddd $1,$0","=x,x",a, b);
If you know how to do it => https://d.godbolt.org/z/ccM38bfMT
it would probably help build speed of SIMD heavy code, also -O0
performance
Also generating the right instruction is good but it must
resist optimization too, so proper LLVM constraints is needed.
It would be really helpful if someone has understood the
cryptic rules of LLVM assembly constraints.
Yeah I can confirm it's aweful. Took me hours to understand how
to use it a bit (my PL has [an
interface](https://styx-lang.gitlab.io/styx/primary_expressions.html#asmexpression) for LLVM asm)
You need to add a "x" to the constraint string
return __asm!int4("paddd $1,$0","=x,x,x",a, b);
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed as
operand **$0**
- **x** (2) is the constraint for input `b`, which is passed as
operand **$1**
So the thing to get is that the output constraint does not
consume anything else, it is standalone.
Re: Faster Dlang Execution
On Tuesday, 8 June 2021 at 17:10:47 UTC, seany wrote: Hello How can I increase the speed of executable files created via : `dub build -b release` try `dub build -b release --compiler=ldc2` Then you can set some specific DFlags for ldc, like -O3 or --mcpu I am unable to parallellise all of it, as it depends on part of the result being calculated before something else can be calculated. I have many `nonsafe, nonpure` functions. `nothrow` presumably opens optimisation opportunities with the stack management, although it's not verified Classes are virtual by defalut. set them final when possible. When not possible set the virtual methods that are not overridden `final`. Profiling doesn't help, because different input is causing different parts of the program to become slow. if you're on linux, you can try callgrind + kcachegrind instead of builtin intrumentation. Thank you.
Re: Compiler Explorer Assembly Output for C, C++ and D (dlang)
On Thursday, 27 May 2021 at 08:47:50 UTC, Tariq Siddiqui wrote: When using Compiler Explorer (https://godbolt.org/) to compare assembly output of simple programs, why D language assembly output is so long compared to C or C++ output. The simple square function output is the same for C, C++, and D, but the D output has additional lines that are not highlighted when hovering over the square function in the source code. - What are these additional lines? - How can I remove these lines from being generated? In addition to other answers, see https://forum.dlang.org/post/myrjutqyzpzlyltrd...@forum.dlang.org
Re: cannot I override and mark it as private?
On Wednesday, 12 May 2021 at 19:35:31 UTC, Jack wrote: I'd to change the visibility of a method overrided from public to private but it doesn't work tho to protected it does. Why is that? ... Why is that? why must I leave it accessible somehow (even if it's protected) to all derived class of my derived class? See specs : https://dlang.org/spec/attribute.html#visibility_attributes Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden.
Re: alias & local function
On Monday, 10 May 2021 at 01:25:10 UTC, Alain De Vos wrote:
This does not:
```
import std.stdio;
void main()
{
int afunction(int x){return x;};
it's not static so -> context -> delegate
alias myint = int;
myint i=5;
alias tfunction = int function(int);
tfunction f = & afunction;
writeln(f(1));
}
```
It gives compile error :
Error: cannot implicitly convert expression of type
int delegate(int x) pure nothrow @nogc @safe to int
function(int)
add static in the second case.
Re: class grammar
On Friday, 7 May 2021 at 18:07:45 UTC, Nick wrote:
The class grammar, as defined in the D language specification
...
is not clear to me how a user-defined type (such as a class or
interface) is also a 'BasicType' (as defined by the grammar).
However, the compiler only accepts classes or interfaces as a
base type.
Just like a natural language what is grammatically correct is not
necessarily semantically correct.
In the case of the inherithence list it's easier to choose
'BasicType' because 'TypeOf' and 'QualifiedIdentifier' can both
be solved to a class or an interface.
With this example:
```
alias B = int;
class A : B {}
```
you can see that the semantic check to reject `int` is necessary
anyway.
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Sunday, 2 May 2021 at 15:41:13 UTC, kdevel wrote:
On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:
Hard breakage is not acceptable, even if the goal is to
introduce a more correct behavior.
I still wonder why module names are taken as a candidates for
types and functions in the first place. Isn't there a symbol
table for module names separate from that for type and function
names?
I dont think so. That would lead to special cases in fully
qualified lookups.
Lookups must follow the reverse lexical order of declarations so
an import adds a symbols in the current scope.
BTW during the PR review the problem you encounter [was
anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si I guess you're stuck with [the author answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e "this worked because of a special case".
Again you can still try to get the change turn into a deprecation
first, that'd be legit.
Just checked how things are done in another language where
modules are called “packages”:
I have checked in styx too. This does not work either but for
another reason that D, that is that overloads are explicit,
meaning all names unique in a given scope, so
```styx
§s.sx
unit s;
§u.sx
unit v;
struct s {}
import s;
var s s1;
```
gives
u.sx:8:8: error, symbol `s` already declared line 6
same when the import and the var decls positions are exchanged.
Re: Fake IFTI-compatible struct constructors
On Saturday, 1 May 2021 at 21:57:54 UTC, Chad Joan wrote: I came up with a couple techniques for making it seem like templated structs deduce their template parameters from constructor invocations. These are given further down in the post. ... However, this was not to be. Rather, this setup doesn't work at all, because IFTI doesn't seem to work on function-templates with alias parameters. Yes your observation is correct. That should work but this is currently not implemented and referenceced as [issue 20877](https://issues.dlang.org/show_bug.cgi?id=20877)
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Friday, 30 April 2021 at 21:41:43 UTC, kdevel wrote: On Friday, 30 April 2021 at 19:17:14 UTC, user1234 wrote: [...] Likely a side effect of https://github.com/dlang/dmd/pull/12178 but according to me the new behavior is correct. It breaks my code. I have files named $C containing struct or class $C plus some other stuff. Using the workaround means to switch to selective imports for all used types/functions within this module. Found another workaround: I created a symlink here -> . and replaced all imports $C with here.$C. In some places I had to remove an artificial "prefix" ($C.$C -> $C). I understand the situation but I can opnly suggest to fill a report. Hard breakage is not acceptable, even if the goal is to introduce a more correct behavior.
Re: Derived type
On Wednesday, 31 March 2021 at 04:49:50 UTC, novice3 wrote:
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
yeah template instances are identified using the parameters
identifiers, then the alias is just a syntactic shortcut to that,
not producing a new symbol with a unique mangle... but the
message is correct assuming you want void* to be rejected.
That being said you can still use a string mixin if the messages
have to be correct
---
string genTypeDef(TBase)(string name)
{
return "struct " ~ name ~ "{" ~ TBase.stringof ~ " payload;
alias payload this;}";
}
mixin(genTypeDef!(void*)("Xobj"));
void foo (Xobj obj) {}
---
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: Using onOutOfMemoryError in C wrappers
On Wednesday, 24 March 2021 at 08:51:34 UTC, Per Nordlöw wrote:
On Wednesday, 24 March 2021 at 08:31:19 UTC, Basile B. wrote:
There are several ways to do that. In addition to
onOutOfMemoryError, you can use a static instance
void v() @nogc nothrow
{
__gshared oom = new OutOfMemoryError();
auto X* = X_create();
if (X is null)
throw oom;
}
How is that better than
void v() @nogc nothrow
{
auto X* = X_create();
if (X is null)
onOutOfMemoryError();
}
considering the fact that accessing `__gshared` state is
neither `@safe` nor `pure`? Which, in turn, makes `v()`
unconditionally unsafe and unpure regardless of safety and
purity of `X_create()`.
In now way. But in your question you mentioned @nogc nothrow and
not @safe and pure.
Re: Using onOutOfMemoryError in C wrappers
On Wednesday, 24 March 2021 at 07:58:22 UTC, Per Nordlöw wrote:
When wrapping C code that tries to allocate memory resources
via functions such as
X* X_create();
should one call `onOutOfMemoryError();` upon null return?
Making more D wrappers `nothrow @nogc`.
There are several ways to do that. In addition to
onOutOfMemoryError, you can use a static instance or `if (somePtr
is null) assert(0);`
void v() @nogc nothrow
{
__gshared oom = new OutOfMemoryError();
auto X* = X_create();
if (X is null)
throw oom;
}
Re: Checking for manifest constants
On Friday, 5 March 2021 at 08:23:09 UTC, Bogdan wrote:
I was using a trick with dmd to check for manifest constants
which worked until dmd v2.094. Yesterday I tried it on the
latest compiler and it failed with:
source/introspection/manifestConstant.d(37,28): Error: need
this for name of type string
source/introspection/type.d(156,13): Error: value of this is
not known at compile time
any ideas how to fix it? or, is it a bug with dmd?
```
/// Check if a member is manifest constant
bool isManifestConstant(T, string name)() {
mixin(`return is(typeof(T.init.` ~ name ~ `)) &&
!is(typeof(` ~ name ~ `));`);
}
/// ditto
bool isManifestConstant(alias T)() {
return is(typeof(T)) && !is(typeof());
}
enum globalConfig = 32;
int globalValue = 22;
unittest {
struct Test {
enum config = 3;
int value = 2;
}
static assert(isManifestConstant!(Test.config));
static assert(isManifestConstant!(Test, "config"));
static assert(isManifestConstant!(globalConfig));
static assert(!isManifestConstant!(Test.value));
static assert(!isManifestConstant!(Test, "value"));
static assert(!isManifestConstant!(globalValue));
}
void main() {}
```
Hello, you can use this template instead:
template isManifestConstant(alias V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isKnown = is(typeof((){enum v = V;}));
static if (!T.length)
enum isManifestConstant = isKnown;
else
enum isManifestConstant = isKnown && is(typeof(V) ==
T[0]);
}
The optional T is to verify if it is a compile time constant of a
certain type.
the tests you wrote and that are not based on a string pass.
Re: Dimensions in compile time
On Monday, 8 February 2021 at 13:27:14 UTC, Vindex wrote:
Thanks everyone!
The solution that works for me now looks like this:
template ndim(T) {
static if (std.traits.isArray!T) {
static if (is(typeof(T.init[0]))) {
alias SubArrayType = typeof(T.init[0]);
enum ndim = ndim!SubArrayType + 1;
}
else enum ndim = 1;
}
else enum ndim = 0;
}
unittest {
assert(ndim!(int[]) == 1);
assert(ndim!(int[][]) == 2);
assert(ndim!(int[4][3]) == 2);
assert(ndim!(int[][2][]) == 3);
assert(ndim!(string) == 1);
}
Nice. You should look at Rumbu solution too. It possibly has a
better behavior toward the recursive expansion. Also interesting
to learn the more advanced use of "is".
Re: Dimensions in compile time
On Monday, 8 February 2021 at 13:13:33 UTC, Basile B. wrote:
On Monday, 8 February 2021 at 13:09:53 UTC, Rumbu wrote:
On Monday, 8 February 2021 at 12:19:26 UTC, Basile B. wrote:
[...]
dimensionCount!string should be 2.
My take without std.traits:
template rank(T: U[], U)
{
enum rank = 1 + rank!U;
}
template rank(T: U[n], size_t n)
{
enum rank = 1 + rank!U;
}
template rank(T)
{
enum rank = 0;
}
yeah you're right, strings were a special case (I remember now)
so that stuff could be stored as literals.
well to OP just dont use my dimensionCount template ^^. it should
have been declared with the "package" protection in first place;
not public.
Re: Dimensions in compile time
On Monday, 8 February 2021 at 13:09:53 UTC, Rumbu wrote:
On Monday, 8 February 2021 at 12:19:26 UTC, Basile B. wrote:
[...]
dimensionCount!string should be 2.
My take without std.traits:
template rank(T: U[], U)
{
enum rank = 1 + rank!U;
}
template rank(T: U[n], size_t n)
{
enum rank = 1 + rank!U;
}
template rank(T)
{
enum rank = 0;
}
yeah you're right, strings were a special case (I remember now)
so that stuff could be stored as literals.
