月份：2011年7月

在”传智播客DotNet面试宝典(改).pdf“有这样一道非常有意思，也比较有深度的题目。

String s = new String(“xyz”);创建了多少个String实例？

传智的老师告诉同学们：答案是两个，一个是”xyz”，一个是指向”xyz”的引用对象。

貌似很正确，很有道理。没错，”xyz”是一个字符串，而DotNet字符串（其实Java也是）有驻留intern这样一种机制。

 

抱歉的是，传智的老师没有料到，问这个问题的同学或者是公司太坏了。这道题的题目是错的，答案也不对。

大家手头有visualstudio的可以建立一个console程序试试看，能不能编译通过？！

至于答案为什么也不对，看看这篇非常详细的解释吧，虽然作者解释的是针对Java语言。

http://www.iteye.com/topic/774673

为什么Java能这样写？因为Java有这种构造函数String(String original)而DotNet中的String类没有。

稍微修改让它能够编译

        static void Main(string[] args)         {             char[] chars = { 'w', 'o', 'r', 'd' };             String s2 = new String(chars);             String s3 = new String(chars);             int i = s2.Length;             int j = s3.Length;             Console.WriteLine(i + j);         }

如果我们用ILSpy看，结果如下，注意，其中只调用了两次newobj，分别是针对s2和s3。

 

.method private hidebysig static
void Main (
string[] args
    ) cil managed
{
// Method begins at RVA 0x2058
// Code size 57 (0x39)
.maxstack 3
.entrypoint
.locals init (
        [0] char[] chars,
        [1] string s2,
        [2] string s3,
        [3] int32 i,
        [4] int32 j
    )
    IL_0000: ldc.i4.4
    IL_0001: newarr [mscorlib]System.Char
    IL_0006: dup
    IL_0007: ldtoken field int64 ‘<PrivateImplementationDetails>{06FAE1C3-0E45-4AE7-A401-B8A7D1EFF5D6}’::’$$method0x6000001-1′
    IL_000c: call void [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class [mscorlib]System.Array, valuetype [mscorlib]System.RuntimeFieldHandle)
    IL_0011: stloc.0

    IL_0012: ldloc.0
    IL_0013: newobj instance void [mscorlib]System.String::.ctor(char[])
    IL_0018: stloc.1

    IL_0019: ldloc.0
    IL_001a: newobj instance void [mscorlib]System.String::.ctor(char[])
    IL_001f: stloc.2

    IL_0020: ldloc.1
    IL_0021: callvirt instance int32 [mscorlib]System.String::get_Length()
    IL_0026: stloc.3

    IL_0027: ldloc.2
    IL_0028: callvirt instance int32 [mscorlib]System.String::get_Length()
    IL_002d: stloc.s j

    IL_002f: ldloc.3
    IL_0030: ldloc.s j
    IL_0032: add
    IL_0033: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0038: ret
} // end of method Program::Main

我在推上发了一些牢骚，有些朋友来面试，基础不是很扎实，理由是自己一直做对日外包，没有机会提升自己，掌握一些基础内容。

另外一个理由是公司只用了某某技术，没有用某某技术，只用了2.0，所以我不知道3.5、4.0等等。

这都不是理由。

这都不是理由！

 

这时候我假设自己是一个对日外包企业的程序员，吃完饭后老婆在看电视，我拿起Thinkpad笔记本，登录进著名的MSDN，开始继续自我提升的步骤。

坚持每天抽出半小时到一小时学习，足够你提升自己的水平！

这次也不推荐书了，只要能上网，就每天看一段MSDN的文章或者代码。保证能提高自己！

 

首先要知道自己缺少什么，有一个评估很有意思也很容易评估自己需要提升哪些地方：《程序员能力矩阵》http://static.icybear.net/%5BCN%5DProgrammer%20competency%20matrix.htm 这里假定我想提升Windows平台上DotNet、CSharp开发。

这里有一系列链接可以学习，每天一篇或者几天一篇应该没问题。其实比较好的办法是买本书系统学习，但我这里想说的是，资料到处都是，书籍唾手可及。

 

没用心不努力才是水平差基础薄弱的最大原因！

 

下面的链接没有什么系统性，如果有一两年经验了，看这些东西问题不大。

http://msdn.microsoft.com/en-us/library/3bwa4xa9.aspx Using Objects That Encapsulate Resources

这一篇要着重提一下，很多四五年经验的C#开发者，不知道using关键字的这种用法，怎么说呢，说你不求甚解好呢？还是说你不够努力好呢？

 

http://msdn.microsoft.com/en-us/library/dd642420.aspx Visual Studio 2010 Visual Basic and Visual C#

http://msdn.microsoft.com/en-us/library/618ayhy6.aspx C# Reference

http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx C# Programming Guide

http://msdn.microsoft.com/en-us/library/dd460655.aspx Programming Concepts

http://msdn.microsoft.com/en-us/library/w0x726c2.aspx .NET Framework 4

http://msdn.microsoft.com/en-us/library/w0x726c2%28VS.90%29.aspx .NET Framework 3.5

http://msdn.microsoft.com/en-us/library/ff921347.aspx EnterpriseLibrary Unity MEF Prism这些概念，至少知道它们是什么

http://msdn.microsoft.com/zh-cn/magazine/default.aspx MSDN杂志

http://msdn.microsoft.com/en-us/library/orm-9780596516109-03.aspx C# 3.0 Cookbook, Third Edition: More than 250 solutions for C# 3.0 programmers

http://msdn.microsoft.com/en-us/library/orm-9780596527730-01.aspx C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems

 

http://msdn.microsoft.com/en-us/library/k5532s8a.aspx .NET Framework 4 CLR Managed Execution Process

http://msdn.microsoft.com/en-us/library/f144e03t.aspx Automatic Memory Management （GC）

http://msdn.microsoft.com/en-us/library/ee787088.aspx Fundamentals of Garbage Collection

http://msdn.microsoft.com/en-us/library/ms404247.aspx Weak References

http://msdn.microsoft.com/en-us/library/ms172334.aspx Reflection and Generic Types

http://msdn.microsoft.com/en-us/library/a4a92379.aspx Accessing Custom Attributes

http://msdn.microsoft.com/en-us/library/ff519622.aspx Observer Design Pattern Best Practices

http://msdn.microsoft.com/en-us/library/sd10k43k.aspx Interoperating with Unmanaged Code

http://msdn.microsoft.com/en-us/library/hyz69czz.aspx Managed Threading Basics

http://msdn.microsoft.com/en-us/library/ms973850.aspx Microsoft .NET Framework FAQ

http://msdn.microsoft.com/en-us/library/ms973837.aspx Garbage Collector Basics and Performance Hints

http://msdn.microsoft.com/en-us/library/bb985748.aspx Displaying Metadata in .NET EXEs with MetaViewer

http://msdn.microsoft.com/en-us/library/ms973858.aspx Writing High-Performance Managed Applications : A Primer

http://msdn.microsoft.com/en-us/magazine/cc164086.aspx Implementing Coroutines for .NET by Wrapping the Unmanaged Fiber API

http://msdn.microsoft.com/en-us/library/aa479866.aspx Generics FAQ: .NET Framework

http://msdn.microsoft.com/en-us/library/aa479858.aspx Generics FAQ: Best Practices

http://msdn.microsoft.com/en-us/library/aa479859.aspx Generics FAQ: Fundamentals

http://msdn.microsoft.com/en-us/library/aa302329.aspx Improving String Handling Performance in .NET Framework Applications

http://msdn.microsoft.com/en-us/library/ms973880.aspx The Microsoft Shared Source CLI Implementation Refresh

http://msdn.microsoft.com/en-us/library/bb985613.aspx Migrating Native Code to the .NET CLR

http://msdn.microsoft.com/en-us/magazine/cc164123.aspx Calling Win32 DLLs in C# with P/Invoke

http://msdn.microsoft.com/en-us/magazine/cc164139.aspx The CLR’s Thread Pool

http://msdn.microsoft.com/en-us/magazine/cc164094.aspx Introducing Generics in the CLR

http://msdn.microsoft.com/en-us/library/ms973893.aspx Object Serialization in the .NET Framework

http://msdn.microsoft.com/en-us/library/ms973872.aspx An Overview of Managed/Unmanaged Code Interoperability

http://msdn.microsoft.com/en-us/library/ms973838.aspx Performance Considerations for Run-Time Technologies in the .NET Framework

http://msdn.microsoft.com/en-us/library/ms973839.aspx Performance Tips and Tricks in .NET Applications

http://msdn.microsoft.com/en-us/library/aa302338.aspx Primary Interop Assemblies (PIAs)

http://msdn.microsoft.com/en-us/library/bb264782.aspx Profiler Stack Walking in the .NET Framework 2.0: Basics and Beyond

http://msdn.microsoft.com/en-us/library/aa302324.aspx Using the .NET Framework SDK Interoperability Tools

http://msdn.microsoft.com/en-us/library/ms973826.aspx Using the ECMA Standards: An Interview with Miguel de Icaza

博客园cnblogs不知为何最近开始渐有C语言开发重启的迹象，不少人开始写一些C语言的教程。

其中看到一段有趣的留言，提到这个写法：if (p == NULL)，

有人说这是不好的~，经典不提倡的~，会写错出问题的~，华为都禁止的~。

 

我倒是有些不同的看法。

 

首先这种写法是有问题，一般来讲对于空指针可以这样写

if ( p )

或者反义是这样 if ( !p )

既简单，还节省字数。

 

如果是想写的比较容易懂，那么if (p == NULL) 是我提倡的方式。

你可以很简单的读成“如果p等于空值”，反过来的方式NULL==p就有些别扭，不是给人看的。

 

有人提到p==NULL很容易写成p=NULL，代码出错啦！会有bug啦！

 

好吧，我承认这是一种可能性，在早期编译器不完善的时候的确如此。那时候还提倡用匈牙利命名法，因为编译器对类型识别支持不好，很容易写出胡乱转型的代码（当然现在的C语言也容易）。但是针对正在使用的编译器以及将来更先进的编译器，在条件判断中使用p==NULL不是问题。

 

做一个很简单的实验，使用VC2010，项目设置为compile as C，注意关键一点“把warning级别提高到最高级别4”，这时候if (p=NULL )会得到如下警告：

1>purec.cpp(10): warning C4706: assignment within conditional expression

很简单吧，不需要你使用那种反人类常识的代码规范。

 

使用GCC（v4.5.2 in Ubuntu11.4）也很容易，它有一个编译选项-Wall，警告信息如下：

/home/sun/foobar-sample/main.c:24:2: warning: suggest parentheses around assignment used as truth value

 

如果工具支持，为何不使用一种更为合乎阅读习惯的方式呢，BTW，我查找了一下经典的K&R，其中==的使用都是我提到的p==0这种方式，其它更为经典的（有么？）我就不知道了。

Python程序员很幸福，因为他们不需要像C#程序员那样东一榔头西一棒子的找资源学习。

把下面资源按顺序学完，代码都自己手敲过，应该就是初级以上水平了。

http://docs.python.org/py3k/tutorial/

之所以选择py3k，是感觉新版本的生命力应该更长久一些。

 

学完tutorial，再看看这个Python竞赛，花个一两周时间搞定它。

http://www.pythonchallenge.com/

 

最后看看这本书，了解一些有趣的话题

http://product.china-pub.com/195771

 

如果有问题，搜索一下“python cookbook”或者到google新闻组python.cn发文都应该很快得到答案（只要你问的靠谱）

https://groups.google.com/forum/#!forum/python-cn

 

简单吧，Python就是这么简洁明朗！