博客园_懒猪乐园

我也谈面试附赠一份题目

2011-03-04T09:25:00Z

小弟不才，只被面试过，从未面试过别人。所以想从被面试方的角度来谈谈，在我心中理想的面试应该是咋个样的。

前阵子lzprgmr同学，站在面试官的立场上谈了谈他的感受，见谈谈技术面试。里面写道：

首先，我觉得技术面试是需要讲究技巧的，不是随随便便拉一个技术不错的人就可以，因为面试的过程是双方相互交流的过程，你需要给对方营造一个轻松的气氛，并在不断的提问与回答的过程中，进行“合理的引导”，“适时的追问”与“正确的判断”

我非常赞成他的观点，面试官跟被面试的人无论如何都很难做到绝对的平等，面试官对题目准备充分，享有话语权，而且接受面试的人很容易也很普遍表现紧张，如果再遇到不太Nice的面试官，很容易搞坏心情，影响发挥。

面试的时候我比较乐意回答些开放式的问题，或者由浅入深的问题套问题的问题。有时候我们可能一上来没完全理解面试官的意图，缺失上下文，一时半会儿答不上来，如果这样就被一票否决的话，我觉得是有失公允的。如果面试官能够稍加提示，“合理的引导”，说不定就能答上来，说不定还有自己独特的见解。

面试官应该更多地考察对方想法，思路，而不是简单的考察那些知道/不知道很容易只有正反答案的问题。

比如：写一个Swap函数，不借助第三方变量。这个问题太考验技巧了，如果之前看过，自然不难，如果没有接触过想半天也很难答的上来。况且会跟不会都说明不了什么问题，我不清楚这样的问题意义何在。再说这道题在实际项目中一点意义也没有，我写逻辑简单，性能还不错的代码，也不愿意写羞涩难懂，标榜性能最大化的代码。有时候这么点性能的提升真的有必要吗？

以上我只是就事论事谈谈对这个问题的看法，如果作为面试题，我觉得无所谓，面试嘛什么都可以谈，不管是纯技术的，还是涉及到实际项目应用的，都可谈。但千万别一棒子打死人，答不上来就觉得对方能力不行。我到更喜欢，一开始答不上，适当给点提示后，对方很快就跟上节奏的人。

我享受如下的面试过程，LinkedList有用过吗？能简单说说跟List有什么区别吗？两者适用的场景是什么？他们各自的优势是什么，性能有什么不同，什么原因造成了性能的区别。。。

先抛出个简单的问题，然后”适时的追问”去挖掘更深层次的问题，最好能问及到对方恰巧未思考过，不熟悉的领域，加适当地提示。我觉得这个过程式相当考验人的，而且良莠应该很容易分辨。

我觉得：程序员的价值，不仅在于他懂得多少个知识点，更多的时候体现在于能不能融会贯通各个知识点，能不能做到举一反三。更重要的是在遇到困难，遇到新情况时所表现出来的特质，是如何思考问题的，能否从过去的经验中得到启发，并进行合理的变通，恰当地解决当下的问题。

最后引用我们CEO的一段话：

Innovation is rarely about the creation of something entirely new; in fact, it's about looking at things from a new perspective, and changing or combining them in ways that create new value.

老赵很大方，在博客上提前罗列了很多可能会考察的知识点，不怕应聘者做突击准备，“蒙混过关”：

我并不担心大家知道这些问题，而且我可以表示以后的面试估计也逃不开这些。如果您有某些意向，做些针对性的准备可能也是不错的。当然，既然是面试，就会有“随机应变”，你我都一样。我有自信可以在不断追问下发现到底是“真材实料”还是“临时抱佛脚”。

我特相信，一个优秀合格的面试官确实能够大致分辨出对方的水准。反过来，合格的程序员也应该能通过一次愉快的面试，大致了解到面试官的水准，自己是不是合适加入他们的Team。

@DeepNight同学在下面评论到: 其实仔细看了CLR via C#大多数的问题还是能答上来的。

我想如果你带着问题去看的话，确实都能找到答案。那对于上面未罗列的问题呢？问题背后的问题呢？你在看CLR via C#能够对所有的知识点，展开一番思考吗，多问几个问题吗？

《幸福课》里提到：很多事情一直都在那里，只是你没有问为什么，所以忽视了他们的存在。Question create realistic。这句话TTM令我震撼了！

小弟不才，简单罗列了下几个问题，希望能够引起一番思考如果你还不会的吧

.NET Quiz

下面两个函数签名有什么区别，能举例子详细说明下吗 private void Modify(string str){...} private void Modify(ref string str){...}

ref 和out 参数有什么区别，为什么要这样设计

Int? 是什么，什么是nullable类型，值类型 or 引用类型？怎么理解 int? I = null；为什么要引入Nullable类型

GetType() 方法有什么用，哪里定义的，子类可重写吗？ Int? i = 2； i.GetType() 返回的是什么类型，为什么，意义在哪里，怎么做到的？ Int? i = null； i.GetType() 为什么会异常，真的是i没有分配空间，没有初始化引起的吗？

泛型和delegate 有什么共通性，共同的理念是什么

什么是代码可读性，怎么看待可读性 VS 性能问题

怎么理解封装，就是为了屏蔽数据？能不能从更高的层面理解这个问题

Array 和 List 有什么区别； List 和 LinkedList 有什么区别；性能，应用场合？什么是deque（double ended queue）? 不知道的话没关系，面试官给出定义，特性，要求被面试者用现有的集合类实现一个deque吧

try { } finally {} finally 里的代码一定能保证执行吗？如果不能，什么情况下。 throw； throw ex；有什么区别，什么时候需要重新抛出自定义的异常

Assert 是什么，平时用的多吗，什么是防御式编程？方法检测时，传入的参数为空情况下，是用Assert 呢还是直接抛异常?

什么是面向过程编程，什么是面向对象编程，面向对象编程一定比

面向过程编程有意义吗？什么是面向组件开发，什么是AOP，什么是面向服务编程，他们有共性吗，他们的引入是为了解决什么样的问题？为什么历史是朝这个方向发展的，可以倒着来吗?

在主线程中进行计算密集型操作，这个时候UI能响应用户反应吗，如果要更新UI 怎么办？如果要用一个进度条实时反馈当前计算进度，应该怎么做？可以在其他线程进行如下操作吗? textBox.Text = "Name"; 为什么？为什么有这个限制？ textBox.BeginInvoke( action) 做了什么事.

有人说：软件开发中所有的问题，都可以引用中间层解决。你怎么理解？举些例子吧。

IL 是什么，引入的理念是什么？什么时候IL才会被编译成native代码。下面两段代码有什么区别

// 代码 1：

static void Main(string[] args)
{
   Console.WriteLine("Start In main");
   A a = new A();
   Console.WriteLine("End In main");
}

//  代码 2：
static void Main(string[] args)
{
    Console.WriteLine("Start In main");
    SimpleWrap();
    Console.WriteLine("End In main");
}

void SimpleWrap()
{
   A a = new A();
}

如果class A是定义在另一个工程里，运行的时候凑巧A所在的dll不在应用程序目录下，会发生什么，两者输出有不同吗?

ICloneable是什么，什么是浅克隆，什么深克隆，如何实现深克隆，原理是什么，你怎么理解。如果下面函数是一事件响应函数链上一环，应该注意什么: (提示： const 应该明白我想问什么了吧)

private void OnPreSelected（ObjectPath path)
{
    // Setp 1: check valid path
    path.PopTo(...)
    if (path == ...)
    ...
}

附加题：一个计算密集型操作，我不想使用多线程，又希望同步进度条，可以做到吗？如何做到？(提示：消息泵， .NET 3.5）（如果有人能顺畅答上这道题，我觉得可以加50分：））

Sunday, June 26, 2011:

下面2段代码有什么区别：

public void FireMouseMove()
{
   if (mMouseMove != null)
       mMouseMove(this, 10);
}

public void FireMouseMove()
{
   var tempCopy = mMouseMove;
   if (tempCopy != null)
       tempCopy (this, 10);
}

Level 2: 什么是线程栈？

本文链接

败给了IEqualityComparer

2010-11-22T01:36:00Z

LINQ中的Distinct方法能够帮助我们轻松地剔除集合里面相同的元素。它提供了2个重载函数，其中一个允许我们传入IEqualityComparer<T> 接口，给我们充分的自由来决定2个元素是否相同。

为了实现剔除一堆string集合中相同的string，我写下了如下的代码。 注：不区分大小写

source.Distinct(new StringComparer());

internal class StringComparer : IEqualityComparer<string>
{
    public bool Equals(string x, string y)
    {
        return string.Compare(x, y, true) == 0;
    }

    public int GetHashCode(string obj)
    {
        return obj.GetHashCode();
    }
}

结果调试的时候始终不对，结果始终不能剔除那些只是大小写有区别的字符串，如"good” 跟"Good”.

当时因为时间紧张，就先提交了，事后发现原来还是自己不严谨，败给了GetHashCode()方法。

印象中自己没怎么实现过IEqualityComparer，到实现过多次的IComparer接口。在上面的例子中虽然我意识到在比较的时候忽略大小写，但是再实现GetHashCode(), 随手地用了上面的方式。

问题就在这，既然我们认为"good” 跟"Good”是一样的，那么我们必须给他俩返回一样的hash code，但显然以我上面实现方式它俩返回的hash code是不一样的。

在鄙人的《避免陷阱，重现Equals方法您需要注意的其中2个原则》与《Just Reflect 》中，其实我是多次提到了这个问题，想不到这次还是马失前蹄了，罪过啊。

所以正确的写法应该是:

public int GetHashCode(string obj)
    {
        return obj.ToUpper().GetHashCode();
    }

扩充话题: 既然第一次写法返回的结果不正确，这就能说明Distinct扩展方法是先调用GetHashCode(), 再调用Equals(). 因为如果是先调用Equals()方面，理论上"good” 跟"Good” 是能剔除一个的。问题是为什么要先调用GetHashCode()，或则换种说法是为什么Distinct方法接受IEqualityComparer接口，而不是IComparer接口。因为判定2个对象是否相同，只需调用Equals() 方法就好。或者说因为 ICompare接口返回的是int，而不是直接的bool类型吗？那为啥不是IEquatable呢?

调试Framework的源代码，可以发现如下踪迹：

static IEnumerable<TSource> DistinctIterator<TSource>(IEnumerable<TSource> source, IEqualityComparer<TSource> comparer) {
    Set<TSource> set = new Set<TSource>(comparer);
    foreach (TSource element in source)
        if (set.Add(element)) yield return element;
}

也就是说Distinct执行时在遍历集合的时候，是把那些非重复的元素放在了Set容器里，而非普通的List，这样的好处是因为Set是一个HashTable结构的容器类，可以提高执行效率。我们知道在HashTable里找一个元素的间复杂度为O(1). 而在List里查找的效率却是O(n)。

因此将Distinct方法接受IEqualityComparer接口，是很有必要的，目前按照它的实现方式时间复杂度为O(n)。而如果改为传IEquatable接口，那么时间复杂度就得变为O(n2).

本文链接

标注随测量物体旋转问题

2010-11-20T08:27:00Z

假设我们对如下Block中的红色线段做了标注，那么这个标注的两个锚点(Anchor Point)分别为红色线段的2个端点

当我们旋转这个Block后，我们自然希望这个标注也跟着物体旋转的，调整到如下合理的位置，

现在的问题是如何为这个标注求得变换矩阵。

一开始我以为只要根据红色初始位置，跟终止位置，求得它的变换矩阵，再作用到标注上就可以了。但是结果下来，发现自己想简单了。在上面第二张图中，用户可以继续绕着红色线段，旋转Block，比如得到下面的形状：

我们发现实际上第二张图跟第三张图中红色线段对应的向量是一样的,那么计算出来的变换矩阵肯定跟第二张图一样，得到的一定是下面这个错误的结果：

正确的结果应该如下：

这个问题的本质原因在于： 一条直线不能决定平面。 那么2点不能决定平面，三点总归可以了吧。关键问题就是第三个点怎么选取。这个第三个点必须相对红色线段是稳定的，那么当Block旋转后，我们依然能够找回来。于是想到了求这个Block的中心点，而后构建一个平面，根据这个平面前后位置，求得变化矩阵，问题就得以解决了。

原始矩阵：

Vector3d vecX = (p2 - p1).Normal();
Vector3d refVec = (centerPoint - p1).Mormal();
Vector3d vecZ = vecX.CrossProduct(refVec);
Vector3d vecY = vecX.CrossProduct(vecZ);
Matrix3d m0 = new Matrix3d();
m0.SetCoordinateSystem(p1, vecX, vecY, vecZ); // orignal transform

新的矩阵：

Vector3d vecX' = (p2' - p1').Normal();
Vector3d refVec' = (centerPoint' - p1').Mormal();
Vector3d vecZ' = vecX'.CrossProduct(refVec');
Vector3d vecY' = vecX'.CrossProduct(vecZ');
Matrix3d m1 = new Matrix3d();
m1.SetCoordinateSystem(p1', vecX', vecY', vecZ'); // new transform

变换矩阵：

Matrix3d transform = m1 * (m0.Invert());

本文链接

How to detect memory leak issue

2010-11-20T07:27:00Z

首先,托管代码由GC自动回收，不代表托管应用程序就没有内存泄露问题

其次, 程序不总是精确知道哪些托管对象是垃圾，这就代表着没有一款工具，一运行就能给你一个报表，说某某对象没回收，某某地方发生了内存泄露。

再次, 工具只能dump出当前应用程序的内存快照，有没有内存泄露还需要你敏锐的眼光。比如说下面的例子，当某个文档被关闭后，这个文档对象及其它引用的资源依然包含在Dump的内存快照中，我们就可推断出此处有内存泄露。

Tool:

I used the .Net Memory Profiler tool to investigate this issue. You can get a fully functional 14 day trial version form here, and there are some training stuff list here.

Suggestion:

· If any plug-in listen system events which will adds into EventManager (Application level object), please make sure remove the handlers before closing document.

· Avoid implement empty destructors in C#, try to implement IDisposable interface to dispose unmanaged and managed resource in Dispose method, or use dispose pattern. if any incorrect place, please correct me.

(In book of “CLR VIA C#” chapter 20, page 477, Jeffrey Richter mentioned: “the CLR doesn't make any guarantees as to the order in which Finalize methods are called, so you should avoid writing a Finalize method that accesses other objects whose type defines a Finalize method; those other objects could have been finalized already. )

Now, please refer to the following explanation why we need to notice those.

Diagnosis:

To make it more clear, I add two commands in Windows class , this will force GC to collect garbage:

Next, run the application, create a default document , then close the document. Run the .Net Memory Profiler tool, and attach it to the application process, then execute “Collect heap Snapshot” command. Now, Profiler will analyze the memory of the application. This process is very slow, in the end, we can see the following snapshot:

Filter the Namespace to select the namespace - “xxx.xxx.xxx.xxx.Documents.Objects”, we can see there is still a copied IllustrationDocument object. However, we expect it should be 0. This tells us the IllustrationDocument object don’t be disposed successfully.

Double click the IllustrationDocument row, we can get this instance’s details information that also includes its reference

Now we found there are 19 references. But some references have no problems like Asset, because the asset object’s lifecycle is in the scope of document’s lifecycle. Check the “Only show instance included in root paths” checkbox, it will filter the references, and only show the instances included in root paths. Those references are the really killers who caused to the IllustrationDocument object couldn’t be disposed successfully:

(The row which mark up by red rectangle is caused by the Renderer class, which forgot to remove system events handler in its dispose method)

Double click the highlight row in the above figure, we can look over which objects have references to ShotEditor instance:

Go on (double click the highlight row in above figure), then refer to the following:

Go on…, finally we get the following figure:

Reason: The CameraEvents has been added into EventManger class whose lifecycle is global. Any class who listens camera’s events, will cause it still keep to live, so the CLR could not mark them as garbage. This is the real reason for that we could not dispose document object successfully.

Solution:

Let’s have a look at CtxMenuForm source code, we will find it listens the OnCameraEventChange event in its construction, but forget to remove this event handler.

So let’s do some changes for it, implement the IDisposable interface:

Then call form’s dispose method in someplace before close the document :

Collect the Application memory snapshot again following above steps, we will found the root references count reduce from 4 to 3, has no referenced by ShotEditor.

The some problems also exist in Renderer class and some UI class, after I do some changes for those class, remove all listened events handlers before close document, I finally remove all the root references to IllustrationDocument object, but there is still a copied IllustrationDocument object. I don’t know what’s wrong, then I refer it to MSDN, and got the following infomation:

Implementing Finalize methods or destructors can have a negative impact on performance and you should avoid using them unnecessarily. Reclaiming the memory used by objects with Finalize methods requires at least two garbage collections.

You can get more information from here.

So, I modify the Windows class, try to call GC.Collect method more than twice, run the Application application, close the default document, collect its memory snapshot, the result is there is still a copied IllustrationDocument object. I am confused! Then I turn to write a small test application, it works as MSDN said. So what’s wrong?

After some struggle, I build a release version, then I found the document can complete dispose successfully. Refer to the following figure:

Hope it helps.

本文链接

图纸中角度标注算法

2010-11-18T13:58:00Z

两条非平行线段，如何合理的标注角度。比方说对于下面2条初始线段：

根据当前鼠标所在位置的不同，我们可能得到如下不同的标注方式：

本人求标注的思路大体思路是：首先求出圆弧（Dimension Line）的两个端点, 然后根据这两个已求得的端点，分别计算出两条引线（Witness Line）的端点。

求圆弧端点的算法：

我们把问题简化下，对于任意2条相交的射线，以下均以锐角为例(钝角求解过程完全一致)：
以2线段所在直线交点作为圆心，鼠标位置到圆心的距离为半径，画一个圆，2条直线与圆必有4个交点，而Dimension Line的2个端点必然为这4个交点中的两个。

问题是我们如何从这4个交点中，选取其中的2个点作为Dimension Line的端点。
方法如下：我们把上面图中的红色实心向量和蓝色实心向量，作为2个参考向量，将图切分为如下4个象限：

然后根据当前的鼠标位置，决定出应该取那个象限，做法是记 value = (红色向量 X 橙色向量) . (橙色向量 X 蓝色向量)
如果得到的value值大于0，则当前鼠标必定落在一三象限，否则则在二四象限

接下来就是如何精确点位到鼠标是在一象限呢，还是在三象限。本人想到了用角度去推测，相信应该有更高效便捷的算法存在，只是目前自己没想到。
观察上图我们可以发现：假设当前鼠标在第三象限，那么橙色向量分别到两参考向量（红色实心向量和蓝色实心向量）的角度之和必然大于 180°，如果求得角度和小于180°就可断定为第一象限。(此方法钝角也依然适用，考虑下当前鼠标在上图二象限，以红色虚线向量以及蓝色实线向量作为参考向量)

算法实现如下，思路大体跟上面一致，仅做了点优化：
1  private void GetDimensionLineEndPoints(LineSeg3d firstSeg3d, LineSeg3d secondSeg3d, Point3d thirdPt, out Point3d firstCrossPt, out Point3d secondCrossPt)
2  {
3      Point3d centerPoint = GetIntersectPoint(firstSeg3d, secondSeg3d);
4      double radius = thirdPt.DistanceTo(centerPoint);
5
6      Vector3d firstLineVec = (firstSeg3d.EndPoint - centerPoint).Normal();
7      Vector3d secondLineVec = (secondSeg3d.EndPoint - centerPoint).Normal();
8      Vector3d thirdLineVec = (thirdPt - centerPoint).Normal();
9
10      if ((firstLineVec.CrossProduct(thirdLineVec)).DotProduct(thirdLineVec.CrossProduct(secondLineVec)) < 0)
11          secondLineVec = -secondLineVec;
12
13      if ((thirdLineVec.AngleTo(firstLineVec) + thirdLineVec.AngleTo(secondLineVec)) > Math.PI)
14      {
15          firstLineVec = -firstLineVec;
16          secondLineVec = -secondLineVec;
17      }
18
19      firstCrossPt = centerPoint + firstLineVec * radius;
20      secondCrossPt = centerPoint + secondLineVec * radius;
21  }
22

求引线端点的算法：

Witness Line的2个端点为上述4个点中的两个，组合方式取决于绿色圈圈相对于其他3个点的位置，目前本人想到的方案不是很理想，看看明天能不能想到更方便简单的算法来描述，敬请等待明天的更新。

如果大家有更好的标注算法，请不吝指教！
本文链接

认真的程序员最可爱

2010-08-20T10:07:00Z

记录一段小经历，当我们嗅觉到一段有问题的代码时，仔细研究下会有不错的发现。

经验总结：当我们跟IntPtr打交道时一定要小心谨慎，谨防GDI泄漏

Yesterday, I noticed that someimage resources in Annotation project are not defined as static, the clientdirectly access by “Properties.Resources…”.

As far as I know is, in original we have a ‘rule’ that theimage resource should defined as static in order to defense GDI leak. (I’m notsure about this, because I could not find out the related mail now.)

So, I test the annotation ribbon, and found there does existGDI leak problem. If we change the callout shape type or toggle “Keep On Top”check box continuously, the GDI increased shapely, when it reach to 9999,the Application crashed. Please refer to 【...】.

Jerry has helped me located the key problem, that inAnimatedBusyCursor.cs class, line 66, it create a Cursor by IntPtr, but neverdestroy it. Thanks, Jerry, it’s a amazing found.

I have downloaded his code and tested, it works well. Allthe increased GDI object can be decrease now. So I’m not sure if we still needdefined the image resource as static. In 【...】, I does defined the image resource as static. Please help me toreview it. If you don’t mind, I want to check in those code. Any problem,please let me know.

(It is strange to me that why it is ok now we directlyuse the image resource. I guess it may related to the some Contextual Ribbonchanges. In early time, the contextual ribbon for annotation can have severalcopies at the same time, it will created a copy when show annotation’scontextual ribbon, and never released. So if we don’t defined the imageas static, it may reference more than once by the ribbon control, so the GDIincreased. Since, currently this problem has been solved, there is only onecopy contextual ribbon, so maybe directly access the image is ok. I’m not sure,just guessingJ)

本文链接

Clean Code反案例：什么是不好的API

2010-08-11T10:47:00Z

先来看两段代码：

CI.cs:

  public BoundBlock3d meshOrthoBoundBlock(Matrix3d localToBound)
  {
      Matrix3d xfrm = localToBound * this.ChildToParentTransform;
            return this.Child.meshOrthoBoundBlock(xfrm);
  }

CD.cs

public BoundBlock3d meshOrthoBoundBlock(Matrix3d localToBound)
{
    BoundBlock3d rv = new BoundBlock3d();
    Matrix3d mtx = localToBound * this.ScalingTransform;
    foreach (ComponentInstance ci in this.ReferencedComponentInstances)
    {
        rv.orthoExtend(ci.meshOrthoBoundBlock(mtx));
    }

    rv.orthoExtend(this.Body.GetOrthoBoundingBlock(mtx));

     return rv;
}
类之间的简单关系： CD中包含了CI的几何信息

大家可以先看看，仔细想想，如果你一眼看出了问题，那么很是佩服你，你相当的厉害！
------------------------------------------------- 华丽的分割线 -------------------------------------------------
上面这段代码问题有二：

一：两个方法的修饰符都是public。
这个叫引诱他人犯罪，因为当外面Client调用CI::meshOrthoBoundBlock(), 你得的结果是错误的，而且很多情况下你还不一定能注意到, 因为它多乘了CI自身的ChildToParentTransform。你注意到了吗？如果没有理解我说的话，你只需要再研究研究CD里的逻辑。
改进的方法是: 将CI里的public修饰符改成internal，这样就能防止外面调用CI:meshOrthoBoundBlock(), 他们才会意识到应该调用CD里的方法。

二：Client调用CD::meshOrthoBoundBlock()，得传什么参数好呢？
搜索下可以发现Client都是这么调用的 cd.meshOrthoBoundBlock(Matrix3d.Identity). Oh, shit! 大哥，我怎么知道要传入一个标准矩阵进去啊，即使大家都知道了这个潜规则，这样的接口设计就是脱裤子放屁，多此一举。
改进的方法是：封装一个不带参数的方法供外部调用，并把原先的方法访问修饰符改为internal。

问题一二的引入，我们发现实际上都是为了实现CD中递归计算。第一个问题看似小问题，却是很需要讲究的，我们必须时刻注意到封装，尽可以封装一切。对于修饰符的选择，必须使用最严格的，千万不要滥用public。
下面是我重构后代码，欢迎指正：

CI.cs:
重构后的CI
public BoundBlock3d MeshOrthoBoundBlock()
{
    return MeshOrthoBoundBlock(Matrix3d.Identity);
}

private BoundBlock3d MeshOrthoBoundBlock(Matrix3d localToBound)
{
     BoundBlock3d bounds = new BoundBlock3d();
     Matrix3d mtx = localToBound * this.Child.ScalingTransform;

     foreach (CI childCI in this.Child.ReferencedCIs)
       bounds.orthoExtend(MeshOrthoBoundBlock(mtx * childCI.ChildToParentTransform));

     // Calculate self bounds
     bounds.orthoExtend(activeBody.GetOrthoBoundingBlock(mtx));

     return bounds;
}

CD.cs:
   移去meshOrthoBoundBlock方法
大家可以看到为了避免Client传不必要的Matrix3d.Identity，我在外面多包装了一层。现在对于外面来说会清净很多，没有混乱的API， Client应该不用头大了。

本文链接

避免陷阱，重写Equals方法您需要注意的其中2个原则

2009-10-19T09:01:00Z

相信大部分熟读过《CLR Via C#》一书的人应该明白文字代码问题出在哪里，因为道理都在那本书里摆着。至于我为什么写此文重谈一遍，一个是因为读书归读书，碰到实际情况时就不见得也能保持冷静明白个所以然，能够避免踩此陷阱；二则我也很难理解我们的架构师为什么会犯此错误，是故意的呢还是不够仔细踩了地雷。于是写此文记录一下，以免今后自己犯此错误。各位有则改之，无则加勉

What’s the problems with the following code

2009-10-14T08:43:00Z

以下代码源自于真实项目，本人只是做了一点简化，大家来找碴，看看哪些地方不妥:-)

对象池

2009-10-09T08:19:00Z

[代码]

博客园_懒猪乐园

我也谈面试 附赠一份题目

败给了IEqualityComparer

标注随测量物体旋转问题

How to detect memory leak issue

图纸中角度标注算法

认真的程序员最可爱

Clean Code反案例：什么是不好的API

避免陷阱，重写Equals方法您需要注意的其中2个原则

What’s the problems with the following code

对象池

我也谈面试附赠一份题目