wgroeneveld
/
brainbaking
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

a few syntactic mistakes in last article

This commit is contained in:
Wouter Groeneveld 2021-04-22 08:43:14 +02:00
parent 13e5698e0e
commit 5b30106863
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/post/2021/04/stop-limiting-yourself-to-js-in-browsers.md
View File

@ -10,7 +10,7 @@ categories:
- programming
---
While sniffling through various documentations, trying my best in understanding the ramifications of LLVM's license model compared to the older GCC toolchain, I dare to say that I actually found something interesting instead of falling asleep in-between the countless and needless pro or contra Richard Stallman debates[^rms]. Here's what I found:
While sniffling through various documentation records, trying my best in understanding the ramifications of LLVM's license model compared to the older GCC toolchain, I dare to say that I actually found something interesting instead of falling asleep in-between the countless and needless pro or contra Richard Stallman debates[^rms]. Here's what I found:
[Emscripten](https://emscripten.org/). Instead of calling it a day, let's take a closer look. Emscripten is a complete compiler toolchain that targets WebAssembly (and JavaScript), and is able to compile any language that uses LLVM - to work in browsers, Node.js, or wasm runtimes. Hold on, what where how? Okay, let's rephrase that. It acts as a drop-in replacement for gcc, just like clang does for GNU's gcc itself. Instead of outputting native code, it spews out a `wasm` file - wrapped in js or html if you prefer. That means it's possible to compile C and C++ code... To... JS?
@ -18,7 +18,7 @@ While sniffling through various documentations, trying my best in understanding
## C++ and JavaScript, sitting in a tree...
Most of the times, when I stumble on GitHub projects of that scale, they're in pre-alpha state and end up going nowhere. Yet, Emscripten is surprisingly robust and easy to use. It _really is_ a "drop-in" replacement. Open your `Makefile`, locate `CC=g++`, replace it with `CC=em++`, and call it a day. It interprets popular gcc flags, just like clang does with GNU/gcc. For instance, adding optimization flag `-O3` results in a longer compile time, but the binary size was halved, and the execution speed increased. Even "native" threading support (`-lpthread`) or C++14 constructs (`-std=c++14`) work.
Most of the time, when I stumble on GitHub projects of that scale, they're in pre-alpha state and end up going nowhere. Yet, Emscripten is surprisingly robust and easy to use. It _really is_ a "drop-in" replacement. Open your `Makefile`, locate `CC=g++`, replace it with `CC=em++`, and call it a day. It interprets popular gcc flags, just like clang does with GNU/gcc. For instance, adding optimization flag `-O3` results in a longer compile time, but the binary size was halved, and the execution speed increased. Even "native" threading support (`-lpthread`) or C++14 constructs (`-std=c++14`) work.
An example might do wonders. For a [system C course](https://kuleuven-diepenbeek.github.io/osc-course/) at our faculty, we introduce students to the concept of unit testing using Google Test. GTest is C++ code. You first compile the library yourself, and then statically link to its main executer. Your Makefile might end up looking like this: