3 ms·
Writing code that breaks if someone changes the type of the collection is not a bug in any sense that I ever saw the word used in. At most it's a failure to mak
by yosefk 11y ago
Writing code that breaks if someone changes the type of the collection is not a bug in any sense that I ever saw the word used in. At most it's a failure to make the code as pliable as one might desire it to be - but the author is not very likely to value the ability to easily replace an array with a list (it appears he'd be concerned about the performance implications and would want to review all the relevant code anyway.)
Also in reality making sure that your arrays can be replaced with lists means you can't store indexes into the array but instead you must store iterators, which sucks when you have to declare them (auto won't work in many contexts and typedef will expand into the ugly underlying type in many contexts), and sucks when you have to print them ("5" or "342" reads better than whatever garbage you'll have to resort to when printing out an iterator, and it persists better between program runs and across platforms, too.) So if I have an array/vector I'd rather not try to pretend that it's a "non-ordered collection" until I absolutely ought to use random access; I'd just treat it as an array/vector from the start.
So I guess what I'm trying to say is, not only is it not a bug but the attitude of people who write such non-bugs has many advantages.
(And BTW caring about performance is not the main point. A nice thing about your typical dynamic language is that there's not much gratuitous polymorphism. You get a few basic collection types and you use these and most code doesn't jump through hoops to be able to replace the standard collection type with some polymorphic replacement only satisfying a subset of the interface. So-called "type-rich" programming gets gnarly, I prefer "type-poor" on any day. Which isn't the main point, either, the main point is that things that work nicely in practice (like treating arrays as arrays) matter more to me than things that sound "right" from an abstract viewpoint (like being able to replace your collection types with other types.) And calling it a "bug" is, I guess it kinda bothers me and hence the wall of text...)
- Animats 11y agoIf you use ".end()" on an C++ standard array collection, what you get is not the array size. You get an invalid iterator pointing one element past the end of the array, which tells you when to stop. Most newer languages have built-in syntax for "iterate over collection". C++ does not, leading to somewhat clunky constructs like this. It's ugly, but that's where C++ ended up. (I personally think that the C++ committee went way too far in making the template fanatics happy. It's neat that C++ templates, being a general term-rewriting system, allow arbitrary computation at compile time, but templates are a terrible programming language. More recently, it worries me that Rust is going too far in that direction.)
- lcampbell 11y ago> Most newer languages have built-in syntax for "iterate over collection". C++ does not. Huh? C++11 includes a range for: for ( auto i : results )
- kibwen 11y ago> it worries me that Rust is going too far in that > direction. Rust is making no steps at all towards anything akin to templates. Can you elaborate?