I'm looking for a good C++ IDE with a REPL. The one in visual studio isn't... well lets say most of the time if I copy/paste a line in source the REPL rejects it even if its the line I put a breakpoint or step over.
Are there any good IDEs or REPLs for C++?
Cling
What is Cling?
Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries. Its advantages over the standard interpreters are that it has command line prompt and uses just-in-time (JIT) compiler for compilation. Many of the developers (e.g. Mono in their project called CSharpRepl) of such kind of software applications name them interactive compilers.
One of Cling's main goals is to provide contemporary, high-performance alternative of the current C++ interpreter in the ROOT project - CINT. The backward-compatibility with CINT is major priority during the development.
http://root.cern.ch/drupal/content/cling
CINT
What is CINT?
CINT is an interpreter for C and C++ code. It is useful e.g. for situations where rapid development is more important than execution time. Using an interpreter the compile and link cycle is dramatically reduced facilitating rapid development. CINT makes C/C++ programming enjoyable even for part-time programmers.
CINT is written in C++ itself, with slightly less than 400,000 lines of code. It is used in production by several companies in the banking, integrated devices, and even gaming environment, and of course by ROOT, making it the default interpreter for a large number of high energy physicists all over the world.
http://www.hanno.jp/gotom/Cint.html
CLing should be independant of Clang and abble to compile on any platform, recent works of CERN tend to separate Cling from Clang and it's good trends.
What I don't under is mostly the existence of Clipp in C++ allowing to parse javascript embedded in my C++ code and can't find a version of Clipp for just C++ / Boost / Eigen / Quantlib.
Another thing I don't understand is why TinyCC with a 200ko size is abble to parse windows.h without a problem and LLVM team complaining about Clang on windows.H detonate on tarmac.
All in all, with fusion, spirit, wave and the so many people wishing for a C++ REPL, why after 2 decade there is not even small version of it.
Here is my solutions
Forget about REPL C++ and stick to REPL C, use tinyCC and expose only the functionnal action of method by using pointer function A.function(toto t) -> function(A *, toto t). To make it works with object method you can also use declaration as struct __declspec(novtable) A { };
This will allow binary align compatibility between tinyCC struct understanding and your true object. True you will have to split the tuple of data and the tuple of method, but after all, that should have always be the case in first place. Object design should have split data and method into a dual model rather than a mixed model good for bug. In many case, the compiler will split the object into dual model anyway. This will provide extrem fast prototyping even for scientist and user of Cling/Cint.
Second solution, rather than REPL statement, use the dynamic load/unload pair, you setup a chain of compilation ( incremental build or not ) and auto relink compiled library when the source change. It isn't slow at all. This give the advantage to do it on any supported dynamic library OS and it's very EASY to do.
Third solution, the most easiest way, boot a linux based vm ( install llvm tool chain), and use Cling on the vm. That won't work in a firm full windowOSed but it seems LLVM are windows OS haters.
Related
Aren't shaders cool? You can toss in just a plain string and as long as it is valid source, it will compile, link and execute. I was wondering if there is a way to embed GCC inside a user application so that it is "self sufficient" e.g. has the internal capability to compile native binaries compatible to itself.
So far I've been invoking stand alone GCC from a process, started inside the application, but I was wondering if there is some API or something that could allow to use "directly" rather than a standalone compiler. Also, in the case it is possible, is it permitted?
EDIT: Although the original question was about CGG, I'd settle for information how to embed LLVM/Clang too.
And now a special edit for people who cannot put 2 + 2 together: The question asks about how to embed GCC or Clang inside of an executable in a way that allows an internal API to be used from code rather than invoking compilation from a command prompt.
I'd add +1 to the suggestion to use Clang/LLVM instead of GCC. A few good reasons why:
it is more modular and flexible
compilation time can be substantially lower than GCC
it supports the platforms you listed in the comments
it has an API that can be used internally
string source = "app.c";
string target= "app";
llvm::sys::Path clangPath = llvm::sys::Program::FindProgramByName("clang");
// arguments
vector<const char *> args;
args.push_back(clangPath.c_str());
args.push_back(source.c_str());
args.push_back("-l");
args.push_back("curl");
clang::TextDiagnosticPrinter *DiagClient = new clang::TextDiagnosticPrinter(llvm::errs(), clang::DiagnosticOptions());
clang::IntrusiveRefCntPtr<clang::DiagnosticIDs> DiagID(new clang::DiagnosticIDs());
clang::DiagnosticsEngine Diags(DiagID, DiagClient);
clang::driver::Driver TheDriver(args[0], llvm::sys::getDefaultTargetTriple(), target, true, Diags);
clang::OwningPtr<clang::driver::Compilation> c(TheDriver.BuildCompilation(args));
int res = 0;
const clang::driver::Command *FailingCommand = 0;
if (c) res = TheDriver.ExecuteCompilation(*c, FailingCommand);
if (res < 0) TheDriver.generateCompilationDiagnostics(*c, FailingCommand);
Yes, it is possible, for example, QEMU does it.
I don't have any personal experience in this field, but from what I've read, it seems that LLVM might be better suited for embedding and extending than GCC.
Some older list of C++ compilers and interpreters is available at http://www.thefreecountry.com/compilers/cpp.shtml.
Answer to the "self sufficient" application is usually a good language interpreter. There are many of them out there, many compile the code into a byte code files. Very popular and easily embeddable is the Lua language interpreter. Even some strong players use it.
There was also an open source C++ interpreter with great language compatibility produced years ago starting with F.. Don't remember the rest of the name. There are also many other tools able to produce native binaries (e.g. Free Pascal).
Choice of the language and the target platform depends on the intentions. What would be the "self sufficiency" good for. Who will write those libraries. Once you have that clear - use Google - there is a wildlife out there. One of the latest beasts is the open sourced C# compiler "Roslyn"
EDIT
If you need some C compiler (as you generate C subset) that can be "embedded" you are probably looking for a "portable C compiler" in the sense that you can put it on USB stick and carry with you. Portable applications can be easily "embedded" into other applications and can be easily included in the installer.
Possibility to "embed" compiler as statically linked code into main application binary is probably not required.
Some reference to portable MinGW is described in this https://stackoverflow.com/questions/7617410/portable-c-compiler-ide SO question.
An open source C++ editor with integrated MinGW is here https://code.google.com/p/pocketcpp/.
I don't have anything more to say as I'd have to go and browse Google - so I will not win the bounty :)
Why not just call the compiler and linker from your application using fork()/exec() (for UNIX-like platforms)? Create a shared library that you can then load with dlopen().
This avoids possible licensing issues and gives you less of a maintenance burden.
This is e.g. what varnish does with its configuration files;
The VCL language is a small domain-specific language designed to be used to define request handling and document caching policies for Varnish Cache.
When a new configuration is loaded, the varnishd management process translates the VCL code to C and compiles it to a shared object which is then dynamically linked into the server process.
I'm working to learn C++ more and trying to know basics about different compilers and their technologies. I googled this a lot but every time I stepped through I happened to meet new terms which need more explanation. So, what do these terms such as static compiling, dynamic linking and so on which reside in this topic mean in action?
Some languages like C++ compile all of a program to "native machine code" understood by the CPU before it starts running (i.e. actually being used). That's "static compilation".
Other languages (e.g. Java) use "Just In Time" compilers to produce CPU-native code from some other "byte-code" representation of the program, but do so only once they start running. That's "runtime" compilation.
Many other languages (e.g. common python, perl, ruby, Java implementations) use an "interpreter", which means they have native code that keeps consulting some manner of "byte-code" to work out what to do next. (Some very basic inter-company or specialised interpreters even keep consulting the source code without ever generating a more compact byte-code representation thereof, but no popular language does that - it's awfully slow and clumsy).
A single language may potentially use any combination of these approaches, but in general it's either static compilation, or an interpreter that might add a just-in-time compiler to speed up execution.
Sometimes, a single language has implementations that use different approaches, for example: there are limited C++ interpreters (like http://root.cern.ch/drupal/content/cint, but I've never heard of it being used "in anger"), and systems that compile python to native code.
For "dynamic linking": say you have a function "void f();" that does something wonderful. If you put that function in a library for use by many applications, you could "statically link" the function into a specific application to take a "snapshot" of f()'s functionality at the specific point in time your program's executable is being created. Then if f() changes later you have to re-link and redistribute your application to incorporate the changes to f(). Alternatively, you could put f() into a dynamic linked library, which means a separate library file containing f() is distributed alongside - or independently from - your program. Each time your program starts running, if looks to the dynamic library file for the code to use for f(). So, if you distribute an updated dynamic library you can update f() without redistributing all the application programs that call f(). Sometimes, that's just a better model for distributing updated software to your users, and avoiding getting each individual application program involved in the distribution of updates to f(). (Occasionally it's a disaster because a dynamic version of f() hasn't actually been tested with the application, and does something subtly differently that breaks the application).
About static or dynamic linking, read also Levine's Linker & Loader book.
About shared or static libraries, read Program Library HowTo
For shared objects (or libraries) on Linux, read Drupper's How To Write Shared Libraries paper
You could load plugins with dlopen(3) but then read C++ dlopen mini-howto.
Compilation is usually static, since it is ahead of time (e.g. when compiling with GCC). Sometimes, a just in time compilation is done (e.g. by most JVMs).
If coding in C++ on Linux, you'll want to compile with g++ -Wall -g (and later use -O2 to ask GCC to optimize when your program is debugged). See this and that hints.
Also, learn C++11 and use the latest GCC 4.8.2 compiler (GCC 4.9 might be released in a few weeks, e.g. in march or april 2014).
I have a huge amount of code written in Pascal and I need to use it in a C++ application running on an embedded PC with ARM9 processor. My idea was cross compiling Pascal code to dll libraries which I wanted to include in my C++ app. I tried to install Lazarus but I can't get work its cross compiler and I tried to install compiler directly to the embedded PC with similar result. C++ cross compiler works perfectly. Is there any way how to get Pascal code working in C++ application on different platform? I will provide any additional info if needed.
Additional info:
the embedded pc is for use in extremely low temperatures so it has low ram (32MB) running a trimmed Linux and there is only a little free space left on its flash memory (i have to use the SD card for all files)
I don't think anyone can conclusively answer your question, but some hints:
You will need to find a way to communicate between the C++ and Pascal code. This may simply be a case of defining any interface function as a C or C++ style function. But for example strings in Pascal are often NOT standard C or C++ style strings, so will need some extra handling to work out right. Structs (RECORD in pascal) and classes will require even more careful handling as to how they interface between the C++ and Pascal code - in most cases, it will become a full marshalling solution (that is, convert to a byte-stream, and then convert back to correct type at the other end).
Cross compilation of the Pascal code relies on having a Pascal compiler that matches your Pascal code AND your target. If you can't compile your code to the correct target, all other parts of the project will fail... There is a "standard" for Pascal, but most compilers have a range of extensions.
Have you considered making the Pascal code a standalone application that produces results as a file, rather than directly interfacing to the C++ code? Reading a file that you can control the format of can be a much easier solution than trying to interface one language to another.
I want to use Shiny on a large-ish C++ code base, but I'd rather not add the required PROFILE_FUNC() calls to my source. I figure it's easy enough to write a script that for each source file, regex-searches for function definitions, adds a macro call just after the opening bracket and pipes the result to g++; but that seems an awfully obvious source-code instrumentation case, so much so I find it hard to believe no-one has come up with a better solution already.
Unfortunately, searching around I could only find references to LLVM / clang instrumentation and the odd research tool, which look like overly complicated solutions to my comparatively simple problem. In fact, there seems to be no straightforward way to perform simple automated code edits to C/C++ code just prior to compilation.
Is that so? Or am I missing something?
Update: I forgot to mention this "C++ code base" is a native application I am porting to Android. So I can use neither gprof (which isn't available on Android), Valgrind (which requires an older version of the NDK than what i'm using) nor the android-ndk-profiler (which is for dynamic libraries loaded by Android Activities, either Java or native, not plain executables). Hence my looking into Shiny.
Update 2: Despite previous claims I actually managed to build Valgrind on Android NDK r8e, so I settled on using it instead of Shiny. However I still think the original question is valid: isn't there any straightforward tool for effecting simple compile-time edits to C / C++ source files – some sort of macro preprocessor on steroids?
You can consider gprof or valgrind. If memory serves, gprof uses instrumentation and valgrind is a sampling-based profiler. Neither of them requires you to annotate source code.
You can use the android ndk profiler to profile C/C++ code
More info here
http://code.google.com/p/android-ndk-profiler/
You use gprof to analyse the results
I am looking for a C++ IDE in which I can actively play the game and test the updates live instead of testing it, redoing th code, compiling it and running it again. I'm running Windows 7 x86 professional.
This isn't really an answer, and so probably shouldn't get upvotes, but has information.
I don't know of any C++ IDE that can do runtime updates of code, but it's definitely not impossible. There's lots of C++ assemblers which already JIT code, live updates is merely the next step that no IDE has taken quite yet that I know of.
asmjit can JIT C++
Visual Studio can JIT C++/CLI (which isn't quite C++) (RMartinho corrects that VIsual Studio compiles C++/CLI to IL, and then JITs the IL. Tehcnically different.)
cling uses the clang fruntend and LLVM backend, which has a JIT code generation system.
R.Martinho has also reminded me that Microsoft Visual Studio already has this feature. http://msdn.microsoft.com/en-us/library/esaeyddf(v=vs.100).aspx If you "stop" the code, you can make changes, and it will apply those changes and resume execution.
There's an interesting project at http://runtimecompiledcplusplus.blogspot.co.uk/ that is working on this problem and looks like it might work for you; I haven't used it myself but it looks active if still a little raw. It uses the Visual Studio 2010 compiler.
You can't run C++ code without compiling. Minor syntactic differences between languages shouldn't be an issue so you shouldn't limit yourself to just one language.
I suggest you give Unity a chance; there's a fairly robust free version available. You can write scripts in C# (a language similar to C++), or UnityScript (somehting similar to JavaScript) or Boo (similar to Python) and you can test the results right away, without having to compile.
What about Edit and Continue in Visual Studio? In order to use it, you have to pause execution (either by breakpoint or Pause button), recompile and resume. Note, that you can edit the code while the program is running. I know you can't test the game live, but you don't have to reload resources etc. It's IDE integration makes it really easy and straightforward to use.
If you want changes to be visible live, though, consider using script language such as Lua. One of their purposes is what you want to achieve.
I've listed the options for runtime compilation of C++ code on the alternatives wiki page of Runtime Compiled C++.
From the sounds you may interested in either Recode or Alcanterea.
Organize your C++ game to use plugins, and add a feature to load a new (binary version of) plugin during the game.
Then, you could play your game, recompile a plugin, reload it (so invoke your dynamic linker at runtime), and continue playing.
It is not failproof, but it might usually work.
Of course you cannot unload a plugin which has some active call frame on the (or some thread's) call stack. I would suggest to avoid unloading old plugins...