每当我在调试代码时从Visual Studio的实现中打开任何与STL相关的代码时,我就会惊慌失措:
// From <xtree>
if (_Where == begin())
{ // insert at beginning if before first element
if (_DEBUG_LT_PRED(this->comp,
this->_Kfn(_Val), _Key(_Where._Mynode())))
return (_Insert(true, _Where._Mynode(), _Val));
}
else if (_Where == end())
{ // insert at end if after last element
if (_DEBUG_LT_PRED(this->comp,
_Key(_Rmost()), this->_Kfn(_Val)))
return (_Insert(false, _Rmost(), _Val));
}
//...
else if (_DEBUG_LT_PRED(this->comp,
_Key(_Where._Mynode()), this->_Kfn(_Val))
&& (++(_Next = _Where) == end()
|| _DEBUG_LT_PRED(this->comp,
this->_Kfn(_Val), _Key(_Next._Mynode()))))
{ // insert after _Where
if (_Isnil(_Right(_Where._Mynode())))
return (_Insert(false, _Where._Mynode(), _Val));
else
return (_Insert(true, _Next._Mynode(), _Val));
}
评论的存在让我觉得好像是人类写的,但是格式不好,在一切开始时自由使用下划线(为什么?),以及像(++(_Next = _Where) == end()
|| _DEBUG_LT_PRED ...)
这样极其难以理解的条件让我觉得虽然它们是从另一段源代码生成的,但不是按原样编写的。
有谁知道其中的哪一个是这样的? (如果它是从其他一些代码生成的,我会有兴趣知道如何/为什么这样做。)
对于记录,这是同样的事情,但“格式正确”:
if (Where == begin())
{
// insert at beginning if before first element
if (DEBUG_LT_PRED(this->comp, this->Kfn(Val), Key(Where.Mynode())))
return (Insert(true, Where.Mynode(), Val));
}
else if (Where == end())
{
// insert at end if after last element
if (DEBUG_LT_PRED(this->comp, Key(Rmost()), this->Kfn(Val)))
return (Insert(false, Rmost(), Val));
}
//...
else if (DEBUG_LT_PRED(this->comp, Key(Where.Mynode()), this->_Kfn(Val))
&& (++(Next = Where) == end()
|| DEBUG_LT_PRED(this->comp, this->_Kfn(Val), Key(Next.Mynode()))))
{
// insert after Where
if (Isnil(Right(Where.Mynode())))
return (Insert(false, Where.Mynode(), Val));
else
return (Insert(true, Next.Mynode(), Val));
}
恕我直言这个更像是如果一个人写下来的话,但是再一次,我不知道。
答案 0 :(得分:31)
答案 1 :(得分:15)
VC ++提供的STL由Dinkumware编写(可能已经改编)。
据我所知,它是由人类编写的,但经过大量优化,可能会在维护者的口中留下酸味。毕竟,有一个原因,我们建议初学者不要微观优化他们的代码 - 这使得它很难阅读。但是,我们确实希望从库中获得重要优化的STL:我们无论如何都不需要维护它。
我自己觉得它很可读:
你可能想看看libc ++来说服自己,即使是一个人类编写的库,没有遗留代码(很新鲜),也会变得非常复杂。示例<algorithm>
(喜欢排序算法)。
答案 2 :(得分:7)
MS STL的原始公司是Dinkumware。他们有这种糟糕的代码风格,即使MS不再使用它们,它看起来仍然存在。我确定这是手工编写的,可能都是由同一个人编写的,我可以为他命名,但我认为我不会。