Earlier quoted context omitted.
I have one here: https://github.com/dschatzberg/intrusive It can be used in a freestanding (nostd) environment such as a kernel. It uses unsafe code but provides a safe interface. The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.
Off topic, but: I thought in rust they like to statically link everything. So how does that go with the LGPL license you chose?
Why should I have written ZeroMQ in C, not C++ (2012)
141–147 of 147 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#142Earlier quoted context omitted.
I have one here: https://github.com/dschatzberg/intrusive It can be used in a freestanding (nostd) environment such as a kernel. It uses unsafe code but provides a safe interface. The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.
How is it possible to write a no-allocation intrusive linked list without move constructors ? When you move one of the nodes (or sentinel if you use one) it would invalidate the links in other nodes.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#143Earlier quoted context omitted.
"Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. And not just things like point size or margins or what have you, but the contents themselves vary. Some specifications include an EBNF grammar, others may try to describe it via natural-language rules, and others may just say "see the reference implementation". Some specifications include docu…
> "Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. How would you prefer to compare language sizes? Gut feel? Surely that's even worse. I'll certainly admit that - like LOC measurements - it's a metric one can't take too seriously on it's own. On the other hand, it's a useful starting point for discussing said variables. For example, when I w…
> How would you prefer to compare language sizes? Gut
> feel? Surely that's even worse.
Why is it necessary to compare "language sizes" at all? Nobody has ever demonstrated that the "size" of a language (by any definition) has any measurable effect on the quality of the software written in that language. It's as pointless as the classic vim vs. emacs argument.Re: Why should I have written ZeroMQ in C, not C++ (2012)
#144Earlier quoted context omitted.
> "Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. How would you prefer to compare language sizes? Gut feel? Surely that's even worse. I'll certainly admit that - like LOC measurements - it's a metric one can't take too seriously on it's own. On the other hand, it's a useful starting point for discussing said variables. For example, when I w…
> How would you prefer to compare language sizes? Gut > feel? Surely that's even worse. Why is it necessary to compare "language sizes" at all? Nobody has ever demonstrated that the "size" of a language (by any definition) has any measurable effect on the quality of the software written in that language. It's as pointless as the classic vim vs. emacs argument.
It seems relevant in the context of how difficult it is to master a given language, which spawned this thread of debate. Do you disagree that language size is any sort of barrier?
Again, only one metric, to be taken with a measure of salt. But would you prefer we compare languages based on gut feel? Or is comparing languages unnecessary as well?
> It's as pointless as the classic vim vs. emacs argument.
Understanding the merits of vim vs. emacs informs you which you might prefer. The answer to that argument, over which is "ultimately better" is certainly pointless. You can simply choose whichever works best for you, especially as you can change your mind mostly at will.
But people don't simply have the choice of "choose whichever works best for you" when it comes to programming languages on a team project. Nor are languages as fungible as editors when it comes to changing your mind - switching languages mid-project is a massive time sink, and frequently fatal to the project.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#145Earlier quoted context omitted.
Is this a sort of informal RFQ? What's your budget?
There's no shortage of people taking a stab at language design and even resources to pull it off. The post was intended to provide a simple route for making (a) a better C++ or (b) a ZeroMQ variant with improved robustness & maintenance. Just inspiration and stuff to think about. If I had a budget, a few companies that can get the job done would already have the contract.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#146Earlier quoted context omitted.
There's no shortage of people taking a stab at language design and even resources to pull it off. The post was intended to provide a simple route for making (a) a better C++ or (b) a ZeroMQ variant with improved robustness & maintenance. Just inspiration and stuff to think about. If I had a budget, a few companies that can get the job done would already have the contract.
Oh, I think I see — you're generously sharing your language-design expertise by guiding us towards working on things whose potential you can see, potential that a less experienced or talented person might miss?
So, it's not that people are stupid or inferior to me. They've just put more of their time in other things (eg work, coding) rather than digging out gems stored behind paywalls or published in obscure places. I've been digging for years along with R&D on much of it. I share that stuff where it might help and it's helped many people/companies in the past. So, I keep doing it.
People are free to ignore any suggestions. About 99.999% do.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#147Earlier quoted context omitted.
>I think that Go approach to error handling i so much better because of exactly the same simplicyty as C. Not to mention Go having multiple return values IMHO also takes away the major pain point of returning errors in C; using up your only return value and having to take pointer arguments when you would rather not.
A common way to solve that is to have a function argument point to a place where you want the result to end up, and always return FOO_ERROR or FOO_OK. i.e., int foo_new(foo_t **res); int foo_mutate_copy(foo_t *foo, bar_t *bar, foo_t **new_foo); Instead of foo_t *foo_new(); // returns NULL on failure foo_t *foo_mutate_copy(foo_t *foo, bar_t *bar); // returns NULL on failure I also like the Go way, just thought this wa…
I specifically mention the C way of doing things- but use you demonstrate it above. I was suggesting the Go way is superior.