Re: const and immutable values, D vs C++?
On Thursday, 5 December 2019 at 00:05:26 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
Ok, so one has to use a wrapper and then "catch" the result
with auto?
auto x = foo!f();
Nevermind...
Re: confused about template constructors and implicit type conversions
On Wednesday, 4 December 2019 at 23:53:53 UTC, NeeO wrote:
Would someone be able to explain this ? I can only seem to call
a template constructor in one way, but I can't seem to pass
what looks like an accepted type to the template constructor
via a function call.
/+ main.d +/
import std.stdio ;
struct obj_ (T) {
int demo ;
this (int R,int C)(T[R][C] val) {
writeln ("init for type is ",val.init) ;
writeln ("num rows ",R ) ;
writeln ("num cols ",C ) ;
}
}
void check (obj_!float val) {
writeln ("success") ;
}
int main () {
float[3][4] testval ;
obj_!float p = testval ; /+ works +/
check (testval) ; /+ not callable using argument types
compiler error +/
return 0 ;
}
Hello, the problem you encounter here is that D, per spec, does
not perform implicit construction from parameters. You have to
constructs explicitly. Nothing more to explain.
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
Ok, so one has to use a wrapper and then "catch" the result with
auto?
auto x = foo!f();
confused about template constructors and implicit type conversions
Would someone be able to explain this ? I can only seem to call a
template constructor in one way, but I can't seem to pass what
looks like an accepted type to the template constructor via a
function call.
/+ main.d +/
import std.stdio ;
struct obj_ (T) {
int demo ;
this (int R,int C)(T[R][C] val) {
writeln ("init for type is ",val.init) ;
writeln ("num rows ",R ) ;
writeln ("num cols ",C ) ;
}
}
void check (obj_!float val) {
writeln ("success") ;
}
int main () {
float[3][4] testval ;
obj_!float p = testval ; /+ works +/
check (testval) ; /+ not callable using argument types
compiler error +/
return 0 ;
}
Re: const and immutable values, D vs C++?
On 12/4/19 5:57 PM, Ola Fosheim Grøstad wrote:
On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim Grøstad wrote:
Is there a way to specify in generic code that you want the best fit
of a const/immutable reference depending on the return type (but not a
mutable one)?
I mean, if f() return mutable or const then it should be const, but if
it returns immutable then it should be immutable. Something like:
readonly myref = f()
void foo(alias f)()
{
alias ConstType = const(typeof(f()));
pragma(msg, ConstType);
}
const(int) a() { return 1; }
immutable(int) b() { return 1; }
int c() { return 1; }
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
-Steve
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim Grøstad wrote: Is there a way to specify in generic code that you want the best fit of a const/immutable reference depending on the return type (but not a mutable one)? I mean, if f() return mutable or const then it should be const, but if it returns immutable then it should be immutable. Something like: readonly myref = f()
Re: Profiling the memory in D
On 12/4/19 5:04 PM, kerdemdemir wrote: GC.sizeof(cast(void*)object) will be super useful. I will use that. I also tried GC: --DRT-gcopt=profile:1 already. It provides so little information. I need to find out which member AA or array of which object is causing this memory problem of mine.I am ending up around 2GB of ram usage in a single day. These are not easy to discover. Are you using 32-bit compiler? If so, it has an issue with false pointers -- basically a large piece of memory can get pinned by a non-pointer that happens to be on the stack. This is not so much an issue in 64-bit land because the chances of accidental pointers is infinitesimal. Is there any way to manipulate profile-gc flag on run time? Like I will start my program without it somehow and after the my program initializes I will turn it on. I'm not familiar much with the gc profiling features. Lately I have had to measure max GC size, which this does provide. Sorry I can't be more help there. One last thing in my program I am getting a message from vibe sometimes like "leaking eventcore driver because there are still active handles". I use websockets and do web requests. I wanted to add that because I saw you fixed something with Redis about that in https://github.com/vibe-d/vibe.d/issues/2245. What happens is that the eventcore driver provides a mechanism to allocate an implementation-specific chunk of data for each descriptor. This is done via C malloc. In the past, when the eventcore driver was shut down, these spaces were all deallocated when the driver was deallocated. If you had classes which held descriptors that were cleaned up by the GC, they would then try to use that space and generate a segfault. So the eventcore driver will leak when it sees descriptors still in use, even when the GC is trying to clean it up because it doesn't know when the file descriptors will be released fully. To fix, you need to ensure all file descriptors are destroyed deterministically. For the Redis problem, it was really difficult to solve without altering vibe.d itself, because the Redis session manager did not provide a mechanism to release all resources in the pool deterministically. Tracking down what file descriptors are holding on, and who allocated them, is not an easy task. I had to instrument a lot of stuff to find it. Some easy possibilities may be if you aren't closing down all listening sockets before exiting main. I will say that I still get these messages if I kill my web server while some keepalive connections are still open. But now, if there is no activity for about 10 seconds, then I get no messages. Good luck tracking it down! -Steve
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 22:43:35 UTC, Bastiaan Veelo wrote: There is a difference I guess if g() returns a reference type and is an inout function. immutable y will only work if the reference returned is immutable. But not for values? Const is a promise to the rest of the code that you will never mutate it. Immutable is a promise by the rest of the code that it will never mutate. But if it isn't marked as "shared" then only the current thread will modify it, so it is only different if you have a mutable reference as well that could modify the same object as a const reference. So if g() always returns immutable, it’s best to receive it as such, not const. If it can be either, it must be received as const. Is there a way to specify in generic code that you want the best fit of a const/immutable reference depending on the return type (but not a mutable one)? I'm comparing D to C++ and I get the following mapping: Does that make sense at all? D’s const is transitive, C++’s is not. Yes, but it is the same for value types.
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim
Grøstad wrote:
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff with x and y …
}
There is a difference I guess if g() returns a reference type and
is an inout function. immutable y will only work if the reference
returned is immutable.
Const is a promise to the rest of the code that you will never
mutate it. Immutable is a promise by the rest of the code that it
will never mutate.
Immutable is more powerful, allowing data sharing in overlapping
slices and between threads without locks. Const is more
versatile, allowing references to data regardless of its
mutability.
So if g() always returns immutable, it’s best to receive it as
such, not const. If it can be either, it must be received as
const.
I'm comparing D to C++ and I get the following mapping:
Does that make sense at all? D’s const is transitive, C++’s is
not.
Bastiaan.
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 22:29:13 UTC, kerdemdemir wrote: Unfortunately I am not yet good with D to answer your question . But Ali Çehreli made some comparesions with C++. https://dconf.org/2013/talks/cehreli.pdf And I think you will find the answers of your questions in it also. Thanks. He didn't really compare to modern C++, but I appreciate the pointer. Seems to me that immutable references are primarily useful when calling a function with two references to an array. So you can be certain that the read-only reference will not be modified within the function (if both parameters point to the same array as they can with a const reference). Also, constexpr in C++ is a CTFE constraint and not a type, so not fully comparable to immutable, but same effect... perhaps. Not sure how smart compilers are in this regard. So immutable references i D is basically the same as const-references with restrict in C/C++ (non-standard, but common C++)?
Re: const and immutable values, D vs C++?
On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim
Grøstad wrote:
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff with x and y …
}
I'm comparing D to C++ and I get the following mapping:
D:
enum constant = number
C++:
enum : decltype(number) { constant = number }
D:
auto p = g()
C++:
auto p = g()
D:
const p = g()
C++:
const auto p = g()
D:
immutable p = g()
C++:
hmmm...
Has anyone done a feature by feature comparison with C++? It
would be interesting to see what it looks like.
Unfortunately I am not yet good with D to answer your question .
But Ali Çehreli made some comparesions with C++.
https://dconf.org/2013/talks/cehreli.pdf
And I think you will find the answers of your questions in it
also.
Re: Profiling the memory in D
On Wednesday, 4 December 2019 at 15:38:36 UTC, Steven Schveighoffer wrote: On 12/4/19 3:10 AM, Erdem wrote: I am used to have cool tools like valgrid massif to visualize the memory usage from C++ but in D it seems I am blind folded looking for the problem. Until now I tried: --vgc option which show million things which makes it not useful --build=profile-gc which seems to slow down my program like *200 times and I have some operation depending on time which makes creating the real case of the application impossible. The observation itself effect the experiment very badly. Since this options are not useful for me, I tried to put debug logs in critical places to estimate where I am losing memory. I couldn't find a D native call to get the memory usage of the program. I had to call a shell command which also slows down the app. This slow down causes me to not be able to put this debug log too many places or in critical loops. I manage to narrow it down a bit. Than I wanted to check the object instances to find out which objects are getting bigger. I tried GC.sizeOf() which always prints 0. GC.sizeOf also does not works with associative arrays , I don't see any usefull case than GC.sizeOf(array.ptr). That is the background of my questions and my questions are: Is there a better way to visualize the memory in D something like valgrid massif? profile-gc literally makes to program not do anything due to slow down is there any way to profile-gc in a faster fashion? Is there a native function which will return the memory usage of my program? If it's total GC memory only you are interested in, then try the D runtime switch for the GC: --DRT-gcopt=profile:1 This will print out a summary of GC usage at the end of your program, and shouldn't significantly affect runtime. Is there a function to return sizes of AAs and even class instances ? Class instances have a compiler-defined size. Try __traits(classInstanceSize, SomeClass) This is the compile-time size of that specific type. If you have a class instance, and you want the actual class size, in the case of a derived instance, you may retrieve that using typeid(classInstance).initializer.length. Note also that this is not necessarily the size consumed from the GC! If you want *that* size, you need to use GC.sizeof(cast(void*)object) (you were almost correct, what you did was get the GC size of the *class reference* which is really a pointer, and really lives on the stack, hence the 0). -Steve GC.sizeof(cast(void*)object) will be super useful. I will use that. I also tried GC: --DRT-gcopt=profile:1 already. It provides so little information. I need to find out which member AA or array of which object is causing this memory problem of mine.I am ending up around 2GB of ram usage in a single day. Is there any way to manipulate profile-gc flag on run time? Like I will start my program without it somehow and after the my program initializes I will turn it on. One last thing in my program I am getting a message from vibe sometimes like "leaking eventcore driver because there are still active handles". I use websockets and do web requests. I wanted to add that because I saw you fixed something with Redis about that in https://github.com/vibe-d/vibe.d/issues/2245. Thanks for your help and replies Steve.
Re: Building and running DMD tests
On Monday, 2 December 2019 at 02:15:36 UTC, Suleyman wrote: The command you need is "make -Ctest". Or you can run a specific test manually using run.d. ``` cd test/ ./run.d compilable/traits.d ``` Thanks
Re: Strange casting error when using lamdas
On 12/3/19 12:35 PM, Robert M. Münch wrote: The first three lines are on module level, the second two lines are inside a class member function. pragma(msg,WM_MOUSEMOVE_LBUTTON_STREAM.sizeof); 8LU but pragma(msg,windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON)).sizeof); 16LU Why do these two things have different sizes even the declaration is exactly the same? Is one a delegate and one a function pointer? This can easily happen for untyped lambdas. -Steve
Re: Strange casting error when using lamdas
On 2019-12-03 16:34:43 +, Robert M. Münch said: I have very strange casting error I don't understand: alias typeof(windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON))) WM_MOUSEMOVE_LBUTTON_TYPE; WM_MOUSEMOVE_LBUTTON_TYPE WM_MOUSEMOVE_LBUTTON_STREAM; pragma(msg,typeof(WM_MOUSEMOVE_LBUTTON_STREAM)); FilterObservable!(__lambda39, SubjectObject!(OS_State)) WM_MOUSEMOVE_LBUTTON_STREAM = cast(WM_MOUSEMOVE_LBUTTON_TYPE)(windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON))); pragma(msg,typeof(wstreams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON; FilterObservable!(__lambda7, SubjectObject!(OS_State)) ..\..\gui.d(317,104): Error: cannot cast expression filter(windows_message_streams[512u]) of type FilterObservable!(__lambda6, SubjectObject!(OS_State)) to FilterObservable!(__lambda39, SubjectObject!(OS_State)) because of different sizes FilterObservable!(__lambda7, SubjectObject!(OS_State)) My code worked in the past but now it doesn't and I don't know why. I don't understand the "because of different sizes" message. It looks like I have to explicitly create a lambda and re-use it. But how to do that? So, it all boils down to a breaking change in the RX framework... which I still don't understand... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Profiling the memory in D
On 12/4/19 3:10 AM, Erdem wrote: I am used to have cool tools like valgrid massif to visualize the memory usage from C++ but in D it seems I am blind folded looking for the problem. Until now I tried: --vgc option which show million things which makes it not useful --build=profile-gc which seems to slow down my program like *200 times and I have some operation depending on time which makes creating the real case of the application impossible. The observation itself effect the experiment very badly. Since this options are not useful for me, I tried to put debug logs in critical places to estimate where I am losing memory. I couldn't find a D native call to get the memory usage of the program. I had to call a shell command which also slows down the app. This slow down causes me to not be able to put this debug log too many places or in critical loops. I manage to narrow it down a bit. Than I wanted to check the object instances to find out which objects are getting bigger. I tried GC.sizeOf() which always prints 0. GC.sizeOf also does not works with associative arrays , I don't see any usefull case than GC.sizeOf(array.ptr). That is the background of my questions and my questions are: Is there a better way to visualize the memory in D something like valgrid massif? profile-gc literally makes to program not do anything due to slow down is there any way to profile-gc in a faster fashion? Is there a native function which will return the memory usage of my program? If it's total GC memory only you are interested in, then try the D runtime switch for the GC: --DRT-gcopt=profile:1 This will print out a summary of GC usage at the end of your program, and shouldn't significantly affect runtime. Is there a function to return sizes of AAs and even class instances ? Class instances have a compiler-defined size. Try __traits(classInstanceSize, SomeClass) This is the compile-time size of that specific type. If you have a class instance, and you want the actual class size, in the case of a derived instance, you may retrieve that using typeid(classInstance).initializer.length. Note also that this is not necessarily the size consumed from the GC! If you want *that* size, you need to use GC.sizeof(cast(void*)object) (you were almost correct, what you did was get the GC size of the *class reference* which is really a pointer, and really lives on the stack, hence the 0). -Steve
Re: const and immutable values, D vs C++?
Also, in file scope, would C++: constexpr auto constant = 3; be the same as: immutable constant = 3; ?
const and immutable values, D vs C++?
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff with x and y …
}
I'm comparing D to C++ and I get the following mapping:
D:
enum constant = number
C++:
enum : decltype(number) { constant = number }
D:
auto p = g()
C++:
auto p = g()
D:
const p = g()
C++:
const auto p = g()
D:
immutable p = g()
C++:
hmmm...
Has anyone done a feature by feature comparison with C++? It
would be interesting to see what it looks like.
Re: Unexpectedly nice case of auto return type
On Wednesday, 4 December 2019 at 03:17:27 UTC, Adam D. Ruppe
wrote:
On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
typeof(return) is one of the lesser known cool things about D
that make it so cool. Somebody should write an article about
it to raise awareness of it. :-D
you know i probably will write about that next week. so be sure
to like, comment, and subscribe so you never miss my next post
and then give me all your money on patreon so i can keep
bringing you content :P :P
I've just made the refact using typeof(null) and gained 78 SLOC
The pattern was:
void issueError();
and then in the code, in a dozen a function returning different
classes types
if (...) {
issueError();
return null;
}
now this becomes:
typeof(null) issueError();
if (...)
return issueError();
I wish I knew that trick before. I prefer typeof(null) in case I
would translate to another language. I tend to type the static
type when I know it anyway.
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 10:19:02 UTC, Jonathan M Davis
wrote:
On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via
Digitalmars-d- learn wrote:
On Tuesday, 3 December 2019 at 09:58:36 UTC, Jonathan M Davis
wrote:
> On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via
>
> Digitalmars-d- learn wrote:
>> I wish something like this was possible, until I change the
>> return type of `alwaysReturnNull` from `void*` to `auto`.
>>
>>
>> ---
>> class A {}
>> class B {}
>>
>> auto alwaysReturnNull() // void*, don't compile
>> {
>>
>> writeln();
>> return null;
>>
>> }
>>
>> A testA()
>> {
>>
>> return alwaysReturnNull();
>>
>> }
>>
>> B testB()
>> {
>>
>> return alwaysReturnNull();
>>
>> }
>>
>> void main()
>> {
>>
>> assert( testA() is null );
>> assert( testB() is null );
>>
>> }
>> ---
>>
>> OMG, isn't it nice that this works ?
>>
>> I think that this illustrates an non intuitive behavior of
>> auto
>> return types.
>> One would rather expect auto to work depending on the inner
>> return type.
>
> The void* version doesn't work, because void* doesn't
> implicitly convert to a class type. It has nothing to do
> with null. auto works thanks to the fact that typeof(null)
> was added to the language a while back, and since class
> references can be null, typeof(null) implicitly converts to
> the class type. Before typeof(null) was added to the
> language, null by itself had no type, since it's just a
> literal representing the null value for any pointer or class
> reference. The result was that using null in generic code or
> with auto could run into issues. typeof(null) was added to
> solve those problems.
>
> - Jonathan M Davis
That's interesting details of D developement. Since you reply
to the first message I think you have not followed but in the
last reply I told that maybe we should be able to name the
type of null. I think this relates to TBottom too a bit.
There isn't much point in giving the type of null an explicit
name given that it doesn't come up very often, and typeof(null)
is quite explicit about what the type is. Also, anyone doing
much generic programming in D is going to be well versed in
typeof. They might not know about typeof(null) explicitly, but
they should recognize what it means when they see it, and if
someone were trying to get the type of null, it would be the
obvious thing to try anyway. And typeof(null) isn't even the
prime case where typeof gets used on something other than an
object. From what I've seen, typeof(return) gets used far more.
As for TBottom, while the DIP does give it a relationship to
null, they're still separate things, and giving typeof(null) a
name wouldn't affect TBottom at all.
- Jonathan M Davis
I think that any internal compiler types that are also things in
code should be named.
Things like tuples are really a thing in the compiler (TupleExp,
TypeTuple, also Tuple in dtemplate.d, ...), we still need a
library type for tuples while everything there in the compiler.
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
On Tuesday, 3 December 2019 at 10:13:30 UTC, mipri wrote:
Speaking of nice stuff and aliases, suppose you want to
return a nice tuple with named elements?
Option 1: auto
auto option1() {
return tuple!(int, "apples", int, "oranges")(1, 2);
}
Option 2: redundancy
Tuple!(int, "apples", int, "oranges") option2() {
return tuple!(int, "apples", int, "oranges")(1, 2);
}
Option 3: an alias
alias BadMath = Tuple!(int, "apples", int, "oranges");
BadMath option3() {
return BadMath(1, 2);
}
Option 4: typeof(return)
Tuple!(int, "apples", int, "oranges") option4() {
return typeof(return)(1, 2);
}
aha nice
Profiling the memory in D
I am used to have cool tools like valgrid massif to visualize the memory usage from C++ but in D it seems I am blind folded looking for the problem. Until now I tried: --vgc option which show million things which makes it not useful --build=profile-gc which seems to slow down my program like *200 times and I have some operation depending on time which makes creating the real case of the application impossible. The observation itself effect the experiment very badly. Since this options are not useful for me, I tried to put debug logs in critical places to estimate where I am losing memory. I couldn't find a D native call to get the memory usage of the program. I had to call a shell command which also slows down the app. This slow down causes me to not be able to put this debug log too many places or in critical loops. I manage to narrow it down a bit. Than I wanted to check the object instances to find out which objects are getting bigger. I tried GC.sizeOf() which always prints 0. GC.sizeOf also does not works with associative arrays , I don't see any usefull case than GC.sizeOf(array.ptr). That is the background of my questions and my questions are: Is there a better way to visualize the memory in D something like valgrid massif? profile-gc literally makes to program not do anything due to slow down is there any way to profile-gc in a faster fashion? Is there a native function which will return the memory usage of my program? Is there a function to return sizes of AAs and even class instances ? Erdemdem
Re: Intersection of two sets
On Tuesday, 3 December 2019 at 13:43:26 UTC, Jan Hönig wrote:
pseudocode:
alias set = bool[]
set foo = ...
set bar = ...
set result;
One simple optimization is to
set* smallest;
set* largest;
if (foo.length < bar.length)
{
smallest =
largest =
}
else
{
smallest =
largest =
}
foreach(key; *smallest)
{
if (key in *largest)
{
result[key] = true;
}
}
return result;
Provided that your set type has an `in`-operator with
time-complexity O(1), this will, in the worst case, reduce time
complexity from
O(max(foo.length, bar.length))
to
O(min(foo.length, bar.length))
