I've been shifting a little more into C++ after decades of C. It takes longer to compile, but I find that a lot of the tedious stuff that I'm doing with C (function pointer structures, etc) is handled automatically in C++, and I kind of like the RAII pattern.
Also, I enjoy embedding Lua in projects for extensibility, so this guy is really pulling my heart strings. :-)
> Serialisation Compared to serialisation in almost any modern language, serialising state in C (or C++) is excruciating. There are no reflection capabilities in C, and minimal capabilities in C++, so you need to manually specify each and every field when serialising or deserialising the game state
My biggest issues are crashes in programs by someone who writes C/C++ and doesn't take it through valgrind (or even bothering to lint it).
I feel like Google's Carbon could be good, but it's still not ready for general use. I'm surprised they even bothered with Carbon since they had built golang for their server software development.
Rust is slowly getting there, and there could be a good chance of using LLVM to touch the platforms with only C runtimes indirectly.
As in, transforming directly to the LLVM-IR byte code which can be compiled to C or more readily C++.
I've stated this before, but on my ancient (12 year old) i7 a sufficiently complex C project (6000 lines, more or less) can completely compile in under a second.
I dunno how much under a second because my build process only reports durations in seconds.
When using vim with the autocomplete using clang, single file compilations can finish in between keystrokes.
> Is there a 0 missing? 6k lines of C is on the lower end of things, especially given how verbose vanilla C can be for basic stuff...
No zero missing. Routines for dynamic arrays/vectors, hashmaps, strings, etc (i.e. the basic stuff) are already in precompiled libraries (*.so).
The programs (there were two) consisted of an agent that sat on a remote box gathering packet traces and listening for commands to start/stop/change expression for capture, and would store+forward that capture to a server, which saved the capture in a format wireshark was able to read.
6000 lines is about right for something of that complexity.
That's the entire build process, not just the compilation. This means that things in the build (copying files, building archives, linking, etc) get counted as well.
In C, certainly. A short program I wrote took under 1s to compile and about 2s to link.
In C++ this is not the case; compilation is very computationally expensive, with my experiments in Rust leaving me with the feeling that Rust was even more computationally expensive than C++.
As someone who still regularly does C for fun and for profit, I am often left feeling frustrated when trying to compile projects in languages like C++ or Rust.
As an aside, some of the Lisp compilers (SBCL comes to mind) where much faster than one would expect, even though feature-wise it is more or less complete. It's the (I feel) typing and rules checking in complex languages that slows down the compilation, not the linking after everything is compiled.
I've been shifting a little more into C++ after decades of C. It takes longer to compile, but I find that a lot of the tedious stuff that I'm doing with C (function pointer structures, etc) is handled automatically in C++, and I kind of like the RAII pattern.
Also, I enjoy embedding Lua in projects for extensibility, so this guy is really pulling my heart strings. :-)
> Serialisation Compared to serialisation in almost any modern language, serialising state in C (or C++) is excruciating. There are no reflection capabilities in C, and minimal capabilities in C++, so you need to manually specify each and every field when serialising or deserialising the game state
I got tired of that years agao, and have used this approach with success in a few projects: https://www.lelanthran.com/chap2/content.html
That looks really interesting, I'll experiment with swapping to it!
My biggest issues are crashes in programs by someone who writes C/C++ and doesn't take it through valgrind (or even bothering to lint it).
I feel like Google's Carbon could be good, but it's still not ready for general use. I'm surprised they even bothered with Carbon since they had built golang for their server software development.
Rust is slowly getting there, and there could be a good chance of using LLVM to touch the platforms with only C runtimes indirectly. As in, transforming directly to the LLVM-IR byte code which can be compiled to C or more readily C++.
That would be perfect. There is so much good about Rust, and if it could compile to C in that way it would have been amazing for this game
>Successes
>Fast Compilation Iron Roads builds quickly, so I can iterate fast, and in this way C has helped my workflow a lot
I wish they'd given a number. 1s?
I've stated this before, but on my ancient (12 year old) i7 a sufficiently complex C project (6000 lines, more or less) can completely compile in under a second.
I dunno how much under a second because my build process only reports durations in seconds.
When using vim with the autocomplete using clang, single file compilations can finish in between keystrokes.
> a sufficiently complex C project (6000 lines, more or less)
Is there a 0 missing? 6k lines of C is on the lower end of things, especially given how verbose vanilla C can be for basic stuff...
> Is there a 0 missing? 6k lines of C is on the lower end of things, especially given how verbose vanilla C can be for basic stuff...
No zero missing. Routines for dynamic arrays/vectors, hashmaps, strings, etc (i.e. the basic stuff) are already in precompiled libraries (*.so).
The programs (there were two) consisted of an agent that sat on a remote box gathering packet traces and listening for commands to start/stop/change expression for capture, and would store+forward that capture to a server, which saved the capture in a format wireshark was able to read.
6000 lines is about right for something of that complexity.
Use the time command when running make.
> Use the time command when running make.
That's the entire build process, not just the compilation. This means that things in the build (copying files, building archives, linking, etc) get counted as well.
Linking tends to be the slow part, right?
Especially for rust and c++.
From an iteration speed perspective, you’d want to time the whole build process, not just specially compilation.
> Linking tends to be the slow part, right?
> Especially for rust and c++.
In C, certainly. A short program I wrote took under 1s to compile and about 2s to link.
In C++ this is not the case; compilation is very computationally expensive, with my experiments in Rust leaving me with the feeling that Rust was even more computationally expensive than C++.
As someone who still regularly does C for fun and for profit, I am often left feeling frustrated when trying to compile projects in languages like C++ or Rust.
As an aside, some of the Lisp compilers (SBCL comes to mind) where much faster than one would expect, even though feature-wise it is more or less complete. It's the (I feel) typing and rules checking in complex languages that slows down the compilation, not the linking after everything is compiled.
[flagged]