11–20 of 49 posts
> vim temp.cpp
> g++ temp.cpp
> ./a.out
Very similar to my process with Python, actually. Every time I use the REPL for some experimenting, the code ends up outgrowing it and I have to stuff it in a file anyway, so I may as well cut out the middleman to begin with. YMMV.
Why would I do that :S
Creating an entire "project" just to check a code snippet is just silly.
Just create a "testing" directory and throw your one off test files into it and compile/run them there.
I start mine with a comment explaining what I'm testing, why I'm testing it, and what special compilation flags are required, if any. I even have an Emacs macro that fills in the boilerplate includes and main function. The overhead involved is probably less than 15 seconds.
It has the advantages that I can test multiple compilers and I keep a history of the things I've tried.
Earlier quoted context omitted.
Why not? It's great to quickly test C++, I have yet to find a developer who doesn't love a REPL for one. C++ could also be used as an embedded extension language using something like this.
I share your enthusiasm but there are limits. C++ compilation speed (and thus interpretation speed) will make it quite impossible to use it as an extension language. And while I like and use C++ a lot I don't think it is the right language for this purpose. It can do quite a lot of things, but working in a homogeneous language in your extensions as well as your core product doesn't have enough benefits compared to us…
I would very much like to use D as an extension language.
It's a cool idea, but his reason for creating it is kinda dumb. Creating an entire "project" just to check a code snippet is just silly. Just create a "testing" directory and throw your one off test files into it and compile/run them there. I start mine with a comment explaining what I'm testing, why I'm testing it, and what special compilation flags are required, if any. I even have an Emacs macro that fills in the…
This is just an updating of what must be an awful hack to be built on LLVM infrastructure.
I just keep a fixed .cpp file with a bunch of common includes and directives, and alias the g++ command to link to common libraries, so my workflow goes: > vim temp.cpp > g++ temp.cpp > ./a.out Very similar to my process with Python, actually. Every time I use the REPL for some experimenting, the code ends up outgrowing it and I have to stuff it in a file anyway, so I may as well cut out the middleman to begin with.…
Earlier quoted context omitted.
Why not? It's great to quickly test C++, I have yet to find a developer who doesn't love a REPL for one. C++ could also be used as an embedded extension language using something like this.
I share your enthusiasm but there are limits. C++ compilation speed (and thus interpretation speed) will make it quite impossible to use it as an extension language. And while I like and use C++ a lot I don't think it is the right language for this purpose. It can do quite a lot of things, but working in a homogeneous language in your extensions as well as your core product doesn't have enough benefits compared to us…
I think you vastly underestimate the speed of the clang C++ compiler (or any modern C++ compiler at that). I can't imagine that the compilation time for anything that could be classified as an "extension" would be significant in any meaningful way.
#include