1. run time和compile time的區別
run time即運行時.
解釋:
程序"運行時"即是程序被編譯了之後,打開程序並運行它直到程序關閉退出這段時間.經常說到的"運行時錯誤",即是指程序在打開並執行裡面的代碼時發生的錯誤.
造成運行時錯誤的原因有很多,不過大多數是因為程序在最初設計時的代碼沒有寫正確而留下的隱患.比如說下面的代碼,能通過編譯(編譯時),但在運行時會出現錯誤.
int * p;
p=NULL;
*p = 123;
上面的*p = 123;這一句會發生運行時錯誤,但編譯時卻不會發生錯誤.因為上面的代碼沒有任何語法錯誤,所以在編譯時不會發生任何錯誤;但在運行時,由於p為一指向地址零的指針,當向地址零進行寫操作時,由於地址零受操作系統保護,所以會發生一個運行時的內存非法訪問的錯誤.在WINDOWS下面,並不是所有的4GB的地址空間我們都可以進行訪問.有很多地址是被操作系統保護的.
compile time即為編譯時:
解釋:
准確的說編譯時是指我們寫好的源代碼在被編譯成為目標文件(OBJ)這段時間.但我們可以通俗的看成是我們寫好的源代碼在被轉換成為最終可執行的文件這段時間.
通常提到編譯時錯誤是指編譯器在將我們已經寫好的源代碼,轉換成為目標文件時發生的錯誤,這類錯誤大多是語法錯誤,也即是我們沒有按照編譯器能夠認識的格式書寫源代碼造成的.如下面的代碼會發和編譯時錯誤:
int a;
a = NULL
*a = 1000;
其中a=NULL這一句將發生編譯時錯誤,原因是由於這一句少了一個分號;編譯器無法理解這一句的意思,所以就會發生編譯時錯誤了.
2. c語言,編譯器上調試沒有問題,但是為什麼提交時顯示runtime error
int b[n];這句代碼不對
int *b;
然後動態分配 b = malloc(n * sizeof(int));
3. 用CODE IDE編譯runtime時說64bit的vs,沒找到這個版本,怎麼解決
你應該確認一下,你是否安裝了 C 編譯器,因為 Code::blocks需要手動安裝編譯器,一般是由官方提供MinGW(完整安裝包中有這個)。\r\n檢查一下是否安裝了Mingw ,如果安裝了就檢查安裝目錄(例如 ..\CodeBlocks\MinGW\bin )下的文件:\r\nmingw32-gcc.exe (C的編譯器)\r\ngdb.exe(調試器)\r\nwindres.exe(資源文件編譯器)\r\nmingw32-make.exe (製作程序)\r\n然後再檢查設置,將編譯器設置為 GCC ,再關聯到 Mingw 安裝目錄(例如 ..\CodeBlocks\MinGW),組件列表如上對號入座。\r\n還有是不是 C::B 和 Visual Studio 2005\\/2008 一樣,編譯前要先建立工程?\r\n一般程序面板上會有錯誤提示,可以按照提示解決。具體使用參考官方 wiki 。\r\n其實如果是新手,那一定使用的是標准C,對目標程序也沒有什麼特殊要求,完全可以使用 其他編譯環境,比如 Visual C++ 6.0,使用也很方便。當然如果一定要使用開源軟體,那也可以使用 DEV C++ ,它同樣也使用 GCC或 Mingw 編譯器。
4. nvidia/cuda 公開源中的devel和runtime有什麼區別
從很多方面來看,CUDA和OpenCL的關系都和DirectX與OpenGL的關系很相像。如同DirectX和OpenGL一樣,CUDA和OpenCL中,前者是配備完整工具包、針對單一供應商(NVIDIA)的成熟的開發平台,後者是一個開放的標准。
雖然兩者抱著相同的目標:通用並行計算。但是CUDA僅僅能夠在NVIDIA的GPU硬體上運行,而OpenCL的目標是面向任何一種Massively Parallel Processor,期望能夠對不同種類的硬體給出一個相同的編程模型。由於這一根本區別,二者在很多方面都存在不同:
1)開發者友好程度。CUDA在這方面顯然受更多開發者青睞。原因在於其統一的開發套件(CUDA Toolkit, NVIDIA GPU Computing SDK以及NSight等等)、非常豐富的庫(cuFFT, cuBLAS, cuSPARSE, cuRAND, NPP, Thrust)以及NVCC(NVIDIA的CUDA編譯器)所具備的PTX(一種SSA中間表示,為不同的NVIDIA GPU設備提供一套統一的靜態ISA)代碼生成、離線編譯等更成熟的編譯器特性。相比之下,使用OpenCL進行開發,只有AMD對OpenCL的驅動相對成熟。
2)跨平台性和通用性。這一點上OpenCL佔有很大優勢(這也是很多National Laboratory使用OpenCL進行科學計算的最主要原因)。OpenCL支持包括ATI,NVIDIA,Intel,ARM在內的多類處理器,並能支持運行在CPU的並行代碼,同時還獨有Task-Parallel Execution Mode,能夠更好的支持Heterogeneous Computing。這一點是僅僅支持數據級並行並僅能在NVIDIA眾核處理器上運行的CUDA無法做到的。
3)市場佔有率。作為一個開放標准,缺少背後公司的推動,OpenCL顯然沒有占據通用並行計算的主流市場。NVIDIA則憑借CUDA在科學計算、生物、金融等領域的推廣牢牢把握著主流市場。再次想到OpenGL和DirectX的對比,不難發現公司推廣的高效和非盈利機構/標准委員會的低效(抑或謹慎,想想C++0x)。
很多開發者都認為,由於目前獨立顯卡市場的萎縮、新一代處理器架構(AMD的Graphics Core Next (GCN)、Intel的Sandy Bridge以及Ivy Bridge)以及新的SIMD編程模型(Intel的ISPC等)的出現,未來的通用並行計算市場會有很多不確定因素,CUDA和OpenCL都不是終點,我期待未來會有更好的並行編程模型的出現(當然也包括CUDA和OpenCL,如果它們能夠持續發展下去)。
5. ios 中runtime和runloop 的區別
一.RunLoop:
Runloop是事件接收和分發機制的一個實現。
Runloop提供了一種非同步執行代碼的機制,不能並行執行任務。
在主隊列中,Main RunLoop直接配合任務的執行,負責處理UI事件、定時器以及其他內核相關事件。
(1).RunLoop的主要目的:
保證程序執行的線程不會被系統終止。
(2).什麼時候使用Runloop ?
當需要和該線程進行交互的時候才會使用Runloop.
每一個線程都有其對應的RunLoop,但是默認非主線程的RunLoop是沒有運行的,需要為RunLoop添加至少一個事件源,然後去run它。
一般情況下我們是沒有必要去啟用線程的RunLoop的,除非你在一個單獨的線程中需要長久的檢測某個事件。
主線程默認有Runloop。當自己啟動一個線程,如果只是用於處理單一的事件,則該線程在執行完之後就退出了。所以當我們需要讓該線程監聽某項事務
時,就得讓線程一直不退出,runloop就是這么一個循環,沒有事件的時候,一直卡著,有事件來臨了,執行其對應的函數。
RunLoop,正如其名所示,是線程進入和被線程用來相應事件以及調用事件處理函數的地方.需要在代碼中使用控制語句實現RunLoop的循環,也就是說,需要代碼提供while或者for循環來驅動RunLoop.
在這個循環中,使用一個runLoop對象[NSRunloop currentRunloop]執行接收消息,調用對應的處理函數.
Runloop接收兩種源事件:input sources和timer sources。
input sources傳遞非同步事件,通常是來自其他線程和不同的程序中的消息;
timer sources(定時器)傳遞同步事件(重復執行或者在特定時間上觸發)。
除了處理input sources,Runloop
也會產生一些關於本身行為的notificaiton。注冊成為Runloop的observer,可以接收到這些notification,做一些額外
的處理。(使用CoreFoundation來成為runloop的observer)。
Runloop工作的特點:
1>當有時間發生時,Runloop會根據具體的事件類型通知應用程序作出相應;
2>當沒有事件發生時,Runloop會進入休眠狀態,從而達到省電的目的;
3>當事件再次發生時,Runloop會被重新喚醒,處理事件.
提示:一般在開發中很少會主動創建Runloop,而通常會把事件添加到Runloop中.
二.Runtime:
RunTime簡稱運行時。就是系統在運行的時候的一些機制,其中最主要的是消息機制。對於C語言,函數的調用在編譯的時候會決定調用哪個函數(
C語言的函數調用請看這里
)。編譯完成之後直接順序執行,無任何二義性。OC的函數調用成為消息發送。屬於動態調用過程。在編譯的時候並不能決定真正調用哪個函數(事實證明,在編
譯階段,OC可以調用任何函數,即使這個函數並未實現,只要申明過就不會報錯。而C語言在編譯階段就會報錯)。只有在真正運行的時候才會根據函數的名稱找
到對應的函數來調用。
那OC是怎麼實現動態調用的呢?下面我們來看看OC通過發送消息來達到動態調用的秘密。假如在OC中寫了這樣的一個代碼:
[objc] view plain?
<spanstyle="font-size:18px;">[objmakeText];</span>
其中obj是一個對象,makeText是一個函數名稱。對於這樣一個簡單的調用。在編譯時RunTime會將上述代碼轉化成
[objc] view plain?
objc_msgSend(obj,@selector(makeText));
首先我們來看看obj這個對象,iOS中的obj都繼承於NSObject。
[objc] view plain?
@interfaceNSObject<nsobject>{
ClassisaOBJC_ISA_AVAILABILITY;
}</nsobject>
在NSObjcet中存在一個Class的isa指針。然後我們看看Class:
[objc] view plain?
typedefstructobjc_class*Class;
structobjc_class{
Classisa;//指向metaclass
Classsuper_class;//指向其父類
constcharchar*name;//類名
longversion;//類的版本信息,初始化默認為0,可以通過runtime函數class_setVersion和class_getVersion進行修改、讀取
longinfo;//一些標識信息,如CLS_CLASS(0x1L)表示該類為普通class,其中包含對象方法和成員變數;CLS_META(0x2L)表示該類為metaclass,其中包含類方法;
longinstance_size;//該類的實例變數大小(包括從父類繼承下來的實例變數);
structobjc_ivar_list*ivars;//用於存儲每個成員變數的地址
structobjc_method_list**methodLists;//與info的一些標志位有關,如CLS_CLASS(0x1L),則存儲對象方法,如CLS_META(0x2L),則存儲類方法;
structobjc_cache*cache;//指向最近使用的方法的指針,用於提升效率;
structobjc_protocol_list*protocols;//存儲該類遵守的協議
}
我們可以看到,對於一個Class類中,存在很多東西,下面我來一一解釋一下:
Class
isa:指向metaclass,也就是靜態的Class。一般一個Obj對象中的isa會指向普通的Class,這個Class中存儲普通成員變數和對
象方法(「-」開頭的方法),普通Class中的isa指針指向靜態Class,靜態Class中存儲static類型成員變數和類方法(「+」開頭的方
法)。
Class super_class:指向父類,如果這個類是根類,則為NULL。
下面一張圖片很好的描述了類和對象的繼承關系:
注意:所有metaclass中isa指針都指向跟metaclass。而跟metaclass則指向自身。
Root metaclass是通過繼承Root class產生的。與root class結構體成員一致,也就是前面提到的結構。不同的是Root
metaclass的isa指針指向自身。
Class類中其他的成員這里就先不做過多解釋了,下面我們來看看:
@selector (makeText):
這是一個SEL方法選擇器。SEL其主要作用是快速的通過方法名字(makeText)查找到對應方法的函數指針,然後調用其函數。SEL其本身是一個
Int類型的一個地址,地址中存放著方法的名字。對於一個類中。每一個方法對應著一個SEL。所以iOS類中不能存在2個名稱相同的方法,即使參數類型不
同,因為SEL是根據方法名字生成的,相同的方法名稱只能對應一個SEL。
下面我們就來看看具體消息發送之後是怎麼來動態查找對應的方法的。
首先,編譯器將代碼[obj makeText];轉化為objc_msgSend(obj, @selector
(makeText));,在objc_msgSend函數中。首先通過obj的isa指針找到obj對應的class。在Class中先去cache中
通過SEL查找對應函數method(猜測cache中method列表是以SEL為key通過hash表來存儲的,這樣能提高函數查找速度),若
cache中未找到。再去methodList中查找,若methodlist中未找到,則取superClass中查找。若能找到,則將method加
入到cache中,以方便下次查找,並通過method中的函數指針跳轉到對應的函數中去執行。
6. vc9runtime是什麼
vc不是微軟的編譯器嗎?9不是版本嗎?也就是編譯器運行時。
你單問這個要人家怎麼答。
7. 什麼是Runtime
runtime就是程序運行時的狀態
還有一個compiletime,就是編譯時代狀態
程序設計中要避免runtime的錯誤,compiletime的錯誤由編譯器檢測。
8. C語言問題,編譯器上自己調試沒問題,但在線提交時總顯示Runtime error,怎麼解決
runtime error是運行時錯誤。你自己可以成功編譯運行,但是提交上去之後報錯的原因是你的程序在特定輸入的時候出現錯誤。
9. 編譯器不會強制程序員處理哪種異常
在java編譯器中,是不會強制要求程序員進行處理Runtime異常的。
RuntimeException類及其子類的實例被稱為運行時異常,即UnChecked Exception。
我們較為常見的NullPointerException(空指針異常)和 IndexOutOfBoundsException(數組越界異常),對於這些Runtime異常。
在java編譯器中是不會強制要求程序員進行處理或聲明的(有些IDE可能會給可能出現Runtime異常問題的提示,但不會報錯)。
常見的RunTime異常幾種如下:
NullPointerException - 空指針引用異常。
ClassCastException - 類型強制轉換異常。
IllegalArgumentException - 傳遞非法參數異常。
ArithmeticException - 算術運算異常。
ArrayStoreException - 向數組中存放與聲明類型不兼容對象異常。
IndexOutOfBoundsException - 下標越界異常。
NegativeArraySizeException - 創建一個大小為負數的數組錯誤異常。
NumberFormatException - 數字格式異常。
SecurityException - 安全異常。
UnsupportedOperationException - 不支持的操作異常。
10. 我的C語言程序在編譯器上運行正確,但作業提交上去卻是runtime error這是什麼原因
runtime error是運行時錯誤。你自己可以成功編譯運行,但是提交上去之後報錯的原因是你的程序在特定輸入的時候出現錯誤。