[bug #68172] any() and all() should work only on numeric or logical args

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Follow-up Comment #7, bug #68172 (group octave):

I haven't come around to testing and reviewing your patch yet.

When it comes to the OCTINTERP_OVERRIDABLE_FUNC_API macro, here's what I think
is happening:

On Windows, exporting and importing functions between DLLs and other
executables needs attributes on the function declarations on both ends. When
building the DLL, it needs "dllexport" attributes. On the side of the
"consumer" of the DLL, it needs "dllimport" attributes.
The "normal" API macros (like OCTINTERP_API) automatically switch between
these two depending on whether the headers are included in compilation units
that are part of the DLL itself, or whether they are included in compilation
units for a different DLL or executable.
Having a "dllimport" attribute on a function definition causes a compilation
error. (It can only be used with function declarations *without* definition in
the same compilation unit.)

All of that becomes more complicated when it comes to C++ templates:
E.g., if the definition of a member function of a class template needs to be
exported from the DLL for some of its template instantiations, it needs to
have a "dllexport" attribute even if it is declared in a header. Otherwise,
the template would need to be instantiated in all "consuming" compilation
units (without "dllexport" attributes). For most class templates, that just
works. 
However, if template instantiations (or was it child class templates?)
specialize (or overload) member functions, that would need to happen in each
"consuming" compilation unit, too. That is impractical, and iirc we take
measures to avoid that from happening accidentally.

Overall, that means that these definitions of class template members need a
"dllexport" attribute on Windows. But they can't have a "dllimport" attribute
(because they are definitions - not just declarations). I.e., we need a macro
that expands to the "dllexport" attribute on Windows when building the DLL but
expands to nothing when "consuming" the header in other compilation units. 
That is the use case for these *_OVERRIDABLE_FUNC_API macros.


None of that is properly documented afaict. And sometimes even different
compilers for the same target can't agree on which attributes are needed
where.
I tried to deduce the "rules" from experimentation. So, I might have reached
at the wrong conclusions. I'd be happy to learn the actual rules if the above
isn't quite right.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68172>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCacVdgAAKCRCqLAuaBUf3
ToK2AP4vjeRyen94RpFNgnWAtcYzNUzghtrBCI7aaHND+mJq9QEAwdc3/vXtHNxx
oMGziv4YVcB7Qd5dcwDaeixOrXbxmQo=
=+lPQ
-----END PGP SIGNATURE-----