Live data from Hacker News

The Time Needed to Write “Effective Modern C++”

scottmeyers.blogspot.com

91–100 of 152 posts

Re: The Time Needed to Write “Effective Modern C++”

#91

Earlier quoted context omitted.

The builder pattern is the right way to go. It is stronger than const-references, because once the object is created, there is no way to unfreeze it. It guarantees that the object is truly const, no matter what. On the other hand, const keyword in C++ does not guarantee the object is really const. Your reference may be const, but something else might still have a non-const reference and mutate the object.

Most of the time `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. In addition, to enforce immutability in C++, you have to disable copy/move constructors and assignment operators, which removes much benefit of using values instead of references.

I see this sometimes in code at work. As soon as you need to stuff one of the 'const' objects into any kind of container you start requiring unique_ptrs everywhere, and then you start thinking how much easier your life would be if you wrote Haskell for a living instead.

Re: The Time Needed to Write “Effective Modern C++”

#92
post #76

This is interesting, but the hours are vastly overestimated, at least compared to similar metrics (e.g. from the deliberate practice and expertise literature): If we figure a 40-hour work week... it wasn't my only activity. Let's knock that number down by 20% to account for my occasionally having to spend time on other things. There's no way anyone spends 40 or even 30 hours a week writing . Most authors spend someth…

I find the hours amazing. My understanding is that a typical tech publishing cycle is three months for a first draft, with an SD of around 1.5 months, and a page count of 300-600. Not infrequently the book will be a side project and not the author's main gig.

E.g. When iPhone OS (as it was) first appeared, in-depth guides like Erica Sadun's were on the shelves almost as soon as it was released.

Even if some of those authors had limited distribution beta versions, they still worked their way through all the new features of the OS, wrote and tested sample code, and wrote all the content in a couple of months.

I understand Meyers wants to make sure the content represents industry practice, and that takes longer than just cranking out some code and making sure it works.

But even so - that's still a surprisingly long time for a tech book.

Re: The Time Needed to Write “Effective Modern C++”

#93
post #81
post #44

I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!" for now, it seems that C is insufficiently expressive and everything else is too slow. but the complexity of C++ is troubling.

The price for zero-cost abstractions and expressiveness is a monstrous complexity. If you want clean, expressive and easy-to-write code, you have a ton of languages where you can do just that. If you want performance and expressiveness, you will have to do with C++'s complexity.

I think Rust is making the case that you don't.

In particular, I think one of the largest sources of complexity is C++'s backwards compatibility.

Re: The Time Needed to Write “Effective Modern C++”

#94
post #70
post #44

I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!" for now, it seems that C is insufficiently expressive and everything else is too slow. but the complexity of C++ is troubling.

> but the complexity of C++ is troubling. It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected. I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it. 1) There are many other alternatives than C++ that…

C++ isn't evolving; it's just accumulating features. That's a crucial difference. The amount of harmful patterns you can accidentally use just keep on strictly increasing.

Re: The Time Needed to Write “Effective Modern C++”

#95
post #75

Earlier quoted context omitted.

To within a disturbingly accurate margin of error I can tell you right now his financial return for this book: zero dollars. There isn't enough money in tech books for writers to rely on it as a day job. At best it'll get you noticed and make other jobs or speaking engagements easier to get.

Actually book writing is booming business these days as long as books are meant for general audience. Tim Ferriss, for example, has made more than $3M from his books. E L James reportedly made $100 million from Fifty Shades of Grey. There are many other authors in the millionair list purely from writing books. The reason this is happening now more than before is because of cheap electronic version of book that can be…

E L James is primarily a marketer. Reddit had a very interesting comment from someone who knew the backstory about her relationship to the Twilight fanfic scene.

Let's just say people still remember her there, but perhaps not very fondly.

The Amazon gold rush for new authors is pretty much over. That's mostly a good thing. The people who stick with it now will be talented and/or persistent, and quality is going to start increasing.

As for tech - book sales are actually incredibly low. The general audience "How to use an iPhone" guides can sell very well, but titles on specific niche developer subjects rarely sell more than a few K copies.

A title on - say - JavaScript that racked up sales of 10K would be considered a run-away best seller.

Also royalties are closer to 5%, because they're usually calculated from net publisher income, which is around half the jacket cost.

Publishers sell tech books because many authors accept very low advances, so the numbers still work out. But to some extent it's a legacy industry. It was big in the 80s, peaked in the 90s and 00s, but has been in decline ever. There is so much excellent free training/example content online that it's making less and less sense to package it up in book form.

Re: The Time Needed to Write “Effective Modern C++”

#96
post #90

Earlier quoted context omitted.

"the complexity of C++ is troubling" This comes out of the fact that C++ is being developed more as an engineering tool than as a programming toy. When you're into real engineering, you don't have free lunch.

You can see this with Rust which tries to satisfy the same niche. It's possible to avoid the gotchas in C++ while preserving the advantages, you just pay a different price by working harder to satisfy the compiler.

A lot of people working with C/C++ I know are looking forward to Rust, but the problem is that currently it's nowhere near as mature and widespread as former languages. I hope that will change in the near future as it looks like promising system language.

Re: The Time Needed to Write “Effective Modern C++”

#97

Earlier quoted context omitted.

Or if you use clever algorithms. I don't have benchmarks at hand, but I suspect that an FFT in Python is faster than a naive Fourier transform in C.

Err, why?

My point is that a good algorithm, a good strategy can give you a several orders of magnitude speedup, more than the speed differences among languages. If a higher level language makes it easier and faster to develop good algorithms, then you should use that. After that, if you have time or really need it, you can re-implement it in hand-coded assembly, or even in hardware. But you generally don't have the time and don't really need it.

Re: The Time Needed to Write “Effective Modern C++”

#98
post #70

Earlier quoted context omitted.

> but the complexity of C++ is troubling. It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected. I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it. 1) There are many other alternatives than C++ that…

> I don't think its complexity is a problem. C++ is complex in many ways which are unrelated to its core functionality. For example: most vexing parse, integer promotions, conflated language features (classes provide records, polymorphism, namespacing, encapsulation), header files, vector , the grammar is insanely complicated, et cetera. C++, like Common Lisp, is a standards effort which places more value on preservi…

Well many of those issues are inherited from C, and Stroustrup has stated that compatibility with C was an absolute prerequisite otherwise C++ would have been stillborn. Given its position now, it's impossible to say that he was wrong, although I wonder if certain things could have been tidied up that would only have compilation-failed really bad code (e.g. it annoys me that you can pass a floating point value where an integer is expected).

Re: The Time Needed to Write “Effective Modern C++”

#99
post #93
post #81

Earlier quoted context omitted.

The price for zero-cost abstractions and expressiveness is a monstrous complexity. If you want clean, expressive and easy-to-write code, you have a ton of languages where you can do just that. If you want performance and expressiveness, you will have to do with C++'s complexity.

I think Rust is making the case that you don't. In particular, I think one of the largest sources of complexity is C++'s backwards compatibility.

One advantage of c++ is it is kind of nice to know that code you wrote six weeks ago is going to still work.

Re: The Time Needed to Write “Effective Modern C++”

#100
post #76

This is interesting, but the hours are vastly overestimated, at least compared to similar metrics (e.g. from the deliberate practice and expertise literature): If we figure a 40-hour work week... it wasn't my only activity. Let's knock that number down by 20% to account for my occasionally having to spend time on other things. There's no way anyone spends 40 or even 30 hours a week writing . Most authors spend someth…

I think that the lesson here is that it is kind of silly to try and put a time estimate on these things. How do you define time spent "writing"? Does it include time spent researching? Time spent thinking of the structure? If you pause to formulate the next sentence or line of code, should you stop the clock? Maybe we should only measure time taken in each individual key press.

It makes much more sense, and is less ambiguous, to talk about "time to complete a project". Like a book, for example.

Post reply on HN