441–450 of 475 posts
Earlier quoted context omitted.
Yes, but the C++ library becomes inherently broken because there is no error reporting.
Only the parts that need to heap-allocate. Which includes most containers, but not e.g. algorithms.
Earlier quoted context omitted.
Can't you disable exceptions?
Yes, but the C++ library becomes inherently broken because there is no error reporting.
Earlier quoted context omitted.
That works for something where the events being handled are like "serve a web page" or "compile a C function". It doesn't work for a spreadsheet or word processor or a web browser.
I'm not convinced it even works very well for either of those cases. It's common in many applications to return the result of a computation as an object in memory, like an array or string of arbitrary length or a treelike structure. Without the ability to allocate memory which exists after a function exits, I'm not sure how you'd do that (short of solutions which create arbitrary limits, like writing to a fixed-size…
My preferred solution is definitely to use the GC. With some help if you want. You can GC the nursery each time around the event loop. You can create and destroy arenas.
Earlier quoted context omitted.
> You have to memorize the borrow checker Correct me if I am wrong, but Rust at least has a borrow checker while in C (and Zig) one has to do the borrow checking in their head. If you read a documentation for C libraries, some of them mention things like "caller must free this memory" and others don't specify anything and you have to go to the source code to find out who is responsible for freeing the memory.
The point is that any formal borrow checking will reject perfectly valid patterns because they are impossible to statically prove, and this comes up especially often with data structures like graphs. So you end up struggling against the compiler - either you just go unsafe (in which case you have to be even more careful than in C and Zig because Rust makes more optimization assumptions based on ownership which you're…
C/Zig do not even allow to specify who is responsible for freeing the allocation, and every time you use a library you need to either search the docs or (more often) reverse-engineer the code. Probably this is why writing or checking C code is so slow. I end up adding annotations to function prototypes but nobody is going to validate them so they only serve as documentation.
Earlier quoted context omitted.
I saw mentions of Zig here often, so I decided to look at the docs to see what features it has. I had to scroll through all the docs only to find myself disappointed by the fact that Zig doesn't help with memory management in any way and advices to use comments and careful coding instead. And what adds to the disappointment is that its plus/minus operators do not catch overflow. If I wanted undefined behaviour, I cou…
> plus/minus operators do not catch overflow They do (in Debug and ReleaseSafe modes)
Without reading the comments here, I read the blog entry first. After I finished I was puzzled, "what is the author trying to communicate to the reader here?" As near as I can determine, enough people weren't using the author's program/utility because it was written in a language that hasn't been blessed by the crowd? It is hinted at that there might be issues involving memory consumption. The author does not write l…
I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years. Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other pro…
Have you looked at Zig? It is often termed a modern C where Rust is the modern C++. Seems like a good fit.
If anyone is the modern c++ its D. They have template metaprogramming while rust has generics and macros.
Rust doesn't have constructors or classes or overloading. I believe its type system is based on Hindley–Milner like ML or Haskell and traits are similar to Haskell type classes. Enums are like tagged Union/sum types in functional programming and rust uses Error/Option types like them. I believe rust macros were inspired by Scheme. And finally a lot of what makes it unique was inspired by Cyclone (an obscure excitemenal language that tried to be a safer C) and other obscure research languages.
I guess rust has RAII that's one major similar to c++. An there's probably some similarities in low level memory access abstraction patterns.
But I'd describe rust as more of an imperative non GC offshoot of MLs then a modern c++ evolution.
Earlier quoted context omitted.
Funnily enough, 16 years ago, I too was in exactly this type of company. C++, using classes, inheritance only for receiving callbacks, most attributes were public (developers were supposed to know how not to piss outside the bowl), pthreads with mutexed in-memory queues for concurrency, no design patterns (yes we used globals instead of Singleton) etc. So blazingly fast we were measuring latencies in sub 100-microsec…
Yes, very similar. We had pthreaded mutexed queues too, and measured timings with clock_gettime() with CLOCK_MONOTONIC. Our facial template match runs at 25M compares per second per core, and simply keeping that pipeline fed required all kinds of timing synchronizations. The only community I know that produces developers that know this kind of stuff intimately are console game programmers, and then only the people re…
Earlier quoted context omitted.
What do you consider the difference in their core models. Rust and C++ both use RAII, both have a strong emphasis on type safety, Rust just takes that to the extreme. I would like to even hope both believe in 0 cost abstractions, which contrary to popular belief isn't no cost, but no cost over doing the same thing yourself. In many cases it's not even 0 cost, it's negative cost since using declarative programming can…
Rust is basically what you get if you start with ML and then do enough to avoid having garbage collection.
Rust feels like taking an imperative language and adding ML features till you cannot anymore.
Earlier quoted context omitted.
Try doing C with a garbage collector ... it's very liberating. Do `#include ` then just use `GC_malloc()` instead of `malloc()` and never free. And add `-lgc` to linking. It's already there on most systems these days, lots of things use it. You can add some efficiency by `GC_free()` in cases where you're really really sure, but it's entirely optional, and adds a lot of danger. Using `GC_malloc_atomic()` also adds eff…
>Try doing C with a garbage collector ... it's very liberating. Doing that means that I lose some speed and I will have to wait for GC collection. Then why shouldn't I use C# which is more productive and has libraries and frameworks that comes with batteries included that help me build functionality fast. I thought that one of the main points of using C is speed.