4 ms·
Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones
by mappu 6y ago
Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones.
t. C++ developer with a mixed std::string/QString/BSTR codebase.
- comex 6y agoBut strings are not generic types...
- zxcmx 6y agoSo much this. Have seen apps where there were 4 diff string types brought by external dependencies and then like 3 or 4 more to deal with from diff Windows APIs.
- monocasa 6y agoWell, that's the current state of Go if the half dozen blessed versions don't fit your use case. Everyone just writes their own slightly incompatible versions.
- adev_ 6y ago> t. C++ developer with a mixed std::string/QString/BSTR codebase. This has absolutely nothing to do with generics. None of std::string or QString are generics. They are just an example of historical alternative implementations for 'reasons' ( portability/speed) that create a lesson the long term
- slavik81 6y agoIt's also unavoidable. It's not like you can pass UTF-8 Go strings to UTF-16 COM interfaces. Somebody wrote code to convert a Go string to a BSTR and vice versa. You can do the exact same thing for std::string if you want.