Конструкции интерфейса std :: basic_fstream и std :: unique_lock

Question

Я сравниваю два класса, потому что они оба ассоциируются с чем-то другим. std::basic_fstream должен ассоциироваться с файлом, а std::unique_lock должен ассоциироваться с мьютексом. Таким образом, предоставление метода open() представляется разумным. Тем не менее, std::unique_lock не предоставляет таких методов. В любом случае можно выполнить ленивую инициализацию с помощью назначения перемещения. Таким образом, представляется излишним предоставить метод open(). std::basic_fstream, с другой стороны, предоставляет метод open(). std::basic_fstream существует до C++ 11, и это единственный способ выполнить ленивую инициализацию. Исходя из соображений обратной совместимости, можно было бы удалить std::basic_fstream::open()? Или он все еще должен быть там, чтобы операция могла потерпеть неудачу на самом деле? Обратите внимание, что открытая (ассоциированная) операция всегда выполняется с std::unique_lock (не путать с операцией блокировки).

Answer 1

Ваше последнее предложение фактически содержит подсказку: «open (ассоциированная) операция всегда выполняется с std::unique_lock». Это позволяет объявить открытость как инвариант класса, установить ее в конструкторе и исключить исключения при редких ошибках. По сравнению с файлами: их открытие может и не выполняется, поэтому объявление open-ness как инварианта класса также не работает.