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

Obvious things C should do

digitalmars.com

Post reply on HN
Print view View original

21–30 of 310 posts

Re: Obvious things C should do

#21

Post by WalterBright »

TinkersW wrote: post #15

C++ has all of these except forward referencing declarations(though Importing Declarations requires modules which nobody uses yet). I'm not sure why forward reference declarations is needed nowadays(or if it really is from a language standpoint). C could probably copy C++'s constexpr & static_assert stuff to get the first 2.

Nobody uses C++ modules because they are clumsy to use. D's are easy. Note: anyone is free to copy D's module design. It's the best one out there.

> I'm not sure why forward reference declarations is needed nowadays

The article gives reasons. Although they aren't necessary, they are deleterious to code layout which becomes a slave to the declaration order rather than aesthetic order.

> C++'s constexpr

is still lagging behind D's, after 17 years of development. In D, the garbage collector makes memory allocation in it trivial. Furthermore, only the path taken through a function needs to be CTFE-compatible, the path not taken does not.

Re: Obvious things C should do

#22

Post by WalterBright »

xigoi wrote: post #20
chacham15 wrote: post #16

While the author has WAY more knowledge/experience than me on this and so I wonder how he would solve the following issues: Evaluating Constant Expressions - This seems really complicated...if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. Compile Time Unit Tests - This is alrea…

I personally don’t like forward referencing because it makes code harder to read. You can no longer rely on the dependency graph being in topological order.

As the article writes, that forces the private leaf functions to be at the top, with the public interface at the end of the file. The normal way is the public interface at the top, and the implementation "below the fold", so to speak.

> topological order

You are correct. But its the reverse topological order, which is not the most readable ordering. One doesn't read a newspaper article starting at the bottom.

Re: Obvious things C should do

#23

Post by xigoi »

WalterBright wrote: post #22
xigoi wrote: post #20

Earlier quoted context omitted.

I personally don’t like forward referencing because it makes code harder to read. You can no longer rely on the dependency graph being in topological order.

As the article writes, that forces the private leaf functions to be at the top, with the public interface at the end of the file. The normal way is the public interface at the top, and the implementation "below the fold", so to speak. > topological order You are correct. But its the reverse topological order, which is not the most readable ordering. One doesn't read a newspaper article starting at the bottom.

Maybe it’s because I’m primarily a mathematician, but I like building complex stuff up from primitives and having the most important results at the end.

Re: Obvious things C should do

#24

Post by daymanstep »

WalterBright wrote: post #19
chacham15 wrote: post #16

While the author has WAY more knowledge/experience than me on this and so I wonder how he would solve the following issues: Evaluating Constant Expressions - This seems really complicated...if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. Compile Time Unit Tests - This is alrea…

> if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. You are correct in that the source code to the function being evaluated must be available to the compiler. This can be done with #include. I do it in D with importing the modules with the needed code. > This is already somewhat…

Can't you use precompiled headers?

Re: Obvious things C should do

#25

Post by WalterBright »

xigoi wrote: post #23
WalterBright wrote: post #22

Earlier quoted context omitted.

As the article writes, that forces the private leaf functions to be at the top, with the public interface at the end of the file. The normal way is the public interface at the top, and the implementation "below the fold", so to speak. > topological order You are correct. But its the reverse topological order, which is not the most readable ordering. One doesn't read a newspaper article starting at the bottom.

Maybe it’s because I’m primarily a mathematician, but I like building complex stuff up from primitives and having the most important results at the end.

Vive la différence - and you'll still be able to do it your way!

Re: Obvious things C should do

#26

Post by ryukoposting »

Yeah... no.

Constexpr function evaluation sounds like a great idea until you start trying to use it, and get surprised when seemingly-constexpr-safe functions aren't constexpr. Or, you tweak one function and suddenly all your fancy compile-time unit tests explode.

Ok, so you get around that with good code hygiene and by limiting the complexity of your constexpr functions... in other words, do the exact things we already do with preprocessor macros.

Alternatively, you add a constexpr keyword to the lang, but now we have red functions and blue functions. Great.

In another language, there'd still be an argument for the type-safety that would precipitate from constexpr function eval, but this is C we're talking about.

How about container_of? Could we please standardize that already? Why is this crucial and immensely useful macro a thing we all copy-paste from that one page on kernel.org?

Re: Obvious things C should do

#27

Post by WalterBright »

daymanstep wrote: post #24
WalterBright wrote: post #19

Earlier quoted context omitted.

> if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. You are correct in that the source code to the function being evaluated must be available to the compiler. This can be done with #include. I do it in D with importing the modules with the needed code. > This is already somewhat…

Can't you use precompiled headers?

Interesting you brought that up. I implemented them for Symantec C and C++ back in the 90s.

I never want to do that again!

They are brittle and a maintenance nightmare. They did speed up compilations, though, but did not provide any semantic advantage.

With D I focused on fast compilation so much that precompiled headers didn't offer enough speedup to make them worth the agony.

Re: Obvious things C should do

#28

Post by wging »

WalterBright wrote: post #11
dang wrote: post #66

[stub for offtopicness]

I didn't know X put articles behind a paywall? I haven't tried putting articles there before. Anyhow, here's the same article: https://www.digitalmars.com/articles/Cobvious.html Fun fact: X's article formatter recognizes D code!

I'm not sure what you are seeing, but perhaps it's just a login wall. I was able to read it; I'm logged in but have never paid for Twitter or X. X does tend to hide certain things (such as replies and replied-to tweets) if you're not logged in.

Re: Obvious things C should do

#29

Post by throwawaymaths »

WalterBright wrote: post #7
_lvbh wrote: post #4

It really reads like the author just wants Zig.

Zig copies features from D!

more importantly, though, zig deliberately doesnt implement a whole TON of things that D does.

sometimes parsimony is called for. zig is basically c--+ where the + is the constexpr stuff.

Re: Obvious things C should do

#30

Post by WalterBright »

throwawaymaths wrote: post #29
WalterBright wrote: post #7

Earlier quoted context omitted.

Zig copies features from D!

more importantly, though, zig deliberately doesnt implement a whole TON of things that D does. sometimes parsimony is called for. zig is basically c--+ where the + is the constexpr stuff.

It keeps adding D features anyway, like constexpr.
Post reply on HN