wuch

12 ms·

61.
by wuch 10y ago
While hiding unsafe parts of code behind safe interface works great in Rust, especially that ownership / borrowing rules expresses much more than is possible in other mainstream languages (in Java you wouldn't know if you are the
62.
by wuch 10y ago
Given that in unsafe block you still have to uphold the same invariants as in other blocks of code, your job is actually much harder in Rust that it is in C/C++. Take a look at examples in [0], they would be perfectly valid in C/C
63.
by wuch 10y ago
And in C++ you would write this as follows (with a range library it would be a one-liner): const auto & xs = {1, 2, 3}; cout << accumulate(begin(xs), end(xs), 0);
64.
by wuch 11y ago
I have been playing with Rust for a few weeks now, so I can give a few reasons not to use it. What I will write may sound overly negative, but keep in mind that those are only reasons not to use it, in general I found a lot to like in Rust.
65.
by wuch 11y ago
If you consider subjective priors to be a problem, this can be addresses to some degree using so called "objective priors". They are objective in a sense that if two people agree on underlying principles of how priors should be as
66.
by wuch 11y ago
Libunwind also works great in this context. For some cases I even found it to work much better than backtrace. It also has a signal-safe functions that facilitate implementation of stack printing on crash. I work with projects where stack t
67.
by wuch 11y ago
I did indeed look a little bit about previous attempts at collections in Rust, but didn't find too much about ranges. What would be good keywords and place to look for, any hints? It seems to me that you can go quite far with mutable b
68.
by wuch 11y ago
Thanks for link. In C++ ensuring whether something is safe is indeed sometimes quite non-trivial, my favourite, but non-practical example is non-empty std::list<int> x, used in following way: x.remove(x.front()); Comment for no
69.
by wuch 11y ago
The crucial difference I had in mind, is that those from C++ work in-place. Returning a new collection as a result poses no problem for either of those languages. Writing specialized version for each collection is also possible, but with ST
70.
by wuch 11y ago
Is there a language package manager that you would consider a good role model in this respect?
71.
by wuch 11y ago
Right, in most cases you could replace begin(), end() with whole container / range, when considering arguments to the algorithm function. Though, there are some exceptions, like std::rotate, or just cases where you want to place result
72.
by wuch 11y ago
On one hand it indeed feels like more strict version of move semantics in C++, on the other hand it also prohibits what is central idea of STL - having multiple mutable references to the same object (almost all algorithms operate on at leas
73.
by wuch 11y ago
What authors point out is not trivial observation that programs are running on finite-memory machines and thus cannot be Turing complete. What they do point out is that even if C programs have been running on infinite-memory machines the me
74.
by wuch 11y ago
Beta is conjugate prior of binomial distribution. That means is you start with prior beta, and likelihood has binomial distribution, then posterior obtained using Bayes theorem also will have beta distribution (with different paramters). If
75.
by wuch 11y ago
This is required by the standard. unique_ptr<Gadget> in your example uses default_delete<Gadget> deleter, which in turn requires that type Gadget is complete at the point where this deleter is used, otherwise program is ill-form
76.
by wuch 11y ago
If I were to compare complexity C++ and Java, I would say that the former is much more complex and intricate than latter. Complexity of both of course keeps increasing. But, that does not necessarily mean that programming in any of them is
77.
by wuch 11y ago
Suppose somebody have written above code. Then under current C++ standard it would invoke UB on overflow. But, if standard were to change and require wrapping behaviour for int, then it would be "fixed", i.e, do what programmer in
78.
by wuch 11y ago
What I had in mind, is the fact that with defined overflow you could unconditionally perform the operation, and then observe the result to decide if overflow have in fact happened. For example, following pattern to check if adding 100 to an
79.
by wuch 11y ago
In fact, prior to Java 8, you could not even declare unsigned integers. In Java 8 you still can't declare unsigned integers. It just that API have been extended to provide operations that treat an int or a long as having unsign
80.
by wuch 11y ago
Using types to encode additional invariants is of course very useful, though those pointers does not enforce non-nullability. For example you can transfer ownership out of them more than once: void f(nn_unique_ptr<std::string> a,
81.
by wuch 16y ago
Actually his example can be written quite succinctly (but in general case closures would be much more expressive): copy(words.rbegin(), words.rend(), ostream_iterator<string>(cout));