

Ridiculous_fish: I Didn’t Order That, So Why Is It On My Bill, Episode 2 - mark_h
http://ridiculousfish.com/blog/archives/2009/09/17/i-didnt-order-that-so-why-is-it-on-my-bill-episode-2/

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

~~~
steverb
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".

------
tedunangst
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.

~~~
masklinn
> 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

~~~
tedunangst
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.

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

He's had some excellent blog posts.

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

~~~
yan
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.

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

------
thras
_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.

