Re: [[patch] valarray (was Re: valarray_copy implementation question)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Thu, Nov 26, 2009 at 9:29 AM, Christian BRUEL <christian.bruel@st.com> wrote:
> I think I understand your point. dest[b] has 0 size because there were 0
> matching elements, correct ?

Yes.  That is also the size that dest[b] would have reported if
dest was const.  E.g. modifying you earlier program, run this:


#include <valarray>
#include <iostream>

using namespace std;

int main(void)
{
   int n = 1;

   const valarray<int>  dest(n);

   valarray<bool> b(false, n);

   std::cout << dest[b].size() << std::endl;

   return 0;
}


> your definition of size of dest[b] is the
> number of true elements.

yes (and dest and b are already required to have same length).

>
> What I found really strange with this interpretation is that the legality of
> the program depends on a runtime behavior

That is precisely what the Standard says 'undefined behaviour' as opposed
to 'ill-formed' -- we don't say "legal".

There is nothing strange about it.  Not everything can be determined
at compile time; most interesting stuff happen at run time.

>
> for instance if the boolean's value is not known at compile time, like with
>
> ...
> b[0] = foo(); // with extern bool foo (void);
> dest[b] = src;
> ...
>
> Is this legal or not ?

whether the above invokes undefined behaviour depends on the
value of b[0] and the length of src.

>  that's quite disturbing :-(

Not to me.  Do you find it disturbing that
the validity  of

    int a, b;
    cin >> a >> b;
    return a / b;

depends on the state of 'cin'?

-- Gaby