Re: Variables in for loop (style issue)

Anders J. Munch wrote:
  > Thorsten Ottosen wrote:
  >
  >>Anders J. Munch wrote:
  >>
  >>>Performance characteristics are different, when compared to the
  >>>original with a vector<int> member returned by const reference. Not
  >>>worse, not better, just different.
  >>
  >>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.

  >>>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?

  >>A generic container cannot
  >>assume very much about the elements it stores, and certainly not that an
  >>element will be incrementable.
  >
  >
  > Since when is vector<int> a generic container?

Then consider vector<T> and let the class have a template parameter.

  > 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?

In C++:
-------
You can keep performance and return a Vec3&, thus violating encapsulation.

You can keep encapsulation an return a Vec3, thus hurting performance.

In a GC-language:
-----------------

You can keep performace and return a reference, thus violating
encasulation.

You can keep encapsulation by making Vec3 immutable and return a
reference, thus violating performace when updating small amount
of state in the vector,

You can keep encapsulation and return a non-mutable view of the Vec3,
thus violting performance by adding extra heap-allocations and extra
function calls. And worse: your interface is now not compatble with
functions expecting a Vec3.

I repeat: Pick your poison or use C++.

-Thorsten

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]