我们经常听到/读到应该避免动态转换。我想知道我们认为它的"好用"示例是什么？

编辑：

是的，我知道其他话题：确实是在阅读那里的第一个答案时，我问了我的问题！

解决方案

回答

我当前的玩具项目使用dynamic_cast两次；一次是为了解决C ++中缺乏多重调度的问题(这是一种访问者风格的系统，可以使用多个调度而不是dynamic_casts)，并且一次是对特定的子类型进行特殊处理。

在我看来，这两者都是可以接受的，尽管前者至少源于语言缺陷。实际上，我认为这可能是常见的情况；大多数dynamic_cast(通常有很多"设计模式")都是针对特定语言缺陷的解决方法，而不是针对特定缺陷的解决方法。

回答

通过C接口将句柄公开给对象时，可以将其用于运行时类型安全。让所有公开的类都继承自一个公共基类。接受函数的句柄时，首先转换为基类，然后动态转换为所需的类。如果它们传递了一个无意义的句柄，则在运行时找不到rtti时会出现异常。如果它们传入了错误类型的有效句柄，则将获得NULL指针，并可能引发我们自己的异常。如果它们传递了正确的指针，那就很好了。
这并不是万无一失的，但是与从句柄直接重新解释强制转换并等待某些数据在我们传递错误的句柄时被神秘破坏相比，捕获错误的库肯定要好得多。

回答

这是我经常做的事情，虽然不漂亮，但简单实用。

我经常使用实现接口的模板容器，
想像像

template<class T>
class MyVector : public ContainerInterface
...

ContainerInterface有一些基本有用的东西，仅此而已。如果我想在不公开我的模板实现的情况下对整数向量使用特定的算法，则接受接口对象并将它动态实现到实现中的MyVector很有用。例子：

// function prototype (public API, in the header file)
void ProcessVector( ContainerInterface& vecIfce );

// function implementation (private, in the .cpp file)
void ProcessVector( ContainerInterface& vecIfce)
{
    MyVector<int>& vecInt = dynamic_cast<MyVector<int> >(vecIfce); 
    // the cast throws bad_cast in case of error but you could use a
    // more complex method to choose which low-level implementation
    // to use, basically rolling by hand your own polymorphism.

    // Process a vector of integers
    ...
}

我可以将Process()方法添加到ContainerInterface中，以多态解析，这将是一种更好的OOP方法，但有时我更喜欢这样做。当我们有简单的容器，大量的算法并且想要隐藏实现时，dynamic_cast提供了一个简单而丑陋的解决方案。

我们还可以查看双调度技术。

高温超导

回答

好吧，用C＃中的扩展方法真的很好。

例如，假设我有一个对象列表，我想从它们中获取所有ID的列表。我可以逐步解决所有问题，然后将它们拉出，但我想对这些代码进行细分以供重用。

所以像

List<myObject> myObjectList = getMyObjects();

List<string> ids = myObjectList.PropertyList("id");

会很酷，除了扩展方法外，我们将不知道传入的类型。

所以

public static List<string> PropertyList(this object objList, string propName) {
    var genList = (objList.GetType())objList;
}

会很棒。

回答

这个最近的线程提供了一个方便使用的示例。有一个基本的Shape类，以及从其派生的Circle和Rectangle类。在测试相等性时，很明显，Circle不能等于Rectangle，尝试对其进行比较将是一场灾难。在遍历指向Shapes的指针的集合时，dynamic_cast会执行双重任务，告诉我们形状是否可比较，并为我们提供适当的对象以进行比较。

向量迭代器不可取消