这道题最开始我用记搜写的，然后WA了一些点，后来看了半天才发现是数组开小了，原来他给了两个数据范围，一个是60%数据的数据范围，另一个是100%数据的数据范围。我没仔细看，没看见后面那行，把60%数据当成本题数据范围了....自然WA了（不过有点好奇为什么不是RE，但是不重要，这种情况不罕见）
然后，增大数组后WA的点就变成TLE了，80分的TLE。然后我用上了cincout加速并且化递归为递推，用正儿八经的DP代替了记搜，过了。
但是，我意识到我提交代码时默认勾选了O2选项，按往常的习惯，我吸口氧能过的题绝对不再花时间。但这道题鬼使神差的我试了试不开O2，结果让我大跌眼镜直接TLE了四个点只有60分...我突然不再那般不求甚解了，得认真些才是呀，于是我打开了题解，想知道自己为什么TLE了以及正解应该怎么优化。（直到那时我还以为这是一道卡常题所谓正解也无非是优化了常数的做法）但是，看到题解后瞬间意识到自己O（n^2）的做法在这个2*10^5数据范围的题目中过不去简直太正常了，我差的不是常数优化，而是根本性的优化。然后我接触到了好多新的优化方法，优先队列、单调队列、线段树、分块。我随后学习了优先队列和单调队列的思想，然后意识到用单调队列来优化我这道题是非常之自然的做法，此前也隐约想到了这种优化但是考虑到下标会在优化过程中丢失然后就不知道该怎么处理了所以没这么做。然而题解仿佛一语点醒梦中人，直接用结构体当队列节点不就行了，把下标和数据绑死在一起，下标本身也存起来而不是依赖其序号而确定就可以消灭一个我此前以为优先队列和单调队列存在的缺点——下标丢失。所以我此前以为的缺点其实根本不算一回事。
最后我感悟到单调队列的思想以及那个用结构体的小tips之后手写了起来，写的不快，但最终写成了，这个过程便让我彻底理解了单调队列，以后就完全会了这种手段了。
顺便还意识到原来deque是可以用迭代器访问其中间元素的，此前我被某些垃圾博客忽悠以为这东西不能访问内部来着，所以此前一直用vector代替deque，现在好了，直到deque可以用并且前端插入的效率远快于vector，以后的各种新队列都可以用deque来实现喽，很方便。
最后，发现这个做法的提升不是一点半点，原本的算法2s的时限都超出了，新代码直接三十多ms过大数据，并且取消掉cincout优化后仍可以50多毫秒过大数据，开了O2后甚至十几ms就能过大数据。
看来读入优化等常数优化的效果果然远小于此类根本性的优化，以后要先分析自己的时间复杂度，发现有明显问题是优先想彻底性的优化，然后再考虑读入优化尾递归等小优化，别上来就读入优化。长期用常数优化+O2骗过洛谷是会有很多坏处的！今天要不是我多想了想，这些知识就错过了！
Code
#include <iostream>
#include <deque>
using namespace std;
struct node
{
int index,num;
node(){}
node(int i,int n){index=i;num=n;}
};
deque<node> q;
int n,l,r,a[400000+5],ans=-99999999,dp[400000+5];
signed main()
{
ios::sync_with_stdio(false);
cin.tie(0);
cin>>n>>l>>r;
for(int i=0;i<=n;i++)cin>>a[i];
for(int i=1;i<l;i++)dp[i]=-99999999;
for(int i=l;i<=n+r;i++)
{
while(!q.empty()&&q.front().index<max(0,i-r))q.pop_front();//出队是全自动的，只要设定好新的窗口左端
int k=min(i-l,n);//单调队列处理滑动窗口问题，入队时只需要考虑新纳入队列考虑范围的那些未入队节点如何入队，有时每轮循环中只需要考虑一个节点的入队
while(!q.empty()&&q.back().num<dp[k])q.pop_back();
q.push_back(node(k,dp[k]));
dp[i]=a[i]+q.front().num;
}
for(int i=n+1;i<=n+r;i++)ans=max(ans,dp[i]);
cout<<ans<<endl;
return 0;
}