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

241–250 of 310 posts

Re: Obvious things C should do

#241

Post by johannes1234321 »

uecker wrote: post #163
Lvl999Noob wrote: post #81

Earlier quoted context omitted.

I don't really program in C much so please correct me if I am wrong. There is a flaw in header files in that they work the exact same for dynamic vs static linking, right? If I am making a library in C for static linking, I need to put my internal details in the header file if I want the user's compiler to be able to use those details. But putting them in the header files also means they are part of the public interf…

In C programs only the external definition of an interface goes into the header of a library but not implementation details (there could be headers intentionally exposing details for internal use, of course). The problem is real for C++. Optimizers can look across translation units nowadays (link-time optimization), so there is no reason to expose internal details in a header for this. For dynamic libraries this does…

Even for C it's normal ways true: When size of structures have to be known to the user (if they are supposed to keep them on stack or mallox themselves or whatever) the "private" structure often ends up in a "private" header. (There are ways to still hide it, but they cause work to keep things proper)

And then there are cases where (often die to performance) you want inlining of some operations without relying on Link time optimisation, then implementation has to go to headers, too.

Re: Obvious things C should do

#242

Post by the-grump »

norir wrote: 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…

C will always live.

I’m not onboard with significant changes to C but the language will always be around at the interface between hardware and software and probably as the lingua franca for FFI.

Re: Obvious things C should do

#243

Post by kstenerud »

marcosdumay wrote: post #227
kstenerud wrote: post #132

Earlier quoted context omitted.

> it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care. And this is precisely why I disagree with forcing it upon the developer at every stage of development. Generally, while in the thick of things, I just want to get things working with one part, not worry about what other parts this breaks (yet). But the pedantic "you have to fix this first" enforcement bre…

> I don't want to even be bothered with yet Why did you get out of your way to write tests about something that you don't want to be bothered about?

Because the test already exists as part of the solution that's worked up until now, and I don't want to modify it or any other related tests until I've finished my work to the point that I think the interface is stable enough for the tests to be updated.

Re: Obvious things C should do

#244

Post by kstenerud »

fishstock25 wrote: post #214
kstenerud wrote: post #132

Earlier quoted context omitted.

> it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care. And this is precisely why I disagree with forcing it upon the developer at every stage of development. Generally, while in the thick of things, I just want to get things working with one part, not worry about what other parts this breaks (yet). But the pedantic "you have to fix this first" enforcement bre…

> because now I have to split my attention to things I don't want to even be bothered with yet. One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them. Is that the same as saying I don't want to have to write types either? Maybe. Types are like lightweight incomplete specs.

> One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them.

Or perhaps the parts existed, were useful, did have tests, and now a new feature requires refactoring that temporarily breaks things before I finally bring the house in order again. But I don't want to throw out the tests because parts of them may still be useful.

My point is, if the code is capable of being compiled and run, who is anyone to dictate that I shouldn't be allowed to run it (even broken) during my development cycle, just for some bureaucratic "I know better than you" reason?

This is the problem I see all over - people peer out from their limited perspective, assume that they see enough, and then make excessively restrictive policy decisions about what we can and cannot do. It's hubristic and so very, very annoying to the rest of us, especially since they also have a tendency to double-down, and there seems to be no way of getting through to them.

Re: Obvious things C should do

#245

Post by throwawaymaths »

WhereIsTheTruth wrote: post #133
throwawaymaths wrote: post #29

Earlier quoted context omitted.

more importantly, though, zig deliberately doesnt implement a whole TON of things that D does. sometimes parsimony is called for. zig is basically c--+ where the + is the constexpr stuff.

Parsimony? more like thankful for learning from other language experiments and research work Zig is young, and far from 1.0, and many long promised features still not implemented

> many long promised features still not implemented

name one that isn't async / sane recursion (which is also async)

Re: Obvious things C should do

#246

Post by layer8 »

chii wrote: post #118
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.

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

It’s important to not conflate Java’s interface keyword with the more general notion of “interface” as in “API”. In Java, you generally don’t and can’t have a source-level representation of the API without it being interspersed with its implementation.

(You could imagine such a representation, i.e. remove all method bodies and (package-)private elements, but the result wouldn’t be valid Java. IDEs arguably could and should provide such a source-level view, e.g. via code folding, but I don’t know any that do.)

Re: Obvious things C should do

#247

Post by samiv »

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

I really agree, I think that making the tests as easy as possible to get going goes a long way towards a code base that actually has tests.

I have something very similar.

https://github.com/ensisoft/detonator/blob/master/base/test_...

Borrowed heavily from boost.test.minimal and used to be a single header but but over the years I've had to add a single translation unit!

My takeaway is that if you keep your code base in a condition where tests are always passing you need much less complications in your testing tools and their error reporting and fault tolerance etc. !

Re: Obvious things C should do

#248

Post by Yoric »

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…

Have you looked at how OCaml does it?

The historical way is to have a .ml and a .mli files. The .ml file contains the implementation. Any documentation in that file is considered implementation detail, will not be published by ocamldoc. The .mli file contains everything users need to know, including documentation, function signatures, etc.

Interestingly, the .mli and the .ml signatures do not necessarily need to agree. For instance, a global variable in the .ml does not need to be published in the .mli. More interestingly, a generic function in the .ml does not need to be exposed as generic in the .mli, or can have more restrictions.

You could easily emulate this in Rust, but it's not the standard.

Re: Obvious things C should do

#249

Post by SkiFire13 »

hawski wrote: post #177
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…

Depending on coding style you could just do something like this: ^struct whatever

The issue is that the coding style depends on whoever wrote the external library, not on you, so this ends up working only sometimes. You can probably find some other combination that will help you find what you're looking for (I do this all the time when using Github's web interface) but ultimately this is just a bad experience.

Re: Obvious things C should do

#250

Post by WalterBright »

brabel wrote: post #192
WalterBright wrote: post #100

Earlier quoted context omitted.

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?

Aargh. Those sorts of extensions should not be in the system .h file.
Post reply on HN