dolphin/Source/Core/Common/IOFile.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

129 lines
2.8 KiB
C
Raw Normal View History

// Copyright 2008 Dolphin Emulator Project
// SPDX-License-Identifier: GPL-2.0-or-later
#pragma once
2021-09-03 20:39:05 +00:00
#include <array>
#include <cstddef>
#include <cstdio>
#include <string>
#include <string_view>
#include "Common/CommonTypes.h"
namespace File
{
enum class SeekOrigin
{
Begin,
Current,
End,
};
enum class SharedAccess
{
Default,
Read,
};
// simple wrapper for cstdlib file functions to
// hopefully will make error checking easier
// and make forgetting an fclose() harder
Remove NonCopyable The class NonCopyable is, like the name says, supposed to disallow copying. But should it allow moving? For a long time, NonCopyable used to not allow moving. (It declared a deleted copy constructor and assigment operator without declaring a move constructor and assignment operator, making the compiler implicitly delete the move constructor and assignment operator.) That's fine if the classes that inherit from NonCopyable don't need to be movable or if writing the move constructor and assignment operator by hand is fine, but that's not the case for all classes, as I discovered when I was working on the DirectoryBlob PR. Because of that, I decided to make NonCopyable movable in c7602cc, allowing me to use NonCopyable in DirectoryBlob.h. That was however an unfortunate decision, because some of the classes that inherit from NonCopyable have incorrect behavior when moved by default- generated move constructors and assignment operators, and do not explicitly delete the move constructors and assignment operators, relying on NonCopyable being non-movable. So what can we do about this? There are four solutions that I can think of: 1. Make NonCopyable non-movable and tell DirectoryBlob to suck it. 2. Keep allowing moving NonCopyable, and expect that classes that don't support moving will delete the move constructor and assignment operator manually. Not only is this inconsistent (having classes disallow copying one way and disallow moving another way), but deleting the move constructor and assignment operator manually is too easy to forget compared to how tricky the resulting problems are. 3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable". It works, but it feels rather silly... 4. Don't have a NonCopyable class at all. Considering that deleting the copy constructor and assignment operator only takes two lines of code, I don't see much of a reason to keep NonCopyable. I suppose that there was more of a point in having NonCopyable back in the pre-C++11 days, when it wasn't possible to use "= delete". I decided to go with the fourth one (like the commit title says). The implementation of the commit is fairly straight-forward, though I would like to point out that I skipped adding "= delete" lines for classes whose only reason for being uncopyable is that they contain uncopyable classes like File::IOFile and std::unique_ptr, because the compiler makes such classes uncopyable automatically.
2017-08-04 21:57:12 +00:00
class IOFile
{
public:
IOFile();
IOFile(std::FILE* file);
IOFile(const std::string& filename, const char openmode[],
SharedAccess sh = SharedAccess::Default);
~IOFile();
Remove NonCopyable The class NonCopyable is, like the name says, supposed to disallow copying. But should it allow moving? For a long time, NonCopyable used to not allow moving. (It declared a deleted copy constructor and assigment operator without declaring a move constructor and assignment operator, making the compiler implicitly delete the move constructor and assignment operator.) That's fine if the classes that inherit from NonCopyable don't need to be movable or if writing the move constructor and assignment operator by hand is fine, but that's not the case for all classes, as I discovered when I was working on the DirectoryBlob PR. Because of that, I decided to make NonCopyable movable in c7602cc, allowing me to use NonCopyable in DirectoryBlob.h. That was however an unfortunate decision, because some of the classes that inherit from NonCopyable have incorrect behavior when moved by default- generated move constructors and assignment operators, and do not explicitly delete the move constructors and assignment operators, relying on NonCopyable being non-movable. So what can we do about this? There are four solutions that I can think of: 1. Make NonCopyable non-movable and tell DirectoryBlob to suck it. 2. Keep allowing moving NonCopyable, and expect that classes that don't support moving will delete the move constructor and assignment operator manually. Not only is this inconsistent (having classes disallow copying one way and disallow moving another way), but deleting the move constructor and assignment operator manually is too easy to forget compared to how tricky the resulting problems are. 3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable". It works, but it feels rather silly... 4. Don't have a NonCopyable class at all. Considering that deleting the copy constructor and assignment operator only takes two lines of code, I don't see much of a reason to keep NonCopyable. I suppose that there was more of a point in having NonCopyable back in the pre-C++11 days, when it wasn't possible to use "= delete". I decided to go with the fourth one (like the commit title says). The implementation of the commit is fairly straight-forward, though I would like to point out that I skipped adding "= delete" lines for classes whose only reason for being uncopyable is that they contain uncopyable classes like File::IOFile and std::unique_ptr, because the compiler makes such classes uncopyable automatically.
2017-08-04 21:57:12 +00:00
IOFile(const IOFile&) = delete;
IOFile& operator=(const IOFile&) = delete;
IOFile(IOFile&& other) noexcept;
IOFile& operator=(IOFile&& other) noexcept;
void Swap(IOFile& other) noexcept;
bool Open(const std::string& filename, const char openmode[],
SharedAccess sh = SharedAccess::Default);
bool Close();
IOFile Duplicate(const char openmode[]) const;
template <typename T>
2017-09-04 10:35:21 +00:00
bool ReadArray(T* elements, size_t count, size_t* num_read = nullptr)
{
2017-09-04 10:35:21 +00:00
size_t read_count = 0;
if (!IsOpen() || count != (read_count = std::fread(elements, sizeof(T), count, m_file)))
m_good = false;
2017-09-04 10:35:21 +00:00
if (num_read)
*num_read = read_count;
return m_good;
}
template <typename T>
2017-09-04 10:35:21 +00:00
bool WriteArray(const T* elements, size_t count)
{
2017-09-04 10:35:21 +00:00
if (!IsOpen() || count != std::fwrite(elements, sizeof(T), count, m_file))
m_good = false;
return m_good;
}
2021-09-03 20:39:05 +00:00
template <typename T, std::size_t N>
bool ReadArray(std::array<T, N>* elements, size_t* num_read = nullptr)
2021-09-03 20:39:05 +00:00
{
return ReadArray(elements->data(), elements->size(), num_read);
2021-09-03 20:39:05 +00:00
}
template <typename T, std::size_t N>
bool WriteArray(const std::array<T, N>& elements)
{
return WriteArray(elements.data(), elements.size());
}
bool ReadBytes(void* data, size_t length)
{
return ReadArray(reinterpret_cast<char*>(data), length);
}
bool WriteBytes(const void* data, size_t length)
{
return WriteArray(reinterpret_cast<const char*>(data), length);
}
bool WriteString(std::string_view str) { return WriteBytes(str.data(), str.size()); }
bool IsOpen() const { return nullptr != m_file; }
// m_good is set to false when a read, write or other function fails
bool IsGood() const { return m_good; }
explicit operator bool() const { return IsGood() && IsOpen(); }
std::FILE* GetHandle() { return m_file; }
void SetHandle(std::FILE* file);
bool Seek(s64 offset, SeekOrigin origin);
u64 Tell() const;
u64 GetSize() const;
bool Resize(u64 size);
bool Flush();
// clear error state
void ClearError()
{
m_good = true;
if (IsOpen())
std::clearerr(m_file);
}
private:
std::FILE* m_file;
bool m_good;
};
} // namespace File