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
Summary: | WW 11 → WW #11 |
---|
comment:2 Changed 4 years ago by
Component: | WW_c_io → WW cpp_io |
---|
comment:3 Changed 4 years ago by
Owner: | changed from Дмитрий Свиридкин to ushakova.alina |
---|---|
Type: | ожидается проверка → ожидаются исправления |
comment:4 Changed 4 years ago by
Resolution: | → задача сдана |
---|---|
Status: | assigned → closed |
Note: See
TracTickets for help on using
tickets.
Вроде работает
В опреаторы вывода объект нужно передавать по константной ссылке
В Операторы присваивани и конструкторы копирования -- также.
Стоит сделать в пару к вирутальным print -- виртуальный read, чтобы не переобперделять оператор ввода в каждом классе.
Переопределение виртуальных методов стоит помечать override.
Зачем нужны отдельные операторы для классов-наследников, если оператор для базового класса реализован с помощью виртуального метода?
Тривиальные констркуторы/деструкторы стоит реализовать с помощью = default
Все манипуляторы в операторы ввода/вывода лучше передавать по кеонстантной ссылке.
Манипулятор read_c_str не должен менять переданный указатель -- в передаче по ссылке нет надобности. Иначе в параметре, ограничивающем размер буфера, нет смысла.
Если чтение упадет, в переменной, в зависимости от стандарта, будет либо мусор, либо ноль. Следует всегда явно инициализировать переменные встроенных типов.
Код, определяющий тип сотрудника, а потом читающий, лучше убрать из main -> вынести в отдельный метод, связанный с EmployeesArray?. Пользователь библиотеки не должен думать о том, какой тип и как конструировать.
7/10