问题标签 [resource-management]

我们的商店已经为十几个客户端安装开发了一些 WEB/SMS/DB 解决方案。这些应用程序有一些实时性能要求，并且足以正常运行。问题是客户端（生产服务器的所有者）正在使用相同的服务器/数据库进行自定义，这会导致我们创建和部署的应用程序的性能出现问题。

客户定制的几个例子：

• 为在查询中转换为其他数据类型的列添加具有许多文本数据类型的大型表
• 没有主键、索引或 FK 约束
• 在脚本的循环中使用使用 的外部脚本count(*) from table where id = x来确定稍后如何在同一脚本中构造更多查询。（没有计划者可以优化的批量操作或一次完成所有操作）
• 服务器上的所有新代码文件均由 root 创建/拥有，具有 0777 权限

客户不接受建议/批评。如果我们继续尝试自己移植/更改脚本，旧代码可能会回来，破坏我们所做的任何更改！或者在对它们的用例了解有限的情况下，我们会在尝试优化它们的更改时破坏功能。

我的问题是：我们如何将资源限制在我们创建和部署的查询/应用程序之外？在这种情况下是否有任何务实的选择？我们以拥有 OSS 解决方案而自豪，但似乎它已成为一种负担。

我们使用在 Linux Distos 上运行的 PG 8.3。客户更喜欢 php，但 shell 脚本、perl、python 和 plpgsql 都以一种或另一种形式在系统上使用。

在 C# 中从 Windows 窗体对 MySql 数据库运行查询后关闭踏板的正确方法是什么？

像这样一个简单的打开关闭就足够了吗？

我编写了一个完全基于单个文本文件的程序：我读取文件，存储信息，然后搜索信息等。因此，要使程序工作，文件必须存在并且程序可以检测到. 我用的是eclipse，所以我把文件放在了默认的资源映射（src/main/resources）中。在我的程序开始时，我创建了文件：

但是，当我尝试使用 Maven 打包我的程序时，我得到一个 JAR，其中所有类和资源文件都存在于同一个文件夹中；我的程序停止工作，因为它再也找不到文件了。

有关如何处理此问题的任何帮助？我更喜欢我的程序在 Eclipse 和 JAR 中工作的情况，但只作为 JAR 也可以。

在关于垃圾收集是否是一件好事的圣战中，人们经常指出它不处理诸如释放文件句柄之类的事情。将此逻辑放入终结器中被认为是一件坏事，因为资源随后会被非确定性地释放。然而，对于操作系统来说，一个简单的解决方案似乎是确保大量文件句柄可用，以便它们是一种廉价而丰富的资源，并且您可以在任何给定时间浪费一些。为什么在实践中不这样做？

我看到很多围绕文件句柄的 RAII 示例类。

我试图将这些示例改编为字符指针，但没有运气。

我正在使用的库具有获取字符指针地址的函数（声明为 get_me_a_string(char **x)）。这些函数为该字符指针分配内存，并将其留给库的最终用户在他们自己的代码中清理它。

所以，我有看起来像这样的代码......

听起来 RAII 是我上面提到的这个烂摊子的答案。有人可以提供一个简单的 C++ 类来包装 char* 而不是 FILE* 吗？

谢谢

我在网上看到了很多 Scala 的 ARM（自动资源管理）示例。写一个似乎是一种仪式，尽管大多数看起来很像。不过，我确实看到了一个非常酷的使用延续的例子。

无论如何，很多代码都有这样或那样的缺陷，所以我认为在 Stack Overflow 上有一个参考是个好主意，在这里我们可以投票选出最正确和最合适的版本。

我对任何涉及组件对象模型的东西都很陌生，我想知道这种管理对 CoInitalize/CoUninitalize 的调用的方法是否有意义：

COM.hpp：

COM.cpp：

然后任何需要 COM 的组件都会调用COM::Setup()并忘记它。

这有意义还是我违反了 COM 的任何“规则”？

我是 C++ 业余爱好者。我正在编写一些 Win32 API 代码，并且有很多句柄和奇怪的复合分配对象。所以我想知道 - 是否有一些包装类可以使资源管理更容易？

例如，当我想加载一些数据时，我打开一个文件CreateFile()并获得一个HANDLE. 当我完成它时，我应该调用CloseHandle()它。但是对于任何相当复杂的加载函数，都会有几十个可能的退出点，更不用说例外了。

因此，如果我可以将句柄包装在某种包装类中，该类会CloseHandle()在执行离开范围后自动调用，那就太好了。更好的是——它可以做一些引用计数，这样我就可以将它传入和传出其他函数，并且只有在最后一个引用离开范围时才会释放资源。

这个概念很简单——但标准库中有类似的东西吗？顺便说一句，我正在使用 Visual Studio 2008，我不想附加像 Boost 之类的第 3 方框架。

也许是一个微不足道的问题，但我对答案很感兴趣。我目前正在重构一些非常大的整体字符串资源文件（每个项目一个垃圾箱资源文件，大约 30 个项目）。我将它们拆分，以便我们遵循文件约定，并使字符串在编码时更易于查找和管理。

通常我将文件拆分成这个方案：

• 错误消息.resx
• 日志消息.resx
• 查看资源.resx
• 应用资源.resx

我对命名并不十分兴奋，我只是想知道其他人使用什么。例如AppResources，我看到很多演示项目使用StringResources, Internal(terrible!) 等，而不是 (应用程序内部使用的字符串)。

对管理资源或标准命名方案的想法/轶事/建议表示赞赏。

一百万用户访问服务器上的一个文件与一百万用户访问一百万个不同文件是一样的吗？