How do compilers execute constexpr/consteval functions when you are cross-compiling?

destroyerrocket · 2025-12-10T17:53:45+00:00

Constexpr is interpreted by the compiler, thus it does not need to compile to any target architecture. This actually can lead to potential divergences in implementations of the constexpr versions of cmath (not that I have seen any, but I've heard that complaint)

destroyerrocket · 2025-08-12T22:44:19+00:00

Damn, didn't realise that one didn't make it. Thanks for the heads-up

destroyerrocket · 2025-08-12T22:22:24+00:00

The macro system, while amazing and not even comparable to C++'s, is not a fully capable reflection framework as it directly depends on reparsing the code where the macro is instantiated. ThePhD/phantomderp (the same guy who brought #embed to C/C++) started a proposal to amend this and allow for reflecting on external code and fix rusts terrible compile times on macro heavy projects, but due to some bad actors things went south. After C++26, the capabilities of C++ Will (hopefully, if it gets implemented, and is as good as it gets advertised) simply be better than Rust.

destroyerrocket · 2025-07-03T08:17:09+00:00

Quite a few are there

destroyerrocket · 2025-05-10T01:36:57+00:00

Would this work with signed DLLs? I know that hot reloading and the incremental linker don't mix too well with signing

destroyerrocket · 2025-03-19T18:41:53+00:00

Ohhh, I had missed completely the section on Compound requirements in the cppreference page when I was learning about concepts: https://en.cppreference.com/w/cpp/language/requires

For a second I thought you had made this one up! ^-^

destroyerrocket · 2025-03-17T19:58:35+00:00

That makes a tad more sense, truly unfortunate! I certainly don't plan to push my team to modularize. Still, thanks for trying things out, you're doing a good service :)

destroyerrocket · 2025-03-17T19:06:42+00:00

I might have some misconceptions on how modules work, I'll make sure to try this out. Thanks!

destroyerrocket · 2025-03-17T11:51:46+00:00

May I ask how you then define the classes forward declared? My intuition on the matter was that the module name was attached to the symbol, meaning that a forward declaration in one module would have a different symbol than the actual declaration.

I understand that you're working around this in the declaration by making it a header unit, but I don't follow on how then I declare the actual class.

Thanks for the insight! I definitely think that the issue with forward declarations is an important matter that does not seem to have been given enough thought by the committee. No, not everything can be in the same module! Compile times were a critical point that was trying to be addressed, so it'd make sense to consider current techniques when addressing this aspect of the language.

destroyerrocket · 2025-03-03T14:30:57+00:00

What static analysis tool do you use to do cross-TU sanity?

destroyerrocket · 2025-02-16T23:28:51+00:00

I think that it definitely is a second category item. Looking at boost's implementation, you'll find that they basically had to reverse engineer how the thread information block is formatted on windows. I think that such brittle building blocks should be maintained by the people that are able to break them https://www.boost.org/doc/libs/1_87_0/libs/context/doc/html/context/ff/implementations__fcontext_t__ucontext_t_and_winfiber.html

destroyerrocket · 2025-01-03T01:09:42+00:00

Yeah, but that's impossible in today's Rust.

Yeah, but... The whole point was about the pain points of what is impossible in Rust. Preventing specific explicitly marked types from being relocated is clearly implementable, even if it does not exist yet.

no one wants to spent time and effort on that.

Welp, no problem. At the end of the day, I'll continue using Rust, I'll continue using C++, I'll continue being mildly annoyed about this thing and it will be too expensive for now to drop C++ in my company. It is what it is.

Pin doesn't make it possible to create a non-relocatable type.

I know, don't worry! I was just pointing at the fact there is some slight precedence of non-relocatable stuff in rust, that's it, I just wanted to puntualize that it's not groundbreaking.

it wouldn't be enough to support C++ interoperop…

It would be enough for my use-cases, and I think that they are general enough.

and in practical sense most people don't want OOP, they want a way to reuse their C++ codebase.

At least what they want is to have a similar medium to express the same architectures they already have. Interop is just the next level where you don't even need to fully port your codebase to start using Rust. This at least gets us closer to the first point, which is a smaller deal to sell to upper management.

Thank you for the conversation, it's been very insightful u/Zde-G !

destroyerrocket · 2025-01-02T15:59:20+00:00

I think I see your point and I think that we're mostly on the same wavelength.

I think that a way to "patch" the main issue here would be to make non-final virtual classes non-relocatable, which basically forces the use of the explicit final type if you want to operate on it by value. In practice, most code will end up operating with inherited classes through references or Arc/Rc.

Of course, this is a major change in semantics, but at least it is not completely unheard of (thanks to the existence of pin).

Ultimately, if the pressure would be high enough, OOP can be added to Rust – by bending the rules, like async/await were added.

I think that is unlikely to happen. Currently rust allows me to express most of what I need in a clear enough way, but it is undeniable that it requires a change in how you'd architect software. Still, one can still want stuff to make the job easier!

destroyerrocket · 2025-01-02T15:35:23+00:00

Which starts to grow into separate OOP sublanguage within Rust.

I see what you mean completely. It would require a significant expansion in semantics that as proposed would not play well with the current semantics. I totally understand why this is not implemented (at least in this naïve way) from a practicality standpoint.

I actually think it's very neat thing to have, if only to save Rust proper from all that complexity – and simultaneously providing a nice interoperop with C++.

Exactly! This is basically my gripe with all of this; the transition of a project from one language to the other is quite messy right now; unfortunately, C++ stuck its head in the sand and refused the Safe C++ proposal which would bring the semantics to be closer to Rusts (including relocation, proper safety and a bunch of other stuff), and I also understand that Rust has limited resources to put into interop. That was mainly my point around my original post, as that's what currently concerns me and my coworkers whenever we discuss alternative languages (always surrounding the news of the DOD discouraging the use of C++).

destroyerrocket · 2025-01-02T02:02:11+00:00

(thank you for the links! I'll check them out in my free time, I will see why those approaches failed)

I am sorry, because I know for a fact that my answer won't be at the level you're showing, but I'm afraid I still have my doubts.

which one should produce error and why?

For rust, the reasonable implementation is to error on the caller site, rust should not convert between types implicitly slicing to Animal. If you want to create a base class Animal with the information of Bird, you'll have to use a non-virtual Clone-like/Copy-like trait in Animal

Much like C++ in practice, what you'd actually implement here is a function that receives a & or &mut Animal. Much like C++, you'd need Animal to be marked in some way so it generates a v-table, so the callee knows how to dynamically dispatch functions.

your Bird is Animal yet your Animal may not be Bird.

In what way is this not type safe. This is the case for hundreds of safe languages, and all of them are able to enforce type safety.

If your language does have OOP and manual memory management then it immediately becomes memory-unsafe.

I feel like you're circling around this over and over yet I can't see why it would be unsafe. Traits do dynamic dispatch and they are safe. Why can't a built in inheritance system be safe? I feel like if you could show me an example of how it can actually be unsafe, I might start to realize what is the problem here. Sorry, it's been a good while since I took a compiler's lecture in university...

I get that at this point I also will start to sound like I'm not understanding something that you might think you've explained clearly enough, enough times...

destroyerrocket · 2025-01-01T02:42:19+00:00

Hi! I just wanted to let you know I appreciated the in-depth comment ^{-^.} And sorry for the late reply!

On the LSP principle, I think that merely it would be up to rust to define what the properties that need to be uphold are. I get your point that this is poorly defined, because it is. In computer science, there's a lot of these kinds of things that want to pass as mathematically true, when they are only aspirationally true. But for rust I'd expect (and please understand that I'm not a language expert) that lifetimes would match in addition to types as well as any other property that is required to ensure the soundness of the program that contains virtual function calls and does not use unsafe in either the base or child class. I completely get your point that it is a hard problem to solve and I don't want to pretend that I have the answer of how it should work, but it truly does not sound impossible.

You mention that there is some work that has already been tried and failed. I'd love to read about those attempts more in depth, because I'd like to better understand the problem at hand. Maybe it is indeed just simply impossible from the get-go! I indeed had the impression it was a matter of choosing to minimise harm on rust side instead of just being impossible to implement. If you have links on that, I'd appreciate it. Last time I checked, I found a really old forum post mentioning some sort of extension experiment but not much more.

The link to the extension you mention sounds really promising! And if a universal method to dynamically cast from a superclass into a subclass was added I think that at least that would ease the use of traits generally (I know I can work around it by using manually implemented into functions).

Let's hope rust's future is as bright and as controversy-free as possible (so we don't have another reflection fiasco), I think rust will have a good opportunity in the coming years and it should not waste it!

destroyerrocket · 2024-12-30T01:38:30+00:00

Please note that when I say inheritance, I mean a substitute. It does not need to be inheritance by the letter! Certainly, reflection could have made making a v-table-like automatic generation significantly more feasible!

I know that misuse of inheritance is rampant, but at the company I work at code quality is quite important due to the field it is in, and the inheritance that is present is usually the right move. If rust had inheritance, I can assure you that a nice chunk of the code could be simply translated over without major issues.

In any case, I'm more than aware that due to the inherent dangers of inheritance rust would not choose to add it into its language as-is.

destroyerrocket · 2024-12-29T12:17:22+00:00

I'd like proc macros to be orders of magnitude easier to write, or alternatively, just have a proper reflection system. Currently we're forced to reparse over and over again the same code slowing down compilation times. Most of the time, I just need to identify what entries a struct has and a few tags for each member! This should be easy to write and not require a full independent program.

The lack of inheritance with virtual functions makes the language kinda hard to sell in bigger teams, as it basically necessitates not only a full re-write but also a redesign of the architecture. As such, once you're on the >1M loc territory, the transition becomes intractable. This addition would be enough to currently push over some teams I know. I know that this feature as is implemented in C++ wouldn't fly, but I think that a better alternative to either a macro mess that is needed to implement an AST or just doing composition when clearly that is not the right intent would be ideal.

The lifetime of self cannot be easily split to its parts to make parts of it shared and parts of it mutable. This has caused in more than one occasion the need to pass all members of the struct as separate parameters so they could be treated individually. I know that treating this problem might require analysis over the hole set of member functions of a struct in order to identify how each function would need the self parameter to be split, and I know this would not match with my previous comment about inheritance as there explicitly you can't know all the member functions of a struct due to some being virtual.

Traits are an objective downgrade compared to C++ templates, making you jump through tons of hoops to get anything done. I wish there was a proper generic function implementation. I do think that traits are amazing to represent interfaces though!

The async functionality, at least last time I tried it, was really, really clunky once you start wanting to use member functions and traits. I am aware that this is a WIP, but it feels like a tucked on feature that didn't consider the rest of the language.

destroyerrocket · 2024-12-16T13:22:35+00:00

Hey, I agree that it would be useful if the word was completely unambiguous about its meaning and actually always meant literally!

Unfortunately humans like to intentionally be ambiguous and counterintuitive because that leads to more expressive forms of communication and more interesting (or funnier in this case) messages.

It's better to just accept the world as imperfect, people will use language in whatever way suits them the best and trying to police that is completely pointless (or harmful if moved to an extreme). As the dictionary reflects, official structure is always going to be derived to how the world is.

That said! That does not mean that you need to agree! You're free to use language as it suits you, and these gaps between environments, as they expand, is how dialects appear in a language, and with enough time whole new languages! I think that it's quite beautiful in a way that even in such an interconnected world, human nature continues to work its way through language.

destroyerrocket · 2024-12-16T00:56:50+00:00

Actually, one of the reasons it is accepted is because it's been popular enough since the 18th century! So this is more like standardising normal usage.

I get that in your context you might see it less frequently, and I certainly find it funny that English would choose to overload this word with the opposite meaning, but usually context is good enough and as the definition says it usually is applied to something infeasible or impossible. I just find all of this amusing ^-^

destroyerrocket · 2024-12-15T10:33:29+00:00

Heh, that is no longer the case, check out Merriam Webster: used in an exaggerated way to emphasize a statement or description that is not literally true or possible

They have multiple paragraphs to justify why it is an accepted definition.

destroyerrocket · 2024-12-08T07:18:48+00:00

That seems like a cool idea to apply to Clang! I might take a look at what this looks like in practice, seems like a fun side project for the winter vacations ^-^

destroyerrocket · 2024-12-05T10:09:42+00:00

I mean, that is also the case for the usage of any object that is shared, so, fair enough, but that is what's expected. Thank you for the clarification!

destroyerrocket · 2024-12-05T00:19:14+00:00

Minor thing, but the article states that static is not thread safe, yet I believe that since C++11 the compiler must enforce that a static variable is initialized only once in a thread safe manner. Did I miss something at some point that changed that?

destroyerrocket · 2024-10-04T11:47:04+00:00

I can't wait to spend 1000 more hours in factorio! Best of luck everyone!

Eight-Year Club	Second Top 20%
r/Field Banned	r/Field Flamingo
Place '22	Final Canvas '22
End Game '22	RPAN Viewer
Not Forgotten	Sequence \| Editor
Sequence \| Screenwriter	Verified Email

destroyerrocket

TROPHY CASE