I think you misunderstand me. I am saying that on Linux text at normal PPI is pretty much as good (to me) as text at high PPI because it has sub pixel rendering and strong hinting that Mac OS X lacks,
482 karma · joined July 15, 2013
When using Windows or Linux I don't find much benefit in text rendering on a 4k display.
But as Mac OS X has no sub pixel rendering or grid fitting text looks terrible without a high ppi display.
Does it require constant time concat?
Does it require immutability?
Does it require a balancing scheme based on the fib sequence?
Does it require that the tree is binary?
My tree is an attempt to be as fast as possible with log everything operations and no pointer/reference stability.
Basically, it has O(log n) everything like a binary search tree you suggested but also very good constant factors.
By default, leaves hold 1024/sizeof(T) elements and branches hold 47 elements, so it can access up to 13,289,344 8 byte elements with only 4 levels.
Note that the assembly for process_message2 calls each function only once even though some appear twice in the body.
Consider this example: http://ideone.com/T872Oj
In F1 the compiler can NRVO away the move.
In F2 it cannot.
Both will fail to compile if you delete the move constructor.
void TestSigned(int min, int max, int step) {
for (int i = max; i >= min; i -= step) F(i);
}
void TestUnsigned(unsigned min, unsigned max, unsigned step) {
while (true) {
F(max);
if (max < min + step) break;
max -= step;
}
}
void TestUnsigned(unsigned *min, unsigned *max, unsigned step) {
while (true) {
F(*max);
if (max < min + step) break;
max -= step;
}
}
Truetype fonts are an example of a vector format that can still look sharp at arbitrary resolutions because they can include hinting programs that align the control points to pixel boundaries. This is why fonts tend to look sharper on Windows and Linux than MacOS X. Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
Can you elaborate on this? While it's true that SHA-1 is now broken, my understanding is that git's reason for using SHA-1 was to ensure the integrity of the entire history.
Remote: Yes
Willing to relocate: Yes
Technologies: C++, C#, C, Python, Git, Subversion, Linux, Windows
Github: http://github.com/det
Email: chris@detrino.org
Your problem is that you are trying to imagine what happens in the real world rather than just looking at it.
> This is from experience in various large C++ codebases. I'm not saying people use refcounting a lot, I'm saying it gets used more than Rust.
I count 56 imports of Arc and 37 of Rc in servo, would you wager the equivalent parts of chromium or firefox use more ref-counting?
> Not really. Aside from non-lexical borrows and a couple other nice-to-have things (but not necessary), the borrow checker is pretty precise for what it tries to prove.
The problem is that the borrow checker does not look at the function as a whole. You are a slave to the borrow checker, you can only consider other things when it has been satisfied, even if its trivially safe from a whole-function view. Some simple things aren't even expressible at all without non-lexical borrows, no matter what gymnastics you try.
> It sort of does. If you try to introduce borrows and listen to the suggestions the compiler gives you, and eventually end up nowhere, it's probably not possible to do it that way.
That sounds like a terrible workflow that I don't think Rust programmers use in the real world. I think they usually use shared ownership because they know they have shared ownership, not because they gave up on the borrow checker. Any instance of actually resorting to reference counting because of the inability to make the borrow checker happy actually counts against Rust, not for it.
> in practice IMO the things Rust makes you feel safe to do is a superset of what C++ lets you feel safe to do
People routinely do safe things in C++ that would be impossible to express in safe Rust code. You need to let go if this untruth.
> if we're going to talk about "all possible things C++ theoretically allows you to do", then you should include unsafe -- you were comparing "safe Rust" with "all C++", which is unfair here, since the entities to be compared for what you're theoretically allowed to do are "all Rust" and "all C++".
I focused on safe Rust because your argument was that safe Rust is just as powerful as C++, just proved safe statically. This is far from the truth and you refuse to accept the correction. Most people in the Rust community would probably say they accept the loss in power because they prefer absolute safety. This is a very defensive position. It's impressive just how little power Rust gives up in comparison to languages like C#/Java. But to pretend that you actually have more power in Rust due to psychological effects is just zealotry and doesn't reflect how people use C++ in the real world.
> Examples?
Any abstraction that uses dynamic checking that would be considered a bug to actually trigger. Some examples include borrowing a RefCell, random access of iterators, sequential access of certain kinds of iterator adaptors, etc.
Most large C++ projects do not unnecessarily use reference counting.
Most C++ programmers do not fear using references or pointers because of invalidation.
The Rust compiler does not tell you when it's impossible to satisfy your problem using borrows. In fact it often has false positives requiring borrow gymnastics because it is too primitive.
And your last line is a complete reversal of your previous attitude: Suddenly you are focusing on theory while ignoring that in practice you can not usually break out `unsafe` to solve your borrow problems. In fact it's Rust, not C++, that is more likely to reach for more heavyweight abstractions than necessary because it's not practical to litter unsafe throughout your codebase.
The things you can prove statically with the borrow checker are a subset of the things that wont trigger UB in C++.
When talking about Java:
> JVM garbage collection is notoriously expensive.
> Java’s known performance issues made it unappealing.
> However, in our past experience, we ported a large system from Java to Go, which greatly decreased its memory footprint and garbage collection overhead.
When talking about Go:
> What remains to be seen, of course, is how all of this Go code will perform.
Yet: The JVM's GC is superior to Go's, Java tends to outperform Go, and a large memory footprint is a necessary evil for getting good performance out of any GC.