You should consider a position in Marketing.These modern days with modern C++ it would be something modern like:
std::increment<std::atomic_lock<[](){++}>>(C);
You should consider a position in Marketing.These modern days with modern C++ it would be something modern like:
std::increment<std::atomic_lock<[](){++}>>(C);
Likely the original shell written by Steve Bourne.So the shell this Unix book uses is close to the t/csh shell we use as default or rooted in the same tradition?
Publications that use troffCan you imagine today using troff to write a book?
Clearly Donald Knuth could not, but I would say it depends on the book. I still use it, quite regularly...Can you imagine today using troff to write a book?
gcc has this to say: ‘ISO C99. This standard is substantially completely supported’
either is preferable to that stupid gnu "info" command. Bleck!
Stick to c89 or c99 and you will be fine. I believe K&R style declarations are going away in c23.Can I expect my ancient 'C' books to still work the same?
GPIO drivers are defiantly on the list.The same if he intends to write a hardware driver.
I don't think so. In fact, C is an almost perfect counter-example: You can do OOP in it (and as long as you don't need polymorphism / virtual methods, it can be done in a straight forward very simple way), still it is not object-oriented.The problem with trying to define what class C is makes you put it into a box which leads to restrictions on what it can do.
And sometimes we get to see theflame wars of "my square wheel is cooler than your square wheel" (some people seem to be mentally stuck in the age where they put all in a square hole). If a language is domain specific, by all means make a new one if you have benefits to your cause. But don't try to force everybody into the same square hole.to expand on zirias@ comment, unfortunately too many newer languages and tools are solutions in search of a problem, designed by kids looking to make their mark in the world. They often don't fulfill a need, but are new and kool.
Quite a lot of nice thingsThis is Off-topic in a Off-topic; But
Any ideas on C23?
I personally really like the0b
literals borrowed from the embedded space .
Reading static_assert(3):static_assert like C++
The static_assert() macro conforms to ISO/IEC 9899:2011 (“ISO C11”).
It's the overload without message that is newReading static_assert(3):
Are they reinventing their own standards? (I have also noticed memset_explicit(), reinventing memset_s()?)Code:The static_assert() macro conforms to ISO/IEC 9899:2011 (“ISO C11”).
I always hated the name of this function (not what it does, that's pretty convenient and often needed), because it's really a bad fit among all the otherstrdup finally part of the C standard
string.h
functions named str*
. None of them would ever allocate memory. A missed chance to find a better name for it I think that was partly down to the name length in object files being limited to 8(?). There was one character before the name in the assembler that denoted C functions (_) and so 7 letters were left. By making function names 6 letters long they were sure no stupid linker would confuse "strdupl" with "strduplicate".I always hated the name of this function (not what it does, that's pretty convenient and often needed), because it's really a bad fit among all the otherstring.h
functions namedstr*
. None of them would ever allocate memory. A missed chance to find a better name for it
Quite a lot of nice things
I'm sure I've missed some big things, and there are many more small changes.
- static_assert like C++
- strdup finally part of the C standard
- realloc of size 0 is UB
- #elifdef and #elifndef
- #embed
- no more k&r declarations
Based on notes in man page, it's so widely available that it's better than some standard (which almost no one implements fully/correctly).I would have liked the memmem() function to be added to the standard too.
Hmm. Personally I prefer to have standards, which means at least there is something for everyone to aim for.Based on notes in man page, it's so widely available that it's better than some standard (which almost no one implements fully/correctly).
One advice I can give is don't get hung up on versioning with C. The reason why people do with C++ in particular is because they have a particularly organized approach from overly large language committees. And strangely I feel this bubbles back down to standard C.Looking closer at versioning I see that there was also C-2018 and C-2024 pending.
Can I expect my ancient 'C' books to still work the same?
(Try compiling with different standards)