111–120 of 152 posts
Earlier quoted context omitted.
When K&R was written, it's not a given that the man pages for C functions already existed, is it?
They were, albeit potentially more terse than is available now. System III's functions section was pretty full by 1983 even [1]. [1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/man/...
K&R was published in 1978
Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not seem to apply his guidelines into any practical project of his. As a programmer, I'm suspicious when people have opinions and give advice but never showed me more than snippets of code. Like a master tailor that wouldn't sew. How come he gets that much recogniti…
His webpage: http://www.aristeia.com/ indicates that he has been a programmer since 1972. Even if he has been doing training/consulting for a couple of decades, that leaves a lot of time to get the basics down. I've never met him, though I have browsed one of his books once. My own personal feeling is that books like these can be invaluable for people starting out in the industry. It gives you a reference point to re…
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.
But Rust also introduces complexity, while improving substantially in many areas. Of course it will do things better than what a language initially designed decades ago will do. A large amount of important systems rely on C++ and so it cannot change overnight, if at all. Rust on the other hand is free to experiment. The cost, at least in this early period, is unreliability.
When, or if, Rust becomes as performant as C++, with a comparable number of libraries and platform support, then it will be a viable alternative (and I hope that day comes). For now, the only possibility for this use case is C++.
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,…
This does not seem like a strong argument. Yes, table salt is useful, but if you don't know what it actually does and you put it in your eyes, it will burn them, just like most, well, everything... 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.
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.
I think the objection is that b may get passed throughout the program such that it's no longer local to a. Then you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object (probably through a member variable), and suddenly you have some very hard to track down bugs. If you're multi-threaded, you have a data race. You ei…
And this is exactly why const means pretty close to nothing. Compilers can't enforce it in so many situations that it is almost like the "auto" keyword in pre-C++11 times.
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.
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.
Yes, exactly. In particular, this can be seen in the syntax. There are lots of angle brackets and colons these days. I hope at some point, around 5 years from now, a version can be made that is nearly the same thing underneath, but looks more like python.
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.
But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.
Earlier quoted context omitted.
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…
While that's true, a lot of the complexity is self-inflicted. C++ tries to define syntaxes for its features in a C style which cripples a lot of features in unnecessary ways. For example, classes being kinda like a C struct instead of a separate syntax altogether. Honestly, even Objective-C is better in this regard because the Objective-C parts are well separated from the C parts instead of feeling wedged-in.
I would argue that's "better". As a result, Objective-C feels like an alien language for a C programmer. Although to be fair I don't think a core C programmer would move to either C++ or Objective-C unless (s)he has to (iOS support or legacy code). I think it is the same reason why C++ developers are not moving to Go anytime soon.
Earlier quoted context omitted.
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?
I think the argument isn't that Python code out performs C code, it's that code written by mediocre Python programmers often outperforms code written by mediocre C programmers. C code is fast enough the mediocre programmers get used to letting the language bail them out. Python programmers know that their language is slow and that they have to work around it. I've encountered this several times in my own career. A co…