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

191–200 of 310 posts

Re: Obvious things C should do

#191

Post by kouteiheika »

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.

> "you always have the exe" is just not even remotely a valid argument.

Why? Can you explain it to me?

I'm a Rust developer. I use my work station every day for 8 hours to write code. I also use `cargo doc` (the tool for which "I always have the exe") every day to look up API docs, and in total this saves me a ton of time every month (probably multiple hours at least, if I'm working with unfamiliar libraries), and I save even more time because I don't have to maintain separate header files (because Rust doesn't have them).

Can you explain the superior flexibility and utility of "merely opening a text file" over this approach, and how that would make me (and my colleagues at work) more productive and save me time?

I'm not being sarcastic here; genuinely, please convince me that I'm wrong. I've been a C developer for over 20 years and I did it the "opening a text file" way and never want to go back, but maybe you're seeing something here that I never saw myself, in which case please enlighten me.

Re: Obvious things C should do

#192

Post by brabel »

WalterBright wrote: post #100
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_…

Your function looks like it's doing I/O, which won't work at compile time test. Here's an example of a unittest for the ImportC compiler: struct S22079 { int a, b, c; }; _Static_assert(sizeof(struct S22079){1,2,3} == sizeof(int)*3, "ok"); _Static_assert(sizeof(struct S22079){1,2,3}.a == sizeof(int), "ok"); The semantics are checked at compile time, so no need to link & run. With the large volume of tests, this speeds…

Hey Walter, importC is great but on Mac it doesn't work right now because Apple seems to have added the type Float16 to math.h (probably due to this: https://developer.apple.com/documentation/swift/float16) and DMD breaks on that.

Could you have a look at fixing that?

Re: Obvious things C should do

#193

Post by devvvvvvv »

nindalf wrote: post #184
Brian_K_White wrote: post #172

Earlier quoted context omitted.

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…

[flagged]

Re: Obvious things C should do

#194

Post by devvvvvvv »

nindalf wrote: post #150
jmb99 wrote: post #140

Earlier quoted context omitted.

> The "what if you don't have the tool" situation never happens in case of Rust. So it’s built into GitLab and GitHub? BitBucket? How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)? How easy is it to use from a command line environment with vim or emacs bindings? I could go on. “Never” is doing a lot of heavy lifting in your assertion. I shouldn’t have to install a toolcha…

> I could go on Please do. It just sounds like you’re nitpicking. If you can open a browser, open docs.rs. The GitHub repo usually contains a link to docs.rs because that’s how people prefer to read the documentation. If you prefer working without the internet that’s fine too. Use cargo doc, which opens the rendered doc page in a local web browser. If you prefer being in a text editor exclusively, no problem! Grep fo…

[flagged]

Re: Obvious things C should do

#195

Post by bluGill »

sim7c00 wrote: post #153
josephg wrote: post #147

Earlier quoted context omitted.

I have the same experience a lot of the time with 3rd party rust crates. Doc.rs is amazing - but it’s rare that I’ll use a library without, at some point, hitting view source.

for most rust ive done (not tons) the docs were very basic as onky auto generated with minimal content. totally useless, have to read sources to find out what is in there. auto documentation to me ia just ti satisfy people who need to tick all of these boxes and want to do with minimal effort. has dox has tests etc. such artitude never leads to quality.

Useful documentation is impossible for the developer to write - they are too close to the code and so don't understand what the users (either api users or end users) need to know. Developers agonize over details that users don't care about while ignoring as obvious important things users don't know.

Re: Obvious things C should do

#196

Post by bluGill »

xigoi wrote: post #174
panic wrote: post #112

Earlier quoted context omitted.

As someone who likes C header files, I enjoy manually maintaining them. Designing the interface separately from the implementation feels good to me, and a well-structured .h file is nicer to read than any auto-generated docs I've encountered.

The problem is that you have to write the interface not only separately grom the implementation, but together with the implementation as well, which leads to duplication of information;

So? Yes you need some duplicatin but it forces you to put information useful to api users where they won't have to wade through pages of information not of interest to them. eventually they may need to read the source but a lot of common questions are answered by the header and so the small cost to make them is worth it.

of course javadoc can answer the same questions but then you have to run it.

Re: Obvious things C should do

#197

Post by uecker »

Lvl999Noob wrote: post #97
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 disagree with you on this. In another language with explicit public / private separation, the compiler can have access to the internal layout of a type (and thus optimise on it) without letting the developer mess around with it directly. I am assuming static compilation of course. Across a dynamic boundary, I would expect this compiler to behave like a normal C compiler and not use that layout. In a header file, th…

A compiler can still have access to the internal layout in C via link-time optimization.

Re: Obvious things C should do

#198

Post by bluGill »

chikere232 wrote: post #176

If you want to write D, write D. C is fine without these things

I want to write d, but I have a ton of c - d makes it easy. rust is harder as I have to write ffi. d makes working with something else easy shich it an advantage. Too bad it never took off.

Re: Obvious things C should do

#199

Post by bluGill »

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

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

Re: Obvious things C should do

#200

Post by hooli_gan »

devvvvvvv wrote: post #194
nindalf wrote: post #150

Earlier quoted context omitted.

> I could go on Please do. It just sounds like you’re nitpicking. If you can open a browser, open docs.rs. The GitHub repo usually contains a link to docs.rs because that’s how people prefer to read the documentation. If you prefer working without the internet that’s fine too. Use cargo doc, which opens the rendered doc page in a local web browser. If you prefer being in a text editor exclusively, no problem! Grep fo…

[flagged]

Most normal people don't read documentation of programming libraries.
Post reply on HN