Multiple return values is now handled in C++ with tuples and std::tie.

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.

> "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.

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).

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.

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.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.

A common way to solve that is to have a function argument point to a place where you want the result to end up, and always return FOO_ERROR or FOO_OK.

i.e.,

    int foo_new(foo_t **res);
    int foo_mutate_copy(foo_t *foo, bar_t *bar, foo_t **new_foo);

Instead of

    foo_t *foo_new(); // returns NULL on failure
    foo_t *foo_mutate_copy(foo_t *foo, bar_t *bar); // returns NULL on failure

I also like the Go way, just thought this way of doing things in C should be mentioned in the thread.

>using up your only return value and having to take pointer arguments when you would rather not.

I specifically mention the C way of doing things- but use you demonstrate it above. I was suggesting the Go way is superior.