- 主题:标准库为什么不喜欢用方法，喜欢独立的函数？
比如下面的any， 我觉得a.cast<string>()是最顺手的方式，因为只要定义了any对象，
后面就可以自动完成，而现在any_cast设计成单独的函数，必须自己敲，很不方便。
其他类似的还有很多。c++这么设计，有什么明显的好处吗？
//--------------------------------------------------
std::any a = 1;
a = std::string("Hello world");
try {
std::cout << std::any_cast<std::string>(a) << '\n';
} catch(const std::bad_any_cast& e) {
std::cout << e.what() << '\n';
}
--
FROM 223.72.41.*
说了一堆， 还是不能否认不如a.cast_to<string>()这样舒服的事实。
【 在 z16166 的大作中提到: 】
: chatgpt：
: C++标准库中，倾向于使用非成员函数而不是成员函数的设计哲学，主要是出于以下几个原因：
: 泛化能力（Generality）：通过独立的函数可以使其适用于更多类型，不仅仅是特定于某个类的实例。例如，std::any_cast可以用于流式API设计模式，这种设计模式允许对各种不同的容器和类型进行操作，而不局限于某个特定的对象。
: ...................
--
FROM 223.72.41.*
any_cast本来支持任意类型啊
如果要做其他的事情，一样可以自己写个函数
【 在 dormouseBHU 的大作中提到: 】
: 如果要向你自定义的类型cast怎么办？独立的函数的话你可以自己写一个，成员函数你就没法自己写了
--
FROM 223.72.41.*
对， C#跟方面都不错。
不过C++、java程序员都鄙视C#程序员
【 在 fanci 的大作中提到: 】
: C# 支持 extension method，可以实现你的语法
--
FROM 223.72.41.*
std::any_cast<T1>(T2 x)
放了T2进去，却要拿T1出来， 这个本身就违背了any_cast的语义。
这样的转换，本身就应该另取一个名称。
【 在 mathzqy 的大作中提到: 】
: 模版化可能是一种原因。
: 你可以为任何一个类实现std::any_cast<T1>(T2 x)。这样std::any_cast就可以用在模版函数里，自动对T2适用。
: 但你可能无法为T2添加 T.cast 成员函数。
: ...................
--
FROM 223.72.41.*
我大概理解，有另一个类型T2, 对他定义一个自己的any_cast，这样他就能与any公用一套代码
这样有时候能带来一些便利，但是感觉不是一个好设计，容易让人混淆
【 在 mathzqy 的大作中提到: 】
: 我可能没说清楚。
: 我的意思是 T2 可能是一个别的类似any的类型。考虑下面这个函数。如果你用 t.cast 可能就受限。
: template <T1, T2>
: ...................
--
FROM 223.72.41.*
我觉得c++委员会的想法是， 你既然都用了C++了，就说明你是效率优先，其他的都靠后
否则干嘛不用其他语言。
【 在 gfkid 的大作中提到: 】
: 感觉不是以方便为首要目的
: 可能还是考虑优化方便，减少模板膨胀等
--
FROM 223.72.41.*