(And it doesn't matter if it's a physical book or e-book, the cost of printing nowadays is ca. $1 for each 100 pages.)
Resume-wise, I've been writing C code since 1985, and I've been an expert on the C Standards Committee (WG14) since 2004. I've written two prior books on C Programming including "Secure Coding in C and C++" and "The CERT C Coding Standard". I also teach Secure Coding in C for NCC Group https://www.nccgroup.trust/us/our-services/cyber-security/se... and I also taught these topics to Computer Science undergraduates and graduate students at CMU for over a decade. So I think I have a good balance of technical skills and communications skills, but you know, pick up a copy and judge for yourself.
I'll buy an extra copy if you can get 'defer' in there too!
Those two features would really be the bee's knees :)
But it's also not exactly -complete-. The standards committee makes changes every few years, including language additions.
I'm a fulltime C programmer, and I would _love_ to have both of the features I suggested - for the following reasons.
- defer: I could defer a free() statement after every malloc, guaranteeing that I won't miss one or forget about it. Lots of memory leaks and file-descriptor leaks could be easily avoided if C provided 'defer' as a language feature. GCC already offers something kind of similar with its __cleanup__ attribute, and a lot of programs rely on it. How much better would it be for the language to support it natively?
- constexpr: I am _so tired_ of writing really complex macros. Like say I want to populate a lookup table for a sine-wave (for fast use in a realtime system). Wouldn't it be nice if I could just populate my lookup table with a constexpr function? Then I wouldn't need really nasty macros, and I'd also be able to ensure that the calculations all happen at compile-time.
Re: developing a paper for constexpr, that's an interesting idea. I hadn't really thought about writing one up myself but it'd be an interesting thing to try out. Can you recommend a good example proposal that I could read? Shoot me an email at nicholas dot clark on the gmail if you ever see this.
Now that C allows mixing variable declarations in with statements, it becomes annoying that variable declarations can not have labels. This hits particularly hard with the switch/case, but can also apply with ordinary named labels. The syntax to work around this defect is ugly.
The gcc extension for case ranges is really valuable.
Setting the sign bit via a cast should not cause undefined behavior. (for example, going from uint32_t to int32_t) It should just work in the obvious way. Avoiding the problem requires extremely strange code.
I'd like a way to prevent arrays from being replaced by pointers. Assignment could work. Sometimes I really want to pass an array to a function, and I don't mind if that means a megabyte is copied into the function args on the stack. Sometimes I really want to force the huge copy, and other times I'd rather have the compiler keep it in the caller's frame (but callee can mangle it unless it is const) and just pretend that the callee got more than a pointer. Array dimensions need to survive. The callee's prototype should be able to demand specific dimensions or receive them as variables, and the caller should be able to pass a portion of a larger array
The default function parameters of C++ would be useful. The UNIX API for open() would be best done this way, allowing a prototype without the need for stdarg. There doesn't seem to be any reason why default parameters would have to be at the end; a pair of adjacent commas in the middle is a fine way to indicate that the default is to be used for that missing parameter.
It's time to standardize bitfield layout so that bitfields can be used in portable code for purposes like assemblers and disassemblers. (in other words, not for purposes like access to MMIO registers) Microsoft and GNU compilers are already quite compatible on x86_64, so that would be the basis of standardization.
When a bitfield happens to have the size and alignment of a normal integer type, it should be possible to take the address. The resulting type would be a pointer to the integer type of lowest rank having the correct size.
Anonymous unions and structs would be valuable in all scopes, including at file level. This would allow careful data organization to save space, improve cache locality, prevent undesired cache line aliasing, or allow the intentional aliasing of types. Current technology typically involves abuse of the linker, which is well outside the C language.
Being able to do something like an #include, but with a blob of binary data, would be helpful for initializing big arrays. Current practice is to have build scripts convert binary files to C, to have the linker do it, and to rely on assemblers with the capability. None of that is nice to use.
So that we don't have to invoke m4 or do nasty things with recursive macros, the preprocessor could support loops.
There are a few gcc extensions that make macros far more reasonable, including statement expressions and typeof. Add those.
When our authors ask how long their book should be I always say: Long enough to cover the subject, short enough to keep it interesting. My company is called No Starch Press for a reason. Think of the word starch as a nicer way to say "BS", as in No BS Press.
There's a lot of work behind these pages as with all of our books. Unlike any publisher in this field we have several people who read and craft every line of every book as necessary, together with each author, before a book goes off to a copy editor. That's where most books start but not hours.
The real cost in creating a good book is not in the paper. It's in the time it takes to actually craft the words.
I know the Rust book is already translated in some languages. I even started the Esperanto translation myself[1], but had other priorities in the mid time. Doing that in spare time doesn't help to accelerate the process, but I already achieved the translation of the Lua reference manual this way.
If you are interested, just send me an email through mathieu at culture-libre dot org, or reply to this message with some instruction on which canal you would prefer to use.
[1] https://github.com/psychoslave/Rust-libro [2] https://www.mediawiki.org/w/index.php?title=Extension:Scribu...
This is what has annoyed me about pulp paperback fiction. They skyrocketed from $5 to $15 in 15 years. Then you can buy the eBook for $12 and feel like you're getting a "deal" on a product with near zero production costs.
Amazon may ultimately discount this from the list price as they usually do but they are currently deprioritizing books due to the pandemic.
When I see that Brian W. Kernighan releases a book, it's an instant buy for me.
NoStarch never let me down so far, and paying USD 60 (or 40, or whatever) is such a marginal difference for a book you're going to spends dozens of hours on.
Is that a feature? I'm constantly frustrated by books that use many words to say little. Wasting hours on such books tends to be negative value, and I shouldn't buy them even for two cents..
The book is supposed to be around 270 pages, so verbosity probably won't be an issue.
I am right now working through "Python Crash Course" as an intermediate Python programmer. I very quickly read through chapters 1-8 so far and did all the exercises (rather simple ones), just to make sure that I'm not missing out anything on the basics. In the last couple of chapters, I actually picked up two or three pieces of knowledge I wasn't aware of. I spent around five to ten hours on this so far. This approach sounds terribly inefficient.
However, working through a beginner's book as an intermediate Python programmer, and only getting half a dozen of really new information out of it, gives me the confidence I need at this stage. So I don't consider it as a waste, but rather as an exercise in patience and repetition.
Why am I telling you all this? Because I think people overrate the monetary costs of books.
In this case, I'm definitely curious about the book and would like to skim through it just to satisfy that curiosity, but I have my doubts as to whether I'll get much out of it (I've been writing C for 15 years and I do it professionally). Maybe there are gems of wisdom (or things I've overlooked) in it that would make it worthwhile, but it's possible I'd just regret the time and money spent :-(
Many books nowadays, also from NoStarch, are released as early access books. Your book does not run under the early access program, or at least not yet.
Is this a decision made by you as an author? Or is the kind of book not really suited for early access? I could imagine that introductory books work well as early access books; readers could work through the first couple of chapters, while later chapters are still being written or refined.
Just curious...
I probably won't be able to read it before July, anyway, because I have to finish my bachelor's degree first. But I think it's not a bad time for a financial contribution to my favorite tech book publisher, so I already bought the book "blindly".
So until a preview chapter or similar is available I’ll through this link to Modern C, 2nd Ed by Gustedt. It has been well received and I thought Jens writing style was solid.
I don’t know if it is the perfect second book to read on C, but it seems well paced and things are well explained.
Here is a newer article on Uninitialized Reads published by ACM https://queue.acm.org/detail.cfm?id=3041020
Jens and I are both on the C Standards committee. I would definitely say that our books serve different markets.
If you think there is going to be a large difference in applicability and focus when comparing your ‘Effect C’ and Jens’ ‘Modern C’ I am kind of excited, not just to get your book, but also that even though some people would like to see C be relegated to the trash bin there is still some life left in a language I enjoy using.
maybe older books are cheaper
It's a luxury item. For comparison K&R2 sells for $51.99 new on amazon.
I think a fair price would be $49.99.