3 ms·

While it works, it would be better if multiple return types were supported natively by the C++ language precisely because of this: #ifdef _WIN32 # i

by cjslep 11y ago

While it works, it would be better if multiple return types were supported natively by the C++ language precisely because of this: #ifdef _WIN32 # ifdef EXPORTING # define DECL __declspec(dllexport) # define STORAGE # else # define DECL __declspec(dllimport) # define STORAGE extern # endif #else # define DECL # define STORAGE #endif // For every return tuple type actually used: STORAGE template class DECL std::tuple<error_type, return_type1>; STORAGE template class DECL std::tuple<error_type, return_type2>; STORAGE template class DECL std::tuple<error_type, return_type3, return_type4>; // etc. Even without the above, exposing STL across shared objects leads to the games of "which side of the shared object did this get created" and "which STL did this shared object link against". Losing these games leads to sizeable butt pain.

reubenmorais 11y ago
> "which STL did this shared object link against" This alone makes exporting STL objects pretty much impossible in a sizable cross-platform project, in my experience.
maxlybbert 11y ago
That's not a C++ issue, it's a Windows issue (which is why DECL and STORAGE are defined to nothing on anything other than Windows).
- cjslep 11y ago
  It's precisely a C++ issue because if multiple return types were natively supported by the C++ language, none of this would be needed since no one would be trying to export a STL object across shared object (or DLL) boundaries. It's only the workaround (tuples) of this C++ issue that platform-specific issues are allowed to arise, like Windows as you observed, which is why I view the platform-specific issues as symptoms of a deeper problem.
  - maxlybbert 11y ago
    I may have misunderstood your terms, so I apologize if my response doesn't cover what you're talking about. > if multiple return types were natively supported by the C++ language, none of this would be needed since no one would be trying to export a STL object across shared object (or DLL) boundaries. I believe you're talking about C++ export. Everybody will say that export was too complicated to implement; although (1) the full sentence should be "too complicated to implement, using current linkers," and (2) both CFront and EDG implemented did implement export using current linkers CFront implemented it in the early '90s), so the argument that it can't be implemented is simply wrong. It is accurate to say "using current linkers, refusing to use nonportable linker features, and following the Borland template instantiation model ( https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.ht... ), it is hard to implement export; only EDG ever paid the price to do so." But the C macros to #declare dllimport/dllexport (which is what I thought your original complaint was) are meant to solve a Windows linking issue that plagues C as much as it plagues C++. And, to be honest, it's a link time optimization that non-Microsoft linkers don't appear to have trouble with.

by cjslep 11y ago

reubenmorais 11y ago

> "which STL did this shared object link against" This alone makes exporting STL objects pretty much impossible in a sizable cross-platform project, in my experience.

maxlybbert 11y ago

That's not a C++ issue, it's a Windows issue (which is why DECL and STORAGE are defined to nothing on anything other than Windows).

cjslep 11y ago
It's precisely a C++ issue because if multiple return types were natively supported by the C++ language, none of this would be needed since no one would be trying to export a STL object across shared object (or DLL) boundaries. It's only the workaround (tuples) of this C++ issue that platform-specific issues are allowed to arise, like Windows as you observed, which is why I view the platform-specific issues as symptoms of a deeper problem.
- maxlybbert 11y ago
  I may have misunderstood your terms, so I apologize if my response doesn't cover what you're talking about. > if multiple return types were natively supported by the C++ language, none of this would be needed since no one would be trying to export a STL object across shared object (or DLL) boundaries. I believe you're talking about C++ export. Everybody will say that export was too complicated to implement; although (1) the full sentence should be "too complicated to implement, using current linkers," and (2) both CFront and EDG implemented did implement export using current linkers CFront implemented it in the early '90s), so the argument that it can't be implemented is simply wrong. It is accurate to say "using current linkers, refusing to use nonportable linker features, and following the Borland template instantiation model ( https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.ht... ), it is hard to implement export; only EDG ever paid the price to do so." But the C macros to #declare dllimport/dllexport (which is what I thought your original complaint was) are meant to solve a Windows linking issue that plagues C as much as it plagues C++. And, to be honest, it's a link time optimization that non-Microsoft linkers don't appear to have trouble with.