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

61–70 of 310 posts

Re: Obvious things C should do

#61

Post by throw16180339 »

ryukoposting wrote: post #26

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

If you're using C++ 20, you can mark functions consteval to force constant evaluation.

Re: Obvious things C should do

#62

Post by WalterBright »

chacham15 wrote: post #45
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…

Thanks for taking the time to respond! I have a few followup questions if thats ok: > 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. > D's strategy is to separate the parse from the semantic analysis. I suppose it is a hair slower, but it also doesn't have to recomp…

> I dont have the power to make large decisions on an existing codebase like "lets switch languages"

We struggled with that for a long time with D. And finally found a solution. D can compile Standard C source files and make all the C declarations available to the D code. When I proposed it, there was a lot of skepticism that this could ever work. But when it was implemented and debugged, it's been a huge win for D.

> Performance

With D you can put all your source files on one command line invocation. That means that imports are only read once, no matter how many times it is imported. This works so well D users have generally abandoned the C approach of compiling each file individually and then linking them together. A vast amount of time is lost in C/C++ compilation with simply reading the .h files thousands of times.

Modules/imports are a gigantic productivity booster. They're not hard to implement, either. Except for the way C++ did it.

> re multiple translation units compiled at a time? Wouldnt this mean that the entire translation dependency graph would need to be simultaneously recompiled? Wouldnt this inhibit parallelization? How would it handle recompilation? What happens if a dependency is already compiled? Would it recompile it?

Yes, yes, yes, yes. And yet, it still compiles faster! See what I wrote above about not needing to read the .h files thousands of times. Oh, and building one large object file is faster than building a hundred and having to link them together.

Re: Obvious things C should do

#63

Post by pansa2 »

> the compiler only knows about what lexically precedes it. […] it drives programmers to lay out the declarations backwards. The leaf functions come first, and the global interface functions are last. It’s like reading a newspaper article from the bottom up. It makes no sense.

Defining functions on a “bottom-up” order like this is common even in languages like Python which allow forward references. [0]

Is that just a holdover from languages which don’t allow such references? Or does it actually make more sense for certain types of code?

[0] https://stackoverflow.com/a/73131538

Re: Obvious things C should do

#64

Post by WalterBright »

throwawaymaths wrote: post #31
WalterBright wrote: post #30

Earlier quoted context omitted.

It keeps adding D features anyway, like constexpr.

the constexpr stuff has been around since the beginning[0]. concretely, what other thing from D do you claim zig has added since? [0] minimally 2019, 3 years in: https://youtu.be/Gv2I7qTux7g?si=p0kVhtB56GvVLLNr

D had compile time execution of functions in 2007.

Order-independent top level declarations.

Underscores embedded in integer literals. (I stole this idea from Ada, which had been forgotten. Soon after D popularized it, it became standard in other languages.)

Continue or break to labeled loop.

Fixed sizes for ints, longs, etc.

Of course, I don't know if there's a straight line here, and Zig is welcome to use any features from D that they like. But it's just interesting that things innovated in D pop up in subsequent designs.

Re: Obvious things C should do

#65

Post by dang »

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!

We'd always rather go with the more specific site anyhow so I've changed the URL to that from https://twitter.com/WalterBright/status/1878209651306803406. Thanks!

Re: Obvious things C should do

#67

Post by loeg »

kreco wrote: post #35

> Evaluating Constant Expressions The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard. > Imp…

> The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this.

> Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard.

I mean, it's basically 1:1 with the constexpr feature in C++. Almost every C compiler is already a C++ compiler, supporting constexpr functions and evaluation in C can't be that bad, can it?

Re: Obvious things C should do

#68

Post by almostgotcaught »

pansa2 wrote: post #63

> the compiler only knows about what lexically precedes it. […] it drives programmers to lay out the declarations backwards. The leaf functions come first, and the global interface functions are last. It’s like reading a newspaper article from the bottom up. It makes no sense. Defining functions on a “bottom-up” order like this is common even in languages like Python which allow forward references. [0] Is that just a…

You're confused. There are no forward references in python. It's simply that identifiers in the body of a function aren't resolved until the function itself is executed (if ever) and at the point everything in the module scope has been defined. You can test this yourself by just putting any name into a body and loading the module.

Re: Obvious things C should do

#69

Post by loeg »

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.

C's already got static_assert; just missing constexpr.

Re: Obvious things C should do

#70

Post by EuAndreh »

WalterBright wrote: post #47
EuAndreh wrote: post #41

Good suggestions, but also meh, e.g.: forward declaration requirement enables a single-pass compiler to emit code on-the-fly. I have a much better list for things to add to C: Nothing. C isn't perfect, or nearly as good as it could be, but simply adding things onto C gets you C++. Adjusting what sircmpwn says: in C you don't solve problems by adding features, but by writing more code in C. I liked an answer on stack…

> forward declaration requirement enables a single-pass compiler to emit code on-the-fly. True, I know all about that. My Zortech C and C++ compiler was one pass (after the multiple preprocessing passes). The ground up ImportC C compiler completed a couple years ago has a separate parse pass. So I well know the tradeoffs. The parser being stand-alone means it is much simpler to understand and unittest. I found no adv…

> The parser being stand-alone means it is much simpler to understand and unittest.

Stand-aloneness and single-passness are orthogonal.

> I found no advantage to a single pass compiler. It isn't any faster.

A gigantic advantage: a single-pass-compilable language is simpler. By definition.

Implementations may or may not be simpler or faster.

> C++ doesn't allow forward declarations either.

Well, that's not what I meant.

C++ is "C with just this thing" done way too many times.

> The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out.

TBH, I didn't really get this. Is this about sticking to C as is, but it is outdated as is?

C would be outdated if it didn't have, say, long long for 64-bit numbers. Having "true" be a keyword instead of a macro doesn't change how outdated it is or isn't, just like compile-time evaluation also doesn't.

> They are once you use another language that doesn't have those restrictions.

I have used many, and I still don't find them obvious.

> C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time.

I agree that many/most are a waste of time, and shouldn't be added to C. The fact of C adding things to the standard all the time shouldn't justify adding even more things, but make one question if those are needed at all, and how to accomplish the goal without it.

> Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions.

I know about that, and my position is the same: just don't.

I don't use them also.

Post reply on HN