在解LeetCode上面关于DP or BFS/DFS的时候常会用到下面几行code
vector<vector<int>> dirs{{0,-1}, {0,1}, {1,0}, {-1,0}};
func()
{
for(auto& dir: dirs)
{
int nr = r + dir[0];
int nc = c + dir[1];
}
}
for那一行有时候想说没改到dir得值，就直接写成for(auto dir: dirs)
没想到leetcode算效能的时候结果差很多
我试过有时候从70%掉到10%
甚至超过时间submit failed
这两种写法真的有差这么多吗?

pass by reference当然有差 不是只传一个int 是vector

auto& -> vector<int>&auto -> vector<int>一个传reference 没啥开销

我比较喜欢DIRS{0,1,0,-1,0} LEN=4

同楼上

我记得传 reference 会造成没办法把值放到 register，导致有时候 pass by value 反而会让函数跑比较快但这个 case 传 ref 应该是比较好啦...

写auto&&会更好,免得当dirs的容器变成vector<bool>这种proxy class(会让dereference得到一个暂时物件)使得lvalue-reference无法bind to it.

plain struct可能就还好 你这是复制vector所以效能影响比较大

没改到就加 const

DIRS{0,1,0,-1,0} LEN=4 怎么写啊， len=5?

这个不重要 重要的是你的算法而且compiler对于built-in type的东西有最佳化 pass byvalue的效能会更好 但不重要 算法不是要考语言特性

我都用 const auto &var

@peter98 说是这样说，但刷 LeetCode 的人有高比例都不只是为了测试算法，多学一点语言特性都不会是坏事XD而且这年头算法别说语言特性了，连硬件特性都要考虑，已经不太纯了XD

这个哪里不重要 这是超级基本的C++特性

int x = i + dir[d], y = j + dir[d + 1];

这让我想到我某同事把其他语言写的算法直接搬到c++结果更慢就骂c++落伍又没用 XD

高频交易表示硬件才是问题

对语法熟、对编译过程熟、对指令熟、对硬件特性熟，想拼到极致单靠算法是不够的写嵌入式慢慢的 12MHz 可能还要精算每道指令的 cycle数咧，哪有什么哪个东西不重要这种说法

而且也可能是 leetcode 的问题，有时候会发生同一份 code多 submit 几次，每次跑出来效能都不一样啊我的意思是发生效能不如预期也可能是 lc 的锅，虽然这个 case 是因为 deep copying vectors 造成的

有人知道 constexpr等等compile time会不会算进作答时间吗

应该不会 你拿meta programming玩一下No.509就知道了

不是template就不需要用auto&&了，因为你很清楚知道操作的iterator dereference之后的型别是不是proxy，如果是proxy还不如直接pass by value享受compiler对build-in type有可能给出的优化。写template时你才会有考虑iterator dereference之后返回值的各种可能性问题。

dir这个用vector太浪费 建议直接用constexpr

纯粹是lc 那个时间变化很大而已 你同一份多传几次 不同月份传 结果可能出乎你意料