Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 08:55:03 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom wrote: btw. what was the last compiler you wrote? https://github.com/eth-srl/psi https://github.com/tgehr/d-compiler touché ;-) nonetheless. I stand

Re: TickDuration deprecation

On 22.11.2017 03:22, Walter Bright wrote: On 11/21/2017 1:40 PM, Timon Gehr wrote: Computer clocks have discrete ticks, they are not continuous. That may be true, but the plotting library may still just expect a list of doubles. What's the point of removing the simple conversion function that

Re: object.Exception@generated\gtkd\gtkd\Loader.d(125):Library load failed(libgio-2.0.0.dll)

On Tuesday, 21 November 2017 at 18:32:45 UTC, Mike Wey wrote: On 21-11-17 11:19, PECman wrote: On Sunday, 19 November 2017 at 13:39:39 UTC, Mike Wey wrote: On 19-11-17 08:35, PECman wrote: I complied the D application with gtkD successfully.However,I cant run it successfully.My settings are

Re: Having "in" for arrays

On Wednesday, November 22, 2017 08:03:50 Fra Mecca via Digitalmars-d-learn wrote: > Why doesn't D have a in keyword for arrays? > > The docs explains that you can use in only for associative arrays > but I don't see the reasons for such decision. > > > Example code: > > void main() > { > auto v

Re: Looking for a job in USA

On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote: On Saturday, 18 November 2017 at 01:31:09 UTC, Indigo wrote: On Wednesday, 15 November 2017 at 17:32:50 UTC, Satoshi wrote: Hi, as the title says, I'm looking for a job opportunity in the USA (H1B visa sponsorship required). I'm

Re: Having "in" for arrays

On Wednesday, 22 November 2017 at 09:36:43 UTC, Dukc wrote: On Wednesday, 22 November 2017 at 08:03:50 UTC, Fra Mecca wrote: void main() { auto v = ["r", "i", "o"]; assert ("r" in v); } Also note that even if it wereimplemented, you search for 'r' instead of "r". "r" is a

Re: interfacing c++

On Wednesday, 22 November 2017 at 08:29:26 UTC, MGW wrote: Possibly it will be interesting https://pp.userapi.com/c639524/v639524332/60240/uH3jnxrchik.jpg

Re: interfacing c++

On Tuesday, 21 November 2017 at 23:12:33 UTC, Markus wrote: hi, im trying to interface a cpp class. I'd like to interface a bigger library and I'm trying to figure out the minimum effort. Possibly it will be interesting https://www.youtube.com/watch?v=HTgJaRRfLPk

Re: interfacing c++

22.11.2017 02:12, Markus пишет: snip I could do the instancing/destruction by functions and write a custom d class that calls these methods in this()/~this(). This is what I used to do as special members like ctor/dtor did not supported in D before, but your example of using ctor is

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, November 22, 2017 09:28:47 codephantom via Digitalmars-d wrote: > On Wednesday, 22 November 2017 at 08:55:03 UTC, Petar Kirov > > [ZombineDev] wrote: > > On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom > > > > wrote: > >> btw. what was the last compiler you wrote? > > >

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom wrote: btw. what was the last compiler you wrote? https://github.com/eth-srl/psi https://github.com/tgehr/d-compiler

Re: TickDuration deprecation

On 11/21/2017 11:48 PM, Jon Degenhardt wrote: Hi Walter - I wonder if there is a miscommunication. My understanding is that the question is whether there should be a built-in conversion from Duration to float/double in a specific unit of measure, like milliseconds. It sounds as if your concern

Re: Having "in" for arrays

On Wednesday, 22 November 2017 at 08:03:50 UTC, Fra Mecca wrote: void main() { auto v = ["r", "i", "o"]; assert ("r" in v); } Also note that even if it wereimplemented, you search for 'r' instead of "r". "r" is a string, but you would want to search for a char.

Re: TickDuration deprecation

On 22.11.2017 06:50, Walter Bright wrote: There is another, perhaps obsolete, consideration. Some CPUs do not have floating point units. C, for example, is carefully set up so that when you don't need floating point, it isn't required to have an FPU. This made C usable on cheap processors.

Re: TickDuration deprecation

On 11/22/2017 5:45 AM, Steven Schveighoffer wrote: 1. All OS calls with timing requirements use non-floating point to represent how long to sleep. After all a CPU uses discrete math, and the timing implementation is no different. Microsoft has numerous COM APIs for time functions. One of them

Re: Error: 'this' is only defined in non-static member functions

On 11/22/17 5:19 PM, A Guy With a Question wrote: I have an interface where I have a classes embedded in it's scope (trying to create something for the classes that implement the interface can use for unittesting).     interface IExample     {     // stuff ...     class Tester    

Re: TickDuration deprecation

On Wednesday, 22 November 2017 at 22:17:05 UTC, Walter Bright wrote: On 11/22/2017 5:45 AM, Steven Schveighoffer wrote: 1. All OS calls with timing requirements use non-floating point to represent how long to sleep. After all a CPU uses discrete math, and the timing implementation is no

Re: Can I count the of enum's fields at compile time?

On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn wrote: > for example: > > enum A { a = -10, b = -11, c = -12, d = -13, e = -34} > > enum int countOfA = coutOfFields(A); // 5 fields import std.traits; enum countOfA = EnumMembers!A.length; - Jonathna M Davis

Re: TickDuration deprecation

On 2017-11-23 12:55, sarn wrote: +1 to using integer arithmetic for the low-level time APIs. and nobody is advocating to change this. it is about being able to use such result (duration) with non-time focused libraries/functions (eg. general maths/stats) expecting doubles. if this is not

Re: Error: 'this' is only defined in non-static member functions

On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a Question wrote: On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven Schveighoffer wrote: On 11/22/17 5:36 PM, Steven Schveighoffer wrote: This allows access to the outer class's members. So you need an instance to instantiate. I

Re: GitBook about D on embedded ARM Linux

On Friday, 1 September 2017 at 09:14:30 UTC, aberba wrote: On Thursday, 31 August 2017 at 14:43:22 UTC, thinwybk wrote: There is no single point of entry to find information about how to use D on ARM Linux. I created a small project on GitHub https://github.com/fkromer/d-on-embedded-linux-arm

Re: Can I count the of enum's fields at compile time?

On Thursday, 23 November 2017 at 00:58:21 UTC, Marc wrote: for example: enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int countOfA = coutOfFields(A); // 5 fields https://dlang.org/spec/traits.html#allMembers enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int

Re: Error: 'this' is only defined in non-static member functions

On Thursday, November 23, 2017 00:49:33 Mike Parker via Digitalmars-d-learn wrote: > On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a > > Question wrote: > > Out of curiosity, what does static mean in that context? When I > > think of a static class I think of them in the context of

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 22:02:11 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 22 November 2017 at 04:55:39 UTC, codephantom wrote: Consider the Goldbach Conjecture, that every even positive integer greater than 2 is the sum of two (not necessarily distinct) primes. According to the

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote: true up to a number < n ... does not address the conjecture correctly. So what? We only need to a proof up to N for regular programming, if at all.

Error: 'this' is only defined in non-static member functions

I have an interface where I have a classes embedded in it's scope (trying to create something for the classes that implement the interface can use for unittesting). interface IExample { // stuff ... class Tester { } } I'm trying to make an instance

Re: Error: 'this' is only defined in non-static member functions

On 11/22/17 5:36 PM, Steven Schveighoffer wrote: This allows access to the outer class's members. So you need an instance to instantiate. I bet it's the same for interfaces. All that being said, the error message is quite lousy. -Steve

Re: Error: 'this' is only defined in non-static member functions

On Wednesday, November 22, 2017 22:45:53 A Guy With a Question via Digitalmars-d-learn wrote: > On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven > > Schveighoffer wrote: > > On 11/22/17 5:36 PM, Steven Schveighoffer wrote: > >> This allows access to the outer class's members. So you need >

Re: Error: 'this' is only defined in non-static member functions

here as non-static, nested class is associated with a specific instance of the class and has access to that class instance via its outer member. - Jonathan M Davis Hmmm...now you have me very intrigued. What is a use-case where you'd want to use a non-static embedded class? Sorry if I'm

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: By what proof? And what do you mean by mathematics? A mathematical claim, that cannot be proven or disproven, is neither true or false. What you are left with, is just a possibility. Thus, it will always remain an

Re: Error: 'this' is only defined in non-static member functions

On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a Question wrote: Out of curiosity, what does static mean in that context? When I think of a static class I think of them in the context of Java or C# where they can't be instantiated and where they are more like namespaces that you

Re: Error: 'this' is only defined in non-static member functions

On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven Schveighoffer wrote: On 11/22/17 5:36 PM, Steven Schveighoffer wrote: This allows access to the outer class's members. So you need an instance to instantiate. I bet it's the same for interfaces. All that being said, the error message is

Re: Error: 'this' is only defined in non-static member functions

On Thursday, November 23, 2017 00:17:46 A Guy With a Question via Digitalmars-d-learn wrote: > > here as non-static, nested class is associated with a specific > > instance of the class and has access to that class instance via > > its outer member. > > > > - Jonathan M Davis > > Hmmm...now you

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 18:16:16 UTC, Wyatt wrote: "Need"? Perhaps not. But so far, I haven't seen any arguments that refute the utility of mitigating patterns of human error. Ok. that's a good point. But there is more than one way to address human error without having to

[Issue 18006] in GDB `ptype` returns `struct` for classes

https://issues.dlang.org/show_bug.cgi?id=18006 Basile B. changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18006] New: in GDB `ptype` returns `struct` for classes

https://issues.dlang.org/show_bug.cgi?id=18006 Issue ID: 18006 Summary: in GDB `ptype` returns `struct` for classes Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: enhancement

Can I count the of enum's fields at compile time?

for example: enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int countOfA = coutOfFields(A); // 5 fields

Re: Can I count the of enum's fields at compile time?

On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M Davis wrote: On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn wrote: for example: enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int countOfA = coutOfFields(A); // 5 fields import std.traits; enum

Re: Can I count the of enum's fields at compile time?

On 11/22/2017 05:21 PM, Marc wrote: On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M Davis wrote: On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn wrote: for example: enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int countOfA = coutOfFields(A); // 5

Re: Looking for a job in USA

On Wednesday, 22 November 2017 at 13:48:34 UTC, codephantom wrote: On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: I have been told by several that Australia is a good place to go and I myself have thought about it. It seems that Australia is probably a rather insulated society

Re: TickDuration deprecation

Ok I understand why there is no conversion from Duration to float, but would be possible to make Duration.total not a member function? So insted of: static mytotal(string unit)(Duration dur) { return dur.total!unit; } alias msecs = mytotal!"msecs"; I could just add alias msecs =

Re: TickDuration deprecation

On 11/22/2017 1:38 AM, Timon Gehr wrote: My claim is not that conversion from time to floating point values associated with a few natural units is "properly part of the time abstraction", just that it should exist. Do you agree with that? I refer to my reply to Jon Degenhardt which has a

Precise GC state

Hi all ! https://github.com/dlang/druntime/pull/1603 Can someone investigate and bring it to us ? 4 years passed from gsoc 2013 and there's still no gc. Many apps suffers from false pointers and bringing such a gc will help those who affected by it. It seems all the tests are passed except

[Issue 18002] assert subverts the type system with the messages that it accepts

https://issues.dlang.org/show_bug.cgi?id=18002 --- Comment #3 from anonymous4 --- The message is not necessarily static and immutability is only a requirement of default druntime implementation of assert failure handler, so it should be enough for the assert failure

Re: Precise GC state

On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong?

Re: TickDuration deprecation

On 11/22/2017 1:41 AM, Timon Gehr wrote: Why would the conversion function be linked in if I never use it? Good question. It depends on how the code is written, and how the compiler represents it in the object file, and how the linker deals with unreferenced parts of object files.

Re: Having "in" for arrays

On Wednesday, 22 November 2017 at 10:32:48 UTC, lobo wrote: On Wednesday, 22 November 2017 at 09:36:43 UTC, Dukc wrote: On Wednesday, 22 November 2017 at 08:03:50 UTC, Fra Mecca wrote: void main() { auto v = ["r", "i", "o"]; assert ("r" in v); } Also note that even if it

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On 22.11.2017 02:09, codephantom wrote: On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis wrote: While I definitely don't think that it's generally very hard to avoid bugs with null pointers/references, telling someone to code correctly in the first place isn't very useful.

Re: writeln, alias this and dynamic arrays.

Thank you all for the helpful responses. I will read more about ranges.

Re: Precise GC state

On 11/22/17 02:53, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Can someone investigate and bring it to us ? 4 years passed from gsoc 2013 and there's still no gc. Many apps suffers from false pointers and bringing such a gc will help those who affected by it. It seems

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On 22.11.2017 01:19, codephantom wrote: On Tuesday, 21 November 2017 at 20:02:06 UTC, Timon Gehr wrote: I'm confident that you would be able to use null safe languages properly if that is what had been available for most of your career. You do realise, that all of the issues you mention

Re: D client for ROS

On Wednesday, 22 November 2017 at 19:02:17 UTC, thinwybk wrote: On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote: Hi all, Are there any robot folks out here that are working with ROS and would be able to work on creating a D client library for it? ROS is used a lot at our

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote: true up to a number < n ... does not address the conjecture correctly. So what? We only need to a proof up to N for regular programming, if at all. hint. It's not a problem that mathmatics can solve. By what proof? And

Re: Can I count the of enum's fields at compile time?

On Thursday, 23 November 2017 at 01:01:42 UTC, Michael V. Franklin wrote: On Thursday, 23 November 2017 at 00:58:21 UTC, Marc wrote: for example: enum A { a = -10, b = -11, c = -12, d = -13, e = -34} enum int countOfA = coutOfFields(A); // 5 fields

Re: Can I count the of enum's fields at compile time?

On Thursday, 23 November 2017 at 01:34:54 UTC, Ali Çehreli wrote: On 11/22/2017 05:21 PM, Marc wrote: On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M Davis wrote: On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn wrote: [...] import std.traits; enum countOfA =

reduce condition nesting

Hello, is there way to reduce this condition: if (c1) { foo(); } else { if (c2) { bar(); } else { if (c3) { ... } } } for instance in kotlin it can be replace with this: when { c1 -> foo(), c2 -> bar(), c3 -> ... else ->

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 01:16:59 UTC, codephantom wrote: That's why we have the concept of 'undefined behaviour'. Errr, no. High level programming languages don't have undefined behaviour. That is a C concept related to the performance of the executable. C tries to get as close to

Re: reduce condition nesting

On Thursday, 23 November 2017 at 05:19:27 UTC, Andrey wrote: Hello, is there way to reduce this condition: if (c1) { foo(); } else { if (c2) { bar(); } else { if (c3) { ... } } } for instance in kotlin it can be replace with this: when { c1

Re: Looking for a job in USA

On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote: [...] Um, it's the same! You won't escape it if you come to stay. Just because the shit hasn't hit the fan yet does not mean it's not coming down the pipe. There are

glfwSetDropCallback undefined symbol

DCD and DMD says that the symbol is undefined! However, I look into derelichtGLFW3. It has this symbol defined! It looks like a bug for me!

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote: I am a C++ game developer and I want to give it a try. It seems "this" in Dlang is a reference instead of pointer. How can I pass it as void *? void foo(void *); class Pizza { public: this() { Pizza newone = this;

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 00:39:21 UTC, codephantom wrote: On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom wrote: Its seems to be, that you prefer to rely on the type system, during compilation, for safety. This is very unwise. To demonstrate my point, using code from a

Re: Looking for a job in USA

On Thursday, 23 November 2017 at 04:13:33 UTC, Indigo wrote: Wow, no need to get offended Actually, I was not at all offended. And we always find it kind of humorous, how people around the world view Australia. We don't get offended by it. In any case, I think you underestimate the

Is d-apt.sourceforge.net functional?

I couldn't find the d-apt-keyring package anywhere root@d9:~# cat /etc/apt/sources.list.d/d-apt.list deb http://master.dl.sourceforge.net/project/d-apt/ d-apt main #APT repository for D root@d9:~# LANG=C apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring Reading package

Re: betterC and noboundscheck

On Wednesday, 22 November 2017 at 16:57:10 UTC, Joakim wrote: On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote: [...] betterC is a new feature that's still being worked on and still has holes in it: https://github.com/dlang/dmd/pull/7151 I suggest you open an issue for it on

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 06:32:30 UTC, codephantom wrote: Here is another demonstation of why you can trust your compiler: Why you "can't" ... is what i meant to say. I love not being able to edit posts. It's so convenient.

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Thursday, 23 November 2017 at 01:33:39 UTC, codephantom wrote: On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim Grostad wrote: By what proof? And what do you mean by mathematics? A mathematical claim, that cannot be proven or disproven, is neither true or false. What you are

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On 22.11.2017 05:55, codephantom wrote: ... >> The question isn't whether we should use the type system to prevent bugs. The question is which set of problems really make sense to prevent with the type system. No, the question should be, what can the compiler prove to be true/false,

Re: TickDuration deprecation

On 11/18/17 9:03 AM, Timon Gehr wrote: (Jonathan M Davis from comment #4) > TickDuration will soon be deprecated, and none of the other time stuff > supports floating point. Anyone who wants that functionality can calculate > the floating point values from the integral values that the

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:14:32 UTC, Stefan Koch wrote: On Wednesday, 22 November 2017 at 15:11:08 UTC, Tim Hsu wrote: On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch will do. I've tried it in the first place. ... Error: this is not an lvalue In that case casting

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:23:58 UTC, Tim Hsu wrote: I am afraid what will happen when casting this reference to void * a ref is a ptr. The cast will produce a ptr which is valid as long as the ref is valid.

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: On 22.11.2017 01:19, codephantom wrote: No, I ideally want the type system to point out when the code is not obviously correct. That does not mean I assume that the code is correct when it compiles (given that I'm using a

[Issue 18005] New: AA leak

https://issues.dlang.org/show_bug.cgi?id=18005 Issue ID: 18005 Summary: AA leak Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: blocker Priority: P1 Component:

Passing this to void *

I am a C++ game developer and I want to give it a try. It seems "this" in Dlang is a reference instead of pointer. How can I pass it as void *? void foo(void *); class Pizza { public: this() { Pizza newone = this; // works but newone is actually not this pizza.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:27:27 UTC, Dukc wrote: On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe wrote: On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote: will do. Even if it were an lvalue, that would be the address of a local. You should basically

Re: dmd/ldc failed with exit code -11

On Tuesday, 21 November 2017 at 19:22:47 UTC, Anonymouse wrote: Compiling a debug dmd and running the build command in gdb, it seems to be a stack overflow at ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen(). After a lot of trial and error I managed to find /a/ line which lets it

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 13:47:19 UTC, Timon Gehr wrote: On 22.11.2017 05:55, codephantom wrote: No, the question should be, what can the compiler prove to be true/false, correct/incorrect about your code, and what effort have you made in your code to assist the compiler to make that

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote: On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote: I am a C++ game developer and I want to give it a try. It seems "this" in Dlang is a reference instead of pointer. How can I pass it as void *? void foo(void *);

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:11:08 UTC, Tim Hsu wrote: On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch will do. I've tried it in the first place. ... Error: this is not an lvalue In that case casting to void* should be fine.

Re: betterC and noboundscheck

On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote: Why -betterC flag not 'include' -noboundscheck flag? -noboundscheck is extremely harmful. If -betterC implied that, it would no longer be a better C, it would just be the same buggy C. The compiler should perhaps inline the

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote: will do. Even if it were an lvalue, that would be the address of a local. You should basically NEVER do that with D classes. Just `cast(void*) this` if you must pass it to such a function.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe wrote: On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote: will do. Even if it were an lvalue, that would be the address of a local. You should basically NEVER do that with D classes. Just `cast(void*) this` if

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe wrote: On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote: will do. Even if it were an lvalue, that would be the address of a local. You should basically NEVER do that with D classes. Just `cast(void*) this` if

Re: Looking for a job in USA

On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote: I have been told by several that Australia is a good place to go and I myself have thought about it. It seems that Australia is probably a rather insulated society in that the rest of the world could kill itself off and they'd be

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: You do realise, that all of the issues you mention can just be handled by coding correctly in the first place. ... Yes, just like everyone else, I realize that if correct code is written, we end up with correct code, but

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote: BTW of course you must realize that you can make the compiler brutally obsolete by just quickly writing down the most efficient possible correct machine code in a hex editor, so I'm not too sure why you participate in a

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote: I am a C++ game developer and I want to give it a try. It seems "this" in Dlang is a reference instead of pointer. How can I pass it as void *? void foo(void *); class Pizza { public: this() { Pizza newone = this;

Re: Precise GC state

On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote: On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote: Hi all ! https://github.com/dlang/druntime/pull/1603 Only the Win32 build fails as Error: more than 32767 symbols in object file What's wrong? Thats a linker(?)

betterC and noboundscheck

Hello. I try compile simple example: import core.stdc.stdio; import std.algorithm : min; extern (C) void main() { char[256] buf; buf[] = '\0'; auto str = "hello world"; auto ln = min(buf.length, str.length); buf[0..ln] = str[0..ln]; printf("%s\n", buf.ptr); } rdmd

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:36:22 UTC, Adam D. Ruppe wrote: On Wednesday, 22 November 2017 at 15:31:36 UTC, Tim Hsu wrote: It seems in D, reference has its own address, am I right? unlike c++ The local variable does have its own address. Do not take its address - avoid or Just

[Issue 18002] assert subverts the type system with the messages that it accepts

https://issues.dlang.org/show_bug.cgi?id=18002 --- Comment #4 from hst...@quickfur.ath.cx --- .idup may not be usable if the assert is triggered by an out-of-memory condition. --

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:31:36 UTC, Tim Hsu wrote: It seems in D, reference has its own address, am I right? unlike c++ In case of classes, yes. But I think function parameter references do not (or rather, of course they have since they exist in memory but it's hidden). Not sure

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Tuesday, 21 November 2017 at 09:12:25 UTC, Ola Fosheim Grostad wrote: Runtime checks are part of the type system though I wouldn't say that, particularly if we are talking about a statically typed language (which Java is).

Re: ESR on post-C landscape

Also http://ithare.com/chapter-vb-modular-architecture-client-side-programming-languages-for-games-including-resilience-to-reverse-engineering-and-portability/ scroll to the part about language choice.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:27:27 UTC, Dukc wrote: It's worth noting that you will still be passing different addresses to foo(void*) because classes are reference types in D (structs are not). In the constructor you're passing the address of the class object itself, but in the main

[Issue 18005] AA leak

https://issues.dlang.org/show_bug.cgi?id=18005 Steven Schveighoffer changed: What|Removed |Added CC|

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:23:58 UTC, Tim Hsu wrote: m_window = glfwCreateWindow(); glfwSetWindowUserPointer(m_window, cast(void *)()); That that & out of there! glfwSetWindowUserPointer(m_window, cast(void *)(this)); without the &, you are fine. Then, on the other side,

Re: interfacing c++

another indicator (as documented) that GC destructor won't work // extern(C++) classes don't have a classinfo pointer in their vtable so the GC can't finalize them https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L90 annoying :( Markus

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

On Wednesday, 22 November 2017 at 14:51:02 UTC, codephantom wrote: The core language of D does NOT need what C# is proposing - that is my view. "Need"? Perhaps not. But so far, I haven't seen any arguments that refute the utility of mitigating patterns of human error. If, over time, a

Re: D client for ROS

On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote: Hi all, Are there any robot folks out here that are working with ROS and would be able to work on creating a D client library for it? ROS is used a lot at our university and in robot research in general, and most people use

  1   2   >