- 主题:我勒个叉，这个低级 BUG
太复杂了
私有地址优先、ipv4优先，这就两个开关了，再加上v4、v6的地址是不是空，总共相当于4个开关，16种情况了。
那这个函数必须有覆盖这16种情况的单元测试用例，主要靠开发人员，不是靠黑盒测试
chatgpt能找出来错误：
在这段代码中，存在一个笔误的低级错误。问题在于使用了引用类型(std::string&)对局部变量进行赋值操作。具体地，ipAddress是通过条件表达式赋值的，它应该直接被赋值为一个string类型的值，而不是一个引用(std::string&)。由于ipAddress在之后被用作值，而不是用来修改address4或者address6的原始值，因此这里使用引用是不恰当的。
引用我一般是优先写为const auto &的，除非需要通过引用来修改原值才写为auto &。
--
修改:z16166 FROM 221.220.171.*
FROM 221.220.171.*
chatgpt：
根据您的要求，为了使代码更加优雅且清晰，我们可以通过减少条件判断来简化这个函数的逻辑。我们将优先处理IPv4和私有地址的选择，然后根据地址是否为空来决定使用哪个IP地址。此外，我们修正了之前提到的可修改引用的问题：
void getRelayTuple(bool destinationIsPrivate,
bool destV4,
int64_t& serverId,
voice::Tuple& relayTuple)
{
serverId = mServerId;
// 优先选择IP地址：优先考虑私有地址，然后是IPv4
const std::string& preferredAddress4 = destinationIsPrivate ? mPrivateServerIp4 : mPublicServerIp4;
const std::string& preferredAddress6 = destinationIsPrivate ? mPrivateServerIp6 : mPublicServerIp6;
// 根据IPv4/IPv6和地址是否为空进行选择
std::string chosenIpAddress;
if (destV4) {
chosenIpAddress = !preferredAddress4.empty() ? preferredAddress4 : preferredAddress6;
} else {
chosenIpAddress = !preferredAddress6.empty() ? preferredAddress6 : preferredAddress4;
}
// 如果找到合适的IP地址，设置relayTuple
if (!chosenIpAddress.empty()) {
relayTuple = voice::Tuple(chosenIpAddress, mRelayPort, proto::UDP);
}
}
这里的修改点包括：
将std::string&修改为const std::string&来使用引用，因为我们只需要引用成员变量而不需要修改它们。
引入了chosenIpAddress作为局部变量，存储最终选择的IP地址。不再使用引用因为这里我们要存储的是地址字符串的副本。
简化逻辑：首先确定是否需要用IPv4还是IPv6地址，然后在对应的地址（IPv4或IPv6）中选择一个非空的地址。如果IPv4优先但IPv4地址为空，则尝试使用IPv6地址，反之亦然。
增加了对chosenIpAddress是否为空的检查，确保在设置relayTuple之前，我们确实有一个有效的IP地址。
通过这些修改，代码更为直观和易于维护，同时仍旧满足功能需求。
--
FROM 221.220.171.*
我能说啥，你继续用bing呗，哈哈
【 在 speedboy2998 的大作中提到: 】
: BING AI 的答案, 修改对了，但是原因解释错了。
: 这段代码中的问题在于，你试图将一个临时对象（由三元运算符产生）的引用赋值给一个字符串引用。这是不被允许的，因为临时对象在表达式结束后就会被销毁，而引用仍然指向那块已经被销毁的内存。你可以通过去掉引用来解决这个问题。修改后的代码如下：
: [code=c]
: ...................
--
FROM 221.220.171.*
我感觉不如2楼chatgpt的代码
你这个if范围太大了。const std::string &就行，不用string_view也很好。
【 在 speedboy2998 的大作中提到: 】
: 这样应该是最优版本了吧？
:
: [upload=1][/upload]
--
修改:z16166 FROM 221.220.171.*
FROM 221.220.171.*
不存在这个结论吧
const std::string &的实际汇编代码也就是一个指针赋值
string_view是其内部两个成员的赋值，但这个一般用于大的string buffer，比如在一大段xml/html里处理局部的串。
你这个代码不用抠到这个程度吧
【 在 speedboy2998 的大作中提到: 】
: 不是说 string_view 优于 const std::string & 吗
:
--
FROM 221.220.171.*
给出这个结论的来源和依据。
流氓点的回答是：谁这么告诉你的，你问他去。哈哈
应该是各自有各自的适用场合才对
【 在 speedboy2998 的大作中提到: 】
: 那为啥都推崇 把 const std::string & 参数换成 std::string_view
:
--
FROM 221.220.171.*
const std::string & 和 string_view，这里有个讨论，里面各个角度基本都说了，对错自行分辨
stackoverflow dot com /questions/40127965/how-exactly-is-stdstring-view-faster-than-const-stdstring
--
FROM 221.220.171.*
不是大佬。早就学习Rust了，有几年了，哈哈
【 在 horkoson 的大作中提到: 】
: 飞鸿大佬，啥时候转rust？
--
FROM 221.220.171.*
Rust当然值得学习一下，至少详细了解一下Rust是以什么方式解决C++已有的这些问题的，。
应该不存在转的问题，Rust和C++不是互斥的，在项目上有决定权的话，两个都可以用
【 在 horkoson 的大作中提到: 】
: 有啥体会，分享一下呀，比如值不值得转？
--
FROM 221.220.171.*
你那个函数有隐患，因为地址都为空时，可能没给出口参数赋值，所以出口参数relayTuple最好是std::optional<>的
【 在 speedboy2998 的大作中提到: 】
: 感觉现在的新语言都太丑了。。。这些设计新语言的人，没有一点审美观吗？
: 还有 C++，现在也往审丑方向发展了。最新的哪个 <==> 都是什么玩意儿。
:
--
FROM 221.220.171.*