Factor VM ported to C++(factor-language.blogspot.com)
factor-language.blogspot.com
Factor VM ported to C++
http://factor-language.blogspot.com/2009/05/factor-vm-ported-to-c.html
10 comments
If minor changes trigger long compilation, there is something wrong with your code organization. I found that if you count linking time the total build time difference between c and c++ for significant project is not that big at least not at 10-20x.
There are plenty of gdb macros that support stl containers even 18 months ago.
LLVM is also written in C++ for good reasons.
There are plenty of gdb macros that support stl containers even 18 months ago.
LLVM is also written in C++ for good reasons.
If minor changes trigger long compilation, there is something wrong with your code organization
A lot of larger C++ projects use "pimpl" for this reason (http://en.wikipedia.org/wiki/Opaque_pointer). Also in professional projects with large code bases that I've worked on in the past we've always had a distributed compilation environment (distcc, icecream, etc.)
A lot of larger C++ projects use "pimpl" for this reason (http://en.wikipedia.org/wiki/Opaque_pointer). Also in professional projects with large code bases that I've worked on in the past we've always had a distributed compilation environment (distcc, icecream, etc.)
In a lot of cases, just use forward declarations to avoid unnecessary includes in the header files goes a long way.
I tried some of those gdb macros, but they did not work for me. Don't remember the details. In any case, in a recent debugging session, I noticed that gdb elides or loses some essential iterator features. For example, iterator->first and ->second do not show up if I execute the "p" command in gdb. The whole situation led me to claim that, at least in open-source Unixland, the C++ toolchain leaves a great deal to be desired.
I'm as disappointed by gdb's C++ support as anyone, but is it really fair to complain about its lack of support for STL containers? C doesn't have _any_ containers, so there's nothing there for gdb to lack. Either way you have to printf debug, though I can see how the increased compile times make that more tedious.
So Factor is not at all what I thought it was. I thought it was roughly a modern Forth for the JVM...and I thought the point of it was at least partially the JVM. Not dependence, but the ability to use Java libraries. The realization that this is not at all the case makes Factor seem more interesting but less useful, to me.
I suggest you take a look at Factor's standard library. You will be pleasantly surprised at how much it offers. It's not called "a practical stack-based language" without a reason.
(Note that I've only played around with Factor for a few hours.)
(Note that I've only played around with Factor for a few hours.)
Factor has not been related to JVM in any way for many years now. The core of the VM has been in C since 2004 and now it has been ported to C++.
Yes, which is why I said it is not at all what I thought it was. I was wrong before, and now I know. How wrong my existing knowledge of Factor was surprised me enough that I commented on it.
First, don't discount the longer compilation times. After learning Lisp, I became rather addicted to the rapid turn-around time of compiling code at the level of individual functions. I can tolerate C because, with a relatively clean build setup, it compiles quickly. g++ on my project is between 10 and 20 times slower than gcc. This means that, as I make minor changes, I'm more likely to have to wait a while for a build to finish. This means I'm more likely to slack off in between builds. This kills (my) productivity horribly.
Second, auxiliary tool support on Unix leaves a lot to be desired. I sprinkle my code with templates in places where they promote readability, and I use STL containers. gdb, at least the version I'm using, does not support displaying data in STL containers. This means that when I have to track down a problem with data in a map, gdb can't help me. I have run into nasty problems for which I had to write custom print-this-templated-structure-to-log code. In addition, g++ error messages which involve templates absolutely suck. Luckily, I can quickly figure out what I need to change just by looking at the affected line.
After thinking through these issues, I concluded that C++ wasted more of my time than it saved. YMMV, of course.