Re: Aliasing member's members

2018-02-26 Thread Kayomn via Digitalmars-d-learn
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle wrote: On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote: [...] Don't think you can alias member variables directly. You could do this though: struct Player { Entity entity; ref auto pos() inout { return

Aliasing member's members

2018-02-26 Thread Kayomn via Digitalmars-d-learn
I've been experimenting with D's Better C mode, and I have a question regarding something that I started thinking about after watching one of Jonathon Blow's talks on data-oriented programming - more specifically the aspect of fake "inheritance" I have the following code. My question is if

Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
Hi, I've got a scene graph which contains multiple inheriting types. As such, I've been tagging them with a type enum for whenever I need to do things such as loading a structure from binary. Up until now I've been using an enum that looks like this:

Re: Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
I'll give a better example of what it is I'm trying to do. These are node types. Their contents are not important in this explanation, only that they operate as a tree structure. class Node; class RootNode : Node; class SpriteNode : Node; The result of getNodeID on a specific type is

Re: Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 02:18:28 UTC, Kayomn wrote: On Friday, 6 April 2018 at 01:22:42 UTC, Kayomn wrote: On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote: Kayomn wrote: [...] it is already done for you, free of charge. class Node {} class RootNode : Node {}

Re: Compile-time variables

2018-04-06 Thread Kayomn via Digitalmars-d-learn
Besides this, I tried something with types used as user defined attributes. https://dlang.org/spec/attribute.html#uda Automatic compile time tagging is not my speciality, however, I think is also achievable with mixins somehow? But I don't know how to workaround the bug

Re: Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote: Kayomn wrote: [...] it is already done for you, free of charge. class Node {} class RootNode : Node {} class SpriteNode : Node {} void main () { auto nodeId1 = typeid(Node);

Re: Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 01:22:42 UTC, Kayomn wrote: On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote: Kayomn wrote: [...] it is already done for you, free of charge. class Node {} class RootNode : Node {} class SpriteNode : Node {} void main () {

Re: Compile-time variables

2018-04-05 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 00:21:54 UTC, H. S. Teoh wrote: On Thu, Apr 05, 2018 at 11:53:00PM +, Kayomn via Digitalmars-d-learn wrote: [...] [...] [...] [...] `lastID`, as declared above, are runtime variables. The 'static' in this case just means it's thread-local, rather than

Re: Compile-time variables

2018-04-06 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 14:15:08 UTC, Kayomn wrote: On Friday, 6 April 2018 at 13:55:55 UTC, nkm1 wrote: [...] Figured I had a handle on how it worked doing but guess not. One final question, however. [...] Nevermind, I'm blind. I missed the post-increment in newID().

Re: Compile-time variables

2018-04-06 Thread Kayomn via Digitalmars-d-learn
On Friday, 6 April 2018 at 13:55:55 UTC, nkm1 wrote: On Friday, 6 April 2018 at 13:10:23 UTC, Kayomn wrote: ID tags are unique and spsecific to the class type. There shouldn't be more than one type ID assigned to one class type. The idea behind what it is I am doing is I am implementing a

Re: Derelict GLFW3 and dynamic linking on Linux

2018-02-27 Thread Kayomn via Digitalmars-d-learn
On Tuesday, 27 February 2018 at 13:14:38 UTC, Mike Parker wrote: On Tuesday, 27 February 2018 at 12:00:20 UTC, Kayomn wrote: [...] It *is* a version problem. The exception is a SymbolLoadException, which means the loader found the library just fine (you can see it in the file name,

Derelict GLFW3 and dynamic linking on Linux

2018-02-27 Thread Kayomn via Digitalmars-d-learn
Hi, I've been working on something using Windows and now I'm attempting to build it on Linux with Dub, however I appear to be having an issue. import base.application; import derelict.opengl3.gl3; import derelict.glfw3.glfw3; int main(string[] args) { DerelictGL3.load();

DerelictGL3 and glBegin() access violation.

2018-02-28 Thread Kayomn via Digitalmars-d-learn
Maybe I'm missing something, but whenever I attempt to call glBegin() with anything my program immediately encounters an access violation. I've got a very simple setup, with this being my main: import base.application; import derelict.opengl3.gl3; import derelict.glfw3.glfw3; int

Re: DerelictGL3 and glBegin() access violation.

2018-02-28 Thread Kayomn via Digitalmars-d-learn
On Wednesday, 28 February 2018 at 16:58:38 UTC, Mike Parker wrote: On Wednesday, 28 February 2018 at 16:47:49 UTC, Kayomn wrote: Yeah, I knew they were deprecated, just weren't aware Derelict doesn't load them. Thanks though, I'd been up and down the Derelict docs page and I didn't see

Re: DerelictGL3 and glBegin() access violation.

2018-02-28 Thread Kayomn via Digitalmars-d-learn
On Wednesday, 28 February 2018 at 14:02:48 UTC, Mike Parker wrote: On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote: import derelict.opengl3.gl3; Whoa. Just noticed this. That's an older version of DerelictGL3 you're using there. You should really be using the latest version

Re: DerelictGL3 and glBegin() access violation.

2018-02-28 Thread Kayomn via Digitalmars-d-learn
On Wednesday, 28 February 2018 at 12:36:37 UTC, bauss wrote: On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote: [...] Most likely a library issue. Are you sure that you link to the libraries correctly etc.? I'm using DUB for package management and linking and any library

BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-06 Thread Kayomn via Digitalmars-d-learn
Something discovered in the D Language Code Club Discord server with the help of Wild is that the following code: struct Test { ~this() {} } void tester(Test test, Test[] tests...) { } extern(C) void main() { tester(Test(), Test()); } Raises the "TypeInfo cannot be used with ~betterC"

Re: BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-06 Thread Kayomn via Digitalmars-d-learn
On Monday, 6 July 2020 at 20:20:44 UTC, Stanislav Blinov wrote: I'd say the original error should be reported on bugzilla, if it isn't already; if only for the error message which is ridiculously obscure. Yeah, you're tellin' me lol. I spent the better part of the day tracking this one down,

Re: BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-06 Thread Kayomn via Digitalmars-d-learn
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote: example is forgetting to supply an arrange length when array length*

Re: BetterC Bug? Intended Behavior? Asking Here As Unsure

2020-07-06 Thread Kayomn via Digitalmars-d-learn
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote: Similar case here; the 'varargs' end up in a GC-allocated array. I've recently changed `scope` slice params, so that array literal arguments are allocated on the caller's stack instead; so adding `scope` for these variadics *should*