Re: gdc and ldc in MacPorts

On Saturday, 26 August 2017 at 15:28:32 UTC, MacPortsUser wrote: On Wednesday, 23 August 2017 at 22:55:20 UTC, Moritz Maxeiner wrote: [...] If you aren't set on MacPorts, you can use homebrew for ldc. With regards to gdc: A word of caution: Supporting it as a separate package is a bit of a

Re: Appending data to array results in duplicate's.

On Friday, 25 August 2017 at 16:45:16 UTC, Vino.B wrote: Hi, Request your help on the below issue, Issue : While appending data to a array the data is getting duplicated. Program: import std.file: dirEntries, isFile, SpanMode; import std.stdio: writeln, writefln; import std.algorithm:

Re: gdc and ldc in MacPorts

On Wednesday, 23 August 2017 at 18:03:22 UTC, lanphuonglien wrote: Whilst DMD seems to be in MacPorts, GDC and LDC appear not to be. Is this right? If it is then it is wrong – it would be great if the person handling the DMD port could be supported to get a LDC and GDC ports in place. I am a

Re: D as a Better C

On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote: On 8/23/17 11:59 AM, Walter Bright wrote: On 8/23/2017 7:37 AM, Steven Schveighoffer wrote: How do dynamic closures work without the GC? They don't allocate the closure on the GC heap. (Or do I have static/dynamic

Re: D as a Better C

On Wednesday, 23 August 2017 at 15:17:31 UTC, Moritz Maxeiner wrote: On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven Schveighoffer wrote: On 8/23/17 9:12 AM, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on

Re: D as a Better C

On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven Schveighoffer wrote: On 8/23/17 9:12 AM, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm

Re: D as a Better C

On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote: On 8/23/2017 6:28 AM, Moritz Maxeiner wrote: I've been mixing C and full D for a while now (on Linux) by either having the main C program call rt_init/rt_term directly (if druntime is linked in when building a mixed C/D

Re: D as a Better C

On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is

Re: Long File path Exception:The system cannot find the path specified

On Wednesday, 23 August 2017 at 13:04:28 UTC, Vino.B wrote: The line it complains is std.file.FileException@std\file.d(3713):even after enabling debug it points to the same Output: D:\DScript>rdmd -debug Test.d -r dryrun std.file.FileException@std\file.d(3713):

Re: Long File path Exception:The system cannot find the path specified

On Wednesday, 23 August 2017 at 12:01:20 UTC, Vino.B wrote: On Wednesday, 23 August 2017 at 11:29:07 UTC, Moritz Maxeiner wrote: On which line do you get the Exception? Does it happen with shorter paths, as well? Assuming it happens with all paths: Just to be sure, is each of those

Re: Long File path Exception:The system cannot find the path specified

On Wednesday, 23 August 2017 at 05:06:50 UTC, Vino.B wrote: Hi All, When i run the below code in windows i am getting "The system cannot find the path specified" even though the path exist , the length of the path is 516 as below, request your help. Path :

Re: ore.exception.RangeError

On Wednesday, 23 August 2017 at 05:53:46 UTC, ag0aep6g wrote: On 08/23/2017 07:45 AM, Vino.B wrote: Execution : rdmd Summary.d - Not working rdmd Summary.d test - Working Program: void main (string[] args) { if(args.length != 2 ) writefln("Unknown operation: %s", args[1]); } When

Re: Parameter File reading

On Wednesday, 23 August 2017 at 10:25:48 UTC, Vino.B wrote: Hi All, Can anyone provide me a example code on how to read a parameter file and use those parameter in the program. From, Vino.B For small tools I use JSON files via asdf[1]. As an example you can look at the tunneled settings

Re: Static inline field initialization

On Wednesday, 23 August 2017 at 09:12:19 UTC, Kagamin wrote: On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner wrote: class Test { ubyte[] buf = new ubyte[1000]; // thread local storage, instances in the same thread refer to the same static array } Dynamic initialization is

Re: Another reason to use BetterC

On Wednesday, 23 August 2017 at 01:22:44 UTC, Walter Bright wrote: https://news.ycombinator.com/item?id=15075242 Or better yet, full :D. I still find it strange how people willingly increase their own attack surface with such software, when even a single missed malware program is a total

Re: Static inline field initialization

On Tuesday, 22 August 2017 at 15:52:48 UTC, Kagamin wrote: On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner wrote: There is a bug [1] - as others have pointed out - that the static array isn't stored in TLS, but in global storage, however, but that doesn't apply in this single

Re: Static inline field initialization

On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote: On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner wrote: I agree that it can be confusing if you try to read it with C++ semantics [1]; the solution, however, imho is not to change D semantics or throw warnings

Re: Static inline field initialization

On Tuesday, 22 August 2017 at 13:53:05 UTC, Daniel Kozak wrote: s/buf/bug/ On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak <kozz...@gmail.com> wrote: On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Tuesday, 22 August 2

Re: Static inline field initialization

On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote: Because of D's static initialization of members, this assert fails: class Test { ubyte[] buf = new ubyte[1000]; } void main() { auto a = new Test(); auto b = new Test(); assert(a.buf.ptr != b.buf.ptr); } This

Re: Different Output after each execution

On Friday, 18 August 2017 at 15:46:13 UTC, Vino.B wrote: On Friday, 18 August 2017 at 11:24:24 UTC, Moritz Maxeiner wrote: On Friday, 18 August 2017 at 10:50:28 UTC, Moritz Maxeiner wrote: On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote: On Friday, 18 August 2017 at 08:34:39 UTC, ikod

Re: Different Output after each execution

On Friday, 18 August 2017 at 10:50:28 UTC, Moritz Maxeiner wrote: On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote: On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote: On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote: Hi All, I have written a small program to just list the

Re: Different Output after each execution

On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote: On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote: On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote: Hi All, I have written a small program to just list the directories, but when i run the program each time i am getting

Re: @safe(bool)

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: The only problem would be the lack of actual @safe annotations on the container, as they would only be applicable to one variant, and otherwise cause a compile-time error. [...] Shouldn't the already compiler derive the appropriate

Re: Stefan Koch: New CTFE fix

On Wednesday, 16 August 2017 at 13:53:40 UTC, Johnson wrote: On Wednesday, 16 August 2017 at 10:03:56 UTC, Moritz Maxeiner wrote: On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote: When Moritz commented on your use of 'do' as a function name, that may have been unnecessary for a

Re: Stefan Koch: New CTFE fix

On Wednesday, 16 August 2017 at 10:03:56 UTC, Moritz Maxeiner wrote: You're right in that it was unnecessary to discuss the issue he was describing, but it was relevant to me as a matter of principle. * You're right in that it was unnecessary for discussing the issue he was describing

Re: Stefan Koch: New CTFE fix

On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote: When Moritz commented on your use of 'do' as a function name, that may have been unnecessary for a discussion of your problem. I would contend that when discussing semantics (that is the PL's syntax is not open for change as

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

On Tuesday, 15 August 2017 at 07:52:17 UTC, Gary Willoughby wrote: On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin wrote: An implementation of binary assignment operators for @property functions has been submitted to the DMD pull request queue at

Re: Stefan Koch: New CTFE fix

On Tuesday, 15 August 2017 at 01:41:58 UTC, Johnson wrote: On Tuesday, 15 August 2017 at 01:31:13 UTC, Moritz Maxeiner wrote: On Monday, 14 August 2017 at 22:51:04 UTC, Johnson Jones wrote: string do() { string x; x = "adsf"; pragma(msg, x); return x; } "do" is a keyword in D,

Re: Stefan Koch: New CTFE fix

On Monday, 14 August 2017 at 22:51:04 UTC, Johnson Jones wrote: string do() { string x; x = "adsf"; pragma(msg, x); return x; } "do" is a keyword in D, you can't use it as an identifier. fails because the compiler believes that x is not known at compile time. There are

Re: if (auto x = cast(C) x)

On Wednesday, 9 August 2017 at 21:54:46 UTC, Q. Schroll wrote: For a class/interface type `A` and a class `C` inheriting from `A` one can do A a = getA(); if (auto c = cast(C) a) { .. use c .. } to get a `C` view on `a` if it happens to be a `C`-instance. Sometimes one cannot find a

Re: Get Dll functions at compile time

On Wednesday, 9 August 2017 at 02:11:13 UTC, Johnson Jones wrote: I like to create code that automates much of the manual labor that we, as programmers, are generally forced to do. D generally makes much of this work automatable. For example, I have created the following code which makes

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Wednesday, 9 August 2017 at 08:22:05 UTC, Daniel Kozak wrote: You can write it yourself :P, or pay someone to do it for you. On Wed, Aug 9, 2017 at 10:02 AM, Ryion via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: And that

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: Maybe i made myself not very clear. Sorry about that. I mention this as reading topics here shows the same behavior. People complain. Specific people here keep responding how the complainer needs to do it themselves or pay for it.

Re: Release D 2.075.0

On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Tuesday, 8 August 2017 at 15:40:08 UTC, Ryion wrote: On Sunday, 6 August 2017 at 19:15:59 UTC, bachmeier wrote: Your claim to have limited D skills doesn't prevent you from writing a blog post detailing the things that are missing for Windows development and showing how other languages deal

Re: Specify dmd or ldc compiler and version in a json dub file?

On Tuesday, 8 August 2017 at 09:31:49 UTC, data pulverizer wrote: On Tuesday, 8 August 2017 at 09:21:54 UTC, Moritz Maxeiner wrote: On Tuesday, 8 August 2017 at 09:17:02 UTC, data pulverizer wrote: Hi, I would like to know how to specify dmd or ldc compiler and version in a json dub file.

Re: Specify dmd or ldc compiler and version in a json dub file?

On Tuesday, 8 August 2017 at 09:17:02 UTC, data pulverizer wrote: Hi, I would like to know how to specify dmd or ldc compiler and version in a json dub file. Thanks in advance. You can't [1]. You can specify the compiler to use only on the dub command line via `--compiler=`. [1]

Re: Create class on stack

On Tuesday, 8 August 2017 at 05:37:41 UTC, ANtlord wrote: On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote: If you use this option, do be aware that this feature has been > scheduled for future deprecation [1]. It's likely going to continue working for quite a while (years),

Re: gtk interface responsiveness

On Monday, 7 August 2017 at 22:02:21 UTC, Johnson Jones wrote: I have an icon that I toggle which clicked. It seems that I can't toggle it any faster than about a second. The handler is being called each click but it seems the gui is not updated more than about 1fps in that case? Although,

Re: x64 build time 3x slower?

On Monday, 7 August 2017 at 22:19:57 UTC, Johnson Jones wrote: Why would that be. Program take about 4 seconds to compile and 12 for x64. There is fundamentally no difference between the two versions. I do link in gtk x86 and gtk x64 depending on version, and that's it as far as I can tell.

Re: Create class on stack

On Monday, 7 August 2017 at 22:02:07 UTC, Mike wrote: On Monday, 7 August 2017 at 13:42:33 UTC, Moritz Maxeiner wrote: You can still create a (scope) class on the stack, escape a reference to it using `move` and use it afterwards, all within the rules of @safe, so I'm not convinced that the

Re: Create class on stack

On Monday, 7 August 2017 at 10:42:03 UTC, Jacob Carlborg wrote: On 2017-08-06 17:47, Moritz Maxeiner wrote: If you use this option, do be aware that this feature has been scheduled for future deprecation [1]. It's likely going to continue working for quite a while (years), though. It's

Re: Create class on stack

On Monday, 7 August 2017 at 13:40:18 UTC, Moritz Maxeiner wrote: Thanks, I wasn't aware of this. I tried fooling around scope classes and DIP1000 for a bit and was surprised that this is allowed: --- import core.stdc.stdio : printf; import std.algorithm : move; class A { int i;

Re: Create class on stack

On Monday, 7 August 2017 at 10:50:21 UTC, Mike wrote: On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote: If you use this option, do be aware that this feature has been scheduled for future deprecation [1]. It's likely going to continue working for quite a while (years), though.

Re: Create class on stack

On Sunday, 6 August 2017 at 15:24:55 UTC, Jacob Carlborg wrote: On 2017-08-05 19:08, Johnson Jones wrote: using gtk, it has a type called value. One has to use it to get the value of stuff but it is a class. Once it is used, one doesn't need it. Ideally I'd like to treat it as a struct since

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Sunday, 6 August 2017 at 15:32:07 UTC, Paulo Pinto wrote: On Sunday, 6 August 2017 at 14:16:20 UTC, Moritz Maxeiner wrote: On Sunday, 6 August 2017 at 12:14:16 UTC, Dmitry wrote: [...] A developer who mostly targets Windows wouldn't. But if you look at the statistics [1] you'd see that

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Sunday, 6 August 2017 at 15:18:49 UTC, Ryion wrote: On Sunday, 6 August 2017 at 14:49:47 UTC, Moritz Maxeiner wrote: 1) Anecdotes are not useful here 2) macOS is UNIX, same as Linux, so I'm not sure why the distinction matters as a reply to me Same two points as above. Thanks for the

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Sunday, 6 August 2017 at 14:30:48 UTC, Ryion wrote: On Sunday, 6 August 2017 at 14:16:20 UTC, Moritz Maxeiner wrote: [...] How sure are you even with statistics... On my work half the developers are on Mac, the other half are on Windows. There is not a single Linux system. From the

Re: Jetbrains announce support for rust plugin, show them we want one too!

On Sunday, 6 August 2017 at 12:14:16 UTC, Dmitry wrote: I don't think so. Why developer should use MacOS/Linux if the target platform is Windows in most of cases? A developer who mostly targets Windows wouldn't. But if you look at the statistics [1] you'd see that in the category of systems

Re: Create class on stack

On Sunday, 6 August 2017 at 02:19:19 UTC, FoxyBrown wrote: [...] I don't think you understand what I'm saying. If I use this method to create a "reference" type on the stack rather than the heap, is the only issue worrying about not having that variable be used outside that scope(i.e., have

Re: Create class on stack

On Sunday, 6 August 2017 at 01:18:50 UTC, Johnson Jones wrote: On Saturday, 5 August 2017 at 23:09:09 UTC, Moritz Maxeiner wrote: On Saturday, 5 August 2017 at 17:08:32 UTC, Johnson Jones wrote: using gtk, it has a type called value. One has to use it to get the value of stuff but it is a

Re: Create class on stack

On Saturday, 5 August 2017 at 17:08:32 UTC, Johnson Jones wrote: using gtk, it has a type called value. One has to use it to get the value of stuff but it is a class. Once it is used, one doesn't need it. Ideally I'd like to treat it as a struct since I'm using it in a delegate I would like

Re: delegate confusion

On Friday, 4 August 2017 at 17:47:01 UTC, Moritz Maxeiner wrote: On Friday, 4 August 2017 at 17:44:23 UTC, Timon Gehr wrote: On 04.08.2017 19:36, Moritz Maxeiner wrote: [...] I was (explicitly) arguing that it's in keeping with the current spec. That the spec is unsound and should be

Re: delegate confusion

On Friday, 4 August 2017 at 17:44:23 UTC, Timon Gehr wrote: On 04.08.2017 19:36, Moritz Maxeiner wrote: Next I run `bar`. I get the same output of "4 4 4 4 4". While this hack works in C#, I suppose it's reasonable to assume the D compiler would just reuse stack space for `j`, and that the

Re: delegate confusion

On Friday, 4 August 2017 at 16:57:37 UTC, bitwise wrote: I'm confused about how D's lambda capture actually works, and can't find any clear specification on the issue. I've read the comments on the bug about what's described below, but I'm still confused. The conversation there dropped off in

Re: Who maintains the D website?

On Thursday, 3 August 2017 at 00:48:41 UTC, Andrej Mitrovic wrote: On Thursday, 3 August 2017 at 00:26:31 UTC, Moritz Maxeiner wrote: On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic wrote: Is there a single person who's the main maintainer of the D website..? If not, I have some

Re: Who maintains the D website?

On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic wrote: Is there a single person who's the main maintainer of the D website..? If not, I have some ideas on how to improve it. Not just ideas, I'd like to give a host at improving it myself, really. AFAIK the website is maintained

Re: How do you use D?

On Wednesday, 2 August 2017 at 21:30:11 UTC, SCev wrote: guys don't do your own IDE, i see everyone working on his own IDE, please just make plugin for famous crossplatform IDE.. this will be better for comunity But I'm NIH interested in having my own plugin for Sublime which does exactly

Re: all OS functions should be "nothrow @trusted @nogc"

On Wednesday, 2 August 2017 at 16:32:44 UTC, Andrei Alexandrescu wrote: import std.algorithm; // I probably wouldn't even define this but use the body as is auto strnlen_safe(in char[] str) { return countUntil(cast(ubyte[]) str, '\0'); } Oh that cast it irks me so. -Steve return

Re: Adding deprecated to an enum member

On Tuesday, 1 August 2017 at 01:12:28 UTC, Jeremy DeHaan wrote: I got an error today because I added deprecated to an enum member. Is there a way to achieve this, or am I out of luck? If it isn't doable, should it be? Here's what I want: [...] It's a bug [1]. [1]

Re: this r-value optimizations

On Tuesday, 1 August 2017 at 22:47:24 UTC, Nordlöw wrote: Given the `struct S` with lots of data fields, I've written the following functional way of initializing only a subset of the members in an instance of `S`: struct S { [...] } Now the question becomes: will the S-copying inside

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 1 August 2017 at 22:52:26 UTC, H. S. Teoh wrote: On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer via Digitalmars-d wrote: On 8/1/17 6:17 PM, Moritz Maxeiner wrote: [...] > import std.algorithm; > // I probably wouldn't even define this but use the body as > is >

Re: [OT] Generative C++

On Tuesday, 1 August 2017 at 22:11:47 UTC, Stefan Koch wrote: On Tuesday, 1 August 2017 at 22:06:28 UTC, Walter Bright wrote: On 7/31/2017 5:41 AM, Joakim wrote: If he's right that C++ use is so balkanized, this will simplify some code but further balkanize the language. That might be worth

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer wrote: On 8/1/17 5:54 PM, Moritz Maxeiner wrote: On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote: Am Tue, 1 Aug 2017 10:50:59 -0700 schrieb "H. S. Teoh via Digitalmars-d" : On Tue, Aug

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote: Am Tue, 1 Aug 2017 10:50:59 -0700 schrieb "H. S. Teoh via Digitalmars-d" : On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote: > Direct OS function calls should probably all be

Re: Struct Postblit Void Initialization

On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote: Hey, just wanted to know whether something like this would be possible sowmehow: struct S { int m; int n; this(this) { m = void; n = n; } } So not the whole struct is moved everytime f.e. a function is called, but only n has to be

Re: D move semantics

On Sunday, 30 July 2017 at 16:12:41 UTC, piotrekg2 wrote: What is the idiomatic D code equivalent to this c++ code? There's no direct equivalent of all your code to D using only druntime+phobos AFAIK. class Block { [...] }; Since you don't seem to be using reference type semantics or

Re: M:N thread multiplexing

On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote: Reading this article: http://www.evanmiller.org/why-im-learning-perl-6.html makes me curious about the state of Dlang's M:N thread multiplexing. Quoting the article: "if you want M:N thread multiplexing your options today are precisely

Re: GC

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote: I would like to learn more about GC in D. [...] It would be great if you could point me out to articles on this subject. The primary locations to get information are the language specification [1] and the druntime documentation [2]. I

Re: Accessing memory after destroy

On Saturday, 29 July 2017 at 20:44:30 UTC, Johan Engelen wrote: [...] ``` class Foo { int x; this() { x = 1; } } Foo foo = new Foo; destroy(foo); assert(foo.x == int.init); // object is still accessible ``` [...] 2. It is _valid_ to access the memory after calling destroy. Point 2 is

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

On Friday, 28 July 2017 at 16:44:24 UTC, MysticZach wrote: On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote: One option to solve the out contract ambiguity and aid parsing by tools is to require 'do' after out contract expressions. It allows the syntax `out(expression) do {...}`,

Re: How do you use D?

On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: While the Orgs using D page is very nice ... I hoping to hear more personal stories ... So How do you use D? Privately whenever I need a program for something and D is the right tool for the job. in your side project, (github, links

Re: Problem with dtor behavior

On Friday, 28 July 2017 at 11:39:56 UTC, SrMordred wrote: On Thursday, 27 July 2017 at 20:28:47 UTC, Moritz Maxeiner wrote: On Thursday, 27 July 2017 at 19:19:27 UTC, SrMordred wrote: //D-CODE struct MyStruct{ int id; this(int id){ writeln("ctor"); } ~this(){

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 23:52:27 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 09:32:12PM +, Moritz Maxeiner via Digitalmars-d wrote: [...] Yes, and therefore "you already have much bigger things to worry about than D services hanging". That you're ignorant of the

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 20:48:51 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars-d wrote: On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: [...] > I see no problem whatsoever requiring that the platform > segfault

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 20:09:46 UTC, Steven Schveighoffer wrote: Well, let's not forget that the services should not be dereferencing null. It's still a bug in the code. Of course, but statistically speaking, all software is buggy so it's not an unreasonable assumption on the

Re: Problem with dtor behavior

On Thursday, 27 July 2017 at 19:19:27 UTC, SrMordred wrote: //D-CODE struct MyStruct{ int id; this(int id){ writeln("ctor"); } ~this(){ writeln("dtor"); } } MyStruct* obj; void push(T)(auto ref T value){ obj[0] = value; } void main() { obj =

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via Digitalmars-d wrote: A possibility: "@safe D does not support platforms or processes where dereferencing a null pointer does not crash the program. In such

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 17:52:09 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] However, there do exist places where dereferencing null may NOT cause a segmentation fault. For example, see this post by Moritz Maxeiner:

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 14:45:03 UTC, Steven Schveighoffer wrote: On 7/27/17 10:20 AM, Moritz Maxeiner wrote: On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote: I'm fine with saying libraries or platforms that do not segfault when accessing zero page are incompatible

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote: On 7/27/17 9:24 AM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote: I think we can correctly assume no fclose implementations exist that do anything but access data pointed at

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 13:45:21 UTC, ag0aep6g wrote: On 07/27/2017 03:24 PM, Moritz Maxeiner wrote: --- null.d --- version (linux): import core.stdc.stdio : FILE; import core.sys.linux.sys.mman; extern (C) @safe int fgetc(FILE* stream); void mmapNull() { void* mmapNull =

Re: all OS functions should be "nothrow @trusted @nogc"

On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote: On 7/25/17 8:45 PM, Timon Gehr wrote: On 26.07.2017 02:35, Steven Schveighoffer wrote: On 7/25/17 5:23 PM, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote: The behavior is

Re: Destructors vs. Finalizers

On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote: On 7/26/17 7:28 PM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote: On 7/26/17 2:33 PM, Moritz Maxeiner wrote: A finalizer may freely work on non-pointer members and pointer

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 23:28:38 UTC, Moritz Maxeiner wrote: This falsely assumes that all members point into the GC pool. A finalizer may freely work on non-pointer members and pointer members that target objects outside the GC pool which the programmer knows to be valid at

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote: On 7/26/17 2:33 PM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote: I don't get it. The GC collects the objects which aren't in use anymore. The order in which this is currently happening

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote: Alright, thanks for the clarification. I've briefly hoped for some sort of miracle such as deterministic object lifetime without manual interaction. :) I'm not sure what scheme you are trying to describe here, could you give a code

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote: I don't get it. The GC collects the objects which aren't in use anymore. The order in which this is currently happening is not specified. So, how are the destructors supposed to be called in the right order? Manually? ARC? After the

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 13:54:15 UTC, Guillaume Piolat wrote: On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote: On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat wrote: I don't get the distinction between destructors and "finalizers" but imho the problem is very

Re: Destructors vs. Finalizers

On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote: Regarding the issue with `destroy` not being @nogc, I my understanding is it comes down to `rt_finalize` not being @nogc. I haven't dug too deeply into the discussions around it, but I'm wondering if it's possible to separate the

Re: all OS functions should be "nothrow @trusted @nogc"

On Wednesday, 26 July 2017 at 06:44:51 UTC, Shachar Shemesh wrote: On 25/07/17 18:29, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 14:39:15 UTC, Shachar Shemesh wrote: On 25/07/17 17:24, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote: The title

Re: all OS functions should be "nothrow @trusted @nogc"

On Wednesday, 26 July 2017 at 00:35:13 UTC, Steven Schveighoffer wrote: On 7/25/17 5:23 PM, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote: The behavior is defined. It will crash with a segfault. In C land that behaviour is a platform

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote: On 7/25/17 2:36 PM, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer wrote: On 7/25/17 12:14 PM, Kagamin wrote: While we're at it, check this:

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer wrote: On 7/25/17 12:14 PM, Kagamin wrote: While we're at it, check this: https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047 Looks fine to me. That's not an array of FILE, it's a single pointer. fgetc

Re: Prevent destroy() from calling base deconstructor of a derived class?

On Tuesday, 25 July 2017 at 17:50:18 UTC, Dragonson wrote: I need to call only the deconstructor of the derived class I have an instance of, not every deconstructor in the inheritance chain. Putting `override` before the destructor doesn't compile so I'm not sure how to achieve this? Call

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 25 July 2017 at 14:39:15 UTC, Shachar Shemesh wrote: On 25/07/17 17:24, Moritz Maxeiner wrote: On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote: The title really does says it all. Since you explicitly state *all* OS functions: nothrow: Should be OK (only callbacks

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 25 July 2017 at 14:32:18 UTC, Shachar Shemesh wrote: On 25/07/17 17:11, ag0aep6g wrote: On 07/25/2017 03:50 PM, Shachar Shemesh wrote: The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I

Re: all OS functions should be "nothrow @trusted @nogc"

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote: The title really does says it all. Since you explicitly state *all* OS functions: nothrow: Should be OK (only callbacks could violate this and they should be nothrow, anyway). @trusted: This can only be done for those functions

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

On Tuesday, 25 July 2017 at 07:48:39 UTC, Andrea Fontana wrote: On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote: DIP 1009 is titled "Improve Contract Usability". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md Based on feedback from the first round, this DIP has been

Re: Release D 2.075.0

On Monday, 24 July 2017 at 23:25:50 UTC, Martin Nowak wrote: On Monday, 24 July 2017 at 22:15:16 UTC, Moritz Maxeiner wrote: One thing to watch out for, though, is that if the D frontend starts using features introduced after its conversion to D, we are going to need to explicitly document the

<    1   2   3   4   5   6   >