您是否使用過任何C++解釋器（不是編譯器）？

Question

如果有人使用過UnderC，Cint，Cling，Ch或其他C++解釋器並且可以分享他們的經驗，我很好奇。

Answer 1

cint是粒子物理分析軟件包ROOT的命令處理器。我經常使用它，它對我來說效果很好。

這是相當完整和編譯代碼相處的很好（你可以加載編譯在解釋使用的模塊...）

後期編輯::從後面重複的複製，因爲對海報問題似乎不想在這裏發佈：igcc。從來沒有嘗試過，但網頁看起來很有希望。

Answer 2

很久以前，我使用了一個名爲CodeCenter的C++解釋器。這很不錯，雖然它不能處理像位域或花哨指針混亂的東西。關於它的兩件很酷的事情是，你可以觀察變量何時改變，並且可以在調試時隨時評估C/C++代碼。這些天，我認爲像GDB這樣的調試器基本上是一樣的。

Answer 3

而且不久前，我使用的產品呼叫即時C，但我不知道它曾經開發進一步

Answer 4

我有（約一年前）與Ch玩了一圈，發現它是相當不錯的。

Answer 5

我在使用ch a後查看是否可以將它用於我負責的黑盒測試DLL。不幸的是，我無法弄清楚如何從DLL中加載和執行函數。然後再一次，我沒有那種動力，可能有辦法。

Answer 6

有一個程序叫c-repl，它通過使用GCC反覆編譯你的代碼到共享庫中，然後加載結果對象來工作。它似乎在迅速發展，考慮到在Ubuntu的存儲庫中的the version是用Ruby編寫的（當然不包括GCC），而latest git在Haskell中。 :)

Answer 7

注意：以下是相當CINT特定，但考慮到它可能是最爲widely used C++解釋器它可能是有效的所有。

作爲廣泛使用CINT的粒子物理研究生，我應該警告你。雖然它的「工作」，它is in the process of being phased out，和那些誰花了一年多的粒子物理學通常學習，以避免它的幾個原因：

1. 由於其根源爲C解釋器的，它不能解釋C++的一些最關鍵的組件。例如，模板並不總是能夠工作，所以你會不願意使用使C++如此靈活和可用的東西。

2. 它比最低限度優化的C++要慢（至少是5倍）。

3. 調試消息比g ++產生的更加隱蔽。

4. 作用域是編譯的C++不一致：這是我們經常見到的形式

   if (energy > 30) { 
       float correction = 2.4; 
   } 
   else { 
       float correction = 6.3; 
   } 
   
   somevalue += correction; 
   

   而任何工作的C++編譯器的代碼會抱怨correcton已經超出了範圍，CINT允許這樣做。結果是CINT代碼不是真的C++，只是看起來像它。

總之，CINT現在沒有的C++的優點，並且所有缺點加上一些。

由於CINT被包含在ROOT框架中，因此CINT仍然被使用的事實可能更多是一個歷史事件。回到寫作時（20年前），真正需要用於交互式繪圖/擬合的解釋性語言。現在有很多軟件包可以滿足這個角色，其中很多軟件包有數百個活躍的開發人員。

這些都不是用C++編寫的。爲什麼？很簡單，C++並不意味着被解釋。例如，靜態類型在編譯過程中會爲您帶來巨大的優化收益，但如果只允許計算機在運行時查看它，則大多數情況下會導致混亂和過度約束您的代碼。如果你有能力使用解釋型語言的好處，學習Python或Ruby，即使你已經瞭解C++，學習所花費的時間也不會超過CINT的絆腳石。

根據我的經驗，使用ROOT（必須安裝運行CINT的軟件包）的老研究人員最終將ROOT庫編譯爲正常的C++可執行文件以避免CINT。那些年輕一代要麼遵循這一領先要求，要麼使用Python進行腳本編寫。

順便說一句，ROOT（因此CINT）需要大約半個小時的時間才能在相當現代的計算機上編譯，並且偶爾會失敗，因爲新版本的gcc會失敗。這是一個多年前有重要用途的軟件包，但現在它清楚地表明瞭它的年齡。研究源代碼，你會發現數百個不贊成使用的C風格類型，類型安全方面的巨大漏洞，以及大量使用全局變量。

如果您要編寫C++，請編寫C++，因爲它是用來編寫的。如果你絕對必須有一個C++解釋器，CINT可能是一個不錯的選擇。

Answer 8

有cling CERN的項目基礎上clang C++解釋的 - 這是基於在ROOT CINT 20年的經驗新方法這是相當穩定的，由歐洲核子研究中心的傢伙建議。

這裏不錯Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM。