61–70 of 152 posts
Earlier quoted context omitted.
Remember that that's inluding like 60 pages of what are basically printed man pages.
When K&R was written, it's not a given that the man pages for C functions already existed, is it?
[1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/man/...
Earlier quoted context omitted.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
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.
Earlier quoted context omitted.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
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.
Earlier quoted context omitted.
Constness when used on classes introduces a way to create objects that behave differently in different contexts. Are you calling a member function from a const or from a non-const pointer? Depending on that you could be running different code. In my opinion you should make your mind about what the class does: is it mutable? then don't use it with const. Unfortunately, you are still required to use const in many place…
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.
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?
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,…
It's to be expect that we can change a-through-&b, but not a-through-&a in foo.
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.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
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.
Not sure if this way of comparing programming languages (i.e. do A in language X and do B in language Y => Y is not slower than X) makes enough sense to draw conclusions. If you can use clever algorithms, in the majority of cases you'd do so in any language and in the majority of cases C would lead to more performant code than Python. Then again, wheteher this matters in the scope of the actual application is somethi…
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.
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 will cover a lot of use-cases. You don't always "need" to use C++, unless you have precise needs all the time, or don't want to have another language interact with your code.
2) You can still use C++ and avoid complex features, or just use C.
3) The language keeps evolving, and I think it's great that companies are working towards an ISO standard. Few languages have that. Maybe the language will be a little easier to use in the future.