Re: DMD won't compile re-init of variable

2020-02-03 Thread Simon via Digitalmars-d-learn

On Friday, 31 January 2020 at 14:01:04 UTC, Minty Fresh wrote:
On Thursday, 30 January 2020 at 21:36:53 UTC, Adam D. Ruppe 
wrote:

On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote:

How do I revert my variable to the init state?


null is the initial state for those.


More generally, .init can be used as to get the initial state 
for any type.


ie.
  m_string2edge = typeof(m_string2edge).init;


Thank you, Minty Fresh, this was the solution!



Re: DMD won't compile re-init of variable

2020-02-03 Thread Simon via Digitalmars-d-learn
On Thursday, 30 January 2020 at 21:18:04 UTC, MoonlightSentinel 
wrote:

On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote:

Hi dlang community,

I'm trying to implement a "reset" functionality which should 
revert all variables to the program start initial state.


Example:

import Graph;
protected Edge[string] m_string2edge;

int main()
{
// adding some elements
// not important how it works
// m_string2edge[name] = e;

// resetting it
m_string2edge = null;
m_string2edge = new Edge[string]; // <- won't compile

return 0;
}

How do I revert my variable to the init state?

Thanks in advance,
Simon


You can use m_string2edge.clear() if you want to remove all 
entries from m_string2edge.


See https://dlang.org/spec/hash-map.html#properties


Hi MoonlightSentinel,

in this case it won't compile:
..\Electrics.d(42): Error: function Electrics.clear() is not 
callable using argument types (Edge[string])

..\Electrics.d(42):expected 0 argument(s), not 1



DMD won't compile re-init of variable

2020-01-30 Thread Simon via Digitalmars-d-learn

Hi dlang community,

I'm trying to implement a "reset" functionality which should 
revert all variables to the program start initial state.


Example:

import Graph;
protected Edge[string] m_string2edge;

int main()
{
// adding some elements
// not important how it works
// m_string2edge[name] = e;

// resetting it
m_string2edge = null;
m_string2edge = new Edge[string]; // <- won't compile

return 0;
}

How do I revert my variable to the init state?

Thanks in advance,
Simon



Why is this pure function taking a string literal not CTFE-executable?

2019-06-01 Thread Simon via Digitalmars-d-learn

Hi Guys!

In my programm, I have a custom String-type that I want to 
initialize some variables of at compile time by casting a string 
literal to said custom String type. I thought I could achieve 
this straight forwardly, but after trying a bit, I could not find 
a (simple) working solution. I made this minimal example to show 
where the easy solution all fall flat:


struct My_String{
long size;
char* data;
}

My_String make_my_string(string s){
My_String my_string;
my_string.data = cast(char*) s.ptr;
my_string.size = s.length;
return my_string;
}

struct Dummy{
My_String s = make_my_string("hello!");
}

void main(){
Dummy dummy;
}

Which produces the compilation error "cannot use non-constant 
CTFE pointer in an initializer My_String(6L, &"hello!"[0])". I do 
not understand this error message. What is the non-constant CTFE 
pointer here. The "data"-member? If so, why does this compile:


struct My_String{
long size;
char* data;
}

struct Dummy{
	My_String s = My_String("hello!".length, cast(char*) 
"hello!".ptr);

}

void main(){
Dummy dummy;
}

Why does the error message show an opcall to My_String with 
filled out members ("6L, &"hello!"[0]"), although the code only 
ever default-constructs a My_string variable? I am confused. And 
why on earth does this work:


struct My_String{
long size;
char* data;
}

My_String make_my_string(string s){
My_String my_string;
my_string.data = cast(char*) s.ptr;
my_string.size = s.length;
return my_string;
}

void main(){
My_String s = make_my_string("hello!");
}

Please help, I have no idea whats going on here.




Re: Matching an array-type of a C++ function signature in D, without using a D-array-type, because the compiler crashes otherwise

2019-03-23 Thread Simon via Digitalmars-d-learn

On Saturday, 23 March 2019 at 13:04:10 UTC, kinke wrote:

On Saturday, 23 March 2019 at 11:35:45 UTC, Simon wrote:
Is there any way to end up with the correct mangled function 
signature, using only pointer types?


The problem is that the C++ compiler uses head-const for the 
array param (`float * const`), which cannot be represented in D.

What you can do is specify the mangle manually, e.g.:

pragma(mangle, "?ColorEdit4@ImGui@@YA_NPEBDQEAMH@Z")
extern(C++) bool ColorEdit4(const(char)* label, float* col, int 
flags = 0);


I didn't know specifying the mangle was possible, thanks!


Matching an array-type of a C++ function signature in D, without using a D-array-type, because the compiler crashes otherwise

2019-03-23 Thread Simon via Digitalmars-d-learn

Hi,
I experienced some trouble with DMD today, while trying to 
declare an external C++ function in D, that gets linked from a 
C++ compiled object file.


The C++ function that I want to link against is declared as 
follows:

bool ColorEdit4(const char* label, float col[4], int flags = 0);

Yielding the following signature in the .obj (using a demangler):
BOOL __cdecl ImGui::ColorEdit4(char const * __ptr64,float * 
__ptr64 const,int)


The Function is declared in D as follows:
extern(C++, ImGui) bool ColorEdit4(const(char)* label, float[4] 
col, int flags = 0);


Which unfortunately crashes the compiler, which tells me I can't 
use a D array-type here, and should use a pointer. If you want to 
know the full story, you can look into the bug-report: 
https://issues.dlang.org/show_bug.cgi?id=19759


So as a workaround until this is fixed, I somehow need to end up 
with the same mangled function signature, while using a pointer 
type for the second argument.


I tried:
extern(C++, ImGui) bool ColorEdit4(const(char)* label, const 
float* col, int flags = 0);


which yields:
BOOL __cdecl ImGui::ColorEdit4(char const * __ptr64,float * 
__ptr64,int)


so the 2nd argument is of type "float * __ptr64", when it should 
be "float * __ptr64 const".


Trying "const float* col" or "const(float)* col" doesn't yield 
the correct result either ("float const * __ptr64 const" and 
"float const * __ptr64"), and I didn't find any other 
combinations I could try.


Is there any way to end up with the correct mangled function 
signature, using only pointer types? Another workaround would of 
course be to switch to C-Linkage, so the names don't get mangled 
at all, but the C++-object file has function overloads, so I 
would like to avoid that. If this isn't possible, I might just 
wait for the dmd update.


Re: Aliasing a mixin (or alternative ways to profile a scope)

2019-03-10 Thread Simon via Digitalmars-d-learn

On Saturday, 9 March 2019 at 09:12:13 UTC, Dennis wrote:

On Friday, 8 March 2019 at 11:42:11 UTC, Simon wrote:
Thanks, this works flawlessly. Out of interest: what is the 
"enum" doing there? I had the exact same behaviour in a 
function before, that I only called at compile-time, so why 
did it complain then? Can I somehow tell the compiler that a 
function should only be available at compile-time?


The enum (which in D is not only for enumerations, but also for 
"manifest constants") ensures it is evaluated at compile-time, 
since things are only evaluated at compile-time if they have to.

See also Adam D. Ruppe's post in this thread:
https://forum.dlang.org/post/blaawtdhljjantvga...@forum.dlang.org


Thanks!


Re: Aliasing a mixin (or alternative ways to profile a scope)

2019-03-08 Thread Simon via Digitalmars-d-learn

On Thursday, 7 March 2019 at 21:50:17 UTC, Johannes Loher wrote:

```
enum profile_scope(string name) = "import core.stdc.stdio : 
printf;

printf(\""
~ name ~ "\n\"); scope(exit) printf(\"" ~ name ~ "\n\");";

extern (C) void main()
{
mixin(profile_scope!"func1");
}

```
This uses string concatenation only at compile time and not 
during run
time, so it does not require the garbage collector and is 
compatible

with betterC :)


Thanks, this works flawlessly. Out of interest: what is the 
"enum" doing there? I had the exact same behaviour in a function 
before, that I only called at compile-time, so why did it 
complain then? Can I somehow tell the compiler that a function 
should only be available at compile-time?


Re: Aliasing a mixin (or alternative ways to profile a scope)

2019-03-07 Thread Simon via Digitalmars-d-learn

On Thursday, 7 March 2019 at 20:34:48 UTC, Johannes Loher wrote:


auto profile_scope(string name)
{
import std.format : format;
return q{import std.stdio : writeln; writeln("%1$s"); 
scope(exit)

writeln("%1$s");}.format(name);
}

void main()
{
mixin(profile_scope("func1"));
}


Is there a way to achieve this while compiling with -betterC? I 
use a custom string struct right now, and your version needs 
TypeInfo, concatening using ~ needs the garbage collector. I have 
the feeling D is really not agreeing with the way I want to do 
things. If this is not possible, I will just roll with the Adam's 
struct solution.




Aliasing a mixin (or alternative ways to profile a scope)

2019-03-07 Thread Simon via Digitalmars-d-learn

Hello,

I am currently porting the frontend of my instrumenting profiler 
to D. It features a C++-makro that profiles the time between 
entering and leaving a scope (achieved with con-/destructors in 
C++). Since D has scopeguards, I hoped to achieve this by 
creating a mixin that generates the following code:


measure("func1");
scope(exit) measure("func1");

Since I of course don't want to type a mixin for that everytime I 
want to use it, I tried to alias it:


import std.meta : Alias;
alias profile_scope(string name) = Alias!(mixin("measure(\"" ~ 
name ~ "\"); scope(exit) measure(\"" ~ name ~ "\");"));


I expected this to generate the code above by typing 
profile_scope("func1") in my programm. However the compiler (dmd) 
gives me the following error:


source\main.d(24): Error: template plattform.profile_scope cannot 
deduce function from argument types !()(string), candidates are:
source\plattform.d(262):plattform.profile_scope(string 
name)


This looks like a deduction/overload kind of error, which has me 
completly confused since there is no other identifier of the name 
"profile_scope" in my programm and the error message shows only 
one candidate.


Is there any way I can achive generating those two statements 
using only something that effectively looks like a function 
call/C-macro with an argument?