6 ms·

This is neither here nor there, but in your revised version you are copying all the vectors many times. Use auto&.

jjawssd 9y ago
While perfectly fine, this comment unironically reinforces the GP's assertion of "how [C++] as a whole the language is basically a gigantic ball of special cases"
- kobeya 9y ago
  What specifically annoys me about C++ and is demonstrated by this example is that the simplest possible expression of an algorithm is almost certainly not the most efficient or desirable way to do what you are trying to accomplish. In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so. C++, on the other hand, is only really an effective language in the hands of people who have either fully internalized the 1,000 page specification, or wasted a depressing number of synaptic connections on memorizing minute trivia about what constructs to use under what circumstances. I say this as someone who works with C++ on a daily basis :(
  - llukas 9y ago
    > C++, on the other hand, is only really an effective language in the hands of people who have either fully internalized the 1,000 page specification, or wasted a depressing number of synaptic connections on memorizing minute trivia about what constructs to use under what circumstances. No. You use profiling tools and optimize hotspots. Pareto principle applies here so you look at 20% of program tops. Rest is irrelevant and can be executed as inefficiently as you please as long as you got your big O complexity right.
    - kobeya 9y ago
      Or the language and compiler can just save you the trouble and get it right from the beginning.
      - llukas 9y ago
        What you see as trouble other people see as desired behavior. Pick the right language.
      - klipt 9y ago
        Isn't C++ still pretty much the fastest language out there, except Fortran for some numerical applications? I thought that's the main reason to use it over Python/Java/etc.
        dima55 9y ago
        C. Use C.
        jsolson 9y ago
        Having recently done some C development after a few years of exclusively C++, no, no thank you. I'll take my RAII and destructors, thank you very much.
        pjmlp 9y ago
        Hence why already back in 1993, when faced with the option of Turbo C 2.0 vs Turbo C++ 1.0, I could not understand why bother with C at all, still don't.
        josefx 9y ago
        Those language creators and their names, "C","C++", "Objective-C","HolyC", "C#". I almost thought "C." was a new language.
        CyberDildonics 9y ago
        C doesn't have destructors or move semantics.
  - Retra 9y ago
    I used to despise C++... but now I work on it every day, and while I don't think it's great, it is not so bad. Turns out my hatred was entirely for the std library. At my work, we simply don't use it. And thus `auto` hardly saves anything, so we don't use that either, and I don't miss any of it.
  - gpderetta 9y ago
    > In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. In C++ values are first class, making 'auto x' an implicit reference would be surprising for anybody with experience with the language model. It is also consistent[1] with the template deduction rules. I strongly believe that not not having first class values in a language with mutation is a design mistake [2]. [1] IIRC the ill designed initialization_list has special rules for auto. [2] C++ references are not first class which is also a mistake.
  - claudius 9y ago
    > In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so. But I would expect auto x = y; to create a new variable by copying with type-deduction from y, not a reference (or even const reference) to y. If I want a reference anywhere in the language I always have to say so explicitly. As such, I find it perfectly normal that for(auto x : y) create a copy of the elements of y while for(auto& x : y) creates a reference to the elements of y. Reversing this just within for-loops would only add to the confusion. Defaulting to references over values just for auto where everywhere else values are the default and references need to be specified would also only add to the confusion. Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11. Regarding the specification, I am incredibly happy that there is a specification I can trust and nowadays a series of different compilers which largely implement this specification instead of some "model-implementation" which implicitly defines the language and may look entirely different next week.
    - kobeya 9y ago
      > But I would expect "auto x = y;" to create a new variable by copying Why would you expect that? There are plenty of examples of other referentially transparent languages where "x = y" means x and y refer to the same thing, not different things (one newly created) initialized to the same value. Maybe you expect it to work the way it does because that more closely resembles how C++ has worked for you in the past, which is a bit of a circular argument. > Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11. Yes, that's exactly the point I am making.
      - exprA 9y ago
        Are you sure you're making a point – because I can't see one. Seems more about unnecessary bitching about C++ being different from [some-different-language]. If they could do anything more stupid as introducing a galling difference and a special case to variable initialisation with auto, it would be to do exactly that, but because “some other languages work more like that”.
tonmoy 9y ago
Tried this on a vector<bool>, got this error: error: invalid initialization of non-const reference of type ‘std::_Bit_reference&’ from an rvalue of type ‘std::_Bit_iterator::reference {aka std::_Bit_reference}’
- tonmoy 9y ago
  works great on vector<int> though, it turns out vector<bool> is a special case! http://stackoverflow.com/questions/30376032/error-invalid-initialization-of-non-const-reference-of-type-bool-from-an-rva http://stackoverflow.com/questions/30376032/error-invalid-in...
- klipt 9y ago
  Does const auto& work though?
  - gpderetta 9y ago
    I normally use for(auto&& x : ...) which works with those rare containers that have proxy references, while still allowing mutation.
- Manishearth 9y ago
  Heh, when I first heard that C++ vectors were bitvectors I was like "that can't be right? You can't get sensible references to members that way!" But it turns out that C++ is fine with breaking parametricity so references to bitvector elements just don't compile.
  - Negitivefrags 9y ago
    I wouldn't say C++ is fine with it. vector<bool> is widely viewed as a mistake. I would actually say it's one of the few inconsistencies in a standard library that tends to be very consistent. The problem is that (quite rightly) the C++ standard committee tries very hard to not break existing code. There isn't really an easy way to deprecate a specialization of this container without causing 32x more memory use if someone was relying on it, and even worse it would be a silent breaking change.

While perfectly fine, this comment unironically reinforces the GP's assertion of "how [C++] as a whole the language is basically a gigantic ball of special cases"

kobeya 9y ago
What specifically annoys me about C++ and is demonstrated by this example is that the simplest possible expression of an algorithm is almost certainly not the most efficient or desirable way to do what you are trying to accomplish. In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so. C++, on the other hand, is only really an effective language in the hands of people who have either fully internalized the 1,000 page specification, or wasted a depressing number of synaptic connections on memorizing minute trivia about what constructs to use under what circumstances. I say this as someone who works with C++ on a daily basis :(
- llukas 9y ago
  > C++, on the other hand, is only really an effective language in the hands of people who have either fully internalized the 1,000 page specification, or wasted a depressing number of synaptic connections on memorizing minute trivia about what constructs to use under what circumstances. No. You use profiling tools and optimize hotspots. Pareto principle applies here so you look at 20% of program tops. Rest is irrelevant and can be executed as inefficiently as you please as long as you got your big O complexity right.
  - kobeya 9y ago
    Or the language and compiler can just save you the trouble and get it right from the beginning.
    - llukas 9y ago
      What you see as trouble other people see as desired behavior. Pick the right language.
    - klipt 9y ago
      Isn't C++ still pretty much the fastest language out there, except Fortran for some numerical applications? I thought that's the main reason to use it over Python/Java/etc.
      - dima55 9y ago
        C. Use C.
        jsolson 9y ago
        Having recently done some C development after a few years of exclusively C++, no, no thank you. I'll take my RAII and destructors, thank you very much.
        pjmlp 9y ago
        Hence why already back in 1993, when faced with the option of Turbo C 2.0 vs Turbo C++ 1.0, I could not understand why bother with C at all, still don't.
        josefx 9y ago
        Those language creators and their names, "C","C++", "Objective-C","HolyC", "C#". I almost thought "C." was a new language.
        CyberDildonics 9y ago
        C doesn't have destructors or move semantics.
- Retra 9y ago
  I used to despise C++... but now I work on it every day, and while I don't think it's great, it is not so bad. Turns out my hatred was entirely for the std library. At my work, we simply don't use it. And thus `auto` hardly saves anything, so we don't use that either, and I don't miss any of it.
- gpderetta 9y ago
  > In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. In C++ values are first class, making 'auto x' an implicit reference would be surprising for anybody with experience with the language model. It is also consistent[1] with the template deduction rules. I strongly believe that not not having first class values in a language with mutation is a design mistake [2]. [1] IIRC the ill designed initialization_list has special rules for auto. [2] C++ references are not first class which is also a mistake.
- claudius 9y ago
  > In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so. But I would expect auto x = y; to create a new variable by copying with type-deduction from y, not a reference (or even const reference) to y. If I want a reference anywhere in the language I always have to say so explicitly. As such, I find it perfectly normal that for(auto x : y) create a copy of the elements of y while for(auto& x : y) creates a reference to the elements of y. Reversing this just within for-loops would only add to the confusion. Defaulting to references over values just for auto where everywhere else values are the default and references need to be specified would also only add to the confusion. Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11. Regarding the specification, I am incredibly happy that there is a specification I can trust and nowadays a series of different compilers which largely implement this specification instead of some "model-implementation" which implicitly defines the language and may look entirely different next week.
  - kobeya 9y ago
    > But I would expect "auto x = y;" to create a new variable by copying Why would you expect that? There are plenty of examples of other referentially transparent languages where "x = y" means x and y refer to the same thing, not different things (one newly created) initialized to the same value. Maybe you expect it to work the way it does because that more closely resembles how C++ has worked for you in the past, which is a bit of a circular argument. > Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11. Yes, that's exactly the point I am making.
    - exprA 9y ago
      Are you sure you're making a point – because I can't see one. Seems more about unnecessary bitching about C++ being different from [some-different-language]. If they could do anything more stupid as introducing a galling difference and a special case to variable initialisation with auto, it would be to do exactly that, but because “some other languages work more like that”.

tonmoy 9y ago

Tried this on a vector<bool>, got this error: error: invalid initialization of non-const reference of type ‘std::_Bit_reference&’ from an rvalue of type ‘std::_Bit_iterator::reference {aka std::_Bit_reference}’

tonmoy 9y ago
works great on vector<int> though, it turns out vector<bool> is a special case! http://stackoverflow.com/questions/30376032/error-invalid-initialization-of-non-const-reference-of-type-bool-from-an-rva http://stackoverflow.com/questions/30376032/error-invalid-in...
klipt 9y ago
Does const auto& work though?
- gpderetta 9y ago
  I normally use for(auto&& x : ...) which works with those rare containers that have proxy references, while still allowing mutation.
Manishearth 9y ago
Heh, when I first heard that C++ vectors were bitvectors I was like "that can't be right? You can't get sensible references to members that way!" But it turns out that C++ is fine with breaking parametricity so references to bitvector elements just don't compile.
- Negitivefrags 9y ago
  I wouldn't say C++ is fine with it. vector<bool> is widely viewed as a mistake. I would actually say it's one of the few inconsistencies in a standard library that tends to be very consistent. The problem is that (quite rightly) the C++ standard committee tries very hard to not break existing code. There isn't really an easy way to deprecate a specialization of this container without causing 32x more memory use if someone was relying on it, and even worse it would be a silent breaking change.