Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Finally Gets A New Standard

drdobbs.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: C Finally Gets A New Standard

#61

Post by angersock »

lsiebert wrote: post #57
angersock wrote: post #46

Earlier quoted context omitted.

Our library is mainly focused on cross-platform (Windows, Linux, OSX, Solaris, etc.) and developer ergonomics (Good documentation, orthognal and clean features, descriptive names, etc.). But yes, I do agree with your first paragrpah. And we're always open to friendly emails--see profile for contact info.

Good documentation? I'm interested.

The stuff on our site (see profile) is pretty well documented in the .h files... our next release (hopefully in a week or two) will offer something like MSDN-style overview pages along with detailed function docs.

Really wish there was something like rdoc for C code--and no, Doxygen is fugly and fail.

Re: C Finally Gets A New Standard

#62

Post by Someone »

Retric wrote: post #25
adrianN wrote: post #23

Earlier quoted context omitted.

I believe that has not been true for a long time, at the very least because some things are keywords in C++ that would be valid identifiers in C.

Yea, after looking into it they don't seem to be completely compatible anymore. I have known many people to use a C++ compiler when writing C code, but it looks like that restricts you to a subset of C. They do try and stay reasonably consistent so for example Long Long moved from C to C++. And C99 has reduced some other incompatibilities by incorporating C++ features such as // comments and mixed declarations and co…

"I have known many people to use a C++ compiler when writing C code, but it looks like that restricts you to a subset of C."

Many C++ compilers actually are C/C++ compilers that decide what language to compile depending on command line flags and/or file name extension.

Re: C Finally Gets A New Standard

#63

Post by mkramlich »

tjoff wrote: post #44
ArtB wrote: post #36

Earlier quoted context omitted.

Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?

Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care. Designing for people that don't kn…

mutex: obviously refers to mutex

mtx: maybe mutex? maybe multi-transaction? maybe library prefix? vendor prefix? maybe, maybe...

2 characters

Re: C Finally Gets A New Standard

#64

Post by Retric »

Someone wrote: post #62
Retric wrote: post #25

Earlier quoted context omitted.

Yea, after looking into it they don't seem to be completely compatible anymore. I have known many people to use a C++ compiler when writing C code, but it looks like that restricts you to a subset of C. They do try and stay reasonably consistent so for example Long Long moved from C to C++. And C99 has reduced some other incompatibilities by incorporating C++ features such as // comments and mixed declarations and co…

"I have known many people to use a C++ compiler when writing C code, but it looks like that restricts you to a subset of C." Many C++ compilers actually are C/C++ compilers that decide what language to compile depending on command line flags and/or file name extension.

Ahh, ok now that explains a lot, thanks.

Re: C Finally Gets A New Standard

#67

Post by gruseom »

scott_s wrote: post #43
warmwaffles wrote: post #28

Earlier quoted context omitted.

Back when C was first pioneer'd this was an issue. However this is the 21st century and yes we could have better full names but the standard from before is kept for consistency. I think deprecation and renaming of everything is out of the question at this point as companies and developers have invested considerable amounts of time in building applications using the good ole "fprintf" or "malloc". I wonder what the ra…

You mean back when C was first creat'd .

I recently found myself reading Mason & Dixon and trying to figure out what the rule is for those apostrophes. Pynchon wrote that book in a hybrid of 18th and 20th century English (which is brilliant and possibly also annoying) and boy does he apostrophize. At first it seemed like all the past forms were apostrophiz'd but then I noticed many of them were elongated after all. It appears that the rule is to spell out the "e" in "ed" when it's articulated and use an apostrophe when it's unpronounc'd. I suppose this ought to have been obvious from first principles but I only hit on it by painstaking induction :)

Re: C Finally Gets A New Standard

#68

Post by gruseom »

ArtB wrote: post #45
tjoff wrote: post #44

Earlier quoted context omitted.

Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care. Designing for people that don't kn…

Yes, it definitely matters I think. It's just an extra little bit of work to understand, which when you are debugging you needs as little mental clutter as possible. Why make something more work than it needs to be? Code is read more often then it is written therefore one ought to optimise for reading. Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can neve…

The flaw in your argument is that what's "readable" changes dramatically over time. Once a programmer has used it enough times, "mtx" will be every bit as readable as "mutex". The brain readily tokenizes what it's seen before. Thus the case for plain-English-readability in code is limited to programmers who are not yet familiar with a notation – not a strong general case. We ought to have learned this from COBOL and every other attempt to make programming languages be like natural language.

Code is read more often than it is written, therefore one ought to optimise for reading

But by the same logic, code is read more often by people who know the language and most often by people who have been working on the program for a while, so they are the ones we should optimize for. The readability test that matters for maintaining a complex system over time is hardly "can someone unfamiliar with both the language and the program dive in to any random function and make out what it's doing". So why is that the standard always held up in discussion?

Re: C Finally Gets A New Standard

#69

Post by scott_s »

gruseom wrote: post #67
scott_s wrote: post #43

Earlier quoted context omitted.

You mean back when C was first creat'd .

I recently found myself reading Mason & Dixon and trying to figure out what the rule is for those apostrophes. Pynchon wrote that book in a hybrid of 18th and 20th century English (which is brilliant and possibly also annoying) and boy does he apostrophize. At first it seemed like all the past forms were apostrophiz'd but then I noticed many of them were elongated after all. It appears that the rule is to spell out t…

To be fair, it should be "created." I was making a joke based on the fact that the original function name to create a file in C was in fact called "creat". If I added the (pronounced) "e", then the joke would be lost!

Re: C Finally Gets A New Standard

#70

Post by gruseom »

scott_s wrote: post #69
gruseom wrote: post #67

Earlier quoted context omitted.

I recently found myself reading Mason & Dixon and trying to figure out what the rule is for those apostrophes. Pynchon wrote that book in a hybrid of 18th and 20th century English (which is brilliant and possibly also annoying) and boy does he apostrophize. At first it seemed like all the past forms were apostrophiz'd but then I noticed many of them were elongated after all. It appears that the rule is to spell out t…

To be fair, it should be "created." I was making a joke based on the fact that the original function name to create a file in C was in fact called "creat". If I added the (pronounced) "e", then the joke would be lost!

Ah, I missed that. Creatted? :)
Post reply on HN