7月17號去的UTS軟件部門面試，至今已半月，很想把心得寫出來大家共享，今天終於抽出空來了。
一ile和link哪個先哪個後，生成文件的格式分別是什麼？.
二.字符串比較是哪個函數,兩個串比較後大於和小於的返回值分別是什麼？
原型：extern int strcmp(char *s1,char * s2);
用法：#include <string.h> 功能：比較字符串s1和s2。
說明： 當s1<s2時，返回值<0
當s1=s2時，返回值=0
當s1>s2時，返回值>0
舉例： // strcmp.c
#include <syslib.h>
#include <string.h>
main()
{
char *s1="Hello, Programmers!";
char *s2="Hello, programmers!";
int r;
clrscr();
r=strcmp(s1,s2);
if(!r)
printf("s1 and s2 are identical");
else
if(r<0)
printf("s1 less than s2");
else
printf("s1 greater than s2");
getchar();
return 0;
}
三.在用VC編譯時debug和release兩種編譯指令有啥區別？
relese版和debug不同在於:
debug版使用於調試的,它關閉了大多數代碼優化,並回自動初始化開闢出來的內存(置爲0xcc),並攜帶調試信息,但是執行起來比較慢。
release版是最終給客戶的,開啓了代碼優化,不會自動初始化內存,一般不攜帶調試信息執行比較快。
debug和release還有一個區別，呵呵，編譯成的exe，dll，lib文件的大小差太多了。
如果debug下正確,release版本出錯，原因可能很多，畢竟debug多做了很多事。建議你用寫log到文件的方法除錯。
常見問題:
1.變量未初始化。
下面的程序在debug中運行的很好。
thing *search(thing , *something)
{
BOOL found;
for(int i = 0; i < ize(); i++)
{
if(whatever->field == something->field)
{ /* found it */
found = TRUE;
break;
} /* found it */
}
if(found)
return whatever;
else
return NULL;
}
而在release中卻不行，因爲debug中會自動給變量初始化found=FALSE,而在release版中則不會。所以儘可能的給變量、類或結構初始化。
2. 數據溢出的問題
如：char buffer[10];
int counter;
lstrcpy(buffer, "abcdefghik");
在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什麼問題也沒有。但是在release版中，counter可能被放在寄存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函數的返回地址，這將導致ACCESS ERROR。
3. DEBUG版和RELEASE版的內存分配方式是不同的。
如果你在DEBUG版中申請 ele爲 6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes（debug版以32bytes爲單位分配），而在release版，分配給你的就是24bytes（release版以8bytes爲單位），所以在debug版中如果你寫ele[6],可能不會有什麼問題，而在release版中，就有ACCESS VIOLATE。
四.野指針的問題：
在指針P用完後執行了一句free(p);爲什麼還要加一句 p=null; ?
“野指針”不是NULL指針，是指向“垃圾”內存的指針。人們一般不會錯用NULL指針，因爲用if語句很容易判斷。但是“野指針”是很危險的，if語句對它不起作用。野指針的成因主要有兩種：
1、指針變量沒有被初始化。任何指針變量剛被創建時不會自動成爲NULL指針，它的缺省值是隨機的，它會亂指一氣。所以，指針變量在創建的同時應當被初始化，要麼將指針設置爲NULL，要麼讓它指向合法的內存。
2、指針p被free或者delete之後，沒有置爲NULL，讓人誤以爲p是個合法的指針。別看free和delete的名字惡狠狠的（尤其是delete），它們只是把指針所指的內存給釋放掉，但並沒有把指針本身幹掉。
通常避免野指針的辦法是正確的使用指針:
1.聲明一個pointer的時候注意初始化爲null
int* pInt = NULL;
2.分配完內存以後注意ASSERT
pInt = new int[num];
ASSERT(pInt != NULL);
3.刪除時候注意用對操作符
對於new int類型的，用delete
對於new int[]類型的，用delete []
4.刪除完畢以後記得給他null地址
delete [] pInt;
pInt = NULL;
5.記住，誰分配的誰回收，不要再一個函數裏面分配local pointer，送到另外一個函數去delete
6.返回local address是非常危險的，如必須這樣做，請寫註釋到程序裏面，免得忘記
五.最後一個問題，也是壓死我這個駱駝的最後一根稻草：二分查找法的程序能不能上機寫出來？
看到題目我第一反應是：太簡單了吧，這樣子搞那我豈不是想不留在這裏做事都很難了，簡直不給我選擇的機會嘛，於是我很爽快的答應了，2分鐘之內寫出程序，要知道我面試前做了三天的準備，這個程序可是譚浩強的書中最經典的程序之一，我背都背下來了。
bool binary_search(int* arr, int key, int n)
{
int low = 0;
int high = n - 1;
int mid;
while (low <= high)
{
mid = (high + low) / 2;
if (arr[mid] > k)
high = mid - 1;
else if (arr[mid] < k)
low = mid + 1;
else
return ture;
}
return false;
}
面試經歷：
寫完程序後，我匆匆的試着執行了一下，看着屏幕上顯示的OK，心中揣着的那塊大石頭也就提前登陸了。 我叫來面官，原以爲他應該看兩眼就完事了，沒想到那傢伙居然鄭重其事的坐下來一板一眼的輸入一長串代碼去執行，看着屏幕上顯示的一行又一行"No Found!",我感覺有點不妙。
面官很和藹的讓我再調試下，就起身忙他的去了，而我在調試了3，4分鐘後還是沒有找到問題的情況下徹底傻眼了，我根本就沒做這個預案，而且我敢對天發誓，我寫的程序絕對和書上就差幾個字符不一樣。
就在這萬分危急的時刻，那傢伙居然跑過來站在我的身後假惺惺的做指點。他的一句：“你的“TURE”寫錯了！”基本上是扒掉了我身上的最後一塊遮羞布。我在把函數的返回值和變量定義改了幾個回合之後徹底繳械了。
但是我的繳械不是迫於他的淫威，而是出於我的過分自信。在我看來我已經表現的很好了（當時確實是這麼認爲的），因爲我以往寫的代碼，一調試往往都是幾十行的錯誤信息，今天寫的這段從第一遍調試起就一直沒有語法錯誤，我已經創造了歷史，更何況結果已經出來了，只是有那麼一點點小小的錯誤嘛，表現太完美了也不太好吧？？
然而我得到的卻是完全出乎意料的答覆，而且這個答覆來的那麼快。“很遺憾，我們不能錄用你！”，面官還是那麼和藹，而且還在後面加了一句我懷疑是出於安慰才說的話。“要是你這個程序調出來了可能我們就會錄用你了，但是我們畢竟有個標準。”
他在最後還是給了我一個理由，這個理由成了我此行最大的收穫，這個理由讓我至今都覺得我那次面試有重大意義。“其實程序是調出來的，不是寫出來的。我剛剛看了你調試的過程，你沒有使用斷點，也沒有使用單步運行，這些是程序調試最重要的手段。”
這個理由讓我輸的心服口服，讓我至今任仍有很多感觸。今天我願把我的感觸拿出來與大家分享：
1.學校和公司對我們的要求不一樣，評價的標準也不一樣。在學校，我上面的那段代碼可能是滿分，我也有過很多次這樣的經歷。紙上寫個程序，拿眼睛看看，沒有問題，交上去就完成任務了。但是在公司，他們只看你代碼執行的結果和執行效率，根本不關心你用多久寫出來，你寫的過程是一帆風順還是錯誤累累，只要結果和預期值不一樣，哪怕你的代碼和標準答案只差一個字符，也是白搭。其實，在哪以後的代碼編寫中我也很多次發現，程序沒法得到正確結果經常就是一個非常非常小的錯誤，小的可以忽略。
2.“紙上得來終須淺”，軟件學習，其實書看不看，看多少，根本沒那麼重要，重要的是自己能動手寫出來而且正確執行。在程序的調試過程中最好不要忽略任何一個細小的錯誤，一切以能否得到正確的執行結果爲唯一判斷準則。所謂的經典著作上的經典程序，很多時候執行起來是通不過的，不是我貶低那些個大師，而是程序是要結合一定的環境才能談論結果和效率的，不同的編譯工具對於代碼的執行影響很大。
3.要重視基礎，在斯達康之後，我還去過阿里巴巴和諾基亞西門子杭州研發中心（NSN）做筆試題，一個共同的特點都是很注重基礎，我事先着重準備過的鏈表的操作以及析構函數等等很多東西根本沒涉及到。都是基礎題目，只不過選取的考點都很獨特，都是平時容易被我們忽略的細節，所以不容小覷。很多人做完都覺得很簡單，知道面試名單裏面沒有自己時才清醒，因爲這種大公司筆試名單基本上都是完全按照筆試分數高低來確定的。
