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

181–190 of 310 posts

Re: Obvious things C should do

#181

Post by agumonkey »

WalterBright wrote: post #44
agumonkey wrote: post #38

Earlier quoted context omitted.

Do you think you will keep moving forward for the next decade or will you merge when c/cpp becomes similar enough to D ? Maybe your group still has tons of ideas that need their own space to grow.

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 :-/

Thanks a lot for your answer, I have another one, what languages or topics do you follow for inspiration regarding concepts ?

Re: Obvious things C should do

#182

Post by davisoneee »

TheNewAndy wrote: post #171
kouteiheika wrote: post #138

Earlier quoted context omitted.

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Thanks for the constructive example of the rust doc. I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided. As a preference thing, I don't really like examples in APIs (it is suppose…

The parent linked to a subsection showing usage for a particular object. If you click back into the root level for the document there is a header specifying ‘syntax’, and other more ‘package-level’ documentation

Re: Obvious things C should do

#183

Post by XorNot »

josephg wrote: post #149
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 know people look at me like I’m a heathen and a scoundrel, but I think a lot of software teams spend too much time trying to make things consistent. Where’s the ROI? There is none. GitHub readmes? Bring on the weird quirks, art, rants about other software, and so on. I’ll take it all. Don’t get me started on linters. Yes, there’s lots of things that should actually be consistent in a codebase (like indentation). Bu…

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

Re: Obvious things C should do

#184

Post by nindalf »

Brian_K_White wrote: post #172
kouteiheika wrote: post #157

Earlier quoted context omitted.

> So it’s built into GitLab and GitHub? BitBucket? No. It's built into the toolchain which every Rust developer has installed. > How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)? A easy as on Linux or macOS from my experience. > How easy is it to use from a command line environment with vim or emacs bindings? Not sure I understand the question; use how exactly? You eithe…

I don't understand how you don't understand the order of magnitude difference in flexibility, utility, availability, etc between needing to run a specific executable vs merely opening a text file in any way. "you always have the exe" is just not even remotely a valid argument.

I don’t understand how you don’t understand that that’s always an option. Rust source files are written in plaintext too.

There are a few people in this thread, including you, who claim that they vastly prefer the output of documentation to be plain text in a single file rather than linked HTML files OR reading the source in multiple plaintext files.

That’s a preference, so y’all can’t be wrong. But consider that if this preference was even slightly popular, cargo doc would probably get a —-text option that output everything in a single text file. The fact that it doesn’t have it tells me that this preference is very niche.

Re: Obvious things C should do

#185

Post by wruza »

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…

I used to think like this, but then I discovered generating (prj_root)/types.d.ts. It doesn’t do anything technical because types are in src/**/*, but I do that to generate a quick overview for a project I’m returning to after a month.

Maintaining header files is tedious and I often resorted to a kind of “OBHF.h” for common types, if you know what I mean. Otherwise it’s too much cross-tangling and forwards. Even in ts I do type-only src/types.ts for types likely common to everything, mostly because I don’t want pages of picky this-from-there this-from-there imports in every module.

As for public/private and sharing “friends” across implementation modules, we didn’t invent anything good anyway. I just name my public private symbols impl_foo and that tells me and everyone what it is.

That said, I wouldn’t want to make html out of it like these *-doc tools do. Using another program to navigate what is basically code feels like their editor sucks. My position on in-code documentation is that it should be navigatable the same way you write it. External tools and build steps kill “immersion”.

Re: Obvious things C should do

#186

Post by wruza »

fuzztester wrote: post #131
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…

Object Pascal (not the original Pascal) versions like Delphi and Free Pascal have syntax and semantics for interface and implementation sections of the module. Wouldn't be surprised if Modula-2 and Ada had that too.

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.

Re: Obvious things C should do

#187

Post by wruza »

TheNewAndy wrote: post #93
bjourne wrote: post #79

I write unit tests for my C code all that time. It's not difficult if you use a good build system and if you are willing to stomach some boilerplate. Here is one test from my "test suite" for my npy library: void test_load_uint8() { npy_arr *arr = npy_load("tests/npy/uint8.npy"); assert(arr->n_dims == 1); assert(arr->dims[0] == 100); assert(arr->type == 'u'); npy_free(arr); } int main(int argc, char *argv[]) { PRINT_…

You will be pleased to know that you are not the only one who does this. I previously went down the rabbit hole of fancy unit test frameworks, and after a while I realised that they didn't really win much and settled on something almost identical to what you have (my PRINT_RUN macro has a different name, and requires the () to be passed in - and I only ever write it if the time to run all the tests is more than a sec…

This test/src separation always felt like html/css to me. When still using C, I wrote tests right after a function as a static function with “test_” in the name. And one big run-all-tests function at the end. All you have to do then is to include a c file and call this function. Why would I ever want to separate a test from its subject is a puzzling thought. Would be nice to have “testing {}” sections in other languages too, but in C you can get away with DCE, worst case #ifdef TESTING.

Re: Obvious things C should do

#188

Post by steinuil »

> The leaf functions come first, and the global interface functions are last.

To me that is backwards. I prefer code written in a topological order for a number of reasons:

- It mirrors how you write code within a function.

- It's obvious where you should put that function in the module.

- Most importantly, it makes circular dependencies between pieces of code in a module really obvious.

I'm generally not a fan of circular dependencies, because they make codebases much more entangled and prevent you from being able to understand a module as a contained unit. In Python they can even lead to problems you won't see until you run the code[0], but circular imports are probably so common that current type checkers disable that diagnostic by default[1].

I think languages that don't support forward references (C, but also OCaml and SML) let me apply the "principle of least surprise" to circular dependencies. OCaml even disallows recursive dependencies between functions unless you declare the functions with "let rec fn1 = .. and fn2 = ..", which may be a bit annoying while you're writing the code but it's important information when you're reading it.

[0]: https://gist.github.com/Mark24Code/2073470277437f2241033c200...

[1]: https://microsoft.github.io/pyright/#/configuration?id=type-... (see reportImportCycles)

Re: Obvious things C should do

#189

Post by kouteiheika »

TheNewAndy wrote: post #171
kouteiheika wrote: post #138

Earlier quoted context omitted.

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Thanks for the constructive example of the rust doc. I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided. As a preference thing, I don't really like examples in APIs (it is suppose…

> I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided.

This is a fair question to have. As others have already said, this is the API reference for a particular class, so you won't get the high level details here. You can click in the upper left corner to go to the high level docs for the whole library.

> The distinction between external and internal that you have looks pretty different to me, and that could just be why we have different opinions.

Well, there are two "external" vs "internal" distinctions I make:

1. Code I maintain, vs code that I pull in as an external dependency from somewhere else (to give an example, something like libpng, zlib, etc.). So if I want to fix something in the external dependency I make a pull request to the original project. Here I need to clone the original project, find the appropriate files to edit, edit them, make sure it compiles, make sure the tests pass, make a PR, etc. Having the header file immediately editable doesn't net me anything here because I'm not going to edit the original header files to make the change (which are either installed globally on my system, or maintained by my package manager somewhere deep under my /home/).

2. Code that is part of my current project, vs code that is a library that I reuse from another of my projects. These are both "internal" in a sense that I maintain them, but to my current project those are "external" libraries (I maintain them separately and reuse in multiple projects, but I don't copy-paste them and instead maintain only one copy). In this case it's a fair point that if you're browsing the API reference it's extra work to have to open up the original sources and make the change there, but I disagree that it's making things any harder. I still have to properly run any relevant unit tests of the library I'm modifying, still have to make a proper commit, etc., and going from the API reference to the source code takes at most a few seconds (since the API reference will tell me which exact file it is, so I just have to tell my IDE's fuzzy file opener to open up that file to me.) and is still a tiny fraction of all of the things I'd need to do to make the change.

Re: Obvious things C should do

#190

Post by brabel »

kouteiheika wrote: post #138
TheNewAndy wrote: post #113

Earlier quoted context omitted.

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…

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

I think the person you're responding to must know all of this. This is stuff that's obvious to anyone who has ever written any code that required using libraries. Unfortunately , people like to pretend to have a gripe with something on the internet just for the sake of arguing. This is the only conclusion I can arrive at when people appear to seriously propose reading a header file in a text editor is somehow better than reading documentation in a purposefully designed documentation format. It's like saying browsers are just a waste of time when you can just use Gopher for everything.
Post reply on HN