Earlier quoted context omitted.
That code won't compile because Greetings is undefined. Hence, you may be running some other program which seg faults.
ohh, yeah, I omitted the definition of the class because I thought it'd be obvious, here it is: $ cat main.d import std.stdio; class Greetings { void hello() { writeln("hello"); } } void main() { Greetings g = null; g.hello(); } $ dmd -g main.d && ./main Segmentation fault: 11 $ uname -a Darwin Johan-Ride-Mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64…
D 2.069.0 released, compiler automatically ported from C++ to D
71–80 of 131 posts
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#72Earlier quoted context omitted.
ohh, yeah, I omitted the definition of the class because I thought it'd be obvious, here it is: $ cat main.d import std.stdio; class Greetings { void hello() { writeln("hello"); } } void main() { Greetings g = null; g.hello(); } $ dmd -g main.d && ./main Segmentation fault: 11 $ uname -a Darwin Johan-Ride-Mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64…
Replace: Greetings g = null; with: auto g = new Greetings();
I know it's because I'm trying to call a method on "null", but If I'm working on a huge code base, how do I debug this kind of issues if I don't have stack trace with line and error number of the error?
I'd like to get at least the stack trace and the error number with the line of the source code that caused the problem, like in golang:
$ cat main.go
package main
type Greetings struct {
}
func (g Greetings) hello() {
}
func main() {
g := &Greetings{} // heap instance
g = nil // intentionally shooting myself in the foot like I did in D
g.hello()
}
$ go run main.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x2025]
goroutine 1 [running]:
main.main()
/Users/ride/Documents/main.go:13 +0x15
goroutine 2 [runnable]:
runtime.forcegchelper()
/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/proc.go:90
runtime.goexit()
/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1
exit status 2Re: D 2.069.0 released, compiler automatically ported from C++ to D
#73Earlier quoted context omitted.
Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.
As someone who's been following the hype, but not really jumped on yet, the difference (whether real or imagined) seems to be that rust is trying to do something new , and D looks to be (and I've seen it aggressively marketed as) C++ with some better choices and cool features. Personally, I'm not really interested in C++, but I am interested in getting for familiar with a systems language, so rust interests me.
That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet.
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#74Earlier quoted context omitted.
> It still has implicit numeric cast, Implicit numeric casts that lose bits are not allowed anymore. > exception unsafety ??
> Implicit numeric casts that lose bits are not allowed anymore. That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level. > ?? Sorry if my understandings or my words were wrong, but I got the impression that D a…
There's the 'to' function to perform checked conversions and the standard cast operator to perform unchecked conversions.
int foo = 256; ubyte bar = foo.to!ubyte; // throws ConvException ubyte baz = cast(ubyte) foo; // overflows as expected
If I want more type-safety than this, I'll create simple wrappers:
struct Seconds { int value; alias value this; }
That way I can still pass seconds everywhere an int is expected, but I can now declare arguments to only accept Seconds and not ints.
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#75Earlier quoted context omitted.
Funny anecdote for compiler researchers. Niklaus Wirth did write many of his compilers in the original language (kind of). He would write down on paper the code, using the bootstrap version 0 code style, as it was supposed to be. Then he would manually translate that code into Assembly. So when the compiler for the basic language was working, he could use the same code again, without additional efforts and relying on…
Computer languages were a lot simpler in those days.
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#76Earlier quoted context omitted.
Since 1.0 last May, we have a strong commitment to backwards compatibility as well. Stability should not be an issue any longer.
GP is actually the second post in a week I've seen where someone mentions tracking rust changes, but rust has been 1.0 for a while now. Have there actually any backwards incompatible changes since 1.0, or are people really complaining about a problem that's been fixed for close to six months and even then was specific to beta versions?
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#77Earlier quoted context omitted.
Some things D has that Rust doesn't: compiler-checked function purity annotations, higher-kinded types, variadic functions/generics, types parameterised by numbers, compile-time function evaluation, mixins, a fast compiler (the reference DMD compiler), powerful and convenient compile-time reflection (I think technically Rust can do anything D can at compile time, but it requires writing a syntax extension to do so).…
Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#78Earlier quoted context omitted.
> Implicit numeric casts that lose bits are not allowed anymore. That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level. > ?? Sorry if my understandings or my words were wrong, but I got the impression that D a…
> I want implicit conversion to be forbidden unconditionally Not going to happen in a language with 11 integer types. > (double-throw) Exceptions are chained together.
Re: D 2.069.0 released, compiler automatically ported from C++ to D
#79Re: D 2.069.0 released, compiler automatically ported from C++ to D
#80D is a really amazing language that manages to correct the mistakes of c++ but still retain its good parts. it's a shame that it's not more popular.