Re: Is this a bug? +goto
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn wrote: > On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis > > wrote: > >> And I found a bit strange that in such code, since "x" is > >> never used, why it isn't skipped. > > > > It's skipped right over. The goto jumps out of the scope, and > > the line with > > > > int x; > > > > is never run. In fact, if you compile with -w or -wi, the > > compiler will give you a warning about unreachable code. > > That is exactly my point. > > Since "x" it's skipped and never used, it shouldn't just be a > warning (unreachable code) instead of an error? > > I'm trying to understand why/when such code could give any > problem. > > On the other hand if the code were: > > { > goto Q: > int x; > > Q: > x = 10; // <- Now you are accessing an uninitialized variable. > } > > Then I think an error would be ok. D tries to _very_ little with code flow analysis, because once you start having to do much with it, odds are that the compiler implementation is going to get it wrong. As such, any feature that involves code flow analysis in D tends to be _very_ simple. So, D avoids the issue here by saying that you cannot skip the initialization of a variable with goto. The compiler is not going to do the complicated logic of keeping track of where you access the variable in relation to the goto. That's exactly the sort of thing that might be obvious in the simple case but is highly likely to be buggy in more complex code. Code such as { goto Q; int x; } Q: or { if(foo) goto Q; int x; } Q: is fine, because the compiler can trivially see that it is impossible for x to be used after it's been skipped, whereas with something like goto Q; int x; Q: the compiler has to do much more complicated analysis of what the code is doing in order to determine that, and when the code isn't trivial, that can get _really_ complicated. You could argue that it would be nicer if the language required that the compiler be smarter about it, but by having the compiler be stupid, it reduces the risk of compiler bugs, and most people would consider code doing much with gotos like this to be poor code anyway. Most of the cases where goto is reasonable tend to be using goto from inside braces already, because it tends to be used as a way to more efficiently exit deeply nested code. And with D's labeled break and continue, the need for using goto outside of switch statements also tends to be lower than it is in C/C++. - Jonathan M Davis
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 01:05:04 UTC, Neia Neutuladh wrote: In C++, if you skip over `int i = 10;` it's an error, but not if you skip over `int i;`. In fact I agree with that rule more than the D one to be honest. Since It isn't initialized and never used, I think a warning should be enough instead of an error. On the other hand, if there is a possibility that the variable can be accessed, then an error should be throw. Like: { goto Q: int x; Q: x = 10; // An error is ok. } But here: { goto Q: int x; // An warning should be enough in my IMHO. Q: return; } MatheusBN.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 01:04:46 UTC, Stanislav Blinov wrote: ...Even if you don't see any explicit use, it doesn't mean the compiler doesn't see an implicit one. Sorry I don't think that I follow that. How a compiler could see an use when it's not being used/invoked on a program like in that snipped? MatheusBN.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis wrote: And I found a bit strange that in such code, since "x" is never used, why it isn't skipped. It's skipped right over. The goto jumps out of the scope, and the line with int x; is never run. In fact, if you compile with -w or -wi, the compiler will give you a warning about unreachable code. That is exactly my point. Since "x" it's skipped and never used, it shouldn't just be a warning (unreachable code) instead of an error? I'm trying to understand why/when such code could give any problem. On the other hand if the code were: { goto Q: int x; Q: x = 10; // <- Now you are accessing an uninitialized variable. } Then I think an error would be ok. MatheusBN.
Re: Is this a bug? +goto
On Monday, November 5, 2018 5:33:56 PM MST MatheusBN via Digitalmars-d-learn wrote: > On Tuesday, 6 November 2018 at 00:14:26 UTC, Jonathan M Davis > > wrote: > > On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via > > > > Digitalmars-d-learn wrote: > >> Hi, > >> > >> I posted this in another thread but without any response. > >> > >> This code: > >> > >> void main(){ > >> > >> goto Q; > >> int x; > >> Q: > >> writeln("a"); > >> > >> } > >> > >> Gives me this error: "source_file.d(4): Error: goto skips > >> declaration of variable source.main.x at source_file.d(5)" > >> > >> > >> Now, if I add a pair of brackets: > >> > >> void main(){ > >> > >> { > >> > >> goto Q; > >> int x; > >> > >> } > >> Q: > >> writeln("a"); > >> > >> } > >> > >> It works. So Is this a bug? > > > > All the spec says on the matter is that > > > > "It is illegal for a GotoStatement to be used to skip > > initializations." > > > > https://dlang.org/spec/statement.html#goto-statement > > > > In the first case, x exists at the label Q, and its > > initialization was skipped, so it's clearly illegal. However, > > in the second case, because of the braces, x does _not_ exist > > Just to be clear, when you say "x exists at the label Q", you > mean at the same scope, right? The scope that x was at is over at the label Q. So, x doesn't exist at the label Q. It has no address at that point. It's not on the stack. It doesn't exist in any sense other than the fact that it happens to be in the source code above it. In fact, the line with x never even ran, so x _never_ existed. > That's interesting but a bit confusing isn't? I don't see why. { goto Q; int x; } Q: is basically the same thing as while(1) { break; int x; } The same thing happens in both cases. > And I found a bit strange that in such code, since "x" is never > used, why it isn't skipped. It's skipped right over. The goto jumps out of the scope, and the line with int x; is never run. In fact, if you compile with -w or -wi, the compiler will give you a warning about unreachable code. > I know it's another language but in C at least in GCC there is no > error over such code, so that's my confusion. C is a different language, and it's one that generally doesn't care much about safety. It allows all kinds of horrible things that cause bugs. The folks behind D (and the folks behind _most_ languages since C/C++) tend to prefer a greater degree of safety than C provides. - Jonathan M Davis
Re: Is this a bug? +goto
On Tue, 06 Nov 2018 00:33:56 +, MatheusBN wrote: > Just to be clear, when you say "x exists at the label Q", you mean at > the same scope, right? The same or an outer scope. It's also invalid to write: goto Y; { int x; { Y: } } > That's interesting but a bit confusing isn't? > > And I found a bit strange that in such code, since "x" is never used, > why it isn't skipped. Because simple rules are usually easier to understand and implement. > I know it's another language but in C at least in GCC there is no error > over such code, so that's my confusion. Because C is a horribly unsafe language, far beyond necessary to have a low-level systems language. In C++, if you skip over `int i = 10;` it's an error, but not if you skip over `int i;`. Similarly, if you skip over a class variable declaration without an explicit initialization expression, if the class has a constructor or destructor, it's an error. In D, every variable of every type is initialized unless you opt out. The compiler *could* let you skip over declarations that are void-initialized, but there isn't a huge reason to do so.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 00:38:01 UTC, MatheusBN wrote: On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov wrote: But here it's fine: void main(){ { goto Q; S x; } // <--- Q: writeln("a"); } because goto jumps over both initialization *and* destruction, i.e. neither would even be performed. I see but at same time I found a bit confusing, because in this case we're just adding a new scope to fix the issue, and like I said to Jonathan, I thought that "x" wouldn't be initialized since it is never used. It's not as simple as that, that's why I specifically showed the destructor case. Even if you don't see any explicit use, it doesn't mean the compiler doesn't see an implicit one.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov wrote: But here it's fine: void main(){ { goto Q; S x; } // <--- Q: writeln("a"); } because goto jumps over both initialization *and* destruction, i.e. neither would even be performed. I see but at same time I found a bit confusing, because in this case we're just adding a new scope to fix the issue, and like I said to Jonathan, I thought that "x" wouldn't be initialized since it is never used. Thanks, MatheusBN.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 00:14:26 UTC, Jonathan M Davis wrote: On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via Digitalmars-d-learn wrote: Hi, I posted this in another thread but without any response. This code: void main(){ goto Q; int x; Q: writeln("a"); } Gives me this error: "source_file.d(4): Error: goto skips declaration of variable source.main.x at source_file.d(5)" Now, if I add a pair of brackets: void main(){ { goto Q; int x; } Q: writeln("a"); } It works. So Is this a bug? All the spec says on the matter is that "It is illegal for a GotoStatement to be used to skip initializations." https://dlang.org/spec/statement.html#goto-statement In the first case, x exists at the label Q, and its initialization was skipped, so it's clearly illegal. However, in the second case, because of the braces, x does _not_ exist Just to be clear, when you say "x exists at the label Q", you mean at the same scope, right? That's interesting but a bit confusing isn't? And I found a bit strange that in such code, since "x" is never used, why it isn't skipped. I know it's another language but in C at least in GCC there is no error over such code, so that's my confusion. Thanks, MatheusBN.
Re: Is this a bug? +goto
On Monday, November 5, 2018 4:54:59 PM MST MatheusBN via Digitalmars-d-learn wrote: > Hi, > > I posted this in another thread but without any response. > > This code: > > void main(){ > goto Q; > int x; > Q: > writeln("a"); > } > > Gives me this error: "source_file.d(4): Error: goto skips > declaration of variable source.main.x at source_file.d(5)" > > > Now, if I add a pair of brackets: > > void main(){ > { > goto Q; > int x; > } > Q: > writeln("a"); > } > > It works. So Is this a bug? All the spec says on the matter is that "It is illegal for a GotoStatement to be used to skip initializations." https://dlang.org/spec/statement.html#goto-statement In the first case, x exists at the label Q, and its initialization was skipped, so it's clearly illegal. However, in the second case, because of the braces, x does _not_ exist at the label Q, so its initialization was not skipped, so I don't see why it wouldn't be legal based on what the spec says, and I don't see any reason to make it illegal. Conceptually, it's doing exactly what you'd get with a break if the braces were for a loop. However, it is true that the spec could (and probably should) be more specific on the matter. - Jonathan M Davis
Re: Is this a bug? +goto
On Monday, 5 November 2018 at 23:54:59 UTC, MatheusBN wrote: Hi, I posted this in another thread but without any response. This code: void main(){ goto Q; int x; Q: writeln("a"); } Gives me this error: "source_file.d(4): Error: goto skips declaration of variable source.main.x at source_file.d(5)" Now, if I add a pair of brackets: void main(){ { goto Q; int x; } Q: writeln("a"); } It works. So Is this a bug? No, it's not. Consider replacing that int with a type that has a destructor: struct S { ~this() { /* ... */ } } void main(){ goto Q; S x; Q: writeln("a"); } // <--- Now, what should happen at that closing paren is a destructor call, x.__dtor. However, goto jumps over initialization of 'x', which would lead to calling a destructor on an uninitialized value. That's why the compiler disallows such skips. But here it's fine: void main(){ { goto Q; S x; } // <--- Q: writeln("a"); } because goto jumps over both initialization *and* destruction, i.e. neither would even be performed. I'm guessing you misunderstood the author of that other thread. What he's saying is that code similar to the *second* version fails. That's what all the commotion is about over there. This simple example obviously works, yet in his more complicated code base something goes wrong.
Is this a bug? +goto
Hi, I posted this in another thread but without any response. This code: void main(){ goto Q; int x; Q: writeln("a"); } Gives me this error: "source_file.d(4): Error: goto skips declaration of variable source.main.x at source_file.d(5)" Now, if I add a pair of brackets: void main(){ { goto Q; int x; } Q: writeln("a"); } It works. So Is this a bug? MatheusBN.
Re: Accessing LPARAM param from SendMessage acts weird.
Brilliant! Thanks John !
Re: Implicit cast to const of result returned from findSplit()
On Monday, 5 November 2018 at 13:26:18 UTC, Per Nordlöw wrote: AFAICT, it looks like a missing bool qualifier on `opCast!bool`, right? Fixed at https://github.com/dlang/phobos/pull/6749
Re: Implicit cast to const of result returned from findSplit()
On Monday, 5 November 2018 at 13:26:18 UTC, Per Nordlöw wrote: AFAICT, it looks like a missing bool qualifier on `opCast!bool`, right? ...Like a missing 'const' qualifier ;) auto findSplit(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle) // ... static struct Result(S1, S2) if (isForwardRange!S1 && isForwardRange!S2) { // ... bool opCast(T : bool)() { return !asTuple[1].empty; } // ... }
Implicit cast to const of result returned from findSplit()
Why does @safe pure unittest { import std.algorithm.searching : findSplit; if (const split = "a b".findSplit(" ")) { } } error as f.d(4,5): Error: mutable method `std.algorithm.searching.findSplit!("a == b", string, string).findSplit.Result!(string, string).Result.opCast!bool.opCast` is not callable using a `const` object f.d(4,5):Consider adding `const` or `inout` to std.algorithm.searching.findSplit!("a == b", string, string).findSplit.Result!(string, string).Result.opCast!bool.opCast when @safe pure unittest { import std.algorithm.searching : findSplit; if (auto split = "a b".findSplit(" ")) { } } doesn't? AFAICT, it looks like a missing bool qualifier on `opCast!bool`, right?
Re: javascript or typescript
On Monday, 5 November 2018 at 08:49:42 UTC, Laurent Tréguier wrote: On Monday, 5 November 2018 at 02:51:19 UTC, Fred wrote: hi, my javascript skill is bad. but i want to host some nodejs app i am aware that there is converter to js like dtojs. but it is out of date. i'd like to give d a try. is there any other converter available. a decent one. I haven't personally tried it, but there is an example of compiling D to Javascript here : https://github.com/Ace17/dscripten The example I used (thanks to Cosinuns): https://github.com/cosinus2/dlang-emscripten-demo I'd try DScripten first, though. Without, I need to compile parts of Phobos myself to JS. Plus the Emscripten linker seemingly can't link D symbols because of some bug. I have to manually call the LLVM linker, which sometimes seems to have different ideas about what the program is calling.
Re: javascript or typescript
On Monday, 5 November 2018 at 02:51:19 UTC, Fred wrote: hi, my javascript skill is bad. but i want to host some nodejs app i am aware that there is converter to js like dtojs. but it is out of date. i'd like to give d a try. is there any other converter available. a decent one. Let me recommend https://bridge.net/ Transpiles C# to JavaScript. I use it at work as my main tool. Feels very mature. IMO C# < D, but it still wipes the floor with using JavaScript directly. Minority of my JavaScript is also transpiled from D. If you do the same, you will need a lot more determination and know-how than normal, and you can't except to use all D features. Multithearding and GC among other features are out. You could use DScripten which will probably make D better in this regard, but still not like normal. Personally I haven't still tried DScripten because there is not much I could easily port to D. The reason for that is that D cannot call most js functions directly, because it cannot handle most JavaScript types. Except if you manage to translate Emscripten headers val.h and wire.h (which are heavily templated c++) into D. I have put some effort to that, but it's not going well. Because of the reasoms above, I don't currently recommend D as a JavaScript source for the average programmer. However, you will most likely want to make some utility programs to assist you -build scripts, mass file handling, translating configuration file formats etc. There D works very well. Also, as said, the server backend does not have to be JavaScript - only the frontend. For backend, you can use D web frameworks -vibe.d/hunt/diamond- instead.
Re: Putting dmd error through grep for dustmite
On Monday, 5 November 2018 at 03:13:26 UTC, Vladimir Panteleev wrote: cmd.exe will interpret \` verbatim (i.e. as \`), so, try not quoting the ` characters (or just replace them with . if you want the command to work in both shells). Of course, the one thing I didn't try. Thanks!
Re: javascript or typescript
On Monday, 5 November 2018 at 08:49:42 UTC, Laurent Tréguier wrote: On Monday, 5 November 2018 at 02:51:19 UTC, Fred wrote: hi, my javascript skill is bad. but i want to host some nodejs app i am aware that there is converter to js like dtojs. but it is out of date. i'd like to give d a try. is there any other converter available. a decent one. I haven't personally tried it, but there is an example of compiling D to Javascript here : https://github.com/Ace17/dscripten ok will look at it. thanks.
Re: Profiling with DUB?
On Thursday, 1 November 2018 at 13:59:39 UTC, Guillaume Piolat wrote: On Monday, 29 October 2018 at 10:14:23 UTC, Dukc wrote: I'm trying to profile my program, built like: dub build --build=profile When I run the program, where is the performance profile file supposed to appear? I can find nothing new in the program/project root directory. This happens regardless whether I compile with dmd or ldc2. If you want to use sampling profilers (like the free Intel Amplifier coming with System Studio) you can also use No, I want to use the default profiler. And then check in your profiler. How? That's the question. If the program is compiled with a profiling switch, isn't the performance profile supposed to appear on program directry after it finishes, when running it just like normal?
Re: javascript or typescript
On Monday, 5 November 2018 at 02:51:19 UTC, Fred wrote: hi, my javascript skill is bad. but i want to host some nodejs app i am aware that there is converter to js like dtojs. but it is out of date. i'd like to give d a try. is there any other converter available. a decent one. I haven't personally tried it, but there is an example of compiling D to Javascript here : https://github.com/Ace17/dscripten
Re: javascript or typescript
On Monday, 5 November 2018 at 05:07:49 UTC, Adam D. Ruppe wrote: On Monday, 5 November 2018 at 02:51:19 UTC, Fred wrote: i'd like to give d a try. Why do you need to convert it to javascript? D can serve up web stuff by itself too. did you mean vibe.d? but i want to use in a shared hosting environment where my options are : ruby, python, nodejs and as usual php vibe.d as standalone app will not work. i know kotlin with js support, but maybe there is another option .. thanks for your answer and insight.