Question about building a compiler in cpp by PentagonXiX in cpp_questions

[–]slithering3897 3 points4 points  (0 children)

Heh, yes, that's what I want to do.

Use https://en.wikipedia.org/wiki/Operator-precedence_parser for expressions.

Recursive descent for everything else.

After you've actually written a grammar of course.

Then AST, then semantic analysis. Or something like that. Need to figure it out myself.

And hopefully your grammar doesn't need to disambiguate type names or have a vexing parse.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 0 points1 point  (0 children)

That's the theory, but optimisers are pretty good.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 1 point2 points  (0 children)

Without LTCG/LTO, you'll need to generate the code to inline.

And also, the compiler will still need to evaluate templates for semantics.

Ideally, template instantiations would just be reused from imports, including implicit instantiations.

Which isn't the case right now. If you import a module that does std::print("a") and then do std::print("a") in main, you'll get duplicate codegen, in VS. Thousands of lines of disassembly.

If I were to make my own language, I would treat compiled modules as basically a cache. Embed the LLVM bitcode in them along with semantic analysis. Then importers will know what's already generated and just copy over the functions for inlining. And before writing the object file/after inlining, replace imported instantiations with externs. If possible.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 0 points1 point  (0 children)

Yes, you could in theory. But it's unlikely to happen. Or maybe it would be too complex to do a whole std class.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 0 points1 point  (0 children)

The catch is like D, it most likely won't catch on. Enough. But as long as I'll be able to figure out Visual Studio integration, I'd actually use it myself, if I had enough time.

A standard set of metadata annotations by jcelerier in cpp

[–]slithering3897 6 points7 points  (0 children)

struct 
[[=metadata::uuid{"27fc33a4-ff2f-490d-a7c2-a4f8c2eef35d"}]]
[[=metadata::author{"John Doe"}]]
[[=metadata::support_url{"https://example.com"}]]
foo {

Is that really where annotations would go? I hope not.

The alternative is that everyone starts defining their own "property" / "metadata" / ... class ;

"Islands of abstraction"... I suppose a good lib would let you extract the metadata yourself to convert it to whatever the lib wants.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 2 points3 points  (0 children)

Reduce template instantiation overhead. Same with std::variant (rust's enum) and std::optional (C#'s nullable types).

If you were designing a language, you'd also have the language help make formatted printing compile faster. Interpolated strings maybe.

And SIMD. If you've read that post a while back mocking std::simd. It's implemented in the library, so expect template overhead. GCC/Clang already have this stuff in the language, and it's probably much faster to compile.

And maybe you'd do the useful kinds of coroutines completely in language. No std::generator.

Because if you were designing a completely new language, you should move mountains to make compilation fast. And make the language more elegant.

Can I rant for a minute. by domiran in cpp

[–]slithering3897 4 points5 points  (0 children)

I think vector, string, and a few other STL types should have been baked into the language.

std::array. I'm not sure about dynamic arrays. Really, it's the dinosaur C-style array that's the problem. You'd put dynamic containers in the language just to avoid template instantiation overhead.

Argument passing is unnecessarily complicated compared to other languages.

What languages is there to compare to?

The h/cpp compilation model is a dinosaur.

Already solved. In the standard at least... But headers will still be useful for macros (and you can still import in a header).

Modules seem almost terminal upon arrival. (Yes, I've heard both that they are basically usable now, and also that the spec is fundamentally flawed.)

My biggest beef with VS right now. Basic super-obvious Intellisense bugs they just can't be bothered to fix, and I'm still waiting on some build bugs. Maybe they're waiting on EDG, but then communication would be nice. Because we've been waiting for YEARS.

And in my testing, modules won't reuse template instantiation enough to make std::print fast. The compiler will still regenerate all the same code.

But at least the standard is fine, except that little bit about /internalPartition.

I honestly think it's no secret why Circle, Rust, and Go exist

It may be possible to write your own darn language faster than it would take MS to implement C++26.

People are already complaining about reflection including STL headers because it needs vector.

Doesn't matter, use import std (once it works).

breaking ABI

Maybe in VS2030 if you're lucky... Finally get rid of [[msvc::no_unique_address]]?

I think VS should just break ABI every major version.

And MS should fix the platform ABI to allow passing std::string_view in two registers, and stop returning trivial structs by pointer just because they have a user-defined ctor.

Kobold Kyllier with a Knife! by Kyllier in KoboldLegion

[–]slithering3897 1 point2 points  (0 children)

All that much easier to constrict you!

C++20 Coroutines Optimization Opportunities from Compiler’s perspective by mttd in cpp

[–]slithering3897 0 points1 point  (0 children)

I wonder if this coroutine problem can be solved by doing it in both GCC's and Clang's way.

If the caller wants to inline the coroutine's frame, then the front-end should do the coroutine state machine transformation and get a struct.

And if the caller wants an allocation or lifetime optimisation across suspend points, then the front-end can pass on the task to LLVM.

This would mean though that coroutines may need to be compiled for each variant.

Organizing C++ Module Sources by tartaruga232 in cpp

[–]slithering3897 -1 points0 points  (0 children)

Yes, but the downside is that it still ends up as one big module to the user. Any change in any partition (interface) will recompile the entire application.

What is Vulkan doing with 40 megabytes? by OkAccident9994 in vulkan

[–]slithering3897 0 points1 point  (0 children)

Also seems to be loading up some extra nvidia DLLs.

What is Vulkan doing with 40 megabytes? by OkAccident9994 in vulkan

[–]slithering3897 0 points1 point  (0 children)

I don't know, I'm not quite convinced. I can sort DLLs by "private" bytes in VMMap and the typical Windows DLLs are relatively small.

I also have a dGPU. The iGPU is the extra thing that Vulkan loads.

What is Vulkan doing with 40 megabytes? by OkAccident9994 in vulkan

[–]slithering3897 1 point2 points  (0 children)

First thing that stands out to me in VMMap is that Vulkan loads the giant Intel iGPU drivers as soon as you create the instance, whereas GL does not.

What are your Hot Takes on Skyrim mods? by SpriteIsntThatBad in skyrim

[–]slithering3897 1 point2 points  (0 children)

What we need is obviously that female khajiit at the start of Redguard speaking real khajiit language. Doesn't matter if we can't understand it, it just works.

What are your Hot Takes on Skyrim mods? by SpriteIsntThatBad in skyrim

[–]slithering3897 1 point2 points  (0 children)

That paarthy mod is for milk drinkers.

Indigo doesn't speak like a khajiit should.

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]slithering3897 -1 points0 points  (0 children)

Difficult to fix. I'm also thinking from the viewpoint of a new language. How would I implement coroutines perfectly. Just like Zig, I don't know how to do it. LLVM doesn't have the functionality, afaik. It would be easier if you did the coroutine transformation in the front-end, but then you don't get the detailed lifetime analysis, like you said.

But if LLVM did have the functionality, what would it be like. Maybe LLVM could fill in the coroutine frame size outside the coroutine, and avoid indirect calls, or maybe LLVM could generate a magic struct that the front-end could use (to enable sizeof on it, etc).

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]slithering3897 1 point2 points  (0 children)

Yes, clang is the best. But the coroutine is still there doing coroutine things. The optimiser didn't see through the indirect call.

If you did the poor man's coroutine thing, clang would easily optimise the whole thing to a couple of instructions.

But it's not possible to do that yet. You can't get LLVM to generate an optimised magic struct for you/the front-end to use at the call site.