Weird behavior of range-based for

SAn

The Clang has similar problem too.

You say about some array. I thought the initialiser list

auto a = {4, 3, 2, 1};

is equal to something like that:

std::initializer_list<int, 4> const a(4, 3, 2, 1);

Now I suspect the following:

int const t[] = {4, 3, 2, 1};
std::initializer_list<int> const a(t, t + 4);

Am I right?

The bug was discovered by our female coworker. She wrote something like that:

void process(cv::Mat &image1, cv::Mat &image2, cv::Mat &image3)
{ //cv::Mat is OpenCV image. On object copy it copies only header (image data is reference counted).
  for ( cv::Mat &image: {image1, image2, image3} )
  {
    ...do some common preprocessing...
  }

  ...do specific processing for image1...
  ...do specific processing for image2...
  ...do specific processing for image3... 
}

Sone

Am I right?

Nope. The Array is internal. (Btw, initializer_list has no such ctor)

std::initializer_list<int, 4> const a(4, 3, 2, 1);

What you mean is std::array (and it uses aggregate initialization, which requires curled braces)

Ich habe mich zwar bisher zurückgehalten, aber jetzt ist das Fass übergelaufen.

Ist es wirklich nötig, dass deutsche User in einem deutschen Forum englisch Reden?

Es gibt genug englische Programmier-Foren, und, ich sage das jetzt ungern, die sind z. T. noch besser als dieses hier.

Ach ja: und noch besser ist es natürlich, wenn man einen Thread mit englischem Titel erstellt, und in deutsch diskutiert. So stoßen Englischspracheige über google auf diesen Thread und verstehen nichts. Aber das nur nebenbei.

camper

SAn schrieb:

Now I suspect the following:
int const t[] = {4, 3, 2, 1};
std::initializer_list<int> const a(t, t + 4);
Am I right?

in essence (pseudo-code). Of course, if the initializer_list ist created implicitely it is temporary as is the the array it referes to. It's the compiler's job to keep them in sync.

Copying an initializer_list does not copy the array it uses nor does it magically extend the lifetime of said array. Doing so in a situation where the copy might outlive the original (for example: storing one in a container) is a bad idea.

Sone

Copying an initializer_list does not copy the array it uses nor does it magically extend the lifetime of said array.

WTF?
That can't be true. Whait a sec.

http://ideone.com/MMSJNJ
http://ideone.com/RGvAP1
So what are you talking about?

camper

Sone schrieb:

Copying an initializer_list does not copy the array it uses nor does it magically extend the lifetime of said array.

WTF?
That can't be true. Whait a sec.

http://ideone.com/MMSJNJ
http://ideone.com/RGvAP1
So what are you talking about?

what did you prove?
consider http://ideone.com/ftEcyd

Sone

camper schrieb:

Sone schrieb:

Copying an initializer_list does not copy the array it uses nor does it magically extend the lifetime of said array.

WTF?
That can't be true. Whait a sec.

http://ideone.com/MMSJNJ
http://ideone.com/RGvAP1
So what are you talking about?

what did you prove?

That the array the initializer_list is using, is indeed copied. Which is the exact opposite of what you said.

But apparently i didn't prove anything?

camper

Sone schrieb:

But apparently i didn't prove anything?

I trust you do know what undefined behaviour is.
For example, to pick over the dead bones.

Sone

Oh wait! The stack is not overriden, thus the values stay the same? ... or what ...

Sone

N3337 18.9 / 1

Copying an initializer list does
not copy the underlying elements.

g'dammit

camper

Sone schrieb:

N3337 18.9 / 1

Copying an initializer list does
not copy the underlying elements.

g'dammit

That's only a note though. You might want to read 8.5.4/5 et seq. to figure out how to derive that answer from the normative text (hint: consider what's not written in there).