Re: Operator "+=" overloading for class?
On Wednesday, 20 December 2023 at 02:56:24 UTC, Steven Schveighoffer wrote: Instead you are trying to reassign the `this` reference, which is a local (and also forbidden). Think about it a second, your `this + rhs` is going to allocate a *new* object. Then if the assignment to the local `this` parameter succeeded, what happens outside the member function? The true reference that is calling this will not be updated! The only way to do this I can see is to reimplement for op=, or maybe perform the operation and swap the guts out. -Steve Thank you for such a detailed explanation! That does make sense.
Re: std.int128 not working with -betterC enabled
On 21/12/2023 10:51 AM, Renato wrote: On Wednesday, 20 December 2023 at 19:11:15 UTC, Richard (Rikki) Andrew Cattermole wrote: Yes that is to be expected. It is not templated, and hasn't been compiled into your program. How do I compile that into my program? You copy the file from druntime into your project, and add it to your programs compile command.
Re: std.int128 not working with -betterC enabled
On Wednesday, 20 December 2023 at 19:11:15 UTC, Richard (Rikki) Andrew Cattermole wrote: Yes that is to be expected. It is not templated, and hasn't been compiled into your program. How do I compile that into my program?
Re: std.int128 not working with -betterC enabled
Yes that is to be expected. It is not templated, and hasn't been compiled into your program.
Re: std.int128 not working with -betterC enabled
On Wednesday, 20 December 2023 at 18:46:41 UTC, Renato wrote: ``` dmd -L-ld_classic -unittest -checkaction=context -run main.d Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable (maybe you meant: __D4core6thread10threadbase10ThreadBase7sm_mainCQBtQBrQBnQBe, __D4core6thread8osthread16_mainThreadStoreG312v ) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1 ``` Ouch! I just forgot `-main` :D but yeah, the error does look similar! I can't delete my previous message, it seems, unfortunately... I am looking forward for the new DMD compiler version to be released which fixes the MacOS linker issues! Well, that part is still true.
Re: std.int128 not working with -betterC enabled
On Wednesday, 20 December 2023 at 18:16:00 UTC, Renato wrote: But with -betterC: ``` dmd -L-ld_classic -betterC -run dasc.d Undefined symbols for architecture x86_64: "__D3std6int1286Int1286__ctorMFNaNbNcNiNfllZSQBpQBoQBk", referenced from: _main in dasc.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1 Compilation exited abnormally with code 1 at Wed Dec 20 19:11:56 ``` I don't see anywhere whether int128 is supposed to work on -betterC. Is it not supported? This problem does not seem to be specific to int128 or even to -betterC. Just now, in another thread someone told me about the `-checkaction=context` compiler option... and when I use that, I get the same kind of error: ``` dmd -L-ld_classic -unittest -checkaction=context -run main.d Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable (maybe you meant: __D4core6thread10threadbase10ThreadBase7sm_mainCQBtQBrQBnQBe, __D4core6thread8osthread16_mainThreadStoreG312v ) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1 ``` I am looking forward for the new DMD compiler version to be released which fixes the MacOS linker issues!
std.int128 not working with -betterC enabled
I wanted to write a small program using betterC that needs to use
int128.
This simple program works without -betterC:
```d
module dasc;
import std.int128;
import core.stdc.stdio;
extern (C):
int main() {
auto n = Int128(128, 128);
printf("n=%lu%lu", n.data.hi, n.data.lo);
return 42;
}
```
But with -betterC:
```
dmd -L-ld_classic -betterC -run dasc.d
Undefined symbols for architecture x86_64:
"__D3std6int1286Int1286__ctorMFNaNbNcNiNfllZSQBpQBoQBk",
referenced from:
_main in dasc.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
Error: linker exited with status 1
Compilation exited abnormally with code 1 at Wed Dec 20 19:11:56
```
I don't see anywhere whether int128 is supposed to work on
-betterC. Is it not supported?
Re: D is nice whats really wrong with gc??
On Monday, 18 December 2023 at 17:22:22 UTC, H. S. Teoh wrote: On Mon, Dec 18, 2023 at 04:44:11PM +, Bkoie via Digitalmars-d-learn wrote: [...] but what is with these ppl and the gc? [...] It's called GC phobia, a knee-jerk reaction malady common among C/C++ programmers (I'm one of them, though I got cured of GC phobia thanks to D :-P). 95% of the time the GC helps far more than it hurts. And the 5% of the time when it hurts, there are plenty of options for avoiding it in D. It's not shoved down your throat like in Java, there's no need to get all worked up about it. T Truth
How to set linkage?
In the DMD compiler frontend, the type `TypeFunction` (cf.
astbase.d) representing a function type has a `linkage` member.
Setting this member when parsing seems to have no effect. How do
I set the linkage of a function type?
For alias declarations which support setting function type
linkage, in parse.d, it creates a `LinkageDeclaration`, which I
cannot do because my function type is not declared, but
(potentially) nested in something else.
My overall goal is to allow linkage as part of a function pointer
/ delegate type:
```
void f(extern(C) void function() cFunctionPtr) { }
alias CFP = extern(C) void function();
void g(CFP cFunctionPtr) { }
```
I can already parse this, but `pragma(msg, typeof(&f), '\n',
typeof(&g))` gives me:
```
void function(void function() cFunctionPtr)
void function((extern (C) void function()) cFunctionPtr)
```
This shows that the linkage of `f`’s parameter is not seen
somehow, but when the linkage is seen, it properly does end up in
the parameter’s type.
Re: Compiler analysis fault?
On Wednesday, 20 December 2023 at 11:33:22 UTC, DLearner wrote:
The code below fails to compile with
Error: function `test1.foo` no `return exp;` or `assert(0);`
at end of function
unless the commented-out assert(0) is included.
The compiler basically gives up control flow analysis when
encountering a goto statement or labeled break/continue.
```D
bool foo()
{
while(true)
{
L2:
goto L2;
}
// assert(0);
}
```
Compiler analysis fault?
The code below fails to compile with
Error: function `test1.foo` no `return exp;` or `assert(0);` at
end of function
unless the commented-out assert(0) is included.
Please, what rule of D is being broken?
foo does not unconditionally loop, and the only places where foo
returns, it returns with a bool.
```
bool foo() {
import std.stdio;
int I1;
int nogoagain;
while(true) {
I1 = 2;
while( I1 <= 10) {
if (I1 != 5) {
} else {
goto L2;
}
I1 = I1 + 1;
}
return true;
L2:;
readf(" %s", nogoagain);
if (nogoagain == 5) {
return false;
} else {
}
}
// assert(0);
}
void main() {
import std.stdio;
writeln("A");
writeln(foo());
}
```
