←back to thread

jank is C++

(jank-lang.org)
252 points Jeaye | 1 comments | | HN request time: 0.214s | source
Show context
johnnyjeans ◴[] No.44535498[source]
I'm not surprised to see that Jank's solution to this is to embed LLVM into their runtime. I really wish there was a better way to do this.

There are a lot of things I don't like about C++, and close to the top of the list is the lack of standardization for name-mangling, or even a way mangle or de-mangle names at compile-time. Sepples is a royal pain in the ass to target for a dynamic FFI because of that. It would be really nice to have some way to get symbol names and calling semantics as constexpr const char* and not have to deal with generating (or writing) a ton of boilerplate and extern "C" blocks.

It's absolutely possible, but it's not low-hanging fruit so the standards committee will never put it in. Just like they'll never add a standardized equivalent for alloca/VLAs. We're not allowed to have basic, useful things. Only more ways to abuse type deduction. Will C++26 finally give us constexpr dynamic allocations? Will compilers ever actually implement one of the three (3) compile-time reflection standards? Stay tuned to find out!

replies(8): >>44535506 #>>44535588 #>>44535621 #>>44535873 #>>44535967 #>>44536143 #>>44539903 #>>44540443 #
o11c ◴[] No.44535621[source]
> the lack of standardization for name-mangling, or even a way mangle or de-mangle names at compile-time.

Like many things, this isn't a C++ problem. There is a standard and almost every target uses it ... and then there's what Microsoft does. Only if you have to deal with the latter is there a problem.

Now, standards do evolve, and this does give room for different system libraries/tools to have a different view of what is acceptable/correct (I still have nightmares of trying to work through `I...E` vs `J...E` errors) ... but all the functionality does exist and work well if you aren't on the bleeding edge (fortunately, C++11 provided the bits that are truly essential; everything since has been merely nice-to-have).

replies(2): >>44535879 #>>44538499 #
mort96 ◴[] No.44535879[source]
Like many things people claim "isn't a C++ problem but an implementation problem"... This is a C++ problem. Anything that's not nailed down by the standard should be expected to vary between implementations.

The fact that the standard doesn't specify a name mangling scheme leads to the completely predictable result that different implementations use different name mangling schemes.

The fact that the standard doesn't specify a mechanism to mangle and demangle names (be it at runtime or at compile time) leads to the completely predictable result that different implementations provide different mechanisms to mangle and demangle names, and that some implementations don't provide such a mechanism.

These issues could, and should, have been fixed in the only place they can be fixed -- the standard. ISO is the mechanism through which different implementation vendors collaborate and find common solutions to problems.

replies(3): >>44536325 #>>44536604 #>>44537468 #
josefx ◴[] No.44537468[source]
> The fact that the standard doesn't specify a name mangling scheme leads to the completely predictable result that different implementations use different name mangling schemes.

The ABI mess predates the standard by years and if we look that far back the Annotated C++ Reference Manual included a scheme in its description of the language. Many compiler writers back then made the intentional choice to ignore it. The modern day ISO standard would not fare any better at pushing that onto unwilling compiler writers than it fared with the c++03 export feature.

replies(1): >>44537650 #
1. mort96 ◴[] No.44537650[source]
Well yeah, it can't be fixed now. It could have been specified near the beginning of the life of the language though, and the standard would've been the right place to do that.

I'm saying that the non-standard name mangling is a problem with C++. I'm not saying that it's an easily solvable problem.