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

161–170 of 310 posts

Re: Obvious things C should do

#161

Post by uecker »

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…

At least moderately advanced text editors often interoperate with symbols tables, so you can jump to a definition. But even with grep, you can usually do it in a way where you differentiate between definition and use. But I am not arguing that you should not use advanced tools if you like is, the deeper point is that you can always use advanced tools even with headers, but you can not go back in a language designed around advanced tools and work with simple tools. So it is strictly inferior IMHO to design a language around this additional cmplexity.

Re: Obvious things C should do

#162

Post by m463 »

The most obvious thing c should do is... evolve.

Even Fortran seems to have added object-oriented constructs, all kinds of new types and concurrent and parallel programming

Re: Obvious things C should do

#163

Post by uecker »

Lvl999Noob wrote: post #81
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 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 not work of course, but it also shouldn't.

Re: Obvious things C should do

#164

Post by [deleted] »

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…

[deleted]

Re: Obvious things C should do

#166

Post by uecker »

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 like how headers work).

Re: Obvious things C should do

#167

Post by throwuxiytayq »

pansa2 wrote: post #63

> the compiler only knows about what lexically precedes it. […] it drives programmers to lay out the declarations backwards. The leaf functions come first, and the global interface functions are last. It’s like reading a newspaper article from the bottom up. It makes no sense. Defining functions on a “bottom-up” order like this is common even in languages like Python which allow forward references. [0] Is that just a…

In my code, the public interface always tends to bubble upwards, and implementation details go at the end of the file. I don’t even have a strict rule for this, it just reads more cleanly and seems to make sense. Especially if the implementation is large - you don’t want to scroll through all that before you get to the basics of what it all does. I’m curious how everyone else does things.

Re: Obvious things C should do

#168

Post by chikere232 »

lzsiga wrote: post #136
harisund1990 wrote: post #115

Earlier quoted context omitted.

I love headers but I wish you could split them in two so that private functions and variables can line in the c file. This would help reduce a lot of header bloat as well.

It is perfectly valid to use more than one header files: some of them can be public (meant to be seen by users of your library), others can be private or internal (only used by your own sources).

Also, usually it's pretty rare to have things internal to one C file that need explicit prototypes. It's easier to just put things in the right order so the funtion definition etc is before its use.

Re: Obvious things C should do

#169

Post by chikere232 »

WalterBright wrote: post #22
xigoi wrote: post #20

Earlier quoted context omitted.

I personally don’t like forward referencing because it makes code harder to read. You can no longer rely on the dependency graph being in topological order.

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.

People learn the ordering. If that is their biggest hurdle learning C they have a blessed life

Re: Obvious things C should do

#170

Post by Brian_K_White »

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…

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.

Post reply on HN