简体   繁体   English

/ *来自Java TreeMap实现中的CLR * /

[英]/*From CLR*/ in Java TreeMap implementation

I was looking Java's (JDK 1.6_45) TreeMap code to understand a problem I was having and on few methods I saw a comment saying /** From CLR */. 我正在寻找Java的(JDK 1.6_45)TreeMap代码来理解我遇到的问题,并且在几个方法中我看到了一条评论说/ **来自CLR * /。

I was under the impression that CLR is Microsoft terminology for its common runtime. 我认为CLR是Microsoft常用运行时的术语。 Is CLR terminology used for Java as well? CLR术语是否也用于Java? If not, then is there a common agreement to use each others implementation (after converting of-course) or is it just some auto generated comment? 如果没有,那么是否存在使用彼此实现的共同协议(在转换过程之后)或者它只是一些自动生成的注释?

Example

/** From CLR */
    private void fixAfterInsertion(Entry<K,V> x) {

"CLR" is an abbreviation of three persons, namely Cormen, Leiserson and Rivest, authors of the first edition of Introduction to Algorithms . “CLR”是三个人的缩写,即Cormen,Leiserson和Rivest,第一版算法导论的作者。

EmirCalabuch answered in another thread that EmirCalabuch在另一个帖子中回答说

There is nothing peculiar in the TreeMap implementation of RBT. RBT的TreeMap实现没有什么特别之处。 It closely follows the pseudocode given in CLRS's (Cormen, Leiserson, Rivest and Stein) book, which is what 99% of the implementations around do. 它严格遵循CLRS(Cormen,Leiserson,Rivest和Stein)一书中给出的伪代码,这是99%的实现。

"CLRS" refers to the same book as "CLR" does. “CLRS”指的是与“CLR”相同的书。 Since this kind of method closely follows Introduction to Algorithms , being commented with /** From CLR */ is reasonable. 由于这种方法紧跟算法导论 ,因此使用/** From CLR */是合理的。

It looks like Java's TreeMap "borrowed" part of its implementation from JabberNet's Tree , which is written in C# — here the full C# source code . 看起来Java的TreeMapJabberNet的Tree中 “借用”了它的部分实现,这是用C#编写的 - 这里是完整的C#源代码

Most probably one of the authors of the Java's TreeMap included the comment to reflect this fact (so "CLR" in the comment indeed means "Common Language Runtime"). 很可能Java的TreeMap的作者之一包括反映这一事实的评论(因此评论中的“CLR”确实意味着“公共语言运行时”)。

Here a snippet from Java's TreeMap : 这是Java的TreeMap一个片段:

/** From CLR */
private void fixAfterDeletion(Entry<K,V> x) {
    while (x != root && colorOf(x) == BLACK) {
        if (x == leftOf(parentOf(x))) {
            Entry<K,V> sib = rightOf(parentOf(x));

            if (colorOf(sib) == RED) {
                setColor(sib, BLACK);
                setColor(parentOf(x), RED);
                rotateLeft(parentOf(x));
                sib = rightOf(parentOf(x));
            }

            if (colorOf(leftOf(sib))  == BLACK &&
                colorOf(rightOf(sib)) == BLACK) {
            ...

And here the corresponding snippet from the JabberNet C# code : 这里是JabberNet C#代码的相应片段:

private void fixAfterDeletion(Node x)
{
    while ((x != root) && (colorOf(x) == NodeColor.BLACK))
    {
        if (x == leftOf(parentOf(x)))
        {
            Node sib = rightOf(parentOf(x));

            if (colorOf(sib) == NodeColor.RED)
            {
                setColor(sib, NodeColor.BLACK);
                setColor(parentOf(x), NodeColor.RED);
                rotateLeft(parentOf(x));
                sib = rightOf(parentOf(x));
            }

            if ((colorOf(leftOf(sib))  == NodeColor.BLACK) &&
                (colorOf(rightOf(sib)) == NodeColor.BLACK))
            ... 

As you can see, the code is almost identical — except for indentation, node class name and syntax differences. 如您所见,代码几乎相同 - 除了缩进,节点类名和语法差异。

This is also true for other methods marked as /** From CLR */ . 对于标记为/** From CLR */其他方法也是如此。

However, the Java code does not seem to be fully auto-generated from the C# code, cf. 但是,Java代码似乎不是从C#代码完全自动生成的,参见 this comment in the Java code : Java代码中的这条评论

/**
 * Balancing operations.
 *
 * Implementations of rebalancings during insertion and deletion are
 * slightly different than the CLR version.  Rather than using dummy
 * nilnodes, we use a set of accessors that deal properly with null.  They
 * are used to avoid messiness surrounding nullness checks in the main
 * algorithms.
 */

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM