Здравствуйте, sci_reseacher, Вы писали:

_>требуется только читать эти данные вне (править нельзя).
_>Вот так будет верно?

Да. Если данные требуется только читать, то, конечно, ни копировать, ни перемещать их не нужно. В этой ситуации использовать константную ссылку на них — прямо лучший вариант.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:

__>>что такое "правильным"?

TB>Правильным это значит правильным.

правильность без указания конкретных критериев, является субъективным понятием.

__>>не совсем верная аналогия. у деструктора однозначная семантика — завершать существование объекта, а вот у move она расплывчатая (перемещать и оставлять объект только для удаления или все же оставлять его в "нуль состоянии" с возможностью продолжить работу с объектом).

TB>>>Подумай сам, если объект после мува невалиден, то как у него будет вызываться деструктор? Ведь компилятору пофиг, делали объекту мув. или нет, он по любому будет его деструктировать.

__>>вы наверное не поняли. невалидный не в смысле "даже удалиться не сможет без ошибок",а в смысле — единственное, на что он способен — умереть (на то он и expired). иными словами, он переведен в конечное состояние, из которого нет выхода на нормальную работу (ну, не знаю, например, объект класса, который логически не допускает конструктора по умолчанию, и у которого все нужные для работы данные были перемещены)

TB>Это какой-то надуманный класс. Если есть нулевое состояние, то никто не мешает конструировать по умолчанию в него и делать метод вывода из него.

а если нет нулевого состояния? ну не имеет оно логического смысла/вредно/опасно/неудобно?

TB>>>Так что если увидишь инвалидирующий мув, то пинай этого программиста.

__>>ну так это и означает, что неинвалидирующий мув — это "по правилу хорошего тона", а значит, нет никаких гарантий

TB>Насрать в деструкторе — это тоже "правило хорошего тона"? Тебе какое слово нужно, я просто не понимаю? У тебя кодовое слово "мамой клянусь, что всё збс будет"?

важна однозначность трактовки. если я вижу vec_1.swap(vec_2), где vec_1 пустой, то я точно знаю, что произойдет (нет никаких домыслов, переведется ли он в нулевое состояние или инвалидное, будет ли это нулевое совпадать с обычным состояние впервые созданного по дефолту объекта или нет. и проч.)

Здравствуйте, sci_reseacher, Вы писали:

_>Есть внутренний вектор с данными (правят их методы класса),

_>требуется только читать эти данные вне (править нельзя).

_>Вот так будет верно?

_>

_>class A {
_>std::vector<int> x; // данные здесь
_>public:
_>A(const size_t n){ x.resize(n,25); }
_>const std::vector<int> & getRefToV(){ return x; }
_>};

_>int main(){
_>    A a(5);
_>    const std::vector<int> & ref_to_x = a.getRefToV(); // здесь просто ссылка
_>    for( const auto & e: ref_to_x) { std::cout << e << ' ' ; }
_>}
_>$ c++ -std=c++11 t2.cpp -o t2 && ./t2
_>25 25 25 25 25 
_>

только тогда уже

const std::vector<int> & getConstRefToV(){ return x; }

а вообще, как, ан мой взгляд, правильно выше отметил Егор, ваше дело отдать доступ к объекту,а уже на стороне принимающего должны решать, скопировать его "чтобы гарантировать целостность во времени" или пренебречь (если это не приницпиально). потому, имхо, не надо в названии указывать "RefToV"

Здравствуйте, _hum_, Вы писали:

__>правильность без указания конкретных критериев, является субъективным понятием.

Оставляет объект в правильном состоянии, ты не знаешь, что такое правильное состояние объекта?

__>а если нет нулевого состояния? ну не имеет оно логического смысла/вредно/опасно/неудобно?

Тогда мув-конструктор невозможен, например. Потому что во что переводить второй объект?

__>важна однозначность трактовки. если я вижу vec_1.swap(vec_2), где vec_1 пустой, то я точно знаю, что произойдет (нет никаких домыслов, переведется ли он в нулевое состояние или инвалидное, будет ли это нулевое совпадать с обычным состояние впервые созданного по дефолту объекта или нет. и проч.)

Однозначно промуванному вектору можно вызвать клиар/ресайз и дальше работать с нужным числом элементов.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:

__>>правильность без указания конкретных критериев, является субъективным понятием.

TB>Оставляет объект в правильном состоянии, ты не знаешь, что такое правильное состояние объекта?

нет а можете рассказать?

__>>а если нет нулевого состояния? ну не имеет оно логического смысла/вредно/опасно/неудобно?

TB>Тогда мув-конструктор невозможен, например. Потому что во что переводить второй объект?

невозможен или "попахивает" с точки зрения "правил хорошего тона"? как вариант — второй объект переводится в "expired-state" (с гарантией правильного удаления и только)

T4r4sB, я согласен в с вами, что неплохо было бы придерживаться правила — разрешать применять move только тогда, когда
1) объект имеет null-state в понимании :

Andrzej's C++ blog: Null-state

Properties of null-state
In general, there are only two useful operations that you can successfully perform on such object: assign it a normal (non-null) value and safely destroy it.

(это же вы имели в виду?)

2) перемeщение приводит к переводу объекта в null-state

но, во-первых, в текущем варианте языка это не отслеживается, а значит, развязывает руки
а во-вторых, речь же шла не об этом, а о том, что вариант со свопом более нагляден и однозначен.


__>>важна однозначность трактовки. если я вижу vec_1.swap(vec_2), где vec_1 пустой, то я точно знаю, что произойдет (нет никаких домыслов, переведется ли он в нулевое состояние или инвалидное, будет ли это нулевое совпадать с обычным состояние впервые созданного по дефолту объекта или нет. и проч.)

TB>Однозначно промуванному вектору можно вызвать клиар/ресайз и дальше работать с нужным числом элементов.

ну для этого нужно лезть в доки и узнавать, что это так вот теперь, после разговоров с вами и заверений, что для stl указанные выше пункты выполняются + null state совпадает с первоначальным состоянием только что сконструированного по дефолту объекта, я смогу спокойно применять мув вместо свопа для векторов и других объектов stl

Здравствуйте, _hum_, Вы писали:

__>нет а можете рассказать?

Я хз, как тогда можно на С++ писать. Все методы класса предполагают, что между его элементами есть некие соглашения типа "поле "размер" не равно нулю тогда и только тогда, когда поле "указатель" указывает на блок данных нужного размеры, на который больше никто данного типа не указывает" итд, без соглашений методы накроются, программу разнесёт нахрен.

TB>>Тогда мув-конструктор невозможен, например. Потому что во что переводить второй объект?

__>невозможен или "попахивает" с точки зрения "правил хорошего тона"? как вариант — второй объект переводится в "expired-state" (с гарантией правильного удаления и только)

Во что он будет переводить, чисто логически?
Не, можно делать копию, кстати, да. Это как раз коректно, но не по правилам хорошего тона.
Но валидность гарантируется.

__>но, во-первых, в текущем варианте языка это не отслеживается, а значит, развязывает руки

А кто отслеживает, что ты в деструкторе не накосячишь?

__>а во-вторых, речь же шла не об этом, а о том, что вариант со свопом более нагляден и однозначен.

Своп не нагляден, когда нужен обмен. Потому что своп подразумевает, что мы хотели своп, а не просто переместить.

__>ну для этого нужно лезть в доки и узнавать, что это так

Это для любого класса верно. Только вместо ресайза подставь другой "метод, доступный из любого валидного состояния". Понятно, что обращаться по индексу 100500 у промуванного вектора не стоит.

Здравствуйте, _hum_, Вы писали:

__>только тогда уже
__>const std::vector<int> & getConstRefToV(){ return x; }

только тогда уж:

const std::vector<int> & getConstRefToV() const { return x; }

Здравствуйте, watchmaker, Вы писали:

W>Или через ref-qulifiers отдать выбор нужной перегрузки компилятору:

using V = std::vector<int>;

W>  const V& CopyX() const& {
W>    return x;
W>  }
  
W>  V&& CopyX() && {
W>    return std::move(x);
W>  }
  
W>  void CopyTo(V& target) const& {
W>    target.assign(x.begin(), x.end());
W>  }
  
W>  void CopyTo(V& target) && {
W>    target.swap(x);
W>  }
W>

W>Тогда, например, получится [ccode]

Какой прок от квалификаторов?

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:


TB>>>Тогда мув-конструктор невозможен, например. Потому что во что переводить второй объект?

__>>невозможен или "попахивает" с точки зрения "правил хорошего тона"? как вариант — второй объект переводится в "expired-state" (с гарантией правильного удаления и только)

TB>Во что он будет переводить, чисто логически?

чисто логически в "объект с нарушенной целостностью (incosistent)" — то, что можно только выбросить, но никак не пытаться вновь использовать (какой-то аналог объекта, выбросившего исключение, или объекта, вызов метода set для которого завершился с ненулевым кодом ошибки)

TB>Не, можно делать копию, кстати, да. Это как раз коректно, но не по правилам хорошего тона.
TB>Но валидность гарантируется.

вы про какую копию? оставлять копию исходного перемещенного объекта? ну так зачем тогда вообще понятие перемещения?

__>>но, во-первых, в текущем варианте языка это не отслеживается, а значит, развязывает руки

TB>А кто отслеживает, что ты в деструкторе не накосячишь?

понимаете, тут речь о степени косяков. вроде, есть понятие контракта. так вот переопределение деструктора имеет однозначный контракт — вы подписываетесь под тем, что берете отвественность за корректную деинициализацию объекта перед его физическим удалением. и другой человек ожидает от подписавшего этот конракт очевидных действий.
с move такого очевидного однозначного контракта нет, а значит, один будет при его использовании считать, что подписывается на одно, а другой — на другое. итого — misunderstanding.

так вот, если кто-то нарушает однозначный контракт (нарушает требование контракта о корректной деинициализации объекта в деструкторе) — это ошибка первого рода (криворукий программист), а вот если начинаются ошибки из-за отсутствия однозначного контракта и его требований — это уже совсем другого порядка ошибки.

__>>а во-вторых, речь же шла не об этом, а о том, что вариант со свопом более нагляден и однозначен.

TB>Своп не нагляден, когда нужен обмен. Потому что своп подразумевает, что мы хотели своп, а не просто переместить.

но для пустого объекта он в точности по логике совпадает с перемещением

__>>ну для этого нужно лезть в доки и узнавать, что это так

TB>Это для любого класса верно. Только вместо ресайза подставь другой "метод, доступный из любого валидного состояния". Понятно, что обращаться по индексу 100500 у промуванного вектора не стоит.

нее, одно дело почитать спецификацию функции, и совсем другое искать в стандартах и проч. какие-то там гарантии чего-то..

Здравствуйте, _hum_, Вы писали:

__>чисто логически в "объект с нарушенной целостностью (incosistent)" — то, что можно только выбросить, но никак не пытаться вновь использовать (какой-то аналог объекта, выбросившего исключение, или объекта, вызов метода set для которого завершился с ненулевым кодом ошибки)

Ты понимаешь, что объекту с нарушенной целостностью нельзя вызывать деструктор, что противоречит определению мува? Ты понимаешь, что "выбросить" и вызвать деструктор — это разные вещи?

__>вы про какую копию? оставлять копию исходного перемещенного объекта? ну так зачем тогда вообще понятие перемещения?

Ну иначе для объекта-без-нулевого-состояния мув не сделать никак.

__>понимаете, тут речь о степени косяков. вроде, есть понятие контракта. так вот переопределение деструктора имеет однозначный контракт — вы подписываетесь под тем, что берете отвественность за корректную деинициализацию объекта перед его физическим удалением. и другой человек ожидает от подписавшего этот конракт очевидных действий.
__>с move такого очевидного однозначного контракта нет, а значит, один будет при его использовании считать, что подписывается на одно, а другой — на другое. итого — misunderstanding.

С мув есть однозначный контракт, что объект остаётся валиден. Но точное значение объекта тебе никто не предскажет.

__>но для пустого объекта он в точности по логике совпадает с перемещением

Давай называть красное белым?

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:

__>>чисто логически в "объект с нарушенной целостностью (incosistent)" — то, что можно только выбросить, но никак не пытаться вновь использовать (какой-то аналог объекта, выбросившего исключение, или объекта, вызов метода set для которого завершился с ненулевым кодом ошибки)

TB>Ты понимаешь, что объекту с нарушенной целостностью нельзя вызывать деструктор, что противоречит определению мува? Ты понимаешь, что "выбросить" и вызвать деструктор — это разные вещи?

чтоб не спорить на пустом месте, давайте я введу определение:

u-состоянием объекта назовем состояние, для которого единственная операция, корректность исполнения которой гарантирована — это удаление.

вот в моем понимании минимальное требование к move — перевод в u-состояние. ваше же требование (которое мне симпатично, но от этого не становится едиснтвенным) — перевод в null-состояние.
итого, как минимум два возможных контракта на применение move.

__>>вы про какую копию? оставлять копию исходного перемещенного объекта? ну так зачем тогда вообще понятие перемещения?

TB>Ну иначе для объекта-без-нулевого-состояния мув не сделать никак.

сделать можно , переведя в u-состояние

__>>понимаете, тут речь о степени косяков. вроде, есть понятие контракта. так вот переопределение деструктора имеет однозначный контракт — вы подписываетесь под тем, что берете отвественность за корректную деинициализацию объекта перед его физическим удалением. и другой человек ожидает от подписавшего этот конракт очевидных действий.
__>>с move такого очевидного однозначного контракта нет, а значит, один будет при его использовании считать, что подписывается на одно, а другой — на другое. итого — misunderstanding.

TB>С мув есть однозначный контракт, что объект остаётся валиден. Но точное значение объекта тебе никто не предскажет.

остается определиться
1) что вы понимаете под "валиден" — в состоянии u- или null- ;
2) где в специикации языка указан этот конракт (как для деструктора)

__>>но для пустого объекта он в точности по логике совпадает с перемещением

TB>Давай называть красное белым?

если только есть вероятность, что в дальнейшем пустой вектор может превратиться в непустой перед свопом.

Здравствуйте, _hum_, Вы писали:

__>u-состоянием объекта назовем состояние, для которого единственная операция, корректность исполнения которой гарантирована — это удаление.

Нет смысла делать такой класс. Кончай придумывать бред, нет там такого.

__>остается определиться
__>1) что вы понимаете под "валиден" — в состоянии u- или null- ;

Я выше написал же, что значит "валиден".

__>2) где в специикации языка указан этот конракт (как для деструктора)

Я хз, стандарт не зубрил, где-то там.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:

__>>u-состоянием объекта назовем состояние, для которого единственная операция, корректность исполнения которой гарантирована — это удаление.

TB>Нет смысла делать такой класс. Кончай придумывать бред, нет там такого.

не класс, а состояние объекта (вы вообще читаете, что я пишу?)

__>>остается определиться
__>>1) что вы понимаете под "валиден" — в состоянии u- или null- ;

TB>Я выше написал же, что значит "валиден".

мне перелопачивать все ветки, а вам лишь написать u- или null- (конечно, при условии, что вы поняли, о чем речь)

__>>2) где в специикации языка указан этот конракт (как для деструктора)

TB>Я хз, стандарт не зубрил, где-то там.

и вы, действительно, это видели своими глазами (чтобы в стандарте прописывалось, что применение move к l-value нацелено на перемещение из него данных с переводом при этом его в null-состояние)?

Здравствуйте, _hum_, Вы писали:

__>не класс, а состояние объекта (вы вообще читаете, что я пишу?)

А ты вообще понимаешь, что я пишу? Нет смысла делать такой класс. У которого есть такое состояние. Потому что если сделали такое состояние, то его же можно использовать как "нулевое".

__>мне перелопачивать все ветки, а вам лишь написать u- или null- (конечно, при условии, что вы поняли, о чем речь)

Это было в то же сообщении, на которое ты отвечал, причём в этом же ответе ты спросил "что такое валидное состояние"
И это ты ещё меня обвиняешь в том, что я не читаю, что ты пишешь.

__>и вы, действительно, это видели своими глазами (чтобы в стандарте прописывалось, что применение move к l-value нацелено на перемещение из него данных с переводом при этом его в null-состояние)?

Не в null-состояние, а в какое-то валидное состояние.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:

__>>не класс, а состояние объекта (вы вообще читаете, что я пишу?)

TB>А ты вообще понимаешь, что я пишу? Нет смысла делать такой класс. У которого есть такое состояние. Потому что если сделали такое состояние, то его же можно использовать как "нулевое".

T4r4sB, я предлагал строго очертить границы понятий, которыми пользуемся в разговоре, чтобы, во-первых, понимать одно и то же под одним и тем же термином, а во-вторых, не скатываться в демагогию.
для этого я привел точные определения понятий

null-состояние объекта как состояние, для которого

In general, there are only two useful operations that you can successfully perform on such object: assign it a normal (non-null) value and safely destroy it.

и u-состояние — состояние

для которого единственная операция, корректность исполнения которой гарантирована — это удаление.

и пытался ими оперировать, но вы опять ушли в какое-то эфемерное "валидное состояние". раз так, будьте добры аналогичным образом дать его определение.

Здравствуйте, _hum_, Вы писали:


__>T4r4sB, я предлагал строго очертить границы понятий, которыми пользуемся в разговоре, чтобы, во-первых, понимать одно и то же под одним и тем же термином, а во-вторых, не скатываться в демагогию.

А, хочешь поговорить о сущности понятия "валидное состояние" — это не ко мне, я ляля не умею. Я всё сказал, что мог, твои страхи перед мувом безосновательны.