braindeath

> Buggering op[] would be the slowest possible way to get the NUL there.

> Evidently that is a minority preference.

What evidence? Pointing out a fact isn't an endorsement.

> If you think anybody is complaining about the extra space for the NUL

Then what exactly are you complaining about? Setting the byte to 0? If not, why are you being so obtuse?

> what you are barking up is not even a tree.

In this thread your tone is repeatedly that of a condescending jerk.

Not a particularly informative or well-written one frankly.

"Also, with more memory, there are simply many more possible features that MIDI 2.0 can try to emulate. More memory should also reduce the chance of the timing between playing a MIDI instrument and digital recording to be slightly off. This should mean music played on MIDI 2.0 instruments will feel more analog, and make it possible for non-keyboard instruments to work better with MIDI."

Eh? What?

"The fact that MIDI 2.0 is bidirectional has two major effects. First, it means that it is backwards compatible, and won’t make the billions of MIDI 1.0 devices already out in the world obsolete."

No, backwards compatibility does not follow from MIDI 2.0 being bidirectional.

"“I think using a MIDI guitar would change the way I make music. The way our brain orients to making music on a guitar is just different to a keyboard layout. I used to have a MIDI guitar instrument, but I don’t have it anymore because I felt like there was a lot of latency and I didn’t really like the results I got. I am hoping [MIDI 2.0] will solve some of the issues I had before.”"

Well prepare to be disappointed. The problems with digital non-keyboard instruments has little to do with MIDI. In the case of a MIDI guitar, the latency problem is an issue of physics, not the digital transport.

> Anyway, that was true until somebody jiggered the Standard, just before 1998, to require a NUL visible to s[s.size()].

This is not technically true. You could plugin your hated NUL byte in the implementation of operator [].

> C Code that depends on NUL termination is ubiquitous.

No, that's not what I said. It really doesn't matter what language underlying the API of all the code that expects NUL terminated strings is written in (a lot of it is C++ of course too). Windows, MacOS, and all POSIX-ish systems have a large API that consumes NUL terminated strings. NUL terminated strings are ubiquitous in computing at this point. Sure blame C from 40 years ago and burn a dmr effigy, I don't care, but that battle was long lost.

NUL terminated strings may be terrible, but the C++ accomodation for them is not -- its a well-thought out trade-off. My understanding is that neither go nor Rust make this trade-off. golangs FFI and syscall overhead has always been something of a performance disaster anyway. C++ has always had a greater demand to "play nice" with legacy code and systems then either of those.

The overhead of just having the NUL-byte is almost always a non-factor. If it really is, then use a byte vector.

The front-end is in Visual Basic.

The backend is most certainly not in anything close to Visual Basic.. (MUMPS - using Intersystems Cache as the object store implementation)

hardlinks are paths pointing to the same inode - the same metadata, the same contents - they are the same file - just happen to have multiple addresses.

Inodes that happen to share blocks are not the same file. ie totally different.

How do you "plugin" the NUL. If there's no space for it, then everytime you want a C string, you need to do an allocation. And why would you put something in it's place - as you said if you modify the c_str that was always UB -- so you pretty much lost all guarantees at that point -- that was just dumb.

Basically the NUL-terminator amounts to a 1-byte of wasted space -- which is almost always completely in the noise -- if you're using std::string for tiny strings you're paying at least 24 bytes anyway. There are just very few cases where that one extra byte matters.

I think the overwhelming opinion is that this 1-byte trade-off is better than the overhead of allocation and copying when you want to pass that string around. NUL-terminated strings aren't important in C++ because of C (well, not directly), but because they are essentially the ABI of countless existing libraries and the major operating systems.

> code that depends on NUL termination is not a thing to be proud of.

Whatever. Code that depends on NUL termination is ubiquitous.

Umm.. in any implementation you can already "cast" a std::string to a null-terminated string without a buffer (cf std::string::data() and std::string::c_str()) -- C++11 essentially mandates that. c_str must return "a pointer p such that p + i == &operator[](i) for each i in [0,size()]."

The history of those demonstrate some of the bat-shit insanity of the evolution of C++. Originally data didn't have to null-terminated, but then they finally realized that making c_str actually work without this invariant in general was nearly impossible. So since C++11 data and c_str are equivalent.

Edit: by impossible I really mean something usable with sane complexity requirements -- that wouldn't make people just immediately discard std::string for something better. This is the same C++ that brought you auto_ptr, and other garbage. C++11 corrected many things, this included.

> Hard links mostly work as you tell them to. You may need to set things up properly, but it's essentially the same thing being done.

That's bullshit. hard links are the same exact inode, with all that entails. reflinking is at the data block level. Totally different.

In the US for home connections (cable, fiber, DSL) everybody gets an accessible IP address pretty much -- the worst is that some ports are blocked like port 80 or 25. Phones don't get a dedicated IPv4.

> Afterwards, you will start to see the shell as a glorious, essential element of our civilization, worth of respect and deserving our careful attention.

Nah.

There should be (probably is) a term for the phenomenon/trope where you can take something that was not carefully designed in the first place (like basically all of Unix) and then down the line you can hyper-analyze the hell out of certain bits of it and wax poetic about the few elegant bits that are inevitably there (even BASIC will work, yes) - while conveniently ignoring the whole is still a steaming pile. Lord knows that's what happened with "Unix" starting in the 90s, and Javascript in the 2000s.

> If these are the primary colors, why aren't they what printers use? Printers use cyan, magenta, and yellow.

There really is no such thing as "the" primary colors. The school primary colors are still primary as those used by a printer, and are based on historically widely used pigments. CMY (and usually K) allow for a wider gamut. But even this isn't perfect. There are printing processes with more primaries to get a wider gamut.

> And the only thing that makes these colors primary to us is that they're the colors that the cones in our eyes perceive.

This isn't quite right. For one, our cones are not monochromatic receptors, and moreover, they overlap! There isn't really just one true red, green, blue used in computer monitors either.

Because of the way our brain perceives colors (metamerism), you can create a wide gamut of colors with "alternative" primaries.