㈠ vs有沒有32位與64位的區別
visualstudio沒有專門的64位版,但32位版可以在64位系統上面正常使用。
由於操作系統內存分配的不同,導致軟體開發過程中,需要編譯不同版本的軟體。
編譯程序根據需要選擇不同的編譯環境,x86和win32為32位程序,x64為64位程序,可以選擇不同的編譯條件形成不同位的軟體。
代碼中的基本數據類型,會根據操作系統的位數來分類內存大小。
如int型在32位操作系統下為4位元組,在64位系統下為8位元組。
因此在64位上對int型數據操作,編譯生成32位的程序,有可能導致int型越界,軟體出現問題,32位的程序在64位操作系統上運行,由於64位操作系統的定址和偏移問題,也有可能導致程序在運行過程中,計算結果與32位系統不一致。
64位操作系統理論上能夠箭筒32位和64位軟體,32位操作系統不能運行64位程序。
在vs中,x64生成的程序只能在64位系統中運行。如果用戶用的是32位的系統(比如XP),則運行不了程序。
x32生成32位程序,由於64位系統也能運行32位的程序,所以這個選項跟AnyCPU一樣可以同時運行在兩種系統中,但效率沒有AnyCPU高,因為64位的軟體跟CPU交互的數據要比32位的接近大一倍。
所以當要把項目代碼轉移到另一台計數機時,就要考慮這個問題。假如原來選擇的目標平台是x64,新電腦的系統是32位,當你按F5調試運行時,則跑不起來,這時把目標平台改成AnyCPU或者x32就能解決了。
(1)VS編譯的程序內存分配擴展閱讀:
如果項目引用有32位的dll(c++編譯生成的),則只能選擇32位平台,否則也會報錯,整個項目要保持一致。
在項目調試的過程中,可以看到32位與64位程序載入的dll不同。
32位程序從system32中載入dll;而64位程序從syswow64中載入dll。
64bit程序在x86-64處理器上並不會帶來明顯的性能提高,它只是增加了處理器的定址范圍,可以使用更大的內存。而對於VS這種並非內存敏感的程序,並不十分需要遷移到64bit下。
另外,還有一個歷史原因,就是微軟一直沒有完成64bit下的JIT調試器的EditandContinue功能,這是因為64bit的JIT是C++團隊做的,和原生CLR團隊的32bitJIT有很多不同。
如果微軟推出了64bit的VS,那麼調試的體驗會受到限制,這也是為什麼微軟一直以來沒有推出64bitVS的原因。
㈡ 在VS2017中局部變數的內存地址分配
這是新手常犯的錯,變數必須先賦值,再使用。這樣使用,結果是隨機的。
㈢ VS佔用多少內存
額~問題有點大。
1、VS2003、VS2005、VS2008、VS2010佔用內存大小是不同的。
2、VS啟動成功後,不運行代碼時佔用內存普遍不大,我曾使用512M內存的機器,使用VS2005編輯程序,查看任務管理器,佔用內存不到300M。但一旦你編輯的程序使用了內存,就得另外算了。
3、基本公式:VS佔用內存 = 自己編寫的程序申請的內存+300M(僅供參考)。
㈣ 64位系統上編譯32位vs程序,內存訪問怎樣超
32位APPs可以使用Address Windowing Extensions來使用更多的內存
(可以超過4GB)
DOS中的EMS/XMS擴展。
㈤ vs編譯階段會佔用堆內存嗎
會得,編譯佔用的內存很多,不要在編譯時使用其他的大型軟體
㈥ C++中函數中的局部變數到底是不是執行到變數定義處才分配內存嗎,為什麼我用VS調試有疑問
C語言C++語言的局部非靜態變數或者局部非靜態對象在函數開始執行的時候就分配好了內存空間,但是在到達對象或者變數的定義點之前,是不能對其進行引用的。對於局部非靜態對象,構造函數只有到定義點才調用。這些都是實現細節,不是C++標準定義的,所以不同的編譯器和系統可能有所不同的實現。在C++語言中,一個對象只有調用了構造函數之後才算真正的創建完成,所以即使內存提前分配,但是對象依然還沒有完成創建。
java語言和C++語言本質上不一樣:一個是解釋型語言、一個是編譯型語言。C++語言經過編譯之後直接生成CPU可以直接處理的機器指令,而java語言需要首先編譯成某個中間語言,執行的時候再由解釋器一步一步解釋。所以C++語言編寫的程序在編譯時就可以直接進行優化,比如對於函數的局部變數,因為個數確定、類型確定,所以可以直接在函數的開頭生成分配容納所有局部變數的內存空間的指令(通常是一個修改棧頂的指令),執行一個指令總比執行多個分開的指令要快得多。
你用的Visual Studio,在調試模式下分配給局部變數的內存會大很多,這是用於檢測堆棧異常的。
㈦ 64位系統上編譯32位vs程序,內存訪問怎樣超過2G
在"配置管理器"中把所有項目的"平台"都設置為32位的.試試看呢。開發人員開發的產品如果是面向普通庫戶的建議還是裝32位的。