71–80 of 80 posts
Earlier quoted context omitted.
Dunno, time to check your plugins slowing down the IDE. Better not having Resharper around.
I have zero plugins installed. VS is just so slow that it's even outmatched by a javascript/Electron app like vscode.
Earlier quoted context omitted.
I have zero plugins installed. VS is just so slow that it's even outmatched by a javascript/Electron app like vscode.
Then it is definitely a "my computer/your computer" problem.
Earlier quoted context omitted.
This was one of the best decisions that Rust and Go did; not have constructors. In C# this is super annoying too, specially when you need an async operation to construct a type. This is usually done by having an private constructor and then using a static public method to create the type.
Rust and Go have no form of a conversion operator (even if not a constructor), which makes scripting a type system essentially impossible. Numeric libraries in both of those languages are extremely cumbersome, largely for this reason.
Rust not only has the 'as' operator for this exact purpose, but it also has the suite of traits From, Into, TryFrom and TryInto for the infallible and fallible conversions respectively.
Earlier quoted context omitted.
Wrong is too strong. The code is okay given the constraint — this is a guide for C++ programmers thinking in C++ terms, not for teaching purely idiomatic Rust from the ground up.
Which, as a cpp programmer trying to pick up Rust, is honestly fine to begin with. Once you've written varying amounts of code in 5-10 programming languages, it is incredibly tedious to flip through pages trying to teach you how if conditions work and how for loops work: my brain doesn't pay attention even if I try. This is more like: how to survive rustc as a cpp programmer which is honestly your mindframe when you…
Clippy likes idiomatic Rust and will suggest you change code that's not idiomatic into code which is, even when the machine code would be completely identical - the rationale being that the maintainer (later you with more Rust knowledge, a colleague, or even some stranger) is more likely to follow the idiomatic Rust and the whole point of source code is that it's for humans not machines.
Clippy is no substitute for a capable human reviewer, it has no sense of taste or style, no higher level understanding of the problem, but it's free and it's right there and unlike a human reviewer you won't feel judged which can be sensitive when you're learning a new language and are used to having mastery.
Earlier quoted context omitted.
Can you think of good reasons why an organization would hesitate to use C++ exceptions?
Legacy code writen as if it was C with a C++ compiler, or that predates the C++98 standard (during the 1980-90's, where C++ARM was the only guidance), the Orthodox C++ folks, claiming that they are too slow or bloated (most of the time based on hearsay and not profiled), on embedded computers better than everything I owned since 1980's until 2000's, put together. The same folks won't have a second thought distributin…
Earlier quoted context omitted.
Rust and Go have no form of a conversion operator (even if not a constructor), which makes scripting a type system essentially impossible. Numeric libraries in both of those languages are extremely cumbersome, largely for this reason.
I don't understand this comment at all. Rust not only has the 'as' operator for this exact purpose, but it also has the suite of traits From, Into, TryFrom and TryInto for the infallible and fallible conversions respectively.
Earlier quoted context omitted.
Async vs. non-async is the main example today. There are libraries that support one or the other, or sometimes one library will have two usage modes (effectively two different code bases) because you can't really mix them. In the future who knows, because we don't know what features will get added to the language.
std vs nostd is another big one. Within nostd there are a ton of tiny fragmented worlds. For example, the Linux kernel ecosystem will likely development its own flavor of rust, especially when it comes to memory model. Old Linux distributions will end up with fairly ancient compiler versions that require code to stick to older conventions. I doubt well end up with people stuck on targeting c89 sort of situations, but…
There are so many different flavours of C++ put there that this guide doesn’t exactly do itself the credit it deserves. There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible. Likewise when discussing modules in rust while completely ignoring the existence of modules in C++ that is actually support by modern tool…
> There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible. This guide does exactly that in C++ for methods on enums. For members, won't this result in all instances of an "enum" having all fields? That's not really comparable to Rust enums, if that's what you mean.
Rust enums are not enums, they are tagged unions and there is a C++ equivalent, std::variant which was discussed. It’s not got nice tooling around it like match but it exists and can be used identically.