71–80 of 152 posts
Earlier quoted context omitted.
Err, why?
Because the FFT in python is almost certainly implemented in C, and probably more cleverly done than a naive FFT that I/you/someone would whip up as part of a C program.
Earlier quoted context omitted.
I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include void foo(const int& a, int& b) { std::cout Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes,…
Isn't this inferable from the code itself, though? I was expecting some subtle gotcha, so I had to read your comment three times to realise there was none! It's to be expect that we can change a-through-&b, but not a-through-&a in foo.
You either need to be very strict about creating non-const references to objects, or you need to enforce immutability at the class level. Unfortunately the latter has all sorts of other practical problems, often including efficiency trade-offs or awkward APIs.
Earlier quoted context omitted.
Const-ness gives you a way to express a very common pattern in software, where an object is constructed piecemeal in one section of the code and then "frozen" and only const references get passed around from then on. If you were to express this at the class level, you'd need awkward circumlocutions like the Builder pattern, comments on methods, or friend member functions.
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.
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.
With the amount of time invested into writing the book it would be interesting to see what type of financial return he was able to get for it. Certainly I would hope he was able to make as much as if he were working in private industry for the same amount of time. (though somehow I doubt this is the case)
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.
However this generally doesn't apply to tech books because number of programmers are just around 10 million and if you estimate 1% will buy your book (best case) you will still top out $300K range @ 10% royalty. Even worse, technology will change in next 2-3 years and your royalties would dry up quickly. Most "full time" tech book writers run training consulting business and do conferences as main source of income.
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 something like 3-4 hours a day writing - and that's a good day!
See for example the chapter on writers in Cambridge Expertise Performance Handbook (http://www.amazon.com/Cambridge-Expertise-Performance-Handbo...).
In general this type of reasoning (40h work week => time for 40h of writing) makes time estimates troublesome in my opinion. Another example is people who claim to write code for 40, 60 or even 80 hours a week. A look at actual RescueTime data gives a sober picture: https://news.ycombinator.com/item?id=209195
Of course, you could claim a lot of the work happens in breaks, and I would agree. But then the actual weekly number for our most beloved artists, programmers, and scientists is more like 24*7, literally. In that case, it makes more sense to talk about it in on the timescale of days, weeks, months or years.
Could somebody redpill me on why something like D ( http://dlang.org/ ) is not a better alternative to C++. Is that the library support or what exactly makes C++ still a better option in 2015? I am not sure what is the best alternative to C++.
Earlier quoted context omitted.
That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include void foo(const int& a, int& b) { std::cout Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes,…
A const reference guarantees to the caller that the callee won't modify the object, not to the callee that the object won't be modified.
Earlier quoted context omitted.
That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include void foo(const int& a, int& b) { std::cout Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes,…
Earlier quoted context omitted.
Because the FFT in python is almost certainly implemented in C, and probably more cleverly done than a naive FFT that I/you/someone would whip up as part of a C program.
Is this a joke? Something written with the same algorithm in c will be faster than python. Why not use someone elses non naive FFT impl in c then as well?