I don't have WSL available, but I would love some numbers for tasks like cloning a large repository with git and running cmake. These things tend to be slow on Windows due to fork, see for instance this comparison for Windows vs. Linux in a VM:

https://gist.github.com/jibsen/7ebeddde3bc2bfd421b96ae53a824...

Regarding #3, it's worth noting that even though the elements of the two-dimensional array form a contiguous block of integers, you cannot treat them as such [1].

[1]: http://c-faq.com/aryptr/ary2dfunc2.html

I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.

Conversely, +24 hours may fall on the same calendar date or two calendar days on from now.

Really, "tomorrow" should be the interval from the beginning of the next calendar date to the end.

This was a very convenient way to share files because links were direct. Some people even used the public folder to host small static sites.

Interestingly their help site lists the change as March 15, 2016 instead of 2017, but perhaps they got all the dates wrong there [1]. At least I got the same email.

[1]: https://www.dropbox.com/help/16

I also seem to have an annual attempt at switching to Vim [1]. I can do enough basic commands to survive, but I am so far from the productivity in Sublime/Atom that I always end up going back to them.

[1]: https://www.donationcoder.com/forum/index.php?topic=37747

It's worth noting that ssize_t is a POSIX type, and is only guaranteed to have the range [-1, SSIZE_MAX] (basically a size type with one error value) [1]. If you need negative sizes, then ptrdiff_t is perhaps better.

[1]: http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/...

Thanks for the correction!

> only guaranteed to have the range [-1, SSIZE_MAX]

Oh, that's a weird type. I wonder if any compiler implementation encodes it with -1 bias, so that all bits 0 means "-1".

It could cause a disaster if/when ssize_t is encoded as anything else but standard twos complement signed number...

I'd assume it's just an unsigned number with 0xFF... representing -1. So counting would go (assuming 8 bits)

    0xFC SSIZE_MAX - 2
    0xFD SSIZE_MAX - 1
    0xFE SIZE_MAX
    0xFF -1

That makes more sense to me than a bias that the compiler would have to know about.

Using mingw-w64 (GCC 6.1.0):

  g++ -Os -static -s on `int main() { }' 17.408 bytes
  g++ -Os -static -s on `int main() { throw 42; }' 139.776 bytes

Which libc? You don't necessarily get as much bloat with embedded compilers and libraries.

Not really moot. I do C++ on embedded processors with as little as 32kB of program space. Using a single exception means your code will not fit. My general rule of thumb to use full-fledged C++ is a processor with at least 256kB of program space.

Here's a comment of mine from a previous discussion: https://news.ycombinator.com/item?id=11706840

Not in the bare-metal environment. You may not have the memory to use one. In such a case, the increase to use two is irrelevant.

Try compiling with a recent 64-bit GCC and adding `-mtune=native -flto` to the mix.

It compiles fine with mingw-w64 on Windows. MSVC is a bit more involved due to the GCC extensions used. When LZFSE first came out I made a fork with the changes to compile with MSVC [1], but there wasn't any interest in it.

[1]: https://github.com/jibsen/lzfse/tree/msvc-compatibility

Most importantly, whatever the language or codebase you are working in/on mandates.

I write a lot of C, and given the choice, I tend to prefer tabs for indentation and spaces for alignment. I use a tab-width of 8, so the code will look fine for anyone using a lower tab-width.

Converting from tabs to spaces is a simple search-and-replace, whereas the other way is more work (there was an article here recently about algorithms to guess indentation width).