10225501448 李度 10225101546 陈胤遒 10215501422 高宇菲
Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

108 linhas
2.8 KiB

Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}. The "DeleteFile" method name causes pain for Windows developers, because <windows.h> #defines a DeleteFile macro to DeleteFileW or DeleteFileA. Current code uses workarounds, like #undefining DeleteFile everywhere an Env is declared, implemented, or used. This CL removes the need for workarounds by renaming Env::DeleteFile to Env::RemoveFile. For consistency, Env::DeleteDir is also renamed to Env::RemoveDir. A few internal methods are also renamed for consistency. Software that supports Windows is expected to migrate any Env implementations and usage to Remove{File,Dir}, and never use the name Env::Delete{File,Dir} in its code. The renaming is done in a backwards-compatible way, at the risk of making it slightly more difficult to build a new correct Env implementation. The backwards compatibility is achieved using the following hacks: 1) Env::Remove{File,Dir} methods are added, with a default implementation that calls into Env::Delete{File,Dir}. This makes old Env implementations compatible with code that calls into the updated API. 2) The Env::Delete{File,Dir} methods are no longer pure virtuals. Instead, they gain a default implementation that calls into Env::Remove{File,Dir}. This makes updated Env implementations compatible with code that calls into the old API. The cost of this approach is that it's possible to write an Env without overriding either Rename{File,Dir} or Delete{File,Dir}, without getting a compiler warning. However, attempting to run the test suite will immediately fail with an infinite call stack ending in {Remove,Delete}{File,Dir}, making developers aware of the problem. PiperOrigin-RevId: 288710907
5 anos atrás
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}. The "DeleteFile" method name causes pain for Windows developers, because <windows.h> #defines a DeleteFile macro to DeleteFileW or DeleteFileA. Current code uses workarounds, like #undefining DeleteFile everywhere an Env is declared, implemented, or used. This CL removes the need for workarounds by renaming Env::DeleteFile to Env::RemoveFile. For consistency, Env::DeleteDir is also renamed to Env::RemoveDir. A few internal methods are also renamed for consistency. Software that supports Windows is expected to migrate any Env implementations and usage to Remove{File,Dir}, and never use the name Env::Delete{File,Dir} in its code. The renaming is done in a backwards-compatible way, at the risk of making it slightly more difficult to build a new correct Env implementation. The backwards compatibility is achieved using the following hacks: 1) Env::Remove{File,Dir} methods are added, with a default implementation that calls into Env::Delete{File,Dir}. This makes old Env implementations compatible with code that calls into the updated API. 2) The Env::Delete{File,Dir} methods are no longer pure virtuals. Instead, they gain a default implementation that calls into Env::Remove{File,Dir}. This makes updated Env implementations compatible with code that calls into the old API. The cost of this approach is that it's possible to write an Env without overriding either Rename{File,Dir} or Delete{File,Dir}, without getting a compiler warning. However, attempting to run the test suite will immediately fail with an infinite call stack ending in {Remove,Delete}{File,Dir}, making developers aware of the problem. PiperOrigin-RevId: 288710907
5 anos atrás
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}. The "DeleteFile" method name causes pain for Windows developers, because <windows.h> #defines a DeleteFile macro to DeleteFileW or DeleteFileA. Current code uses workarounds, like #undefining DeleteFile everywhere an Env is declared, implemented, or used. This CL removes the need for workarounds by renaming Env::DeleteFile to Env::RemoveFile. For consistency, Env::DeleteDir is also renamed to Env::RemoveDir. A few internal methods are also renamed for consistency. Software that supports Windows is expected to migrate any Env implementations and usage to Remove{File,Dir}, and never use the name Env::Delete{File,Dir} in its code. The renaming is done in a backwards-compatible way, at the risk of making it slightly more difficult to build a new correct Env implementation. The backwards compatibility is achieved using the following hacks: 1) Env::Remove{File,Dir} methods are added, with a default implementation that calls into Env::Delete{File,Dir}. This makes old Env implementations compatible with code that calls into the updated API. 2) The Env::Delete{File,Dir} methods are no longer pure virtuals. Instead, they gain a default implementation that calls into Env::Remove{File,Dir}. This makes updated Env implementations compatible with code that calls into the old API. The cost of this approach is that it's possible to write an Env without overriding either Rename{File,Dir} or Delete{File,Dir}, without getting a compiler warning. However, attempting to run the test suite will immediately fail with an infinite call stack ending in {Remove,Delete}{File,Dir}, making developers aware of the problem. PiperOrigin-RevId: 288710907
5 anos atrás
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}. The "DeleteFile" method name causes pain for Windows developers, because <windows.h> #defines a DeleteFile macro to DeleteFileW or DeleteFileA. Current code uses workarounds, like #undefining DeleteFile everywhere an Env is declared, implemented, or used. This CL removes the need for workarounds by renaming Env::DeleteFile to Env::RemoveFile. For consistency, Env::DeleteDir is also renamed to Env::RemoveDir. A few internal methods are also renamed for consistency. Software that supports Windows is expected to migrate any Env implementations and usage to Remove{File,Dir}, and never use the name Env::Delete{File,Dir} in its code. The renaming is done in a backwards-compatible way, at the risk of making it slightly more difficult to build a new correct Env implementation. The backwards compatibility is achieved using the following hacks: 1) Env::Remove{File,Dir} methods are added, with a default implementation that calls into Env::Delete{File,Dir}. This makes old Env implementations compatible with code that calls into the updated API. 2) The Env::Delete{File,Dir} methods are no longer pure virtuals. Instead, they gain a default implementation that calls into Env::Remove{File,Dir}. This makes updated Env implementations compatible with code that calls into the old API. The cost of this approach is that it's possible to write an Env without overriding either Rename{File,Dir} or Delete{File,Dir}, without getting a compiler warning. However, attempting to run the test suite will immediately fail with an infinite call stack ending in {Remove,Delete}{File,Dir}, making developers aware of the problem. PiperOrigin-RevId: 288710907
5 anos atrás
  1. // Copyright (c) 2011 The LevelDB Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style license that can be
  3. // found in the LICENSE file. See the AUTHORS file for names of contributors.
  4. #include "leveldb/env.h"
  5. #include <cstdarg>
  6. // This workaround can be removed when leveldb::Env::DeleteFile is removed.
  7. // See env.h for justification.
  8. #if defined(_WIN32) && defined(LEVELDB_DELETEFILE_UNDEFINED)
  9. #undef DeleteFile
  10. #endif
  11. namespace leveldb {
  12. Env::Env() = default;
  13. Env::~Env() = default;
  14. Status Env::NewAppendableFile(const std::string& fname, WritableFile** result) {
  15. return Status::NotSupported("NewAppendableFile", fname);
  16. }
  17. Status Env::RemoveDir(const std::string& dirname) { return DeleteDir(dirname); }
  18. Status Env::DeleteDir(const std::string& dirname) { return RemoveDir(dirname); }
  19. Status Env::RemoveFile(const std::string& fname) { return DeleteFile(fname); }
  20. Status Env::DeleteFile(const std::string& fname) { return RemoveFile(fname); }
  21. SequentialFile::~SequentialFile() = default;
  22. RandomAccessFile::~RandomAccessFile() = default;
  23. WritableFile::~WritableFile() = default;
  24. Logger::~Logger() = default;
  25. FileLock::~FileLock() = default;
  26. void Log(Logger* info_log, const char* format, ...) {
  27. if (info_log != nullptr) {
  28. std::va_list ap;
  29. va_start(ap, format);
  30. info_log->Logv(format, ap);
  31. va_end(ap);
  32. }
  33. }
  34. static Status DoWriteStringToFile(Env* env, const Slice& data,
  35. const std::string& fname, bool should_sync) {
  36. WritableFile* file;
  37. Status s = env->NewWritableFile(fname, &file);
  38. if (!s.ok()) {
  39. return s;
  40. }
  41. s = file->Append(data);
  42. if (s.ok() && should_sync) {
  43. s = file->Sync();
  44. }
  45. if (s.ok()) {
  46. s = file->Close();
  47. }
  48. delete file; // Will auto-close if we did not close above
  49. if (!s.ok()) {
  50. env->RemoveFile(fname);
  51. }
  52. return s;
  53. }
  54. Status WriteStringToFile(Env* env, const Slice& data,
  55. const std::string& fname) {
  56. return DoWriteStringToFile(env, data, fname, false);
  57. }
  58. Status WriteStringToFileSync(Env* env, const Slice& data,
  59. const std::string& fname) {
  60. return DoWriteStringToFile(env, data, fname, true);
  61. }
  62. Status ReadFileToString(Env* env, const std::string& fname, std::string* data) {
  63. data->clear();
  64. SequentialFile* file;
  65. Status s = env->NewSequentialFile(fname, &file);
  66. if (!s.ok()) {
  67. return s;
  68. }
  69. static const int kBufferSize = 8192;
  70. char* space = new char[kBufferSize];
  71. while (true) {
  72. Slice fragment;
  73. s = file->Read(kBufferSize, &fragment, space);
  74. if (!s.ok()) {
  75. break;
  76. }
  77. data->append(fragment.data(), fragment.size());
  78. if (fragment.empty()) {
  79. break;
  80. }
  81. }
  82. delete[] space;
  83. delete file;
  84. return s;
  85. }
  86. EnvWrapper::~EnvWrapper() {}
  87. } // namespace leveldb