today i'm beginning translating Scopes' internal OOP based system to datalog/database/ECS layout, that is, all pointers become enum-typed indices and object attributes are mapped in arrays.
to begin, i'm writing a small DSL in Scopes to describe the datamodel, and then auto-translate it to C++
phew. five hours later, i've translated *all types* used by Scopes into this format, from which C++ definitions will be derived.
what i like particularly here is that all sub-enums like ICmpKind or TypeKind, and even all error codes, are flattened into the main ValueKind one, but can still be their own enumerator types.
many branch-dependent special cases are now unified this way.
we have generated some code. instead of generating plain C++ expressions i employ the same technique i did with the scopes² prototype: generate macro expressions and let the preprocessor translate.
left is an impression of what the output looks like (header file). right is the file used to translate it to C definitions. most of it is stubs so the code compiles at all.
in full refactoring flow now, as i replace explicit classes with generated types, turn methods into functions, figure out small extensions to the type generator, etc.
as a result, codebase's getting smaller, which is always a good sign.
voting this the least helpful error message in C++ (it's a bit verbose because i use heavily templated types, and C++ doesn't know when to quit describing nesting structures).
you get this when you use a type for STL hashmaps that's not supported by std::hash. it doesn't actually tell you where you made that mistake. it does in fact tell you nothing useful aside from the type used. you just have to know by experience.
gen_llvm.cpp is updated, next is globals.cpp. this one implements the C API wrapper around the C++ parts of the compiler and also exports all API symbols to the client context, which looks like below.
these 600+ lines of definitions are all manually maintained, but could be autogenerated from scopes.h alone, which i'll implement now.
i'm going to remove all the internal "homebrew exception" stuff from our C++ codebase and use C++ exceptions instead, which drastically simplifies a lot of the error handling code. we're already converting exceptions at the boundaries, this would be no different.
honestly i no longer understand why i was so reluctant to use this in the first place. i guess i was afraid C++ exception support would leak into the scopes API but those worries were unfounded.
Arts, Maths & Metaprogramming; Game Developer at @duangle. paniq in the demoscene. Building Tukan, a procedural game engine, maintaining Scopes & gently going NowHere. (he/him, they/them)I mostly write in English, rarely in German.Migrated from @paniqMy avatar is the logo of the library I'm working on, a stylized toucan with a four-colored beak.