Opened 4 years ago

Closed 4 years ago

#668 closed ожидаются исправления (задача сдана)

WW #11

Reported by: ushakova.alina Owned by: ushakova.alina
Component: WW cpp_io Version: 1.0
Keywords: Cc:

Description


Change History (4)

comment:1 Changed 4 years ago by ushakova.alina

Summary: WW 11WW #11

comment:2 Changed 4 years ago by ushakova.alina

Component: WW_c_ioWW cpp_io

comment:3 Changed 4 years ago by Дмитрий Свиридкин

Owner: changed from Дмитрий Свиридкин to ushakova.alina
Type: ожидается проверкаожидаются исправления

Вроде работает

В опреаторы вывода объект нужно передавать по константной ссылке
В Операторы присваивани и конструкторы копирования -- также.

Стоит сделать в пару к вирутальным print -- виртуальный read, чтобы не переобперделять оператор ввода в каждом классе.

Переопределение виртуальных методов стоит помечать override.

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

Тривиальные констркуторы/деструкторы стоит реализовать с помощью = default

Все манипуляторы в операторы ввода/вывода лучше передавать по кеонстантной ссылке.
Манипулятор read_c_str не должен менять переданный указатель -- в передаче по ссылке нет надобности. Иначе в параметре, ограничивающем размер буфера, нет смысла.

  int32_t type, number_of_workers;
  istr >> read_le_int32(number_of_workers);

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

Код, определяющий тип сотрудника, а потом читающий, лучше убрать из main -> вынести в отдельный метод, связанный с EmployeesArray?. Пользователь библиотеки не должен думать о том, какой тип и как конструировать.


7/10

comment:4 Changed 4 years ago by Дмитрий Свиридкин

Resolution: задача сдана
Status: assignedclosed
Note: See TracTickets for help on using tickets.