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

231–240 of 310 posts

Re: Obvious things C should do

#231

Post by thayne »

TheNewAndy wrote: post #113
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…

This is probably something where it comes down to preference and familiarity. I would much prefer a simple text file for documentation that I can grep, open in my text editor, modify easily without switching context (oh, I should have been more explicit in the documentation I wrote - let me just fix that now), etc. All the features you mentioned "nice interface, fully searchable API interface, whole public API" are e…

> and that the reformatting done by these tools tends to lead towards worse documentation with the people I have worked with ("Oh, I need to make sure every function argument has documentation, so I will just reword the name of the argument")

That seems like an orthogonal issue to me. I've seen places where documentation is only in the source code, no generated web pages, but there is a policy or even just soft expectation to document every parameter, even if it doesn't dd anything. And I've also seen places that make heavy use of these tools that doesn't have any such expectation.

Re: Obvious things C should do

#232

Post by saghm »

Brian_K_White wrote: post #170
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…

headers perform the same job for all code, not just code that's in some library. Frankly your description of what you just called easy sounds terrible and pointlessly extra, indirection that doesn't pay for itself in the form of some overwhelming huge win somewhere else. It's easy only if the alternative was getting it by fax or something.

Having to make an entire separate file to mark something as public rather than just having a keyword in the language sounds to me "terrible and pointlessly extra". It's not like you can't just put all your public stuff in it's own file in Rust rather than putting private stuff in it as well; empirically though, people don't do this because it's just not worth the effort.

Re: Obvious things C should do

#233

Post by kode-tar-gz »

juped wrote: post #228
jrmg wrote: post #211

Earlier quoted context omitted.

I think there may be a difference in thinking that underlies the difference in opinion here. In my experience, having a header file nudges you to think about interface being a _different thing_ to implementation - something that (because you need to) you think about as more fundamentally separate from the implementation. Folks who think this way bristle at the idea that interface be generated using tooling. The inter…

I would generate implementations from interfaces were it possible, but I never want to generate interfaces from implementations.

Why not?

Re: Obvious things C should do

#234

Post by oplaadpunt »

James_K wrote: post #180

I feel that much of the point of C is that it's easy to implement. Substantially increasing its scope doesn't seem like the best idea. Perhaps they could do something akin to Scheme and have a "small" and "large" version of the specification.

They have that, to some degree. The standard library is mostly optional. Also, a lot of things are 'implementation defined', so you could just not implement those. That leaves quite a small language core.

Re: Obvious things C should do

#235

Post by nine_k »

kouteiheika wrote: post #99
TheNewAndy wrote: post #72

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). 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…

The include file mechanism is a hack that was acceptable at the time when machines were extremely underpowered, so only the simplest solutions had a chance to be implemented within a reasonable time frame.

By now, of course, precompiled headers exist, but their interplay with #define allows for fun inconsistencies.

And, of course, they leak implementation as much as the author wants, all the way to .h-only single-file libraries.

If you want an example of a sane approach to separate interface and implementation files from last century, take a look e.g. at Modula-2 with its .int and .mod files.

Re: Obvious things C should do

#236

Post by KerrAvon »

bluGill wrote: post #199
WalterBright wrote: post #44

Earlier quoted context omitted.

The ideas for advancing D come thick and fast. C and C++ will never merge with D, because we have different philosophies of what makes for a great programming language. For example, D will never have a preprocessor. Or over my dead body :-/

C++ is trying to eliminate the use of preprocessor. they can't get rid of it but you shouldn't use it.

Stroustrup has been saying that in print since 1993, and it hasn’t happened yet.

Re: Obvious things C should do

#237

Post by bmacho »

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.

I think you mean it in the context of proofs, right? Proofs are indeed often best written in a topological order: a series of true statements, where every reference refer backwards.

You don't often see

    Answer = A + B, 
    where 
    
    A = ...
    ...
    B = ...
albeit you sometimes see it, and it is totally valid. For proofreading something, it makes a big difference: if things are in a topological order, you can simulate a constant memory finite machine. If they are not in a topological order, well, probably you better just rewrite it (or at least I do).

For most other things, I usually prefer the bird-view first, when I am doing or reading some elses math.

Funnily the language Haskell which operates on definitions, is very order independent, it even allows circular definitions. I like it for leetcode and such.

Re: Obvious things C should do

#238

Post by nine_k »

uecker wrote: post #166

I think the real question is why not everybody has already moved to D, if it is so much better and can do all the great things. The answer is that all these things have trade-offs, including implementation effort, changes in tooling, required training, backwards compatibility, etc. some of the features are also not universally seen as better (e.g. IMHO a language which requires forward declaration is better, I also l…

You mean, of course, Zig and Rust, right?

Because D has a sizable runtime library and GC, which can be opted out of, but with very significant limitations, AFAICT.

Re: Obvious things C should do

#239

Post by nine_k »

saghm wrote: post #232
Brian_K_White wrote: post #170

Earlier quoted context omitted.

headers perform the same job for all code, not just code that's in some library. Frankly your description of what you just called easy sounds terrible and pointlessly extra, indirection that doesn't pay for itself in the form of some overwhelming huge win somewhere else. It's easy only if the alternative was getting it by fax or something.

Having to make an entire separate file to mark something as public rather than just having a keyword in the language sounds to me "terrible and pointlessly extra". It's not like you can't just put all your public stuff in it's own file in Rust rather than putting private stuff in it as well; empirically though, people don't do this because it's just not worth the effort.

Think about closed-source software that has to export a low-level programmatic interface. You may not believe it, but it's still widespread.

Re: Obvious things C should do

#240

Post by Lucasoato »

TheNewAndy wrote: post #72

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…

If you want something similar in Python, you could structure your code following the port and adapter pattern. Very effective, especially if paired with hexagonal architecture and type checking libraries like pydantic.
Post reply on HN