Does std::wcout forces passing arrays by value!?

[Mantrid]

Hey everyone,

normally an array is passed by reference meaning, that if I change the array in the function, the original array is changed. However, if I call the function within std::wcout, the original array stays untouched, however, std::wcout shows the right calculation. Can somebody explain this to me please?

Thanks
Mantrid

[Moschops]

You mean this?

std::wcout << a[0] + 4; ?

Why would that have any effect on the value of a[0]?

If that's not what you mean, you'll have to give an example. We are not psychic.
http://www.cplusplus.com/articles/Ny86b7Xj/

[ne555]

Nope, that makes no sense.
An array can't be passed by value
¿could you please show your code?

[Mantrid]

Well I know whats going on now...but FYI: These are the 2 functions I was calling:

typedef float elem_type;

elem_type simplemedian(elem_type arr[], uint32_t n)
{
    uint32_t low, high ;
    uint32_t median;
    uint32_t middle, ll, hh;
    low = 0 ; high = n-1 ; median = (low + high) / 2;
    for (;;) {
    if (high <= low) /* One element only */
    return arr[median] ;
    if (high == low + 1) { /* Two elements only */
    if (arr[low] > arr[high])
    ELEM_SWAP(arr[low], arr[high]) ;
    return arr[median] ;
    }
    /* Find median of low, middle and high items; swap into position low */
    middle = (low + high) / 2;
    if (arr[middle] > arr[high])
    ELEM_SWAP(arr[middle], arr[high]) ;
    if (arr[low] > arr[high])
    ELEM_SWAP(arr[low], arr[high]) ;
    if (arr[middle] > arr[low])
    ELEM_SWAP(arr[middle], arr[low]) ;
    /* Swap low item (now in position middle) into position (low+1) */
    ELEM_SWAP(arr[middle], arr[low+1]) ;
    /* Nibble from each end towards middle, swapping items when stuck */
    ll = low + 1;
    hh = high;
    for (;;) {
    do ll++; while (arr[low] > arr[ll]) ;
    do hh--; while (arr[hh] > arr[low]) ;
    if (hh < ll)
    break;
    ELEM_SWAP(arr[ll], arr[hh]) ;
    }
    /* Swap middle item (in position low) back into correct position */
    ELEM_SWAP(arr[low], arr[hh]) ;
    /* Re-set active partition */
    if (hh <= median)
    low = ll;
    if (hh >= median)
    high = hh - 1;
    }
    return arr[median] ;
}

elem_type *simpleabs(elem_type arr[], uint32_t n)
{
    for(uint32_t i=0; i < n; i++)
    {
        if(arr[i] < 0.0)
        {
            arr[i]=-arr[i];
        }
    }
    return arr;
}

And this was my code for the output (just a test):

float numbers[11]={ 2.12, 3.0, -3.0, 9.87,  9.99,  0.01, 0.2,  0.3, -0.3,  0.4, 1.0};
    std::wcout << simplemedian(simpleabs(numbers, 11), 11) << L" " << numbers[0] << L" " << numbers[1] << L" "<< numbers[2] << L" "<< numbers[3] << L" "<< numbers[4] << L" " << numbers[5] << L" " << numbers[6] << L" " << numbers[7] << L" " << numbers[8] << L" " << numbers[9] << L" " << numbers[10] << L" " << std::endl;

And the output was:
1 2.12 3.0 -3.0 9.87 9.99 0.01 0.2, 0.3 -0.3 0.4 1.0

However, when I change it and display it in 2 seperate std::wcout calls, then the values are changed and sorted.....

It was just unexpected, that the output is correct and the values afterwards are still the original ones....well I don't understand the behaviour but at least it is changed after the call...

[ne555]

Basically your issue is equivalent to

int n = 42;
n = ++n;
std::cout << n; //undefined 

The compiler may take the order that it wants to evaluate the expressions.
Check out sequence points

[slicedpan]

I don't think it is the same, isn't using the << operator just function chaining?

[ne555]

It is chaining, but that would only matter for the stream object. (I'm not sure what did I try to say here)

The idea is that you may evaluate the sub-expressions as you please
exp_a op exp_b op exp_c ...
The problem is that exp_c is dependant of exp_a.

This is not the case, however, of operators and or because of the short-circuit behaviour

[slicedpan]

With function chaining, doesn't it have to evaluate left to right? Consider for example a function that finds a specific object and returns it.

FindSomeObject(args).FindASubObject(moreArgs).DoSomethingWithIt();

Replacing the arguments with a function call:

FindSomeObject(GetArgs()).FindASubObject(GetMoreArgs()).DoSomethingWithIt();

I would have thought that GetArgs() would have to be called before GetMoreArgs(), since FindSomeObject gets called first, hence its arguments need to be evaluated first.

Actually I can see how it might not happen that way, I guess the compiler could evaluate the functions in the reverse order, storing the results and then evaluating FindSomeObject and FindASubObject in that order. Sorry to have doubted you ne555!

[slicedpan]

After some googling, I think the behaviour is well defined, it must be evaluated from left to right. There is a sequence point after evaluating the function arguments, but before evaluating the function body. Hence in my example, GetArgs() must be called before FindSomeObject(), and as a result before GetMoreArgs().

EDIT:

Hmmm, a simple example does not back this up. Maybe you should disregard what I just said.

[cire]

After some googling, I think the behaviour is well defined, it must be evaluated from left to right.

While the order of the function calls is well defined, the order of the evaluation of the expressions supplied as arguments for those functions are unspecified. The only thing that's required of them is that they're sequenced before the function call they are arguments to.