Why is not defined operator+ for vector?

[Alex Vinokur]

Why is not defined operator+ for vector?

For instance,
vector<T> v1, v2, v3;
T a;

v1=v2+a;
v1=v2+v3;

 

[Jeff Schwab]

Why is not defined operator+ for vector?

What would it mean?

For instance,
vector<T> v1, v2, v3;
T a;

v1=v2+a;

Does this make v1 the concatenation of v2 and a, or the result of adding
a to each element of v2?

v1=v2+v3;

Does this add each element of v2 to the corresponding element from v3,
or make v1 the concatenation of v2 and v3?

 

[Alex Vinokur]

What would it mean?


Does this make v1 the concatenation of v2 and a, or the result of adding
a to each element of v2?

Concatenation of v2 and a.

Does this add each element of v2 to the corresponding element from v3,
or make v1 the concatenation of v2 and v3?

Concatenation of v2 and v3.

 

[Marcin Kalicinski]

Why is not defined operator+ for vector?

For instance,
vector<T> v1, v2, v3;
T a;

v1=v2+a;
v1=v2+v3;

Too many operators make code less readable. If operator's meaning is not
obvious in context of the operation it performs, it's better to replace it
with named function. In case of standard library containers these functions
were named push_back and insert, which IMO better describes append
operations than operator +.

// v1 = v2 + a becomes:
v1 = v2;
v2.push_back(a);

// v1 = v2 + v3 becomes:
v1 = v2;
v1.insert(v1.end(), v3.begin(), v3.end());

cheers,
Marcin

 

[Jeff Schwab]

Concatenation of v2 and a. ....

Concatenation of v2 and v3.

This behavior differs from the traditional, mathematical meaning of
adding two vectors. Neither concatenation, nor the mathematical meaning
are "wrong." Since there is no single, obvious meaning of operator+ for
vectors, why should any one definition be part of the standard library?
It can be overloaded easily in client code.

 

[Walter Tross]

Alex Vinokur 2004-05-19 :

Concatenation of v2 and a.

I would have said it adds a to every element of v2

Concatenation of v2 and v3.

I would have said it adds v2 and v3 element by element.

So you see a good reason (among others) why that operator is
*not* defined...
ciao
Walter

 

[Julie]

What would it mean?

This is a weak argument. There are plenty of methods/operators that are far
from intuitive.

Take vector::empty(), for example.

Without prior (stl) knowledge, there is no way to know what this means: does it
test for an empty condition or empty the contents of the vector?

 

[Jeff Schwab]

This is a weak argument.

It's not an argument. It's a question.

There are plenty of methods/operators that are far
from intuitive.

And more would help?

Take vector::empty(), for example.

Without prior (stl) knowledge, there is no way to know what this means: does it
test for an empty condition or empty the contents of the vector?

You have a good point; a name like "is_empty" might have been better.

 

[Julie]

Preamble: my previous response wasn't meant to be attacking or argumentative.
I don't disagree that specifically _operator_+_ is ambiguous and not warranted
for various reasons pointed out by other respondents.

 

[Julie]

It's not an argument. It's a question.

Yep, you are absolutely correct. I wasn't thinking clearly at all when I
originally responded -- you can safely ignore it.

 

[Jorge Rivera]

Take vector::empty(), for example.

Without prior (stl) knowledge, there is no way to know what this means: does it
test for an empty condition or empty the contents of the vector?

Look at the full declaration

bool empty() const;

For sure no modifications, returns bool, what's not obvious about it??

JLR