避免c++builder常见错误.pdf

### 避免C++Builder常见错误的知识点详解 #### 一、AnsiString相关问题 **1.1 不要存储AnsiString::c_str()的结果** - **问题描述**: 当使用`AnsiString::c_str()`获取字符串的C风格表示形式时，如果后续对该`AnsiString`对象进行了修改，则之前通过`c_str()`获取的指针所指向的内存内容可能已发生变化。 - **原因分析**: `AnsiString`对象在被赋值新的内容时，会释放旧的内存并重新分配新的内存区域来存储新的内容。这意味着原先保存的`c_str()`返回的指针将不再有效。 - **解决办法**: 每次需要使用`AnsiString`的C风格字符串表示时，都应重新调用`c_str()`。 **1.2 不要使用AnsiString的unsigned long构造函数** - **问题描述**: 使用`AnsiString`的`unsigned long`构造函数可能会导致意料之外的行为。 - **原因分析**: 这种构造方式可能会将数字转换为不正确的字符串表示形式。 - **解决办法**: 应使用更安全的方法来转换数字为字符串，例如使用`itoa`或标准库中的`std::to_string`。 **1.3 对于属性不要使用AnsiString的+=操作符** - **问题描述**: 在处理属性时使用`AnsiString`的`+=`操作符可能会引发内存管理问题。 - **原因分析**: `+=`操作符可能导致不必要的内存复制和分配，尤其是在频繁进行字符串拼接时。 - **解决办法**: 考虑使用其他字符串拼接技术，如`sprintf`或标准库中的`std::string`。 #### 二、TList相关问题 **2.1 不能忘记删除TList里的指针** - **问题描述**: 在使用`TList`时，如果没有正确删除列表中的元素，可能会导致内存泄漏。 - **原因分析**: `TList`默认不会自动管理其中元素的生命周期。 - **解决办法**: 使用`Delete`或`DeleteMem`等方法确保每个添加到列表中的指针都被正确释放。 **2.2 不能删除TList里的void指针** - **问题描述**: 删除`TList`中的`void*`指针会导致未定义行为。 - **原因分析**: `TList`中的元素通常是指向特定类型的指针，而直接删除`void*`指针可能会导致错误。 - **解决办法**: 明确存储到`TList`中的元素类型，并确保使用正确的方法删除这些元素。 **2.3 新不要滥用TList类** - **问题描述**: 盲目使用`TList`可能会导致维护困难和效率低下。 - **原因分析**: `TList`虽然提供了一些方便的功能，但在某些情况下并不适合使用。 - **解决办法**: 根据具体需求选择合适的数据结构，比如`std::vector`或`std::list`。 #### 三、一般的VCL建议 **3.1 不要在运行时更改一个控件的Name属性** - **问题描述**: 在程序运行过程中改变控件的`Name`属性可能导致各种不可预知的问题。 - **原因分析**: 控件的`Name`属性通常用于标识控件，在运行时更改可能会影响其他依赖于该属性的代码。 - **解决办法**: 在设计阶段正确设置控件名称，并尽量避免在运行时进行更改。 **3.2 不要忘记设置运行时创建的控件的Parent属性** - **问题描述**: 忘记设置运行时创建控件的`Parent`属性可能导致控件无法正常显示。 - **原因分析**: 控件的`Parent`属性决定了它所属的容器或父级控件。 - **解决办法**: 创建控件后立即设置其`Parent`属性。 **3.3 不要设置MDI子窗体的Parent属性** - **问题描述**: 设置MDI子窗体的`Parent`属性可能会导致布局问题或其他意外行为。 - **原因分析**: MDI子窗体应该独立于其他窗体，不应与其他窗体建立父子关系。 - **解决办法**: 使用适当的MDI管理机制，避免直接设置MDI子窗体的`Parent`属性。 **3.4 在后台线程中，如果要修改可见控件，不要忘记调用Synchronize** - **问题描述**: 在非主线程中直接修改GUI控件可能导致程序崩溃或不稳定。 - **原因分析**: GUI控件通常只能在创建它们的线程中安全地访问。 - **解决办法**: 使用`Synchronize`方法确保所有对GUI控件的操作都在主线程中执行。 **3.5 如果子控件的父控件已经释放，不要delete子控件** - **问题描述**: 删除已被其父控件释放的子控件可能导致程序崩溃。 - **原因分析**: 子控件的生命周期通常与其父控件关联。 - **解决办法**: 确保在父控件释放前先释放子控件，或检查父控件的状态后再决定是否释放子控件。 **3.6 属性方法的参数不能以引用传递** - **问题描述**: 以引用方式传递属性方法的参数可能导致未定义行为。 - **原因分析**: 属性方法通常用于简单的数据存取操作，不支持复杂的引用传递机制。 - **解决办法**: 使用按值传递的方式传递参数。 **3.7 在单选的ListBox控件中不要使用TListBox的Selected属性** - **问题描述**: 在单选模式的`TListBox`中使用`Selected`属性可能会导致逻辑错误。 - **原因分析**: `Selected`属性适用于多选模式的`ListBox`，而非单选模式。 - **解决办法**: 使用`ItemIndex`属性来管理单选模式下的选定项。 **3.8 Win95/Win98中，不要在TMemo中放置超过32k的文本** - **问题描述**: 在Windows 95/98系统中，`TMemo`控件处理大量文本时可能会出现问题。 - **原因分析**: 这些操作系统对内存管理有一定的限制。 - **解决办法**: 分割大文本为多个部分，或使用更适合处理大文本的控件。 **3.9 不要使用OnCreate和OnDestroy，而要使用C++的构造函数和析构函数** - **问题描述**: 使用`OnCreate`和`OnDestroy`处理控件的生命周期可能会导致代码混乱。 - **原因分析**: 构造函数和析构函数提供了更清晰、更安全的方式来管理资源。 - **解决办法**: 尽量使用C++的构造函数和析构函数来初始化和清理控件。 **3.10 使用new而不是Application->CreateForm** - **问题描述**: 使用`new`创建窗体可以更好地控制内存分配和回收。 - **原因分析**: `Application->CreateForm`方法可能会隐藏一些重要的资源管理细节。 - **解决办法**: 使用`new`来创建窗体，并确保在适当的时候使用`delete`来释放它们。 #### 四、C++语言的建议 **4.1 不要将new[]操作符和delete混用，也不要将delete[]与new混用** - **问题描述**: 错误地使用`new[]`和`delete`或`delete[]`和`new`会导致内存泄漏或程序崩溃。 - **原因分析**: `new[]`分配的是数组，需要使用`delete[]`来释放；而`new`分配的是单个对象，应使用`delete`来释放。 - **解决办法**: 确保成对使用`new[]`和`delete[]`或`new`和`delete`。 **4.2 删除指针变量后，总是要将该变量设置为NULL或0** - **问题描述**: 删除指针后未将其设为`NULL`可能会导致悬挂指针问题。 - **原因分析**: 悬挂指针是指向已释放内存的无效指针。 - **解决办法**: 删除指针后立即将其设置为`NULL`。 **4.3 不要使用memset或ZeroMemory作为构造函数的替代** - **问题描述**: 使用`memset`或`ZeroMemory`初始化对象可能会忽略对象的实际构造过程。 - **原因分析**: 构造函数不仅负责初始化内存，还负责执行其他必要的初始化步骤。 - **解决办法**: 使用构造函数来正确初始化对象。 **4.4 对于一个enum变量，不要对它的大小做任何假定** - **问题描述**: 假定`enum`变量的大小可能会导致错误。 - **原因分析**: `enum`变量的大小可能因编译器和平台而异。 - **解决办法**: 不要依赖于`enum`变量的具体大小，使用`sizeof`来查询实际大小。 #### 五、工程方面的建议 **5.1 不要修改makefile中关于alignment和enum变量的设置开关** - **问题描述**: 修改makefile中关于对齐和`enum`变量的设置可能会导致构建问题。 - **原因分析**: 这些设置通常是为了兼容性和性能优化而设置的。 - **解决办法**: 遵循默认设置，除非有充分的理由需要更改。 **5.2 不要连接由其它编译器生成的LIB或OBJ文件** - **问题描述**: 连接其他编译器生成的库文件可能会导致链接错误。 - **原因分析**: 不同编译器之间可能存在兼容性问题。 - **解决办法**: 尽量使用同一编译器环境下的库文件。 **5.3 不要连接由较早版本的Borland编译器生成的OBJ文件** - **问题描述**: 连接较早版本编译器生成的对象文件可能导致兼容性问题。 - **原因分析**: 编译器版本之间的差异可能导致不兼容。 - **解决办法**: 使用当前版本的编译器重新编译所需的文件。 **5.4 不要使用IDE中的菜单选项来引入COM类型库** - **问题描述**: IDE的某些功能可能不完全可靠。 - **原因分析**: IDE中的某些功能可能不是最佳实践。 - **解决办法**: 手动引入COM类型库以确保正确性。 **5.5 新将BCB3的窗体引入BCB4时，将OldCreateOrder设置为false** - **问题描述**: 在将旧版本的窗体引入新版本时可能会遇到兼容性问题。 - **原因分析**: 不同版本之间的创建顺序不同。 - **解决办法**: 设置`OldCreateOrder`为`false`以确保兼容性。 #### 六、数据库的建议 **6.1 一个字段向另一个字段赋值时，不要使用AsDateTime或AsInteger** - **问题描述**: 使用`AsDateTime`或`AsInteger`进行字段赋值可能导致数据丢失或转换错误。 - **原因分析**: 这些方法可能无法正确处理不同类型之间的转换。 - **解决办法**: 使用更安全的方法进行类型转换。 **6.2 除非不得已，不要使用TCurrencyField** - **问题描述**: `TCurrencyField`可能不如预期那样精确。 - **原因分析**: `TCurrencyField`的精度有限制。 - **解决办法**: 考虑使用更高精度的数据类型。 **6.3 如果数据集的Filtered属性为真，不要打开CachedUpdates** - **问题描述**: 在数据集过滤的情况下打开`CachedUpdates`可能导致数据不一致。 - **原因分析**: 过滤后的数据集可能不完全反映数据源的真实状态。 - **解决办法**: 关闭`CachedUpdates`或在应用过滤器前完成更新操作。 **6.4 如果数据集的Filtered为真，不要调用ApplyUpdates** - **问题描述**: 在数据集过滤的情况下调用`ApplyUpdates`可能导致数据丢失。 - **原因分析**: 过滤器可能隐藏了一些需要更新的数据。 - **解决办法**: 移除过滤器或手动处理更新。 **6.5 不要使用VCL的数据感知控件** - **问题描述**: VCL的数据感知控件可能不够灵活或功能不足。 - **原因分析**: 这些控件的设计较为简单。 - **解决办法**: 使用更现代、更强大的第三方控件或框架。 **6.6 新不要使用TDBLookupComboBox或TDBLookupListBox** - **问题描述**: 这些控件可能不再适应现代应用程序的需求。 - **原因分析**: 更新的技术和控件提供了更好的功能。 - **解决办法**: 考虑使用更现代的替代品。 **6.7 设计时不要将数据集的Active属性设置为true** - **问题描述**: 在设计时激活数据集可能导致调试问题。 - **原因分析**: 活动的数据集可能会干扰设计过程。 - **解决办法**: 在运行时再激活数据集。 **6.8 如果数据集在编辑状态，不要更改Filter属性** - **问题描述**: 在编辑状态下更改过滤器可能导致数据丢失。 - **原因分析**: 过滤器的更改可能影响未提交的编辑操作。 - **解决办法**: 提交或取消编辑后再更改过滤器。 **6.9 不要在数据集的OnUpdateRecord事件中查看UpdateStatus的值** - **问题描述**: 在`OnUpdateRecord`事件中检查`UpdateStatus`可能导致不准确的结果。 - **原因分析**: `UpdateStatus`的值可能还未完全更新。 - **解决办法**: 在适当的时机检查`UpdateStatus`。 **6.10 新在数据集调用了DisableControls后，不要调用Post** - **问题描述**: 在禁用控件后调用`Post`可能导致数据未被正确提交。 - **原因分析**: `DisableControls`可能会影响数据集的状态。 - **解决办法**: 确保在启用控件后再调用`Post`。 通过遵循上述建议，可以显著提高使用C++Builder进行开发的质量和效率。这些技巧不仅有助于避免常见的错误，还能增强代码的可读性和可维护性。