Ridiculous_fish: I Didn’t Order That, So Why Is It On My Bill, Episode 2 | Hacker News Reader

Ridiculous_fish: I Didn’t Order That, So Why Is It On My Bill, Episode 2

ridiculousfish.com

20 pointsmark_h12 comments

750 vertical pixels of header image is a bit much to scroll. I almost left the site thinking it was broken or contentless.

I almost did the same thing.

But then I started resizing my browser, expecting the site to immediately become useless when I did so. I was pleasantly surprised.

I don't necessarily like the design / layout, but it appears that they did it "the right way".

If you click on the big graphic, it'll take you straight to the content.

Analysis is good, but I disagree with the conclusion. If you don't use operator[], then you don't pay for it, and I'm not sure how often this really matters. If you cared about performance, you'd be using more references and fewer copies.

Isn't the argument that using operator[] for read-only access has very unexpected performance issues?

> If you don't use operator[], then you don't pay for it

The feature you pay for without using it is copy on write, not [].

In fact it's very clear in the paragraph before the last chunk of code:

> If you do use these functions, you risk paying for a write that you don't make

I should have made more clear I never really expected COW, so I'm not terribly disappointed when I don't get it. The standard allows but doesn't require it, IIRC. But I don't see how I ever "pay" for COW. It's cheaper than copying when it works.

Or, like I said, if you want copies, it's because you want copies. If you just want cheap references, use references.

ridiculous_fish is posting again! (I guess this happened circa June)

He's had some excellent blog posts.

He rewrote hexfiend too, which is my most favoritest piece of Mac software.

I was writing a plugin system for hexfiend a year or so ago to cover complex data definition overlays, a la 010 editor, but I think I might have mentioned it on here before. I lost the need for it and lost the time needed to put into it.

I had a chunk of c-like struct definition grammar done in lex/yacc that was turned into an AST that consumed some bytes from a hexfiend document and populated an outline view with a description. But it was messy and not what I wanted it to be.

What I'm trying to say is, I love hexfiend also.

I love this type of analysis even thought I will probably never need to use it.

Could the C++ standard have fixed this? Sure – the C++ standard goes into great detail about when iterators and references into strings are invalidated, and all it would have taken would be to add the copy constructor and operator=() to the list of reference-invalidating functions (section 23.1.5, for those who are following along in the standard). A second option would have been to declare that operator=() invalidates existing references for writing, but not for reading. But the standards committee preferred simplicity, convenience and safety to performance – uncharacteristically, if you’ll forgive a smidgen of editorializing.

Yes, it was uncharacteristic...but good god, imagine the chaos if your references were invalidated by any copy or assignment operation. I don't even want to think about the consequences for complex code. The standard committee was exactly right to choose the (avoidable if you're careful) performance hit over the complex "fix."

I disagree with his fix of casting non-const strings to const for a quick fix. The best way is to use const in the first place for any strings you don't plan to write to.

Reply on news.ycombinator.com