valarray <vallaray<T> > efficiency

[Ioannis Vranos]

"The class template valarray<T> is a one-dimensional smart array, with
elements numbered sequentially from zero. It is a representation of the
mathematical concept of an ordered set of values. The illusion of higher
dimensionality may be produced by the familiar idiom of computed
indices, together with the powerful subsetting capabilities provided by
the generalized subscript operators.255)".

Elsewhere it is mentioned:

"The expression &a[i+j] == &a + j evaluates as true for all size_t i
and size_t j such that i+j is less than the length of ===> the
non-constant array a. <===
Likewise, the expression &a != &b[j] evaluates as true for any two
==> non-constant arrays <== a and b and for any size_t i and size_t j
such that i is less than the length of a and j is less than the length
of b. This property indicates an absence of aliasing and may be used to
advantage by optimizing compilers.260)".

So as far as I can understand, in the case of the valarray, pointer
arithmetic can be used only for non-constant valarrays.

I find that a bit bizarre. Why should constant valarrays be hamstrung
with regard to potential optimisability? Or is the intention to
facilitate some different/better optimisation (I can't imagine what)
based on const-ness and which might be impeded by imposing the above
restrictions?

I do not know, but I assume they had one or more possible optimisations
in mind. Also valarrays may use "raw memory" and not operator new, among
other things.

 

[Ioannis Vranos]

Hi in TC++PL3 it is mentioned that an slice_array can not be copied,
however the following code compiled in my system even with "g++ -ansi
-pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

 

[Victor Bazarov]

Hi in TC++PL3 it is mentioned that an slice_array can not be copied,
however the following code compiled in my system even with "g++ -ansi
-pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

I am not familiar enough with slice_array. Does the Standard say
that it "shall not be copied" or does it simply leave the copying
undefined (up to the implementation to provide it if it wants to)?

V

 

[Ioannis Vranos]

Hi in TC++PL3 it is mentioned that an slice_array can not be copied,
however the following code compiled in my system even with "g++ -ansi
-pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

I am not familiar enough with slice_array. Does the Standard say
that it "shall not be copied" or does it simply leave the copying
undefined (up to the implementation to provide it if it wants to)?

The standard says:

"26.3.5.1 slice_array constructors
[lib.cons.slice.arr]
slice_array();
slice_array(const slice_array&);
The slice_array template has no public constructors. These constructors
are declared to be private.
These constructors need not be defined.
26.3.5.2 slice_array assignment
[lib.slice.arr.assign]
void operator=(const valarray<T>&) const;
slice_array& operator=(const slice_array&);
The second of these two assignment operators is declared private and
need not be defined. The first has reference semantics, assigning the
values of the argument array elements to selected elements of the
valarray<T> object to which the slice_array object refers.

26.3.5.3 slice_array computed assignment
[lib.slice.arr.comp.assign]
void operator*= (const valarray<T>&) const;
void operator/= (const valarray<T>&) const;
void operator%= (const valarray<T>&) const;
void operator+= (const valarray<T>&) const;
void operator-= (const valarray<T>&) const;
void operatorˆ= (const valarray<T>&) const;
void operator&= (const valarray<T>&) const;
void operator|= (const valarray<T>&) const;
void operator<<=(const valarray<T>&) const;
void operator>>=(const valarray<T>&) const;
These computed assignments have reference semantics, applying the
indicated operation to the elements of the argument array and selected
elements of the valarray<T> object to which the slice_array object refers".

 

[Victor Bazarov]

Hi in TC++PL3 it is mentioned that an slice_array can not be copied,
however the following code compiled in my system even with "g++
-ansi -pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

I am not familiar enough with slice_array. Does the Standard say
that it "shall not be copied" or does it simply leave the copying
undefined (up to the implementation to provide it if it wants to)?

The standard says:

"26.3.5.1 slice_array constructors
[lib.cons.slice.arr]
slice_array();
slice_array(const slice_array&);
The slice_array template has no public constructors. These
constructors are declared to be private.
These constructors need not be defined.
26.3.5.2 slice_array assignment
[lib.slice.arr.assign]
void operator=(const valarray<T>&) const;
slice_array& operator=(const slice_array&);

Neither of those is a constructor.

[..assignment stuff, irrelevant here..]

I looked over the definition of 'slice_array'. Apparently, the
class is auxiliary, not supposed to be instantiated.

V

 

[Ioannis Vranos]

Ioannis Vranos wrote:
Hi in TC++PL3 it is mentioned that an slice_array can not be copied,
however the following code compiled in my system even with "g++
-ansi -pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

I looked over the definition of 'slice_array'. Apparently, the
class is auxiliary, not supposed to be instantiated.

So, broken implementation?

 

[Victor Bazarov]

Victor Bazarov wrote:
Ioannis Vranos wrote:
Hi in TC++PL3 it is mentioned that an slice_array can not be
copied, however the following code compiled in my system even
with "g++ -ansi -pedantic-errors":



#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2,
2)]; slice_array<int> result2= result;

cout<< endl;
}



Broken implementation?

I looked over the definition of 'slice_array'. Apparently, the
class is auxiliary, not supposed to be instantiated.

So, broken implementation?

Well, "broken" to me implies lack of intent. FAIK, it may have been
intentional because the draft of C++0x lists only the default c-tor
as private, which makes the compiler-generated copy c-tor accessible.
You can call it an "advanced feature".

V

 

[Ioannis Vranos]

Well, "broken" to me implies lack of intent. FAIK, it may have been
intentional because the draft of C++0x lists only the default c-tor
as private, which makes the compiler-generated copy c-tor accessible.
You can call it an "advanced feature".

The standard states:

"The slice_array template has no public constructors. These constructors
are declared to be private. These constructors need not be defined".

Here,

#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

==> slice_array<int> result2(result);
}


my compiler uses the copy constructor.

[john@localhost src]$ g++ -ansi -pedantic-errors main.cc -o foobar-cpp
[john@localhost src]$

 

[Victor Bazarov]

The standard states:

The *current* Standard. If you read what I wrote, I was talking
about the draft of the new Standard. GNU folks are fo the
experimenting kind...

Get yourself a copy of the most recent draft if you'd like to stay
abreast with the language/library design.

"The slice_array template has no public constructors. These
constructors are declared to be private. These constructors need not
be defined".
Here,

#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

==> slice_array<int> result2(result);
}


my compiler uses the copy constructor.

[john@localhost src]$ g++ -ansi -pedantic-errors main.cc -o foobar-cpp
[john@localhost src]$

V

 

[Ioannis Vranos]

The *current* Standard. If you read what I wrote, I was talking
about the draft of the new Standard. GNU folks are fo the
experimenting kind...

Get yourself a copy of the most recent draft if you'd like to stay
abreast with the language/library design.

In any case the sentence: "These constructors are declared to be
private". sounds like an order to me. My compiler is really breaking
this rule.

"The slice_array template has no public constructors. These
constructors are declared to be private. These constructors need not
be defined".
Here,

#include <iostream>
#include <valarray>

int main()
{
using namespace std;

int array[]={1,2,3,4,5};

valarray<int> v(array, sizeof(array)/sizeof(*array));

slice_array<int> result= v[slice(0, v.size()/2 + v.size()%2, 2)];

==> slice_array<int> result2(result);
}


my compiler uses the copy constructor.

[john@localhost src]$ g++ -ansi -pedantic-errors main.cc -o foobar-cpp
[john@localhost src]$

 

[Victor Bazarov]

In any case the sentence: "These constructors are declared to be
private". sounds like an order to me. My compiler is really
breaking this rule.

The phrase in the new [draft] Standard is different. The compiler
appears to follow the draft.

[..]

V

 

[Ioannis Vranos]

In any case the sentence: "These constructors are declared to be
private". sounds like an order to me. My compiler is really
breaking this rule.

The phrase in the new [draft] Standard is different. The compiler
appears to follow the draft.

Can't you just agree with me for once? My compiler is breaking C++03
rule. The draft of C++0x or C++1x is a different issue.

 

[Victor Bazarov]

Victor Bazarov wrote:
The standard states:
The *current* Standard. If you read what I wrote, I was talking
about the draft of the new Standard. GNU folks are fo the
experimenting kind...

Get yourself a copy of the most recent draft if you'd like to stay
abreast with the language/library design.

In any case the sentence: "These constructors are declared to be
private". sounds like an order to me. My compiler is really
breaking this rule.

The phrase in the new [draft] Standard is different. The compiler
appears to follow the draft.

Can't you just agree with me for once? My compiler is breaking
C++03 rule. The draft of C++0x or C++1x is a different issue.

I didn't disagree with your conclusion; yes the rule of C++03 is
broken by the compiler that allows copy-construction of slice_array.
Apparently that rule (no copy-construction possible) has been
already found a defect if the new draft changes it. Now, a recent
compiler can choose to blindly follow the rule or it can choose to
be slightly ahead of the game and implement the correct rule.

I am not advocating breaking rules. I am just against labelling
everything "broken" that doesn't conform to one's point of view.
That philosophy is simply broken!

V

 

[Bo Persson]

In any case the sentence: "These constructors are declared to be
private". sounds like an order to me. My compiler is really
breaking this rule.

But the rule was a mistake. Someone has already noticed that valarray
constructors taking a const reference parameter cannot be called,
because the helper classes' copy constructors are all private.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2483.html#253


Obviously, your compiler has implemented the fix!


Bo Persson

 

[Ioannis Vranos]

But the rule was a mistake. Someone has already noticed that valarray
constructors taking a const reference parameter cannot be called,
because the helper classes' copy constructors are all private.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2483.html#253


Obviously, your compiler has implemented the fix!

Strangely enough, the text in the link is referencing 14882:1998, if
this was a real issue, why it wasn't fixed in 14882:2003?

 

[Victor Bazarov]

Strangely enough, the text in the link is referencing 14882:1998, if
this was a real issue, why it wasn't fixed in 14882:2003?

Even if you know after releasing v1 of your product that a certain
feature should be implemented, does it always make it into v2? Or
does it sometimes either require more thought/design or simply not
imprortant enough, and gets put aside until v3 or v4?

V