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

101–110 of 310 posts

Re: Obvious things C should do

#101

Post by kevin_thibedeau »

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 really a weak hack to deal with resource constrained platforms from the 70s. They only work if you stick to a convention and pale in comparison to languages like Ada with well architected specification for interfaces and implementation without ever needing to reparse over and over again.

I do enjoy using C but that is one area where it should have been better designed.

Re: Obvious things C should do

#102

Post by billfruit »

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…

They are also somewhat of hassle and something not necessary to have.

Re: Obvious things C should do

#103

Post by saidinesh5 »

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

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 think that's a problem with C's header files.

With C++ you have the third option where the compiler makes sure that the "people will do the right thing" with the private keyword - assuming they're not doing some weird pointer math to access the private members..

Of course, you'll have to deal with ABI stability now but it's all tradeoffs for what your requirements are.

Re: Obvious things C should do

#104

Post by WalterBright »

UncleEntity wrote: post #89
WalterBright wrote: post #64

Earlier quoted context omitted.

D had compile time execution of functions in 2007. Order-independent top level declarations. Underscores embedded in integer literals. (I stole this idea from Ada, which had been forgotten. Soon after D popularized it, it became standard in other languages.) Continue or break to labeled loop. Fixed sizes for ints, longs, etc. Of course, I don't know if there's a straight line here, and Zig is welcome to use any featu…

>> Continue or break to labeled loop. Hasn't Java had that since the beginning? rummaging around in my grammar folder... BreakStatement ::= "break" [ IDENTIFIER ] ';' ContinueStatement ::= "continue" [ IDENTIFIER ] ';'

And so it does. I had forgotten. Thanks for the reminder!

Re: Obvious things C should do

#105

Post by TheNewAndy »

saidinesh5 wrote: post #103
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 think that's a problem with C's header files. With C++ you have the third option where the compiler makes sure that the "people will do the right thing" with the private keyword - assuming they're not doing some weird pointer math to access the private members.. Of course, you'll have to deal with ABI stability now but it's all tradeoffs for what your requirements are.

Right, but as soon as you have private stuff in your header file, that is leaking implementation details. Yes it is kind of true that these are compile time checked to make sure that people don't do the wrong thing, but it is still an implementation detail that is leaking.

It comes down to a cost benefit thing - is the cost of poorer readability worth it for mitigating the risk of people doing the wrong thing? My experience says no, other people's experience says yes. Probably we are working on different problems and with different teams.

Re: Obvious things C should do

#107

Post by ryukoposting »

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 also make it a lot more obvious how you're supposed to distribute a library as a binary, which is good.

Re: Obvious things C should do

#109

Post by ksec »

WalterBright wrote: post #13
koolba wrote: post #12

Earlier quoted context omitted.

Imitation is the sincerest form of flattery.

Yup. D is the source for a number of recent features in other languages. The reason I embarked on D is because C and C++ were too reluctant to move forward.

>The reason I embarked on D is because C and C++ were too reluctant to move forward.

I just want to take this opportunity to say thank you. While D may not taken up from the rest of the world. It has surely lived on in C, C++ and many other languages. Still wish more people would use Das C.

Re: Obvious things C should do

#110

Post by omoikane »

kstenerud wrote: post #94

Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away from the developer and inevitably cause you to jump through bureaucratic hoops just to get your work done. These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds (which a…

Maybe these compile time tests are more like `static_assert`, which is valuable for catching incompatible uses of library functions. Pretty good idea in my opinion.
Post reply on HN