Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 21:19:39 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar The only gotcha that comes to my mind is that `private` means private to the module in D, not private to the aggregate. — Bastiaan. A few others that I know: When importing one module(say ```m2```) into another (say ```m1```), the symbols of ```m1``` aren't automatically visible in ```m2```. You must import ```m1``` in ```m2``` for that. You can't just initialize variables willy-nilly in a module, you must do them inside ```static this()``` Method function pointers don't exist in D, equivalent functionality is achieved by using a delegate that captures the context of a class instantiated object. To use a function pointer explicitly, you can't just write ```(func)(arguments)```, it is ```()(arguments)```(thank you evilrat) ```sizeof/alignof``` differs in D and C++(thank you evilrat)
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 19:03:06 UTC, Marcone wrote: On Tuesday, 10 August 2021 at 19:01:42 UTC, Adam D Ruppe wrote: On Tuesday, 10 August 2021 at 18:59:33 UTC, Marcone wrote: Using -Lgdi32.lib -Luser32.lib? Same error. The part after that: If you want the Windows subsystem too, use -L/subsystem:windows -L/entry:mainCRTStartup. Pass BOTH -L/subsystem:windows AND -L/entry:mainCRTStartup Good! work very well! Thank you! The difference is because DMD uses different linkers on Windows. By default, it links 32-bit programs with OPTLINK. That linker only requires the subsystem flag---it will recognize that you have a `main` function. When compiling with -m32mscoff or -m64, it uses the Microsoft linker. That linker requires that you also specify the program entry function---it always expects `WinMain`, and the `mainCRTStartup` tells it to look for `main` instead.
Re: writef, compile-checked format, pointer
On 8/9/21 10:03 PM, nov wrote: > i dreamed that programming will be less-error with compile checking format. I still think so because many errors that can be caught at compile time are moved to run time in non-statically-typed languages. > but reality disappoint :( > message for every error in compile-checked format occupy whole screen :( When that happens, I simply change it to runtime-checked format string like you did and it works. (Better would be to identify and fix the problem. Maybe some other time for me...) Ali
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 18:13:17 UTC, Tejas wrote: On Tuesday, 10 August 2021 at 18:07:35 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: there's casting away const, a clearly seperate language feature which has no equivalent in D; You *can* cast away `const` in D: https://run.dlang.io/is/sWa5Mf — Bastiaan. Yes, but it is UB, not defined and supported by the standard/implementation. OK, strictly speaking casting away `const` is in the language, but modifying after that is UB. https://dlang.org/spec/const3.html#removing_with_cast — Bastiaan.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar The only gotcha that comes to my mind is that `private` means private to the module in D, not private to the aggregate. — Bastiaan.
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 19:01:42 UTC, Adam D Ruppe wrote: On Tuesday, 10 August 2021 at 18:59:33 UTC, Marcone wrote: Using -Lgdi32.lib -Luser32.lib? Same error. The part after that: If you want the Windows subsystem too, use -L/subsystem:windows -L/entry:mainCRTStartup. Pass BOTH -L/subsystem:windows AND -L/entry:mainCRTStartup Good! work very well! Thank you!
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 18:59:33 UTC, Marcone wrote: Using -Lgdi32.lib -Luser32.lib? Same error. The part after that: If you want the Windows subsystem too, use -L/subsystem:windows -L/entry:mainCRTStartup. Pass BOTH -L/subsystem:windows AND -L/entry:mainCRTStartup
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 18:51:28 UTC, Adam D Ruppe wrote: On Tuesday, 10 August 2021 at 18:45:35 UTC, Marcone wrote: Hi, do you have some other solution without arsd.simpledisplay? I want only dmd feature. Did you read the paragraph under the link? That IS a dmd switch. Or a ldc switch. It explains the concept which works with anything. Using -Lgdi32.lib -Luser32.lib? Same error.
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 18:45:35 UTC, Marcone wrote: Hi, do you have some other solution without arsd.simpledisplay? I want only dmd feature. Did you read the paragraph under the link? That IS a dmd switch. Or a ldc switch. It explains the concept which works with anything.
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 18:36:27 UTC, Adam D Ruppe wrote: On Tuesday, 10 August 2021 at 18:34:03 UTC, Marcone wrote: How can I hide console using -m64? http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#installation-instructions Hi, do you have some other solution without arsd.simpledisplay? I want only dmd feature.
Re: -L/SUBSYSTEM:windows Error when using -m64
On Tuesday, 10 August 2021 at 18:34:03 UTC, Marcone wrote: How can I hide console using -m64? http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#installation-instructions
-L/SUBSYSTEM:windows Error when using -m64
How use -L/SUBSYSTEM:windows for hide console in x64 prograns? Becouse if I use -L/SUBSYSTEM:windows and -m64 I get this error: lld-link: error: undefined symbol: WinMain referenced by msvcrt120.lib(msvcrt_stub2.obj):($LN5) Error: linker exited with status 1 If I delete -L/SUBSYSTEM:windows compile fine. How can I hide console using -m64?
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 18:07:35 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: there's casting away const, a clearly seperate language feature which has no equivalent in D; You *can* cast away `const` in D: https://run.dlang.io/is/sWa5Mf — Bastiaan. Yes, but it is UB, not defined and supported by the standard/implementation.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 16:00:37 UTC, Tejas wrote: there's casting away const, a clearly seperate language feature which has no equivalent in D; You *can* cast away `const` in D: https://run.dlang.io/is/sWa5Mf — Bastiaan.
Re: Error when compile with DMD using -m64?
On Tuesday, 10 August 2021 at 17:13:31 UTC, Marcone wrote: On Tuesday, 10 August 2021 at 15:55:42 UTC, Bastiaan Veelo wrote: Use `size_t` and `ptrdiff_t` instead to make your program compile in both 32 bit and 64 bit modes. https://dlang.org/spec/type.html#aliased-types -- Bastiaan. Thank you very much! Your information was very precious! It worked very well! Now I can create x32 or x64 compatible programs without creating two codes. You’re welcome :-) — Bastiaan.
Re: Error when compile with DMD using -m64?
On Tuesday, 10 August 2021 at 15:55:42 UTC, Bastiaan Veelo wrote: On Tuesday, 10 August 2021 at 01:29:04 UTC, Marcone wrote: Solved converting long and int. Use `size_t` and `ptrdiff_t` instead to make your program compile in both 32 bit and 64 bit modes. https://dlang.org/spec/type.html#aliased-types -- Bastiaan. Thank you very much! Your information was very precious! It worked very well! Now I can create x32 or x64 compatible programs without creating two codes.
Re: .tupleof for static array
On Tuesday, 10 August 2021 at 15:32:25 UTC, Dennis wrote: Thanks for this solution as well. On Tuesday, 10 August 2021 at 13:10:23 UTC, Paul Backus wrote: Would definitely be nice to have this in the language, though. Do you know more use cases for this? I've written range pipelines like this: ```d someSourceRange .chunks(2) .map!(chunk => chunk.staticArray!2) // allows random access .each!(pair => doSomethingWith(pair[0], pair[1])); ``` Having to write `pair[0]` and `pair[1]` is a bit awkward, though. Normally I would use something like the following to bind each element to a separate parameter: ```d alias apply(alias fun) = args => fun(args.tupleof); /* ... */ .each!(apply!((first, second) => doSomethingWith(first, second))); ``` ...but `.tupleof` doesn't work with static arrays, so that doesn't compile.
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 13:18:24 UTC, Paul Backus wrote: On Tuesday, 10 August 2021 at 11:05:53 UTC, Tejas wrote: Also, I have read here a principle that **If it looks like C, it behaves like C** How true is that for C++? Does code that look like C++(minus obvious syntax differences) behave like C++? No. D and C++ have different semantics for many things. One example is `const`. In C++, the following code is totally fine: ```c++ int n = 123; // mutable object const int *p = // const pointer const_cast(p) = 456; // ok to mutate via p ``` However, the equivalent code in D is undefined behavior: ```d int n = 123; // mutable object const(int)* p = // const pointer cast(int*)p = 456; // not allowed to mutate via p ``` Yes, I should've been more precise. I was hoping for an answer in terms of implicit conversions, default constructors that get created by the respective compilers(ignoring the move constructors), sequence points(Walter said that the sequence point rules are same for D and C, so is it safe to assume they're the same as C++ as well?), also whether there is any difference in template instantiations(IFTI, or template argument detection rules) Also, about the const thing, since there is no ```const_cast``` in D, therefore it is not the same as D, yet doesn't violate the statement that C++ that looks like D behaves the same as D, since that would require you to write ```(int*)``` but there's casting away const, a clearly seperate language feature which has no equivalent in D; it's kind of like saying that ``` int a[] = [1,2,3]``` is not the same as in D since in D that's a dynamic array, not static. Yeah it isn't but there is an equivalent representation for it available, unlike ```const_cast``` Sorry for the ambiguous statement below Basically, what are the subtle gotcha's in the differences between C++ and D code that looks similar (again, I fully understanding I'm ambiguous here, but I simply don't know how to express this otherwise) Thank you for replying!
Re: Error when compile with DMD using -m64?
On Tuesday, 10 August 2021 at 01:29:04 UTC, Marcone wrote: Solved converting long and int. Use `size_t` and `ptrdiff_t` instead to make your program compile in both 32 bit and 64 bit modes. https://dlang.org/spec/type.html#aliased-types -- Bastiaan.
Re: .tupleof for static array
Thanks for this solution as well. On Tuesday, 10 August 2021 at 13:10:23 UTC, Paul Backus wrote: Would definitely be nice to have this in the language, though. Do you know more use cases for this?
Re: D has the same memory model as C++
On Tuesday, 10 August 2021 at 11:05:53 UTC, Tejas wrote: Also, I have read here a principle that **If it looks like C, it behaves like C** How true is that for C++? Does code that look like C++(minus obvious syntax differences) behave like C++? No. D and C++ have different semantics for many things. One example is `const`. In C++, the following code is totally fine: ```c++ int n = 123; // mutable object const int *p = // const pointer const_cast(p) = 456; // ok to mutate via p ``` However, the equivalent code in D is undefined behavior: ```d int n = 123; // mutable object const(int)* p = // const pointer cast(int*)p = 456; // not allowed to mutate via p ```
Re: .tupleof for static array
On Tuesday, 10 August 2021 at 12:01:24 UTC, Dennis wrote:
```D
struct Vec {
float x, y, z;
}
void setPosition(float x, float y, float z) {
}
void main() {
Vec posS = Vec(10, 20, 30);
setPosition(posS.tupleof); // pass
float[3] posA = [10, 20, 30];
setPosition(posA.tupleof); // Error: no property `tupleof`
for type `float[3]`
}
```
Does anyone know a library utility to make expanding a static
array like this work?
```d
import std.traits: isStaticArray;
template Iota(size_t n)
{
import std.meta: AliasSeq;
static if (n == 0)
alias Iota = AliasSeq!();
else
alias Iota = AliasSeq!(Iota!(n - 1), n - 1);
}
template tupleOf(alias array)
if (isStaticArray!(typeof(array)))
{
import std.meta: Map = staticMap;
ref element(size_t i)()
{
return array[i];
}
alias tupleOf = Map!(element, Iota!(array.length));
}
```
Full example: https://run.dlang.io/is/COG7m4
Would definitely be nice to have this in the language, though.
Re: .tupleof for static array
Thanks! I was considering turning the static array into an AliasSeq directly, but casting it to a struct and doing tupleof on that is pretty smart. On Tuesday, 10 August 2021 at 12:50:55 UTC, jfondren wrote: And I don't see very many static-array-generic functions in Phobos. Indeed, static arrays could use some more love in my opinion.
Re: .tupleof for static array
On Tuesday, 10 August 2021 at 12:01:24 UTC, Dennis wrote:
```D
struct Vec {
float x, y, z;
}
void setPosition(float x, float y, float z) {
}
void main() {
Vec posS = Vec(10, 20, 30);
setPosition(posS.tupleof); // pass
float[3] posA = [10, 20, 30];
setPosition(posA.tupleof); // Error: no property `tupleof`
for type `float[3]`
}
```
Does anyone know a library utility to make expanding a static
array like this work?
I came up with
```d
auto structOf(T, size_t N)(T[N] xs) {
string defstruct(size_t n) {
import std.conv : to;
string m = "struct S { " ~ T.stringof;
foreach (i; 1 .. n) {
m ~= " _";
m ~= i.to!string;
m ~= ",";
}
m ~= " _n; }";
return m;
}
mixin(defstruct(N));
return cast(S) xs;
}
```
for `structOf(posA).tupleof`
And I don't see very many static-array-generic functions in
Phobos.
.tupleof for static array
```D
struct Vec {
float x, y, z;
}
void setPosition(float x, float y, float z) {
}
void main() {
Vec posS = Vec(10, 20, 30);
setPosition(posS.tupleof); // pass
float[3] posA = [10, 20, 30];
setPosition(posA.tupleof); // Error: no property `tupleof`
for type `float[3]`
}
```
Does anyone know a library utility to make expanding a static
array like this work?
D has the same memory model as C++
What exactly does the above statement mean? Also, I have read here a principle that **If it looks like C, it behaves like C** How true is that for C++? Does code that look like C++(minus obvious syntax differences) behave like C++? Does having the same memory model help? Thanks for reading!!
Re: writef, compile-checked format, pointer
On Tuesday, 10 August 2021 at 05:03:12 UTC, nov wrote: every time i try to use templates, i have problems :( That is why C++ introduced concepts. Wonder when D will be getting them :(
