On Sat, 05 Mar 2011 19:15:02 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
Regarding the former, it appears we still don't have a definitive benchmark comparing COW with move emulation, and one would be nice, but we can still predict how many deep copies each strategy will require for a given expression, and except in constrained situations where copies are never modified, I don't think COW gives any benefit. Sometimes COW is worse, since you can't explicitly transfer ownership. Feel free to prove me wrong. [...]
I'll be sure to report the results, either way.
Looking forward to it. It would also help to track the number of allocations via the allocator or defining global new to ensure we get the allocation statistics one expects.
Noted. [...]
I think a quick trip to wikipedia, as suggested by Robert, should convince you.
That was one of the sources of my informal knowledge on the subject, and at least the last time I looked, it explained nothing that I could see about why O(n/2) == O(n).
Right there in the definition: [...] Informally, what complexity estimates tell you is the relative growth in the running time of an algorithm as you increase the problem size.
I'd gotten the idea of it, but so many papers seem to include complex formulas in the big-O notation that I thought it was standard to be as precise as possible.
You didn't really address my primary comment. You can put lipstick on a pig, but it's still a pig. You've just renamed make_unique into a constructor. Is that a fair analysis?
Yes. The complaint, as I recall, wasn't that the make_unique function existed, but that it was part of the interface and meant to be used or at least usable by client code. I didn't understand it either.
So you didn't really faithfully address the complaint. The interface still has the make_unique functionality; you just put lipstick on it ;)
It's an important ability, if the need for CoW is proven. Or to phrase it different, without the lipstick, it would just be a pig. ;-)
More importantly though...
You (or anyone else!) don't necessarily have to accept anyone's or everyone's suggestion. If you feel like you have a compelling case to reject a particular request or do things a certain way, make your case, and your case and the opposing one(s) will be evaluated on its merits. [...]
If I had it to do over again, I'd lurk around this list for a year or so and figure out which of the posters are most worth listening to, *then* asked for the first preliminary review. I got a lot of feedback that made no logical sense to me, but that (I thought) came from On High and had to be implemented if I wanted the library to be accepted. I originally assumed that I must not understand the concepts involved, but looking back on it, I think in many cases the person offering the opinion didn't have the specific experience with writing that kind of library to realize why their suggestion wasn't necessarily a good idea.
Duplicating the code of that constructor function, with what I think would be a single-line change, would be a superior design? I'm not trying to be a pain, I'm honestly baffled at that assertion.
In the interest of list traffic, I'm going to drop this line of discussion, if you don't mind. It's not important enough to belabor (sp?).
In the interests of maximizing development time, I'll accept that. -- Chad Nelson Oak Circle Software, Inc. * * *