Java gets a bad reputation from proponents of FOMO/fad-driven development, but the whole Java ecosystem was built for the web. Anyone is hard-pressed to find a better tech stack than Java-based frameworks without resorting to hand waving and passing personal opinions as facts.
I love C# and the whole .NET Core ecosystem, but even I have to admit it's very hard to argue against java.
Smart pointers were introduced over a decade ago, and since their introduction there were already four updates to the C++ standard. There is really no excuse to shy away from smart pointers at this point. I really recommend you get up to speed on them.
compiler support
That remark was on sum types, not monads. You do not need "compiler support" to have Result or neither monads in C++. There are already plenty of libraries that implement those. I use them in some of my projects. No compiler support needed.
As I said, sum types are not required for Return or Either monads. At best, they are convenient.
I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.
Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.
It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.
I don't think this is a lack of support in C++. There are already a few C++ libraries that implement Either and Result monads. It would be nice if those were supported in the C++ stand library, but that does not stop anyone from adopting them.
True, though here the hack is incredibly unintuitive for the programmer.
I don't think this trick is anything other than trivia. The happy path to enable RVO is to provide a move constructor. There is nothing unintuitive about that.
This trivia item just points out that the way the C++ standard is specified, the definition isn't actually required. That's hardly relevant.
Not to mention the compiler error that should catch this now only occurs at link time, and linking errors are even more cryptic to grok.
There is nothing peculiar about handling missing definitions. Linkers only flag those if a symbol is actually missing.
When they made RVO mandatory, they should’ve removed the constructor declaration requirement as well, instead of a half-ass solution like this.
I don't think that your observation makes sense, or is even appropriate to the topic. RVO requires a movable type, and the rule of 5 is a well established aspect of C++. RVO does not change anything in that regard.
Let me give you a quick life lesson.
You've typed too many words to try to rationalize your toxic behavior.
I repeat: pay attention to what you say and do. All communities have their bad apples, but this does not grant the likes of you the right to spoil the whole barrel.
I am constantly losing track of which function is where and I’m never quite sure if I have code in the right place.
That's not a Rust concern but a software architecture concern. The software architecture pattern you follow determines how the project is structured taking into account what requirements it needs to comply to address common requirements, such as ensuring that things that change a lot will be easier to change and things that don't change won't get in the way.
I recommend you read up on topics such as layered architecture, hexagonal architecture/ports and adapters, clean architecture, etc.
That said, incels REALLY hate Naomi for whatever reason.
I think you're way out of line with the insults and broad accusations. I am bare new to the 3D printing community and I never heard of Naomi Wu before. The article only mentions she is an influencer, and this discussion makes little to no efforts to add context to why is a particular influencer relevant to 3D printing.
Calls to clarification are faced with comments like yours, accusing those of asking a simple question of being incels.
This behavior reflects poorly upon you in particular and the 3D printing community in general. Please pay attention to what you say and do.
Well, it’s really interesting that this is a hack that works, but you’re really fighting the compiler here.
I don't think that's a fair take. Keep in mind that the blog post covers a very specific corner case: you want return value optimization but you don't want a movable type. If you wanted the type to be movable, you just had to went ahead with the happy path and define the move constructor.
What this blog post illustrates is a clever observation over a consequence (possibly unintended) of the way the C++ standard specified this behavior: for RTO to kick in, a necessary and sufficient condition is to have the move constructor declared. Declared but not defined. Oh.
This is making me all the happier I switched to Rust 😂
Except that Rust is not specified in an international standard, so this sort of things can either be downplayed as implementation bugs or implementation-specific quirks.
Focusing on code coverage (which doesn’t distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.
The usefulness of code coverage ratios is to drive the conversation on the need to track invariants and avoid regressions. I agree it's very easy to interpret a metric as a target to optimize, but in this context coverage ratios is primarily used to raise the question on why wasn't a unit test added.
It's counterproductive to aim for ~100% but without this indicator any question or concern regarding missing tests will feel arbitrary. With coverage ratios being tracked, this topic becomes systematic and helps build up a team culture that is test-driven or at least test-aware.
Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them.
True. Coverage ratios are an indicator, and they should never be an optimizable target. Hence the need to keep minimum coverage ratios low, so that the team has flexibility to manage them. Also important, have CICD pipelines export the full coverage report to track which parts of the code are not covered.
The goal is to have meaningful tests and mitigate risks, and have a system in place to develop a test-minded culture and help the team be mindful of the need to track specific invariants. Tests need to mean something and deliver value, and maximizing ratios is not it.
You're misreading it. What do you think a '
Result' type is?