Live data from Hacker News

Obvious things C should do

digitalmars.com

281–290 of 310 posts

Re: Obvious things C should do

#281
> Everywhere a C constant-expression appears in the C grammar the compiler should be able to execute functions at compile time, too, as long as the functions do not do things like I/O, access mutable global variables, make system calls, etc.

That one is easily broken. Pick a function that runs for a lloooonngg time...

  int busybeaver(int n) {...}    // pure function returns max lifetime of n state busy beaver machine

  int x = busybeaver(99);

Re: Obvious things C should do

#282
post #186

Earlier quoted context omitted.

I remember int/impl sections since the 1990’s turbo pascal, which wasn’t “object” still, iirc. Also, commercial closed-source units (modules) were often distributed in a .tpu/.dcu + .int form, where .int was basically its source code without the implementation section.

Interesting. Yes, I remember the .tpu and .dcu filename extensions. IIRC, .tpu stood for turbo pascal unit, and .dcu may have meant delphi compiled unit, not sure of the latter. I don't remember the .int extension, but it would have been there, of course, if you say so. What was the use of the .int file?

It was literally the unit with implementation part just missing. Sort of a header that you can just read(?). Idk if it played a role in compilation, probably not. But some commercial libraries packaged them as well. Here, look at this random repo: https://github.com/keskival/turbo-pascal-experiments/tree/ma... -- few int files at the end of a list.

This page mentions a few ints without any context: https://comp.lang.pascal.borland.narkive.com/1B3WeJkX/rebuil...

This guy seems to package ints for documentation purposes: https://www.wrotniak.net/hplx/lxtpgr.html

Man this is nostalgic... T-T

Re: Obvious things C should do

#283
post #277
post #270

Earlier quoted context omitted.

For one of my C projects (ca. 450 c-files), full rebuild time on my (not super fast) laptop is just below 10 seconds (incremental builds < 1s). Compiling and linking all unit tests takes a second, and running all unit tests takes 6-7 seconds. So even running the optimized code for the tests almost doubles the time for rebuilding the full project. Although I like the machine code to be tested that is actually used. (B…

What about putting common template parameters into an external template in a binary libray?

Na, we will just remove this template nonsense.

Re: Obvious things C should do

#284
post #183

Earlier quoted context omitted.

I don't like complaining linters. I do like auto fixing linters I can leave running in the background.

> auto fixing linters any advice on how to implement an auto linter in an old codebase? i hate losing the git blame info.

I use a .git-blame-ignore-revs file. So if you run the fix once, dump that commit in the file and use it when you use git blame, it'll exclude blame in that commit.

https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...

Re: Obvious things C should do

#285

Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it). Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the docume…

>Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it).

You don't need header files for that.

A dead simple to write tool that parses the actual non-duplicating info, files, and prints you the interfaces and access qualifiers for each method as such, presenting you everything or just the public ones etc, should suffice.

Re: Obvious things C should do

#286

Earlier quoted context omitted.

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

> Order-independent top level declarations.

Javascript has had this for functions since 1995. This has been part of zig from the start, not added later.

> Fixed sizes for ints, longs, etc.

this has existed in stdint.h since C99. It doesn't take a genius, only years of pain with C/C++, to realize this is the better way to do things. And also, this was in zig from the start, not added later.

> Underscores embedded in integer literals

Also in zig from the start, not added later. Others have commented on the provenance.

I could be convinced that continue/break to labels was inspired by D.

Re: Obvious things C should do

#287
post #215

I consider forward references an anti-feature. I want any language I use to have the following property: if I append to the source file, I can't break previously correct code above the insertion point. Forward references both break this property _and_ requires multiple compiler passes. More generally though, it's time to stick a fork in c. To me the only sane ways to use c are as a compilation target or for quick and…

What do you mean by "break previously correct code"? Can you give an example of what you're thinking with original code and appended code, where concatenating the two (1) does not change the behavior of the original code when forward references are not allowed, and (2) changes the behavior of the original code when forward references are allowed?

Re: Obvious things C should do

#288
post #284

Earlier quoted context omitted.

> auto fixing linters any advice on how to implement an auto linter in an old codebase? i hate losing the git blame info.

I use a .git-blame-ignore-revs file. So if you run the fix once, dump that commit in the file and use it when you use git blame, it'll exclude blame in that commit. https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...

awesome, ty!

Re: Obvious things C should do

#289
post #118

Earlier quoted context omitted.

> Designing the interface separately from the implementation feels good to me would you make the same argument for java then?

Even as a java programmer, I think this is a bad take. Java doesn't force separation of implementation and interface, and java interfaces also have a lot of weird stuff going on with them. Java also has too many tools for this. You both have class/interface, but also public/private. I honestly think C does it better than Java.

> java interfaces also have a lot of weird stuff going on with them.

really? I know java pretty well, and there aint nothing weird there.

C uses conventions to produce an "interface" (ala a header file with declarations). Java uses compilers to produce an interface, which i do really like. You can ship that interface without an implementation, and only at runtime load an implementation for example.

> You both have class/interface, but also public/private.

And these are all othorgonal concerns. A private interface is for the internal organization of code, as opposed to a public one (for external consumption). That's why you might have a private interface.

Re: Obvious things C should do

#290

I wish C had a jinja2-like preprocessor!

You could use whatever preprocessor you like really, just add a make step that translates your template into c. I've seem some crazy person use M4 for example. It's usually a bad idea, but very feasible

Integrated preprocessor. That was what I meant. Maybe with c-syntax awareness.
Post reply on HN