Live data from Hacker News

D 2.069.0 released, compiler automatically ported from C++ to D

dlang.org

71–80 of 131 posts

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#71

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…

[deleted]

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#72

Earlier 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'm intentionally making it null to see how the new backtraces work.

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 2

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#73
post #66

Earlier 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.

From what I understand, the only new thing Rust is contributing is managed lifetimes. Everything else is, like in D, just borrowed from other languages and put together.

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

#74

Earlier 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…

I rather like the implicit conversions. Especially in D where they only happen where its safe.

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

#75
post #38

Earlier 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.

Are you sure? I remember reading something about PL/I. :)

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#76
post #64

Earlier 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?

Due to its erratic development and the much-delayed release of Rust 1.0, I fear that many people have associated Rust with frequent breaking changes, even if that is no longer the case. It's much like the "Java is slow" fallacy; it may have been true in Java's very early days, but it hasn't been the case for many, many years. Yet the misconception still persists, even to this day. This is the sort of taint that a language will find very hard to shake. The "Rust suffers from breaking changes" misconception is very ingrained in the minds of many programmers now.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#77

Earlier 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.

Rust inherited the enthusiasm of some very prominent and outspoken members of the Ruby community. These ex-Rubyists honed the craft of projecting excitement with Ruby and RoR, and brought these skills and talents with them when they moved to the Rust camp. The D camp hasn't really had anyone like that join them.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#78

Earlier 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.

Walter, is there any chance that we will see the source code to Digital Mars C++ release at some point? Or is it encumbered in ways that would make such a release impossible?

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#79
post #75

Earlier quoted context omitted.

Computer languages were a lot simpler in those days.

Are you sure? I remember reading something about PL/I. :)

Walter has been around a long time. He knows the game. Walter, have you ever used PL/I?

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#80
post #26

D 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.

I often wonder if it were released today as "new" if it would of gained plenty of more hype. One thing I think that Go has that D is lacking is the standard library. With Go you can write a web server, a mail server, and plenty of things right away out of the box. Where in D and other lovely languages you either need to get a package manager, or make your own. Outside of this small detail I think D is amazing at what it's done, and I hope to work on more projects in D in the future. I only wish schools used D in more classes. I guess the last thing it's lacking is a serious IDE. I've seen and tried a couple, but at the end of the day I end up using a text editor with a hoard of plugins.
Post reply on HN