Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

Post reply on HN
Print view View original

271–280 of 360 posts

Re: Better C – A subset of D Programming Language

#271

Post by WalterBright »

arunc wrote: post #62
WalterBright wrote: post #4

Walter here - AMA!

Hi Walter, I have two questions: 1. Why do functions need to be annotated with @safe and nothrow in betterC? Why not make them default? I understand making it default for non-betterC might break some code. 2. string type was uniform and awesome until it was treated as Unicode. Any plans to fix this and remove auto decoding? That would be awesome. Edit: three questions to two. I had another question about using thread…

1. Making the defaults different between D and betterC would result in an impedance mismatch that would cause more trouble than it is worth.

2. I think you're referring to autodecode. There is an effort ongoing to extricate us from that, but it's difficult while maintaining backwards compatibility.

3. That's right. You'll have to use C threads.

Re: Better C – A subset of D Programming Language

#272

Post by WalterBright »

DoingIsLearning wrote: post #248
WalterBright wrote: post #4

Walter here - AMA!

Hi Walter, I am a bit late to the thread but thank you for all your work and for joining this thread. What is your vision for D/betterC/SafeD? Is the intention at the moment to stay as a systems programming language only, or is your vision that D or betterC or SafeD gain traction as an embedded target language? I definitely think the focus on correctness and the ease of unit testing would be great in the embedded dev…

BetterC is very suitable for embedded work. I wish I had it available when I did such work.

Re: Better C – A subset of D Programming Language

#273

Post by lumberjackstian »

lultimouomo wrote: post #253
lumberjackstian wrote: post #182

Earlier quoted context omitted.

I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard. Another reason is the (ironically) dynamic nature of a return type. E.g. auto whatDoesItReturn(int i)() { static if (i…

> auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } } I agree with your point, but for the sake of the audience who doesn't know D I think this example is misleading, as one could take the "int i" parameter as a runtime one, while it's actually a compile time one (the equivalent of C++ non-type template parameter). If you instantiate the function with 0 as a compile…

Yeah I realise I could've explained a bit more about template arguments indeed! The point was that it can be hard to specify the return type.

Re: Better C – A subset of D Programming Language

#274

Post by lumberjackstian »

RandallBrown wrote: post #247
lumberjackstian wrote: post #229

Earlier quoted context omitted.

When it comes to templates it's not until instantiation time - when the compiler see the code being used. So this is just an issue during compilation. The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif

So the previous code wouldn't compile unless the compiler knew what values were going to be passed into whatDoesItReturn?

Aye correct! I should've been more clear about that, sorry.

Template arguments need to be known at compile time, and the extra set of parens is how templates parameters are declared in D.

Re: Better C – A subset of D Programming Language

#275

Post by saagarjha »

schaefer wrote: post #101
smallstepforman wrote: post #91

Earlier quoted context omitted.

Andrew needs to radically change his stance on Tabs for the language to be taken seriously. White space must be ignored, and Andrew should overlook his personal bias and cater to the ‘preserve white space’ crowd. Because formatting and readability matter - a lot.

You refer to "Andrew's stance on tabs" without being specific or providing a reference, so I wend digging for more details in the language FAQ. From the reference I found[1], Andrew's stance is: The current zig tooling forces spaces instead of tabs because the tooling for the language is not yet complete. The self hosted compiler (which the community will start using just as soon as it's ready) already does accept bo…

I am very curious why the stage1 compiler cannot just run zig fmt prior to parsing the code as a stopgap until the self-hosted compiler is complete…

Re: Better C – A subset of D Programming Language

#276

Post by WalterBright »

zem wrote: post #231

every time I've looked into this I've found the documentation severely lacking in examples of how one would go about incrementally migrating a c project to better c. does someone have a pointer to a blog post or even a git commit that illustrates the first step of migrating a single c file, with all the attendant makefile changes?

The dmd backend itself used -betterC to make the conversion from the original C-with-Classes code. DMC++ itself underwent the conversion to D using -betterC.

https://github.com/DigitalMars/Compiler/tree/master/dm/src/d...

It still looks a lot like C.

Re: Better C – A subset of D Programming Language

#277

Post by saagarjha »

yvdriess wrote: post #55
WalterBright wrote: post #4

Walter here - AMA!

A compiler related question: A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensi…

Another complication to the normal "pass structs by pointer" is that small structs are actually split up and passed in registers depending on the platform ABI, which can be more efficient in certain cases.

Re: Better C – A subset of D Programming Language

#278

Post by DougBTX »

masklinn wrote: post #234
schveiguy wrote: post #215

Earlier quoted context omitted.

What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work…

> What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref The others are separate abstract operations which are available (implemented) on vecs e.g…

I’ve not looked much into D, but I’ve really been enjoying Rust.

I think the main takeaway is that there are very different ways of approaching language design. In Rust there was a decision to make the function signature the single place which defines the guaranteed input and output types to a function, but that is a trade-off. It encourages a more complex type system, as the flexibility of functions is on a sense constrained by the type system. Personally I like that explicitness, since there is only one place to look. In the future features like const generics and GATs will make that more powerful.

But on the other hand, D appears to be able to support much more complex types (possibly dependent types?) by not requiring that the type system can express them directly. In a sense the whole language can be used to define types. That’s a cool thing to be able to do, even if it means having to inspect documentation and method bodies to work out what they do.

Re: Better C – A subset of D Programming Language

#279

Post by WalterBright »

zem wrote: post #231

every time I've looked into this I've found the documentation severely lacking in examples of how one would go about incrementally migrating a c project to better c. does someone have a pointer to a blog post or even a git commit that illustrates the first step of migrating a single c file, with all the attendant makefile changes?

1. rename the file from prog.c to prog.d

2. set up to compile with dmc prog.c -c -betterC

3. replace all the preprocessor stuff

4. compile it, and fix the errors diagnosed by the compiler

The hardest part will be how much metaprogramming was done using the C preprocessor. Once that's dealt with, the rest is fairly mechanical.

Re: Better C – A subset of D Programming Language

#280

Post by underthensun »

F-0X wrote: post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

I really hate the auto keyword but as I like D so much, I kinda get used to it.
Post reply on HN