91–100 of 192 posts
50 years is not a good age for a bottle of wine. There are wines that are still enjoyable after such long time, but will hardly express the same potential they had at the peak of their maturity. Many other bottles will be already totally gone after 50 years.
I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…
"Handle" how? If you're just shuffling bytes around, you don't need to worry about it. If you need to iterate through by codepoints, there's stdlib Utf8View module, though I understand this aspect of the standard library is set to change before 1.0.
The fact that multi-byte codepoints don't have bytes that could be ASCII gets you decently far for common things like splitting a string at a newline, or otherwise matching against a char.
edit: actually, were you talking about the code in the post? Looking at it now, I see it's buggy in this regard, if you're wanting a ? to match ü. I think basically what you'd do is in the branch corresponding to the ? you could use the stdlibs's utf8ByteSequenceLength function to skip the text ahead that many bytes, while advancing the pattern by just the one byte.
Earlier quoted context omitted.
I dunno. One could say that C string handling is "simple" (it's just byte buffers!) or that manual loops are "simpler" than proper iterator abstractions, but those are both constructs that are hideously error-prone in practice. Perhaps it's the other way around and manual buffer management is actually the complex thing, since your application logic will have to involve a lot of code doing toil that isn't directly rel…
Are manual loops, the kind that that can be replaced by iterators, really "hideously error-prone"? Don't get me wrong, I'll take the iterator approach every day, because the index is simply complexity I don't need, but I've never seen issues with the basic for(int i...). Off by one errors tend to happen when you start doing index arithmetic, and iterator are not going to help you there.
Maybe you need to iterate over two differently sized datastructures in lockstep, or over a complex nested structure, or accumulate and filter the values, or load the data into a temporary buffer that gets flushed and reused once it fills up, or maybe your data source is infinite, or all of the above.
These are cases where using iterators is significantly safer and notably, more composable.
Earlier quoted context omitted.
This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.
vcpkg install. It integrates with cmake too!
Earlier quoted context omitted.
If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.
"Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions. ... yet every time time I've been told "you don't need Rust, just use C++", I can point to at least one UAF in their own code, and have even pointed to CVEs on Mitre for their own projects! People make mistakes. Use tools that stop these mistakes, rather than helping you to "wri…
Earlier quoted context omitted.
> If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a cal…
Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?
Earlier quoted context omitted.
There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?
This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). The probl…
(No offense, doing a fair bit of C work myself)
Earlier quoted context omitted.
This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). The probl…
Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)
C, CAN be a bleading edge. Depends on who is using it., based on a simple fact that there is nothing you cant do.
Except for the amount of money the companies need to pay for skilled c/c++ developer against the developer.
I think that in contrast of common belief, the difference in languages has nothing to do with benchmarks. But it has everything to do with price/performance. And performance is not important today (`I'll just start another "cloud" instance whatever the cost`).
So we are getting to the price. 10 monkeys for the price of one "real" developer. Why? I was reluctant to use java/c# software due to a fact that it was mostly a crap (and still is). Now I am forced to use it as there are no alternatives. The software is just another thing where the quality is non relevant to the earning. So we eat shit.