Re: Variables in for loop (style issue)
Anders J. Munch wrote:
Thorsten Ottosen wrote:
> Anders J. Munch wrote:
> > Thorsten Ottosen wrote:
> >>there's only three ways to characterize performance: either it is
> >>slower, just as fast or faster. What you are saying is that
> >>there's a fourth way: they have the same performance, but are
different
> >>anyway. What's the logic in that?
> >
> >
> > Which is faster: O(m*m*n) or O(m*n*n)? Which is faster, a T1
> > line or a wagontrain of DVDs? Which is faster, unmodified
> > quicksort or merge sort? Hvad er h?jest, rundet?rn eller et
> > tordenskrald?
>
> I don't get your point.
So much for my Zen master skills; I'll spell it out then.
Specific builds of specific full programs, can be run on specific
hardware with specific inputs, to produce a simple, onedimensional
performance indicator that is either faster, slower or the same as
some other specific run.
Algorithms (and data structures) can't always be ordered like that.
On some inputs, quicksort is faster than merge sort. On other inputs,
merge sort is faster. Quicksort is likely to be faster on random
input, but merge sort has a lower upper bound on performance. It
doesn't really make sense to say that either algorithm is faster than
the other. They are just different.
You say there are only three ways to characterize performance; but in
the case of quicksort v. merge sort, those three answers are all
wrong.
If you keep the input constant, you get back to my case.
>
> >>>But, barring
> >>>copy-construction costs, replace_all_of_bar has gone from
> >>>O(bar().size()) to O(1), which is good.
> >>
> >>It's still an O(bar().size()) operation.
> >
> >
> > No, it's a dirt cheap pointer-copy. As O(1) as it gets.
>
> but don't you have to assign the pointer to all of the N bars?
What N bars? There are at most two Bar instances
involved. replace_all_of_bar replaces one instance of Bar with
another. In an object-reference language this is just a pointer copy
- nothing happens to the pointed-to objects.
Ok, I just don't get what your interface was doing then. I assumed
that a function called replace_all_* would not replace one object.
> > In any realistic example
> > it would serve some particular function in some particular context.
> > Whatever that function is, we can dream up appropriate high-level
> > concepts to deal with just that.
>
> I think the original example was good enough. Let's consider it again:
>
> struct Photon
> {
> private:
> Vec3& direc_;
>
> public:
> const Vec3& direction() const;
> };
>
> How will you emulate that interface without const?
I hope you don't expect me to complete that woefully inadequate
example for you.
It's big enough to see the issue.
There is no class definition for Vec3, which is really the key class
here, so leaving it to the reader's imagination is not good enough.
Well, you can assume more than one thing about it. It originally was a
3-dimensional vector, so a pack of 3 floats. But, and this is important,
it could just as well be a vector<T>.
What's the deal with direc_ being a reference member, is that really
intentional?
Oh, not that was not what I intended. I should be by value.
How is Photon created, there are no constructors? And
finally, Photon does not have a single non-const operation?!
That is not relevant: if this fraction of the interface cannot be
emulated without const, then neither can the whole interface.
-Thorsten
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]