Re: Can you parse the d source file during compile time with std.regex?
On Tuesday, 1 August 2017 at 16:20:07 UTC, Stefan Koch wrote:
On Tuesday, 1 August 2017 at 16:16:46 UTC, 12345swordy wrote:
I don't see this anywhere in the documentation. I am asking
this as I want to know that it's possible to create a
attribute to prevent certain functions being called in the
body of a function. To enforce a certain code standard upon
myself.
UDA's are your friend here.
There is no need to use parser, and in any case std.regex
cannot match the regex at ct.
I know that UDA exist, what I want to know if it is possible to
create one that prevent certain things like calling certain
functions in a function body Ie
@custom main()
{
//function body
example()//throw error by @custom
}
There is no getRawFunctionBody for traits either, so I was
thinking about using std.regex to get the string of the function
body and and then parse that string during compile time.
Alex
Can you parse the d source file during compile time with std.regex?
I don't see this anywhere in the documentation. I am asking this as I want to know that it's possible to create a attribute to prevent certain functions being called in the body of a function. To enforce a certain code standard upon myself.
Re: SIMD under LDC
On Monday, 4 September 2017 at 23:06:27 UTC, Nicholas Wilson
wrote:
On Monday, 4 September 2017 at 20:39:11 UTC, Igor wrote:
I found that I can't use __simd function from core.simd under
LDC
Correct LDC does not support the core.simd interface.
and that it has ldc.simd but I couldn't find how to implement
equivalent to this with it:
ubyte16* masks = ...;
foreach (ref c; pixels) {
c = __simd(XMM.PSHUFB, c, *masks);
}
I see it has shufflevector function but it only accepts
constant masks and I am using a variable one. Is this possible
under LDC?
You have several options:
* write a regular for loop and let LDC's optimiser take care of
the rest.
alias mask_t = ReturnType!(equalMask!ubyte16);
pragma(LDC_intrinsic, "llvm.masked.load.v16i8.p0v16i8")
ubyte16 llvm_masked_load(ubyte16* val,int align, mask_t
mask, ubyte16 fallthru);
ubyte16* masks = ...;
foreach (ref c; pixels) {
auto mask = equalMask!ubyte16(*masks, [-1,-1,-1, ...]);
c = llvm_masked_load(,16,mask, [0,0,0,0 ... ]);
}
The second one might not work, because of type differences in
llvm, but should serve as a guide to hacking the `cmpMask` IR
code in ldc.simd to do what you want it to.
BTW. Shuffling channels within pixels using DMD simd is about
5 times faster than with normal code on my machine :)
Don't underestimate ldc's optimiser ;)
I seen cases where the compiler fail to optimized for smid.
Can't seemed to get parent name from a class at compile time.
import std.stdio;
class bob
{
}
class tom : bob
{
}
void main()
{
writeln(__traits(identifier,__traits(parent,tom)));
}
Am I doing this right? I am expecting it to print "bob".
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 13:24:49 UTC, KingJoffrey wrote: On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote: But unlike you "king", Bauss isn't using tor to ban evade. why you wanna ban little old me? is it cause I made a crticism of D? No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me.
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 13:49:48 UTC, 12345swordy wrote: No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me. Well... why ya all r busy havin a go at me, the bugs remains (as do all D'other bugs).
Re: High memory usage in vibe.d application
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote: On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole wrote: On 29/06/2018 11:09 PM, Anton Fediushin wrote: It is GC's fault for sure, I built my program with profile-gc and it allocated a lot there. Question is, why doesn't it free this memory? Probably doesn't know that it should deallocate so eagerly. A GC.collect(); call may help. That's a good idea. GC really needs to be kicked in once in a while because it did _nothing_ in 8 hours, even though my application is just a couple of timers - it isn't a hard task for CPU or memory and there's plenty of time to collect some garbage. Now I finally understand why GC is not a great thing. I was writing apps utilizing GC for a long time and never had problems with it, but when it came down to this simple program it stabbed me in the back. Which language that you had write apps in that utilize GC? Java? C#? You shouldn't treat D GC the same as other languages GC. Alexander
TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
I expect ["__ctor", "__dtor", "toString", "toHash", "opCmp",
"opEquals"], instead I got ["toString", "toHash", "opCmp",
"opEquals", "Monitor", "factory"]
Care anyone explain why it is?
Source is the following:
import std.stdio;
import std.traits;
interface A
{
}
class D : A
{
this()
{
}
~this()
{
}
}
void main()
{
alias TL = TransitiveBaseTypeTuple!D;
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
writeln(b);
}
}
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 18:45:17 UTC, Adam D. Ruppe
wrote:
On Wednesday, 10 January 2018 at 18:31:17 UTC, 12345swordy
wrote:
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
Simple mistake there...
I noticed, can't fix it cause it won't let me edit it.
This auto b = [__traits(allMembers, TL[0])];
is meant to be auto b = [__traits(allMembers, TL[x])];
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 19:26:58 UTC, Adam D. Ruppe wrote: On Wednesday, 10 January 2018 at 19:07:46 UTC, 12345swordy wrote: I noticed, can't fix it cause it won't let me edit it. OK, I'd just use foreach there anyway tho (then it actually builds!). But, hopefully once you get it running, you'll see that the base type tuple just gives the bases: it will print two lines, one for the base class Object and one for your interface A. Neither of them have constructors! It won't print the class D itself You know a equivalent template that does that?
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote: On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote: [...] [...] [...] The root of the problem is that in D, class destruction and finalization are conflated. It would be much more accurate to refer to ~this in classes as a finalizer. Then this sort of confusion wouldn't be so widespread. [...] Have you considered writing a DIP on this?
Re: extern(C++): Unresolved scalar deleting destructor
On Tuesday, 24 July 2018 at 19:14:26 UTC, Vladimir Marchevsky wrote: On Tuesday, 24 July 2018 at 19:04:50 UTC, 12345swordy wrote: Have you tried @disable ~this()? Just tried: 1) no changes, still error about unresolved "QObject::`scalar deleting destructor'(unsigned int)". 2) marking destructor as @disable will actually disable it, right? But I want to use to not receive a memory leak. Afaik, previous approach was to re-implement ctor/dtor in D but now they can be used as they are. I found similar error messages regarding c++: https://stackoverflow.com/questions/42449063/vs-c-dll-scalar-deleteing-destructor
Re: extern(C++): Unresolved scalar deleting destructor
On Tuesday, 24 July 2018 at 15:48:28 UTC, Vladimir Marchevsky wrote: After reading 2.081 patchnotes about improvements with binding to cpp classes, I'm trying to test it - with simple examples and Qt as cpp library. [...] Have you tried @disable ~this()? Alexander
Re: trait to get the body code of a function?
On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud wrote: On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole wrote: On 25/07/2018 5:32 AM, Guillaume Lathoud wrote: Thanks for all the answers. I've just had a look at an alternative: using dmd as a package. However that's a lot of doc to browse... Maybe someone has experience with dmd as a package? Not a solution. Leaks memory, not reusable and in general not very friendly to work with. Thanks. Please submit a bug report to Bugzilla on this, as I am also interest in this. Alexander
Re: trait to get the body code of a function?
On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole wrote: On 24/07/2018 4:43 PM, Guillaume Lathoud wrote: [...] Doesn't exist. Well, IMO it should exist as it can be quite useful for generating metainfo.
Re: Better multithreading with D
On Saturday, 21 April 2018 at 02:08:24 UTC, solidstate1991 wrote: In order to call a function multiple time at parallel (rendering function, very well parallelizable), but in order to push the CPU to it's limits I have to get some form of parallelization. Currently I'm using parallel foreach, which isn't very nice, and since it uses GC allocation that creates some performance impact from time to time. Did you attempt to create a memory pool with the GC? Any memory allocation will take time, whatever it's CG or manual.
Re: what is the point of functor ?
On Friday, 22 June 2018 at 14:06:06 UTC, Flaze07 wrote: recently, I visited the glossary and saw that functor exist in D...I know that functor exist C++ as a way to easily allow higher order function, but since D already has function and delegates, is there a point to functor ? It there for Extern(C++).
Re: struggling to link against a C global in D (win/vs2017)
On Monday, 29 October 2018 at 00:16:38 UTC, Stanislav Blinov
wrote:
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The function seems to link OK, but the C global will not.
Should it be extern(Windows), perchance?.. (I haven't D on
Windows for ages).
Nope, you use export.
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote: On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote: On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: When I was first playing with D, I managed to create a segfault What's the reasoning for allowing this? 100 % agree that there should be non-nullable class references, they're my main missing feature in D. Likewise, I'm astonished that only few D users wish for them. https://github.com/aliak00/optional/blob/master/source/optional/notnull.d "But I don't like the verbosity!" alias MyClass = NotNullable!MyClassImpl; Huh neat, though it would nice to allow conversion of Nullable to NotNullable via runtime conditional checking. NotNullable!MyClassImpl = (MyClassImpvar != Null) ? MyClassImpvar : new MyClassImpvar();
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Friday, 30 November 2018 at 15:32:55 UTC, 12345swordy wrote: On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote: On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote: On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: [...] [...] 100 % agree that there should be non-nullable class references, they're my main missing feature in D. Likewise, I'm astonished that only few D users wish for them. https://github.com/aliak00/optional/blob/master/source/optional/notnull.d "But I don't like the verbosity!" alias MyClass = NotNullable!MyClassImpl; Huh neat, though it would nice to allow conversion of Nullable to NotNullable via runtime conditional checking. NotNullable!MyClassImpl = (MyClassImpvar != Null) ? MyClassImpvar : new MyClassImpvar(); I meant new MyClassImp(), but you get the idea.
Re: @property with opCall
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote: On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote: @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place but it never actually affected this. For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL. Now @property changes the result of `typeof(a.prop)`... but nothing else. @property is one of the biggest WTFs of D's development. no kidding, d should just copy c# property semantics as the current implementation of it is wonky. Mike attempted to add binary operations to it, but instead close his dip pull request and the following dmd pull requested. -Alex
Pattern matching via switch?
I.E. switch (object) case Type1 t1: case Type2 t2: case Type3 t3:
Re: Pattern matching via switch?
On Saturday, 14 March 2020 at 20:52:30 UTC, aliak wrote: On Saturday, 14 March 2020 at 19:04:28 UTC, 12345swordy wrote: [...] You can use the sumtype package (https://code.dlang.org/packages/sumtype): [...] That simply to much verbiage.
Re: Pattern matching via switch?
On Sunday, 15 March 2020 at 17:55:59 UTC, Steven Schveighoffer wrote: On 3/14/20 3:04 PM, 12345swordy wrote: I.E. switch (object) case Type1 t1: case Type2 t2: case Type3 t3: Is this a class object and you are trying to determine at runtime which derived type it is and perform an action based on that? Or are you trying to switch on the type of a concrete item? It should technically be possible to use the fully qualified name to switch on, but I don't think typeid(Type1).name is usable as a switch label. -Steve https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching It is an example from c#. object is the top type in that language. https://en.wikipedia.org/wiki/Top_type
Re: How does D's templated functions implementation differ from generics in C#/Java?
On Friday, 7 August 2020 at 21:03:47 UTC, aberba wrote: Syntactically they look the same (although D's can do more things) so I'm trying to understand how why in D it's called template but in languages like C#/Java they're generics. I guess I have fair understanding of D's code generation but isn't it same as what what is available in those languages too? How are the implementation different? I think this is relevent: https://github.com/dotnet/csharplang/issues/110
Re: What is the current stage of @property ?
On Wednesday, 10 June 2020 at 21:40:44 UTC, Paul Backus wrote:
On Wednesday, 10 June 2020 at 20:24:19 UTC, Vinod K Chandran
wrote:
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find
a conclusion. After all that thread is a 48 page longer jumbo
thread. So out of curiosity, i am asking this. What is the
current state of @property ? Is it deprecated ?
The current state of @property is that it doesn't really do
anything. D allows you to call functions without parentheses,
and to use assignment syntax to call a single-argument
function, so you can write getters and setters that work like
properties even if you don't use the @property annotation:
struct Example
{
private int x_;
int x() { return x; } // getter
void x(int n) { x = n; } // setter
}
void main()
{
Example e;
e.x = 123; // calls setter
int y = e.x; // calls getter
}
It can't do binary operations and unary operations.
Re: What is the current stage of @property ?
On Wednesday, 10 June 2020 at 22:30:37 UTC, Vinod K Chandran wrote: On Wednesday, 10 June 2020 at 22:15:25 UTC, 12345swordy wrote: It can't do binary operations and unary operations. @12345swordy, You mean we can't do such ops inside the property ? No, it means you can't do this: e.x += 123;
Re: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
On 5/17/21 9:47 AM, jmh530 wrote:
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which
is deprecated".
However when I look at the list of deprecated features [1],
I'm not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into
member functions. Moving it to a member function fixes the
problem. Alternately, I could make the alias part of Foo's
type. My use case it is just a little easier structured like
this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
The feature is deprecated in its current form. The issue as I
understand it (i.e. very little) is that compilers other than
DMD could not use this same way to implement dual contexts, and
so they could not have the feature. This means that valid code
in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to
implement it for DMD, and at some point tackle it in a
backend-agnostic way.
Personally, I don't know why we can't fix it so that it's
portable, but I understand so little about compilers that I've
pretty much stayed out of it. The feature is very much needed.
-Steve
The dual context that warning is referring to is vthis2, which
the gdc maintainer struggle to implemented for the gdc compiler.
A correct fix involves templates having their own context.
-Alex
