Obvious things C should do

Post by Mankaninen » Sun, Jan 12, 2025, 6:39 AM UTC

saidinesh5 wrote: post #103

TheNewAndy wrote: post #92

Earlier quoted context omitted.

That is less about header files, and more about how machine code works. If you want to have some abstract type where you don't let people know anything about the innards, but you do have an explicit interface which enumerates what you can do with it, then yes - you can only really pass around pointers to these things and people outside your abstraction can only pass references not values. If you want people to be abl…

I think that's a problem with C's header files. With C++ you have the third option where the compiler makes sure that the "people will do the right thing" with the private keyword - assuming they're not doing some weird pointer math to access the private members.. Of course, you'll have to deal with ABI stability now but it's all tradeoffs for what your requirements are.

Post by gary_0 » Sun, Jan 12, 2025, 6:50 AM UTC

salgernon wrote: post #114

kouteiheika wrote: post #99

Earlier quoted context omitted.

> 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). I always found this argument baffling, because the way some other language solve this problem is with tooling, which is a much better way to do it in my opinion. Take Ru…

I’m with parent - what if you don’t have the tool? What if there’s a syntax error in some implementation or dependency such that the tool chokes early? Human readable headers are accessible out of context if the implementation. They also help provide a clear abstraction - this is the contract. This is what I support as of this version. (And hopefully with appropriate annotations across versions)

Post by ndesaulniers » Sun, Jan 12, 2025, 7:09 AM UTC

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?

Post by josephg » Sun, Jan 12, 2025, 7:15 AM UTC

tpoacher wrote: post #135

TheNewAndy wrote: post #130

Earlier quoted context omitted.

That's an interesting assertion, but not one that matches the experience I've had. It is one of those things that sounds "obviously true", but in practice I've found that it doesn't really live up to the promise. As a concrete example of this, having a plain text header file as documentation tends to mean that when people are reading it, if they spot a mistake or see that something isn't documented that should be doc…

I'll second this in Java land. I much prefer reading the sources directly than javadocs. Though jshell also comes in handy.

Post by josephg » Sun, Jan 12, 2025, 7:27 AM UTC

TheNewAndy wrote: post #130

metadat wrote: post #124

Earlier quoted context omitted.

> well written text file The problem with this is no one agrees on the definition of "well-written", so consistency is a constant battle and struggle. Language tooling is a better answer for quality of life.

That's an interesting assertion, but not one that matches the experience I've had. It is one of those things that sounds "obviously true", but in practice I've found that it doesn't really live up to the promise. As a concrete example of this, having a plain text header file as documentation tends to mean that when people are reading it, if they spot a mistake or see that something isn't documented that should be doc…