agreed, zig only from now on
Zig doesn't satisfy the safety concerns that make even modern C++ undesirable.
Nim is what you want.
It's time to halt starting any new projects in C/C++
501–510 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#502Earlier quoted context omitted.
While that is true, using integers as pointers in Rust just makes them invisible to the borrow checker. It's a useful trick but one should be aware this is basically unmarked unsafe code. Though in Rust it has another advantage over pointers: it doesn't force you to suddenly annotate every single type that touches your data structure in any way.
There's nothing unsafe about integer indices because access to the array they index will incur bounds checks.
This means that you have array accesses that cause index out of bounds fatal errors instead of invalid pointer dereferencing that causes fatal segmentation failure errors. Detecting this kind of bugs reliably is a very good thing, but preventing such errors (and optimizing away bounds checking if possible) would be better.
Re: It's time to halt starting any new projects in C/C++
#503You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…
With all due respect, this is coming from a Win32 API C programmer who happens to save the code in files with .cpp extension. In other words, not familiar with modern C++.
Re: It's time to halt starting any new projects in C/C++
#504Earlier quoted context omitted.
Pretty sure most win32 now has an alternative utf8 function?
No, they don't. We typically use the UTF-16 functions (with the W suffix).
More specifically, the 8-bit 'A'-suffixed functions could be used as UTF8, but only on some versions of Windows if, and only if, the system code page is set to use UTF8 instead of the Latin1 (or whatever).
Re: It's time to halt starting any new projects in C/C++
#505I wish technical people would stop pretending that choice of programming language isn't just largely very much a personal choice and then occasionally based on whatever else the ecosystem has to offer. Yeah, most people doing scientific computing might use Python, but then you have whole groups of people who are used to something else and would plainly prefer not to use a language for completely personal reasons. Lik…
One's lived experience may be that all languages are roughly the same, but that's only because one tends to only sink time into languages roughly the same as the ones they're familiar with. Something like 70% of languages have been derivatives of Java since Java was invented, but if you cannot imagine how programming could change meaningfully from Java then you are not trying hard enough. (In particular nobody who has learned a functional language, especially Haskell, would express this opinion.) Rust is a meaningfully different language, fundamentally requiring a different approach to design while offering much more power.
Re: It's time to halt starting any new projects in C/C++
#506Earlier quoted context omitted.
Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.
This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anythi…
This is a tricky subject.
Rust being a low-level library, adding something means inherently choosing a preferred approach to a problem rather than another, which may be disagreeble.
The consequence is that there would be still the sub-sub-dependencies problem, because the author of a crate may decide that the stdlib implementation is not appropriate for the use-case (Rust is low-level; low-level development is typically "pickier" than web development).
I personally think that it's good not to have higher level APIs in the stdlib. My only exception to this is the exclusion of fast hashing, because this choice had side-effects beyond simple need for an API.
Re: It's time to halt starting any new projects in C/C++
#507Earlier quoted context omitted.
What is the advantage of a slotmap style approach vs references? It seems a bit manual and error prone, and the errors risk being silent references to wrong objects that may result in security vulnerabilities or data corruption.
The advantage w.r.t references is that with Slotmap, you can express cyclical data structures, whereas with references you can't. The advantage w.r.t plain Vec and juggling integer indices is that unlike integers, Slotmap keeps track of the "identity" of the stored object; the keys are unique to that object, and you can't accidentally refer to a wrong object with them. > errors risk being silent references to wrong o…
> Slotmap keeps track of the "identity" of the stored object
(I am not sure if slotmap uses this strategy)
To give more details some of these data structures use generational indexes, a pair (generation, index) where index is a plain index of the underlying vector and generation is a bookkeeping counter of how many times you have allocated a value to that index. These two values can be combined in a single 32bit-64bit value but additional memory would be required to keep track of the counter.
E.g. with a vector of length 2
{meta: [0,0], data:[...]}
malloc -> (1,0)
{meta: [1,0], data:[...]}
malloc -> (1,1)
{meta: [1,1], data:[...]}
free(0)
{meta: [2,1], data:[...]}
malloc -> (3,0)
{meta: [3,1], data:[...]}
free(0)
{meta: [4,1], data:[...]}
malloc -> (5,0)
{meta: [5,1], data:[...]}
free(0)
free(1)
{meta: [6,2], data:[...]}
malloc -> (7,0)
malloc -> (3,1)
{meta: [7,3], data:[...]}
This way if you tried to access the pointer (5,0) the library can check that at index zero of the meta array the generation is 7 and conclude that you are doing a use after free (in this example even generations denote unallocated memory).
This is a description of a very simplified algorithm.
Re: It's time to halt starting any new projects in C/C++
#508Inside Azure there’s an over reliance to C#, and the older versions of it to boot! So one team in charge of making .NET run faster and better, while the other one drags on using decade old versions Then for “speed” there’s weird mashups of C++ and C# that are just littered with terrible internal build tools that harken back to a nice 2010s and the idea of: “Idk it builds in my machine just fine” As far as Rust goes,…
This ^^
Really, anyone senior in Microsoft shouldn't be making this sort of argument. They already have a perfectly fine memory safe language that they could use way more widely than they already do. The number of bugs in Windows that either shouldn't happen or are too hard to debug when they do, because Microsoft insist on still using C++ instead of C#, is just phenomenal. Why can Google ship a mobile OS in which large chunks including the entire GUI layer run on a JVM, but Microsoft can't ship memory safe code in Windows for even the non-performance sensitive parts because they have some irrational fear of C#?
The issues there are obviously cultural. If Rust is hard-man enough to convince Microsoft devs to adopt it when they otherwise reject C# then fine, whatever, do what it takes. But to generalize this to the rest of the software industry is silly. Most of us have been writing code in memory safe languages for a very long time, and they could be used way more widely than they are. If you want to make more code memory safe you'd be better off advancing .NET ngen or JVM AOT at this point than pushing Rust, at least they can handle arbitrary data structures in safe ways.
Re: It's time to halt starting any new projects in C/C++
#509I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…
In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.
Sure. But the selling point of Rust is that the compiler will check ownership and lifetimes for you. That goes away if you use integer handles, in which case I might as well use another language.
Re: It's time to halt starting any new projects in C/C++
#510[deleted]