Re:C++ Internals: STL Vector, Part 3
by andrepd on Sunday August 09, 2015 @05:50PM
(#10031709)
And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.
[ Parent
| on HN ]
> And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.
This comment is very interesting. His syntax reminds me of Python syntax of:
for i in [1,2,3]:
Isn't that what the future C++ is trying to achieve? Simplified syntax?> Isn't that what the future C++ is trying to achieve? Simplified syntax?
I think your question was rhetorical, in any case the answer is yes. In fact the proposed C++ pythy syntax tries go even further http://pfultz2.github.io/Pythy/ . IIRC its Clang only. Its author hangs out on HN sometimes and would be able to provide more information
It's worse in every way to:
for (int i = 1; i != 10; ++i)Even in that example, wouldn't it be better to simply write
for i in range(1,4):Why? Because that's the most concise way in general to iterate over an arbitrary list of enumerated values. There's no "abuse" here, just a particular example that could have been written more concisely.
Re:C++ Internals: STL Vector, Part 3
by fauigerzigerk on Monday August 10, 2015 @04:14AM
(#10033295)
It's not the most concise way to iterate over a sequence of numbers from 1 to 9. Worse than that, it suggests that there may be a number missing somewhere in the middle. You have to scan the entire sequence with your eyes to be sure.
for (int i = 1; i <= 9; ++i)
is both more concise and requires less thinking to know what's going on.That the data he chose can be expressed as a range is utterly inconsequential. The values are never even used. In all likelihood, the author just wrote
for (auto item : {})
and then filled in the first sequence of numbers that popped into his head.
Re:C++ Internals: STL Vector, Part 3
by fauigerzigerk on Tuesday August 11, 2015 @08:40AM
(#10040531)
>That the data he chose can be expressed as a range is utterly inconsequential
It could be, but we don't know that. And that's exactly my point. The syntax he uses forces us to think and even speculate about that. So for the particular sequence he chose for his example, it would be less ambiguous to generate the range algorithmically.