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.
