Should I re-build my toolbox libs after upgrading VS tools under windows?
At present my dmd toolsets are DMD2.103+Visual Stiduo 2015 Community+ a lot of libraries built by them and I prefer building 64 bit apps under Win10 64. For some reason,I am planning to upgrade VS2015 community to VS2017+,or even VS2022.If I do so,should all those already built libaries have to re-built again with VS2017+ or even VS 2022?Thank you for the help to figure me out in advance.
Re: interface opEquals
On Thursday, November 23, 2023 2:20:25 PM MST Antonio via Digitalmars-d-learn wrote: > * Why, when applied to interface, ```opEquals``` called directly > behavior is not the same that when calling ```==``` ? > > * Is it the expected behaviour? I'd have to take the time to study your code in detail to see whether what exactly you're seeing makes sense or not, but it's not expected that normal D code will call opEquals directly, and for classes, == does more than call lhs.opEquals(rhs). It does additional stuff to try to have the correct behavior for equality without you having to code it all up yourself in opEquals. == on classes results in the free function, opEquals, in object.d being called. That function does a variety of checks such as checking whether either reference is null (to avoid dereferencing null) and using is to compare the address of the class references first (to avoid calling the class' opEquals if both references are to the same object). It also makes sure that both rhs.opEquals(lhs) and lhs.opEquals(rhs) are true for == to be true to avoid subtle bugs that can come into play when comparing a base class against a derived class. https://github.com/dlang/dmd/blob/master/druntime/src/object.d#L269 - Jonathan M Davis
Re: Doubt about type Inference on templates
On Wednesday, 22 November 2023 at 19:37:58 UTC, Paul Backus wrote:
This is a bug/limitation in the compiler. I couldn't find an
existing report on issues.dlang.org, so I've reported it myself
as [issue 24255][1].
Wow: It is a very concise bug example.
I tested with ```ldc``` ant it fails too.
For now, I think the best way to work around it is to specify
the type in the lambda, as in `(int i) => i%2 == 0`.
agreed
The reason you see `void` is that when the compiler cannot
figure out the type of a function literal, it treats it as a
template function:
```d
static assert(__traits(isTemplate, i => i % 2 == 0));
```
And for silly historical reasons, when the compiler tries to
determine the type of a template, it returns `void` instead of
giving an error:
```d
template example() {}
static assert(is(typeof(example) == void)); // what??
```
Thanks Paul!!!
interface opEquals
```d
interface IOpt(T)
{
T value();
bool empty();
bool opEquals(IOpt!T other);
}
class None(T) : IOpt!T
{
bool empty() => true;
T value(){ throw new Exception("None has not a value"); }
bool opEquals(IOpt!T other)=>other.empty;
}
class Some(T) : IOpt!T
{
this(T value) { this._value = value; }
bool empty() => false;
T value()=> _value;
bool opEquals(IOpt!T other)=>!other.empty &&
other.value==_value;
private T _value;
}
IOpt!T some(T)(T v)=>new Some!T(v);
IOpt!T none(T)()=>new None!T;
void main()
{
assert(new Some!int(1) == new Some!int(1));
assert(new None!int == new None!int);
assert(none!int.opEquals(none!int));
assert(none!int == none!int);
}
```
It compiles, but last assertion ```assert(none!int ==
none!int);``` fails
```
core.exception.AssertError@testiface.d(33): Assertion failure
```
To avoid "extrange effects" I test an alternative equality that
fails too:
```d
assert( (cast (IOpt!int) new None!int) == (cast (IOpt!int) new
None!int));
```
What seems strange to me is that
```none!int.opEquals(none!int)``` works properly.
**Questions**
* Why, when applied to interface, ```opEquals``` called directly
behavior is not the same that when calling ```==``` ?
* Is it the expected behaviour?
Re: D: Declaring empty pointer variables that return address inside function calls?
On Thursday, 23 November 2023 at 20:13:59 UTC, BoQsc wrote:
Nothing wrong. It would be just a more concise compact way to
do the same.
Also I mostly wanted to know if something like that is already
possible in D language.
It's not a huge loss if it is not possible.
This is possible in Go: you dereference a literal constructor and
it's either built on the stack or the heap depending on escape
analysis. Example:
```go
package main
import "fmt"
type T struct {
data [5]byte
}
func usebuffer(a *T) *T {
a.data[0] = 1
a.data[4] = 10
return a
}
func f() *T {
return usebuffer({}) // <--
}
func main() {
fmt.Println(f())
}
```
which is very close to this D that is explicitly allocating on
the heap:
```d
class T {
byte[5] data;
}
T usebuffer(T a) {
a.data[0] = 1;
a.data[4] = 10;
return a;
}
T f() {
return usebuffer(new T()); // <--
}
void main() {
import std.stdio : writeln;
writeln(f().data);
}
```
Which if you want stack allocation, is very similar to:
```d
class T {
byte[5] data;
}
T usebuffer(T a) {
a.data[0] = 1;
a.data[4] = 10;
return a;
}
void main() {
import std.stdio : writeln;
import std.typecons : scoped;
writeln(usebuffer(scoped!T).data);
}
```
but, I don't actually know if this is safe.
Re: D: Declaring empty pointer variables that return address inside function calls?
On Thursday, 23 November 2023 at 20:00:31 UTC, H. S. Teoh wrote: On Thu, Nov 23, 2023 at 07:22:22PM +, BoQsc via Digitalmars-d-learn wrote: Is it possible to declare empty pointer variable inside function calls and pass its address to the function? These are sometimes required while using Win32 - Windows Operating System API. * Empty pointer variables are used by functions to return information after the function is done. My own horrible **suggestion** of empty pointer declaration inside function call: `someFunction(uint & passingEmptyVariableForWrite);` What it would do: * A new variable is declared inside function call. * Address of that variable is passed to the function. * After function is done, you can refer to it for returned value. What's wrong with: uint* result; someFunction(); // use *result ? T Nothing wrong. It would be just a more concise compact way to do the same. Also I mostly wanted to know if something like that is already possible in D language. It's not a huge loss if it is not possible.
Re: mixin under -betterC
On Thursday, 23 November 2023 at 18:54:09 UTC, Julian Fondren wrote: [...] The `enum` answer? [...] No, the 'template' answer. To me, if the 'template' suggestion worked (as it did), then my simple mixin (as in my original post) should also work.
Re: D: Declaring empty pointer variables that return address inside function calls?
On Thu, Nov 23, 2023 at 07:22:22PM +, BoQsc via Digitalmars-d-learn wrote: > Is it possible to declare empty pointer variable inside function calls > and pass its address to the function? > > These are sometimes required while using Win32 - Windows Operating > System API. > > * Empty pointer variables are used by functions to return information > after the function is done. > > My own horrible **suggestion** of empty pointer declaration inside > function call: > `someFunction(uint & passingEmptyVariableForWrite);` > > What it would do: > * A new variable is declared inside function call. > * Address of that variable is passed to the function. > * After function is done, you can refer to it for returned value. What's wrong with: uint* result; someFunction(); // use *result ? T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Re: comparing with c strings
On Thursday, November 23, 2023 11:29:09 AM MST denis via Digitalmars-d-learn wrote: > Let's say I have a D application, with some callbacks from C, > where some arguments to the callbacks are `const char* path`. > What is the recommended way to compare them to D strings? Without > making allocations, if that's possible std.string.fromStringz will slice the char* to give you a char[] (using strlen to find the end of the string). Then you can operate on the C string as a char[] - though since it's a slice of the char*, you'll want to dup or idup it if the char[] risks living longer than the char* that it's a slice of. But if all you're doing is comparing it against a D string, then presumably, you don't need to keep the char[] around, and you won't have to allocate a copy. https://dlang.org/phobos/std_string.html#.fromStringz - Jonathan M Davis
D: Declaring empty pointer variables that return address inside function calls?
Is it possible to declare empty pointer variable inside function calls and pass its address to the function? These are sometimes required while using Win32 - Windows Operating System API. * Empty pointer variables are used by functions to return information after the function is done. My own horrible **suggestion** of empty pointer declaration inside function call: `someFunction(uint & passingEmptyVariableForWrite);` What it would do: * A new variable is declared inside function call. * Address of that variable is passed to the function. * After function is done, you can refer to it for returned value.
interface inference
```d
interface I {
bool check();
}
class A : I {
bool check() =>true;
}
class B : I {
bool check() =>false;
}
I aOrB(bool check) => check ? new A() : new B();
void main()
{
assert( aOrB(true).check );
}
```
Compiler error:
```d
x.d(11): Error: cannot implicitly convert expression `check ? new
A : new B` of type `object.Object` to `x.I`
```
Basically, the ternary conditional ```?:``` result type is not
inferred even if the type returned by the two possibilities are
the same.
**Is it a bug or the expected behaviour?**
Re: mixin under -betterC
On Thursday, 23 November 2023 at 17:46:55 UTC, DLearner wrote:
I just find it surprising that your suggestion worked, but the
(slightly simpler) earlier version did not.
The `enum` answer? That also works, but you have to make a change
at the callsite as well, to `mixin(mxnTest!("Var_A", "Var_B"));`
- passing the strings as template rather than functional
arguments.
comparing with c strings
Let's say I have a D application, with some callbacks from C, where some arguments to the callbacks are `const char* path`. What is the recommended way to compare them to D strings? Without making allocations, if that's possible
Re: mixin under -betterC
On Thursday, 23 November 2023 at 17:03:29 UTC, Julian Fondren
wrote:
On Thursday, 23 November 2023 at 16:33:52 UTC, DLearner wrote:
Why is this so, bearing in mind the concatenations are
executed at
compile, not run, time?
If you compile without -betterC, it'll work, but if you examine
the result you'll find that the mxnTest function is still
compiled into the result. D makes it so convenient to use
functions at compile-time that there's no clear distinction for
functions that should only exist at compile-time.
Make mxnTest a template:
```d
string mxnTest()(string strVar1, string strVar2) {
^^
```
I tried what you suggested, and with no other changes it compiled
and ran correctly.
Thanks!
I just find it surprising that your suggestion worked, but the
(slightly simpler) earlier version did not.
Re: mixin under -betterC
On Thursday, 23 November 2023 at 16:33:52 UTC, DLearner wrote:
Why is this so, bearing in mind the concatenations are executed
at
compile, not run, time?
If you compile without -betterC, it'll work, but if you examine
the result you'll find that the mxnTest function is still
compiled into the result. D makes it so convenient to use
functions at compile-time that there's no clear distinction for
functions that should only exist at compile-time.
Make mxnTest a template:
```d
string mxnTest()(string strVar1, string strVar2) {
^^
```
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?
This is a known limitation:
https://issues.dlang.org/show_bug.cgi?id=23637
The easiest way to work around it is to change `mxnTest` from a
function to a templated manifest constant:
```d
enum mxnTest(string strVar1, string strVar2) =
`(int Var1, int Var2) {
if (Var1 > Var2) {
return true;
} else {
return false;
}
}(` ~ strVar1 ~ `,` ~ strVar2 ~ `)`;
```
Keep in mind that you will also have to change the call site to
pass `"Var_A"` and `"Var_B"` as template arguments:
```d
// Note the ! in front of the argument list
FirstVarGreater = mixin(mxnTest!("Var_A", "Var_B"));
```
mixin under -betterC
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 ~ `)`;
}
```
