26

Re: Help I do not understand

OoCc wrote:

Nonsenses.

In what place?

OoCc wrote:

in 99 % cases vector changeover on  solves all problems with internal relocation and superfluous .

Yes, the deque is deprived some limitation of a vector - insertions in the beginning and in the end not  iterators as well as removal as in storage it is stored in a type of a two-dimensional array, instead of is completely continuous, as a vector. However here at once there is a question with an element insertion in the middle, and also a question of caching of the data of deque CPU. So, neither that, nor another - not panacea, everywhere it is necessary to search for compromises for the specific case. And in a case with a vector from your classes it is possible to reduce considerably an overhead charge on  implementing correctly the move-designer.

27

Re: Help I do not understand

NekZ wrote:

Or it is possible to make noexcept the move-designer. The such will be caused at  a vector if exists, in exchange to the designer of copying.

At  a vector (at exhaustion of the reserved place) designers are caused? I do not trust. For "user" it generally the invisible event purely technically necessary, transfer of a piece of storage (a dial-up of pointers in case of a vector) in a new place.

28

Re: Help I do not understand

CEMb wrote:

At  a vector (at exhaustion of the reserved place) designers are caused? I do not trust. For "user" it generally the invisible event purely technically necessary, transfer of a piece of storage (a dial-up of pointers in case of a vector) in a new place.

Well arrived... Perhaps it was necessary to check up at least?
Simply launch this code and check up (I promise, it not  ) :

#include <iostream>
#include <vector>
using namespace std;
struct S
{
S () {puts ("S ()");}
S (S const) {puts ("S (S const");}
S& operator = (S const) {puts ("operator = (S const"); return *this;}
S (S &&) {puts ("S (S &&)");}
S& operator = (S &&) {puts ("operator = (S &&)"); return *this;}
};
int main (int, char **)
{
vector <S> v;
cout <<"capacity =" <<v.capacity () <<"\n";
v.emplace_back ();
cout <<"capacity =" <<v.capacity () <<"\n";
v.emplace_back ();
cout <<"capacity =" <<v.capacity () <<"\n";
v.emplace_back ();
cout <<"capacity =" <<v.capacity () <<"\n";
return 0;
}

At me such output turned out:
[spoiler]
capacity=0
S ()
capacity=1
S ()
S (S const)
capacity=2
S ()
S (S const)
S (S const)
capacity=4
Program ended with exit code: 0
[/spoiler]
Try to explain each line of an output.
We have three calls  the designer and three calls of the designer of copying.
And then, if you simply add noexcept to the move-designer it will be caused:
[spoiler]
capacity=0
S ()
capacity=1
S ()
S (S &&)
capacity=2
S ()
S (S &&)
S (S)
capacity=4
Program ended with exit code: 0
[/spoiler]

29

Re: Help I do not understand

NekZ wrote:

Simply launch this code and check up [/color]

And, a pancake, I understood, in what business (but had time to look at the code under two compilers), well, all is true, there because objects are stored in a vector. Therefore at , stl them will transfer, because in another way simply is not able. And if std:: move is, yes, it is possible and not to transfer (to what aspired) because objects as a matter of fact do not change.
I did not note a dirty trick because normally so: vector <S> I do not do:-Q (and costed, probably. "In life it is necessary to try all")
The only thing, I ask to explain, how noexcept influences a choice of the designer. The move-designer was caused in me (With ++ 11) without noexept.

30

Re: Help I do not understand

CEMb wrote:

the only thing, I ask to explain, how noexcept influences a choice of the designer. The move-designer was caused in me (With ++ 11) without noexept.

, not noexcept the move-designer will be caused only when there is no generally an accessible designer of copying and there is explicitly  a move-designer without noexcept'.
That is, a priority of a choice such, from top to down:
1. noexcept move-ctor
2. copy-ctor
3. move-ctor
4. error

31

Re: Help I do not understand

CEMb wrote:

there because objects are stored in a vector.

Logically. For POD-types, including crude pointers, you will not redefine the move-designer. In such cases, the vector simply does memmove that as though hints ;-)

32

Re: Help I do not understand

NekZ wrote:

it is logical.

that once throwing object in a vector is logical, I should not expect a repeated call of the designer for it as I do not move object, and at a stretching of a vector the object should not to be moved in an ideal.

33

Re: Help I do not understand

CEMb wrote:

at a stretching of a vector the object should not to be moved in an ideal.

How then it is possible to increase the size of a vector, saving serial layout of its elements in storage? Miracles does not happen.

34

Re: Help I do not understand

CEMb wrote:

it is passed...
Logically that once throwing object in a vector, I should not expect a repeated call of the designer for it as I do not move object, and at a stretching of a vector the object should not to be moved in an ideal.

Perhaps then other container, for example, std:: list is necessary to you?

35

Re: Help I do not understand

NekZ wrote:

Perhaps then other container, for example, std:: list is necessary to you?

yes not, I am simple in vectors indexes/POD I store, so all apprx.
But I really did not expect that the designer will be caused at transfer of interiors of a vector. Why not to transfer byte-in-byte the data?

36

Re: Help I do not understand

CEMb wrote:

Why not to transfer byte-in-byte the data?

For example there there can be a pointer on the buffer in object. recently considered a glitch with std:: string .

37

Re: Help I do not understand

Dima T wrote:

For example there there can be a pointer on the buffer in object.

Thanks, a question it is removed [img=http://www.sql.ru/forum/images/happy.gif]

38

Re: Help I do not understand

CEMb wrote:

yes not, I am simple in vectors indexes/POD I store, so all apprx.

Then you all the same should remember that if store clever pointers in a vector, at them, most likely, is sometimes caused move-ctor ;-)

39

Re: Help I do not understand

CEMb wrote:

I am simple in vectors indexes/POD I store

Well and objects are allocated on a heap devils where, and serial search will be with speed of operation of storage (time in 3-4 more slowly, than could)?

40

Re: Help I do not understand

NekZ wrote:

should remember

yes, now I will be!

alex_k wrote:

well and objects are allocated on a heap devils where, and serial search will be with speed of operation of storage (time in 3-4 more slowly, than could)?

it is necessary to check up. On idea be not strong should more slowly, what flew down, what a heap? In a case with a heap simply one more operation of dereferencing (and I normally in the cycle beginning take at once the pointer from the iterator and I work already with it), and all rests against how we work with object.
Well, the ideal decision on all cases in pluses is not present. If the vector is often transferred - more favourably, probably, to hold pointers. If is not present - objects.

41

Re: Help I do not understand

CEMb wrote:

it is passed...
It is necessary to check up. On idea be not strong should more slowly, what flew down, what a heap? In a case with a heap simply one more operation of dereferencing (and I normally in the cycle beginning take at once the pointer from the iterator and I work already with it), and all rests against how we work with object.
Well, the ideal decision on all cases in pluses is not present. If the vector is often transferred - more favourably, probably, to hold pointers. If is not present - objects.

Here data migration in processor caches when you sequentially address to the continuous piece of storage, probably, meant that much more accelerates code performance. And when the data on storage is scattered under pointers for a gain of speed do not wait.

42

Re: Help I do not understand

NekZ wrote:

And when the data on storage is scattered under pointers for a gain of speed do not wait.

in a case, when a vector very dynamic, without pointers, but with the big objects the gain of speed can and to be for the transfer account only pointers, instead of objects.

43

Re: Help I do not understand

CEMb wrote:

it is passed...
In a case, when a vector very dynamic, without pointers, but with the big objects the gain of speed can and to be for the transfer account only pointers, instead of objects.

It is very thin trade-of