Как заставить C++ не деконструктить экземпляр класса лишний раз в конце цикла?

Question

[Tolik]

Если цикл имеет вид

for (int i = 0; i < 4; i++) {
  neurons[i].init(3);
  neurons[i].setRandomWeights(-1.0, 1.0);
  neurons[i].dumpWeights();
}

то всё хорошо, но при

for (auto neuron : neurons) {
  neuron.init(3);
  neuron.setRandomWeights(-1.0, 1.0);
  neuron.dumpWeights();
}

деконструктор вызывается каждый раз после dumpWeights(). Но конструктор -- нет, только в начале, т.е. копии не создаются. Как исправить? Хотелось бы пользоваться красивым синтаксисом плюсов

Answer 1

[Антон Жилин]

Используйте передачу по ссылке:
for (auto& neuron : neurons)

Иначе при обходе цикла вы скопируете весь массив. А то, что конструктор вызывается только вначале, — очень странно, скорее всего, это ещё один баг. Можно увидеть всё объявление класса neuron (без реализации функций)?

Comments

[Tolik]

Не думал, что так просто:D

[Tolik]

Вот: pastebin.com/R3zrr7Mm

[Антон Жилин]

Tolik: Если заменить float* на std::vector, то это решит проблему. Или есть веские основания его не использовать?

[Tolik]

Антон Жилин: возможно, придется использовать очень много памяти. По этому и делал массив через new, который потом вроде как должен сам освобождаться. Да, можно и вектором. Неужели разница в памяти только в (sizeof(std::vecrot) - sizeof(float*)) плюс дополнительные проверки при доступе к вектору?

[Антон Жилин]

Tolik: да, вектор – это по сути, указатель на массив, плюс 2 дополнительных целочисленных поля size и capacity. Проверок при доступе к элементам нет, если собрать в Release. То есть за производительность можно не беспокоиться. Управлять размером выделенной памяти в векторе можно через reserve и shrink_to_fit.

[maaGames]

Антон Жилин: Не reserve, а resize. После reserve нельзя обращаться по индексу, только пушбэками.
Проверки доступа будут, если использовать at, вместо []. Лучше использовать at, чтобы потом меньше страдать.)

[Максим Мосейчук]

maaGames: resize вызывает конструкторы, что может быть неприемлемым.

[maaGames]

fshp: reserve выделяет память, но не разрешает её использовать, пока не будут добавлены элементы. reserve и resize вообще абсолютно разные проблемы решают. Если вызов конструктора копирования неприемлем, то вектор вообще лучше не использовать, а выбрать list,queue,set.

[Антон Жилин]

maaGames: Согласен. Если вызвать reserve, а не resize, то поле size у вектора останется прежним, и вектор не позволит обращаться к новым элементам по индексу. push_back, понятно, не лучше, так произведёт инкременты size O(n) раз. Есть способы заставить вектор не занулять память, но лучше не надо :)

[Xano]

maaGames: " Если вызов конструктора копирования неприемлем, то вектор вообще лучше не использовать" А чем emplace и std::move не угодили? Вектор - отличный универсальный контейнер. Для использования любого другого нужно найти веские аргументы.

[maaGames]

Xano: move ничем не поможет, если есть ссылки на адреса элементов, например. Если, при изменении размера вектора, невозможно выделить память там же, где она была до этого (типа realloc), то ни emplace, ни move-семантика не поможет. Нетривиальный конструктор копирования как бы намекает, что вектор скорее всего не подойдёт. За исключением случаев, когда копируемый объект может быть разрушен и это не нарушит связи между объектами.

[Mercury13]

Я и сам как-то на этом пожёгся.

[Антон Жилин]

maaGames: Вы что-то путаете. std::vector требует, чтобы элементы были, по крайней мере, MoveContstructible и MoveAssignable. То есть, например, можно запросто хранить элементы вроде std::unique_ptr и std::vector, у которых нежелательно или невозможно пользоваться обычным конструктором копирования, но корректно реализована move-семантика. Ссылки, структуры с ними и прочие константы не удовлетворяют MoveAssignable, поэтому их и нельзя хранить в std::vector.

[Антон Жилин]

maaGames: ну и конечно, объекты, в которых реализованы только обычный (нетривиальный) конструктор копирования и оператор присваивания, этому удовлетворяют, и их можно хранить в std::vector.

[maaGames]

Антон Жилин: Я говорю не про MoveAssignable. Например, есть два объекта, ссылающиехся друг на друга по указателям. Их можно сперва разместить в векторе, затем уже связать друг с другом. Но, после этого уже нельзя изменить размер вектора, потому что указатели могут перестать указывать друг на друга.

[Антон Жилин]

maaGames: Понял, согласен. Кстати, парсер вволю поиздевался над моим комментарием :(