rwbt

Thanks for sharing! This looks like a very well designed container library.

Never heard of SJC. Reading about it and their curriculum makes me happy and also jealous ;)

Ethernet only sounds like a good idea, even for adults ;)

Very well said. This is really the price of progress and technology. Ironically, we still fool ourselves thinking that the way out of this mess is even more technology and progress.

I'm curious if this affects FastMail users in US since they're based out of Australia.

People don't read as much anymore, so I think books are safe for now.

Automakers are hoarding the spectrum citing some pie in the sky safety stuff. Not a single car was ever shipped with that tech. I'd rather have my WiFi router running reliably rather than some promise ware hoarding it.

I was going to say the same. I want to like Stratechery and Ben's writing but most of the time it's a word salad that leads to nowhere.

+1. I was gonna write Ishmael too. Definitely one of the best books I've ever read.

> If you want something to last, don't base it on something that won't last.

Sounds similar to the Lindy Effect.[0]

[0] - https://en.wikipedia.org/wiki/Lindy_effect

That is clever. Using last byte as the flag byte also lets one cast the std::string memory address to a null terminated c-string without intermediate buffers (not that one should).

If I were starting a new project in C, I would definitely rely on a solid foundation library like APR[0] or CoreFoundation[1] without reimplementing a bunch of fundamental data structure algorithms by myself. Glib is another alternative, but too bloated in my view.

[0] - https://apr.apache.org [1] - https://github.com/opensource-apple/CF

I used it in production for a small yet fairly critical utility and it worked out very well.

Only the libc implementation of std::deque allocates 4KiB blocks and lives upto it's performance and utility. The MSVC implementation is terrible (8 bytes) and even the GCC one isn't that efficient (512 bytes).

Even though boost has a customizable deque block size, it's performance is still way behind Clang's libc.

Sure you don't need much 'info' to create a corporation. But if said corporation has any income/employees the reporting and maintenance requirements are far greater than maintaining a library card.

> The UI of Adobe After Effects can be quite overwhelming to a new user.

I suppose so. When I was learning Mograph in school, After Effects was the most intuitive tool among many others. Combustion, Motion etc never quite managed to pull it off in balancing simplicity, ease of use and versatility.

AE aged very well IMHO and to this day is the weapon of choice of Mograph.

If I remember correctly, in MSVC implementation if sizeof(T) is greater than 8 bytes then each 'block' is just one element (also blocks aren't contiguous). So effectively, MSVC implementation is useless.

Boost does have a a deque container where you can specify the block size using type traits, but from my experience boost's deque wasn't such a good implementation performance wise.

But Clang's libc++ implementation is very good performance wise and even beat std::vector in some cases.

The std::deque is also another useful 'hybrid' container that performs close to std::vector or better in some cases when you need to 'grow' the container without reallocating memory so many times. But the only good cache friendly implementation seems to be in clang libc++ (memory is allocated in 4KiB blocks). MSVC's deque implementation is horrible (8 byte blocks) and GCC's is also not that great (512 byte blocks).

I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.

Just giving my experience - I working in rendering graphics and use fossil for version control. Some of my repos are more than 100GiB in size and fossil has no problem with it. Fossil handles binary files adequately but the only catch is file size is limited to SQLite 'Blob' size limits (which is currently 2GiB). So if you have asset files larger than 2GiB, you'll have to split it into multiple files.

Truly a saint. His index funds and passive investing school of thought probably saved trillions of dollars and made investing in the markets accessible to millions of everyday citizens.

RIP.

Interesting. Do you mind telling us what made you choose nursing over tech?

Thanks for the tip. I too work in rendering and often wondered if pre-caching end() would make significant difference but figured its best left to the compiler.

Yes, I'd need to check for end iterator in vector. But my point still stands - C++ does have some weird ergonomics.

Sooner or later, C++ is going to get a borrow checker anyways. I guess it's all going to be ok? :)

I'm not entirely sold on string_view or span yet. But I wasn't sold on tuples either and I use them a lot now.

I agree. These days I can't even imagine programming in C++ without using STL. It still has some weird ergonomics at some places though. For example - instead of a simple vector.contains(something) we have to write this

  std::vector<T> x_Vec;
  if (!(x_Vec.find(another_x) == std::vector<T>::npos) {
      //some code
   }

Also the ugly std::get<N> syntax..

  auto x = std::get<0>(myTuple);

Why not -

  auto x  = myTuple.0

I use C++ everyday and I would describe my usage as mostly "C with templates and destructors." I also tend to avoid OOP paradigms if possible.

All the modern C++11 and above features are great if you're using standard lib and algorithms. But I really don't want to implement copy/move semantics, iterators etc for my own classes. Modern C++ feels more python-esque with a lot of syntax sugar (which is great for expressiveness).

I'm afraid that ship has sailed. Tesla changed the expectation of buyers that touchscreens are more 'luxurious' so the market follows. I prefer physical knobs too, but don't blame car makers for following market trends.

Yes, you're right. The highest spec engine in those cars is indeed the B16!

Those 90s Hondas are very easy to chop up into parts and sell them at a premium.

Other enthusiast models don't suffer from similar theft rates.