Есть класс. Пусть его зовут TItem. Есть другой класс, пусть его зовут TRow и класс этот имеет поле Items тип которого - указатель на TItem. Третий класс по имени, например, TPlane, имеет поле Rows, тип которого - указатель на TRow. В конструкторе TPlane по Rows выделяется память для массива с базовым типом TRow, при этом по Items каждого элемента требуется выделить память для массива с базовым типом TItem. Правильно ли будет написать: ? Иметь в TRow открытый метод, меняющий количество элементов, не желательно.

Это сообщение отредактировал(а) TarasProger - 14.8.2015, 18:02

Критерии правильности зачастую сильно субъективны. Лично я так бы не написал.


Приведённый код излишне сишный. Особенно проверки на nullptr. В современном мире new бросает исключение при невозможности выделить память, а nullptr никогда не возвращается:


Проблема возникла из-за того, что n и m - нефиксированы в программе, а в классе TRow очень не хочется хранить размер массива TCell? Или по какой-то другой причине?

В принципе, в таких случаях обычно делают так:
Аналогично удаление массива.

Бросило оно исклюкаку. Дальше что? Бросить объект как попало? Начать его чистуку? Откуда? Как? Ладно ещё стояла бы задача обработать в вызывающем кода ошибку в функции, вызванной из вызванной. Тогда исключения адекватны. А когда ошибка ловится в месте возникновения, то большей пакости нет, чем исклюкака, искусственно уводящая обработку ошибки в даль от места её возникновения и выбрасывающая информацию об этом самом месте.

Добавлено @ 10:24
А ничего, что я их отпускать то и не умею?

Добавлено @ 10:27
Он там и хранится. Просто массив должен быть строго прямоугольным и ни в коем случае не ступенчатым.

Добавлено @ 10:28
Мешает явной проверке, так будет правильней.


Это сообщение отредактировал(а) TarasProger - 15.8.2015, 10:40

Энто что за абракдабра?

Добавлено через 1 минуту и 38 секунд
По-Вашему один и тот же код в зависимости от каких то субъективностей будет вести себя различно? К сожалению на моей планете маги не живут.

Ну, если Вы не в состоянии понять простых вещей (когда создаётся не массив экземпляров класса, а массив указателей, который затем инициализируется экземплярами класса с вызовом конструктора не по умолчанию), тогда до свидания.

Ах вот это что! А я то думал, почему указатель двойной. Только что это даёт?

Добавлено @ 13:12
А может здесь maloc поможет? А то всё таки во внутренности другого класса лезть не охота. Как явно вызвать конструтор по указателю?

Это сообщение отредактировал(а) TarasProger - 15.8.2015, 13:20

Вызов конструктора не по умолчанию.

Добавлено @ 13:23

Placement new.

Это сообщение отредактировал(а) feodorv - 15.8.2015, 14:26

Нет. Увы, TarasProger, Вы очень часто демонстрируете непонимание своего собеседника или поставленной задачи, уводя разговор на совсем другие рельсы. Я про поведение одного и того же кода не говорил ни слова. Вы спросили:Следовательно, речь идёт не об одном и том же коде, а о наиболее понятном, лаконичном (где-то даже красивом) и безошибочном способе написания кода для решения задачи. Восприятие кода по этим критериям, зачастую, является субъективным. Приведённый Вами код - рабочий, следовательно, можно про него сказать, что он "правильный". Тем не менее, глядя на свой код, Вы задались подобным вопросом, значит в нём есть что-то, Вас не устраивающее. Меня же в нём не устраивает всё. От явного ощущения, что это не C++, и до организации классов. И эта моя субъективность имеет, скорее всего, объективный характер - уверен, что данный код мало кому понравится.
 

Это сообщение отредактировал(а) feodorv - 15.8.2015, 13:51

new(std::nothrow) вам в помощь.

Все равно обработка нехватки памяти практически всегда сводится к убиению программы...

Речь была о правильности, а не красивостях.

Добавлено через 3 минуты и 54 секунды
С какого перепуго она вообще должна включать в себя убиение проги? Тем более сводиться к нему. Вот смотрите: работаете Вы в проге часов 300 с перерывами на сон и обед, а потом жмёте одну единственную кнопку и хлоп всё закрылось без сохранения и даже не сказало, почему. Вместо того, чтоб написать: "Закройте пару программ для освобождения памяти и повторите попытку".

Добавлено через 5 минут и 9 секунд
 Ага, есть. Не тестируемость.

Почитайте на эту тему Саттера, "Новые сложные задачи на С++", задача 23 (стр. 156-162).

Наши желания не всегда совпадают с нашими возможностями 

Вот именно.
При чём здесь какой то Статер? Что, если он в учебной задаче прописал закрытие, то это как то меняет требования к решению реальной задачи? А если он напишет, что при нехватке ширины экрана для вывода строки надо взрывать комп, ты взрывать будешь, или всё таки переностить текст на следующую строку? Если памяти нехватает, то это может быть вызвано множеством причин, в том числе, легко устранимых, выключая использование памяти парой десятков других приложений. И даже если единственная возможность исправить ситуацию - выключить комп и добавить ему физической памяти, то прога всё равно не имеет права убиваться на месте, а должна сначала сказать пользователю, в чём дело, что он не решил, что она просто глючит, а потом ещё предложить сохранить наработатнные данные в файл и даже заняться пока другими делами, для которых столько памяти не нужно, в том числе в той же самой проге, или даже повторить команду с другими параметрами. Например, надо решить дифур в частных производных и дифур этот аппрокисимируется разностной схемой. На сколько часто бить объём? Может быть при адекватном выводе пользователь просто введёт меньшее количество ячеек и ограничится пока более грубым решением. Это он может сделать самостоятельно. А не писать в службу техподдержки: "Ваша прога у меня внезапно упала при нажатии кнопки "рассчёт"" и отсылать обрывок лога, в котором ещё и по недомыслию автора нет количества ячеек. И пока техподдержка будет с этой проблемой разбираться, пользователь уже трижды проапгрейтит память, причём, уже первый апгрейт позволит решать даже с большим количеством ячеек. Но пользователь даже знать не будет, что дело в расходе памяти и пробовать запускать прогу не будет.