Re: Is this a compiler aliasing bug?

2021-09-22 Thread Chris Katko via Digitalmars-d-learn
On Friday, 17 September 2021 at 10:29:12 UTC, bauss wrote: On Friday, 17 September 2021 at 09:44:53 UTC, Chris Katko wrote: [...] It's not a bug because "obj.x" referes to the same symbol that is "this.x" Alias will create an alias for a symbol, not an expression or the like. So obj.x

Re: foreach(ubyte j;0 .. num) is bugging out

2021-09-22 Thread jfondren via Digitalmars-d-learn
On Thursday, 23 September 2021 at 00:30:45 UTC, Ruby The Roobster wrote: I figured out something weird. The variable 'i' is passed by reference, yet the variable 'i' of the loop isn't being incremented by posfunc. I assume foreach creates a new i variable at the start of each new loop. Yep:

Re: foreach(ubyte j;0 .. num) is bugging out

2021-09-22 Thread Ruby The Roobster via Digitalmars-d-learn
On Thursday, 23 September 2021 at 00:17:49 UTC, jfondren wrote: On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The Roobster wrote: So, I have the following function: ```d writeln(tempcolor); //For this matter, the program correctly reports tempcolor as 1... for(ubyte j = 0;j <

Re: foreach(ubyte j;0 .. num) is bugging out

2021-09-22 Thread jfondren via Digitalmars-d-learn
On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The Roobster wrote: So, I have the following function: ```d writeln(tempcolor); //For this matter, the program correctly reports tempcolor as 1... for(ubyte j = 0;j < tempcolor; j++ /*trying ++j has same effect*/ ) { //tempcolor

foreach(ubyte j;0 .. num) is bugging out

2021-09-22 Thread Ruby The Roobster via Digitalmars-d-learn
So, I have the following function: ```d public Sprite ReadSpriteFromFile(immutable(char)[] filename) { //Reads a sprite in my made up .spr format(trash, why does this even exist) ubyte[] ftext; Color[] colors; Point[][] points;

Re: toString and code coverage...

2021-09-22 Thread wjoe via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 18:59:11 UTC, user1234 wrote: [...] I'd use option 2. Thanks, I'll do just that :)

Re: How to make clang use a different tk framework version on MacOS?

2021-09-22 Thread tastyminerals via Digitalmars-d-learn
On Monday, 20 September 2021 at 21:58:27 UTC, tastyminerals wrote: My tkd GUI app started getting compiled with an outdated 8.5 Tk framework version which gets shipped with command line tools: `xcode-select --install`. As a result, the UI doesn't display icons and is laggy. When you run the

Re: toString and code coverage...

2021-09-22 Thread user1234 via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 15:27:23 UTC, wjoe wrote: Is there a convenient way to exclude it from coverage ? Because adjusting the -cov=xx percentage is kind of annoying and may omit other things as well. Do you care and if yes how do you handle it ? You have several options 1.

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/22/21 11:47 AM, eugene wrote: On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven Schveighoffer wrote: On 9/22/21 8:22 AM, eugene wrote: And it follows that programming in GC-supporting languages *may* be harder than in languages with manual memory management, right? I meant my this

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven Schveighoffer wrote: On 9/22/21 8:22 AM, eugene wrote: And it follows that programming in GC-supporting languages *may* be harder than in languages with manual memory management, right? I meant my this particular trouble... I do not want

toString and code coverage...

2021-09-22 Thread wjoe via Digitalmars-d-learn
Is there a convenient way to exclude it from coverage ? Because adjusting the -cov=xx percentage is kind of annoying and may omit other things as well. Do you care and if yes how do you handle it ?

Re: MobI? Really?

2021-09-22 Thread wjoe via Digitalmars-d-learn
On Tuesday, 21 September 2021 at 16:14:52 UTC, Chris_D wrote: Thanks for the replies. jfondren: Sorry, but I am talking about documentation. For me, online web pages don't qualify; they are in the cloud, unreal, with no substance. Does anyone really read 300 pages online, in a web browser?

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/22/21 8:22 AM, eugene wrote: On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven Schveighoffer wrote: Once it's on the stack, the GC can see it for the full run of `main`. This is why this case is different. Note that Java is even more aggressive, and might *still* collect it,

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven Schveighoffer wrote: Once it's on the stack, the GC can see it for the full run of `main`. This is why this case is different. Note that Java is even more aggressive, and might *still* collect it, because it could legitimately set

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven Schveighoffer wrote: Here is what is happening. Many thanks for this so exhaustive explanation!

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/21/21 4:17 PM, eugene wrote: On Tuesday, 21 September 2021 at 19:42:48 UTC, jfondren wrote: On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote: There's nothing special about sg0 and sg1, except that they're part of Stopper. The Stopper in main() is collected before the end of

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 10:05:05 UTC, jfondren wrote: Nondeterminism in heap collection is a very common complaint, It is another kind of nondeterminism that is usually complained about ("*sometime* in the future GC will collect if it wants" or so) but here we have data is that

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread jfondren via Digitalmars-d-learn
On Wednesday, 22 September 2021 at 08:03:59 UTC, eugene wrote: On Tuesday, 21 September 2021 at 20:28:33 UTC, jfondren wrote: Everything is Ok now, I don't think this is reliably OK. If you're not using Stopper later in the function, and if there are no other references to it, then the GC

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Tuesday, 21 September 2021 at 20:28:33 UTC, jfondren wrote: Everything is Ok now, I don't think this is reliably OK. If you're not using Stopper later in the function, and if there are no other references to it, then the GC can collect it. It just has no obligation to collect it, so

Re: Program crash: GC destroys an object unexpectedly

2021-09-22 Thread eugene via Digitalmars-d-learn
On Tuesday, 21 September 2021 at 20:42:12 UTC, H. S. Teoh wrote: A sufficiently optimizing compiler may determine that since Main and stopper are independent, it is free to reorder the code such that the two lifetimes are independent, and therefore end up with the same situation as the first