Re: Nondeterministic unittest debugging problem.
remove the .dub folder and try again, as stated in other reply, might be a cache issue, or something that picks an outdated file in the cache
Re: DMD compiler - warning of unused variables
On Monday, 16 August 2021 at 14:14:27 UTC, DLearner wrote:
Hi
Please see code below:
```
void main() {
import std.stdio;
size_t i;
size_t j;
i = 5;
writeln("i = ",i);
}
```
Is there a compiler option that would warn that variable 'j' is
defined but not used?
Best regards
Hi, not compiler, but with dscanner it is possible, in fact with
the code-d vscode extension, you get that out of the box with
visual hints!
Take a look at this screenshot:
https://i.imgur.com/TGkgY3e.png
If you click on the line, it jumps automatically to the right
line, very nice tooling
Re: Anyway to achieve the following
On Sunday, 15 August 2021 at 21:53:14 UTC, Carl Sturtivant wrote: On Sunday, 15 August 2021 at 07:10:17 UTC, JG wrote: [...] What you are asking for are reference variables. C++ has them: the example here illustrates the behavior you want. https://www.geeksforgeeks.org/references-in-c/ [...] Thanks for the links and code. Looking at the assembly as suggested by others it seems that after optimization this not too bad.
Re: DMD compiler - warning of unused variables
On Monday, 16 August 2021 at 14:14:27 UTC, DLearner wrote: Is there a compiler option that would warn that variable 'j' is defined but not used? Best regards No in DMD but you can use [D-Scanner](https://code.dlang.org/packages/dscanner) for that. The check works reasonably as long as the variables are not introduced by `mixin()` or metaprog.
Re: DMD compiler - warning of unused variables
On Monday, 16 August 2021 at 14:14:27 UTC, DLearner wrote:
Hi
Please see code below:
```
void main() {
import std.stdio;
size_t i;
size_t j;
i = 5;
writeln("i = ",i);
}
```
Is there a compiler option that would warn that variable 'j' is
defined but not used?
Best regards
dmd is anti-warning, so it'd have to be an error, which might be
more annoying than it's worth. `dscanner --report thefile.d`
includes "Variable j is never modified and could have been
declared const or immutable." and "Variable j is never used." as
issues, with line and column numbers.
Re: DMD compiler - warning of unused variables
No. https://github.com/dlang-community/D-Scanner#implemented-checks
DMD compiler - warning of unused variables
Hi
Please see code below:
```
void main() {
import std.stdio;
size_t i;
size_t j;
i = 5;
writeln("i = ",i);
}
```
Is there a compiler option that would warn that variable 'j' is
defined but not used?
Best regards
Re: Nondeterministic unittest debugging problem.
On Sunday, 15 August 2021 at 10:32:27 UTC, Rekel wrote: Note you might need to open the screenshots externally, as they are cut off by the forum. This looks like your build system fails to detect file changes and links outdated .o file(s), or library, which causes a mismatch between your debug info and the real location of the variables. This leads the debugger to look in the wrong place and hence can't read the memory. By inserting the variable int x, Mat a is then again on the stack frame where it's supposed to be according to the debug info. That's my guess anyways. When I encounter a problem like this I do a 'clean all' followed by a full rebuild of both, the lib and the program using it.
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 10:48:19 UTC, Alexandru Ermicioi wrote: On Monday, 16 August 2021 at 06:36:02 UTC, james.p.leblanc wrote: To be honest, I am not exactly sure what is happening here. I am unfamiliar with the "(T : T[])" syntax ... need to read That is template argument secialization. You're saying that T can be accept only types that are arrays of T, where : reads as 'extends'. Now T : T[] might introduce cyclic reference, so more correct would be: foo(T : Z[], Z)(...) Here you say that T might accept only types that are arrays of Z elements. Regards, Alexandru. Alexandru, That is very helpful information. It also answers a nagging question I have been worried about. Specifically, that "T : T[]" bothered me even though I was unfamiliar with the syntax ... now I understand the situation better. Best Regards, James
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:36:02 UTC, james.p.leblanc wrote: To be honest, I am not exactly sure what is happening here. I am unfamiliar with the "(T : T[])" syntax ... need to read That is template argument secialization. You're saying that T can be accept only types that are arrays of T, where : reads as 'extends'. Now T : T[] might introduce cyclic reference, so more correct would be: foo(T : Z[], Z)(...) Here you say that T might accept only types that are arrays of Z elements. Regards, Alexandru.
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:49:08 UTC, james.p.leblanc wrote:
On Monday, 16 August 2021 at 06:42:48 UTC, Tejas wrote:
If the code works, what's the problem?
Hej Again,
I was able to construct the working code shown above from help I
obtained here in the forum and other resources.
My original code was not working ... but updated code is working
fine ... so there are no further problems. (Actually, I learned
a fair amount in this endeavor!)
Cheers!
jpl
Cool
Just for completeness, here's what my solution looks like:
```d
import std;
struct S{
char[] a=['a','v','d'];
T opCast(T)(){
return a.dup ;
}
}
void main()
{
writeln("Hello D");
S s = S();
char[] d = cast(char[])s;
}
```
Re: Bitfield woes
On Monday, 16 August 2021 at 06:47:54 UTC, SealabJaster wrote: ... Wait, I'm actually just a moron. I should be using `uint` and not `int`
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:42:48 UTC, Tejas wrote: If the code works, what's the problem? Hej Again, I was able to construct the working code shown above from help I obtained here in the forum and other resources. My original code was not working ... but updated code is working fine ... so there are no further problems. (Actually, I learned a fair amount in this endeavor!) Cheers! jpl
Bitfield woes
I swear I'm not being stupid right: https://run.dlang.io/is/Wfd214 I should be seeing: ``` 7 // 111 7 // 111 3 // 11 [no error message] ``` instead of: ``` 3 // 11 3 // 11 1 // 1 core.exception.AssertError@onlineapp.d-mixin-8(9): Value is greater than the maximum value of bitfield 'a' ``` Or am I managing to miss something completely obvious?
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:36:02 UTC, james.p.leblanc wrote:
On Monday, 16 August 2021 at 06:20:11 UTC, Tejas wrote:
Maybe just write `T[]` in code rather than making it happen
via the colon?
I also have similar troubles, removing the default value
always helped me.
Can you show the code where you're trying to apply this?
Hej Tejas,
Sure, here is the code snippet, it resides within a struct
along with various operator overloads.
To be honest, I am not exactly sure what is happening here. I
am unfamiliar with the "(T : T[])" syntax ... need to read
up a bit on that. (However, not so eary searching for a ":")
BR,
jpl
// --- cast overloading
---
// T[] opCast(T : T[])(){ // this works
T[] opCast(T[])(){ // yields: "Error: identifier expected
for template value param"
T[] x;
x.length = this.length;
for( int i = 0 ; i< this.length ; i++){
x[i] = this.ptr[i];
}
return x;
}
Oh, you're writing `T[]` in the code anyways.
I was saying to just remove the `:T[]` from the function
parameter and write `T[]` in the function body itself, which
you're already doing.
If the code works, what's the problem?
Re: Drawbacks of exceptions being globally allocated
On Monday, 16 August 2021 at 06:17:22 UTC, Alexandru Ermicioi
wrote:
On Monday, 16 August 2021 at 06:12:14 UTC, Tejas wrote:
...
Fyi, check out std.exeprimental.allocator package. You can use
allocators from there to do allocation of exceptions, on the
heap or any other region.
Yes, I know about Mallocator. would've been nice to be able to do
it just via the language and runtime features that are @nogc. And
I'll have to do deallocation manually with that as well anyways.
When transpiling the C++ code, I really don't want to mix
standard libraries, hence the desire to keep things contained
just to the compiler/runtime as much as possible.
Of course, things like `Octal` are going to force me to use
phobos anyways, so I'm thinking to just introduce a new scope and
import these packages there in order to prevent names from
clashing, but I also don't want an excessive amount of `{...}`
littering the transpiled code...
Ah, I'll see to all this later, thank you very much for your
time, everyone
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:20:11 UTC, Tejas wrote:
Maybe just write `T[]` in code rather than making it happen via
the colon?
I also have similar troubles, removing the default value always
helped me.
Can you show the code where you're trying to apply this?
Hej Tejas,
Sure, here is the code snippet, it resides within a struct
along with various operator overloads.
To be honest, I am not exactly sure what is happening here. I
am unfamiliar with the "(T : T[])" syntax ... need to read
up a bit on that. (However, not so eary searching for a ":")
BR,
jpl
// --- cast overloading
---
// T[] opCast(T : T[])(){ // this works
T[] opCast(T[])(){ // yields: "Error: identifier expected for
template value param"
T[] x;
x.length = this.length;
for( int i = 0 ; i< this.length ; i++){
x[i] = this.ptr[i];
}
return x;
}
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 06:12:42 UTC, james.p.leblanc wrote:
On Monday, 16 August 2021 at 05:26:00 UTC, Tejas wrote:
If you're finding the spec too hard, please try Ali's book.
I'm sharing the part on operator overloading below:
http://ddili.org/ders/d.en/operator_overloading.html
Please ping if you still have problems; I'll then write a full
program.
Hej Tejas!
Thanks for your message. I have it working now. Yes, Ali's
book is
a tremendously good reference. But, I had trouble digging out
the "magic sauce" from the pages to get this working.
I was able to find the sauce in a forum post by Adam Ruppe (his
book is also
an excellent place for ideas and code).
With "opCast", my difficulty was the description of the type I
wish to cast
to uses a colon ":".
Here is the line that allows it to function as desired:
**>> T[] opCast(T : T[])(){... }**
Best Regards,
jpl
Maybe just write `T[]` in code rather than making it happen via
the colon?
I also have similar troubles, removing the default value always
helped me.
Can you show the code where you're trying to apply this?
Re: Drawbacks of exceptions being globally allocated
On Monday, 16 August 2021 at 06:12:14 UTC, Tejas wrote: ... Fyi, check out std.exeprimental.allocator package. You can use allocators from there to do allocation of exceptions, on the heap or any other region.
Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...
On Monday, 16 August 2021 at 05:26:00 UTC, Tejas wrote:
If you're finding the spec too hard, please try Ali's book. I'm
sharing the part on operator overloading below:
http://ddili.org/ders/d.en/operator_overloading.html
Please ping if you still have problems; I'll then write a full
program.
Hej Tejas!
Thanks for your message. I have it working now. Yes, Ali's book
is
a tremendously good reference. But, I had trouble digging out
the "magic sauce" from the pages to get this working.
I was able to find the sauce in a forum post by Adam Ruppe (his
book is also
an excellent place for ideas and code).
With "opCast", my difficulty was the description of the type I
wish to cast
to uses a colon ":".
Here is the line that allows it to function as desired:
**>> T[] opCast(T : T[])(){... }**
Best Regards,
jpl
Re: Drawbacks of exceptions being globally allocated
On Monday, 16 August 2021 at 05:47:10 UTC, Mathias LANG wrote:
On Monday, 16 August 2021 at 05:36:07 UTC, Tejas wrote:
That is why I was using heapAllocate, because using `new` on
scope allocates exception on stack, and if you exit, then the
exception is basically freed before it even gets caught. It
fails even when you catch within the same function.
But allocate on heap and giving ownership to a `scope`
qualified variable is no problem at all. No `signal 11`
killing my process ^_^
You are relying on an accept-invalid though. The compiler
*should not* accept that code, but currently erroneously does
so.
okay that's it, the following is my final try for this thing:
```d
import std;
import core.lifetime:emplace;
import core.stdc.stdlib:malloc,free;
T heapAllocate(T, Args...)(Args args)@nogc{
auto size = __traits(classInstanceSize, T);
auto memory = malloc(size)[0 .. size];
auto instance = emplace!(T,Args)(memory, args);
return instance;
}
void throws()@nogc{
auto/*no more scope*/ a = heapAllocate!(Exception)("works
fine with scope, apparently");
throw a;
}
void main()@nogc
{
try{
throws();
} catch(Exception exp){
scope(exit)free(cast(void*)exp);//new code
printf("%s", cast(char*)exp.msg);
}
}
```
There are 0 problems with this, right? I just have to remember to
free the exception in the `catch`?
