WW 11

[Дмитрий Свиридкин]

lab_11: src/employees.cpp:167: static Employee* EmployeesArray::init_with_type(int): Assertion `false' failed.

Что-то у вас не так из бинарного файла читается. Там точно все нормально было :)

 if (!istr.fail()) {
        employees_array.employees_.insert(employees_array.employees_.end(), new_employees.begin(), new_employees.end());

Костыль с is_init можно убрать, например, запретив конструкторы по умолчанию, а для создания объектов предоставить только фабричный статический метод, принимающий stream.

У вектора есть оператор присваивания. Как-то не логично, что чтение не переписывает массив, а дописывает в конец.

в read/write_cstr верните c-строки. Эти манипуляторы для них и задумывались, иначе никакого смысла.

x_{reinterpret_cast<uint32_t &>(x)} Вот так лучше не делать. Собирайте результат во временную переменную и честно делайте memcpy или static_cast обратно.

    std::ofstream ostr;
    ostr.open(file_name, std::ios::binary);

Объявление и иницализацию не стоит разрывать. std::ofstream ostr(file_name, std::ios::binary)

[Roman Venediktov]

Оказывается, даже при открытии файла для бинарного чтения, при чтении через >>, он игнорирует знаки перевода строки и подобные...

Если запретить конструктор по умолчанию, то у нас не получится читать Employer-а с помощью
istream >> employer
,а придётся делать как-то
Employer *employer{istream}
а мы вроде как раз первого хотели добиться в этой лабе?

[Дмитрий Свиридкин]

Replying to Roman Venediktov:

Оказывается, даже при открытии файла для бинарного чтения, при чтении через >>, он игнорирует знаки перевода строки и подобные...

Если запретить конструктор по умолчанию, то у нас не получится читать Employer-а с помощью
istream >> employer
,а придётся делать как-то
Employer *employer{istream}
а мы вроде как раз первого хотели добиться в этой лабе?

Режим бинарный/не бинарный -- только про то, как обрабатывать специальные последовательности байт для определенный платформ. Под linux бинарный и не бинарный режим работают одинаково.

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

[Дмитрий Свиридкин]

Поле type_ не имеет смысла -- каждый объект и так знает свой настоящий тип. При этом приватный конструктор можно не убирать.

is_init остается костылем

auto *employees_array = new EmployeesArray; почему бы не создать на стеке?

Операторы () для массива, видимо, должны быть приватными.

8/10