[snipped discussion about whether calling convention modifiers make
STL code non-compliant]
It's still unclear where this code is coming from. If the OP is
trying to use a Windows specific header file, the associated library
is unlikely to be available in binary form on other platforms in a
form intended to be used with the Windows specific header. And I'm
still having trouble trying to understand what the function is
supposed to do in practical terms.
The code in question is from MS's ostream header (in the code I have
posted recently I took the liberty to replace the type _Myt with
std:
stream, but it is actually typedef'ed as basic_ostream<_E,
_Tr>):
template<class _E, class _Tr = char_traits<_E> >
class basic_ostream : virtual public basic_ios<_E, _Tr> {
public:
typedef basic_ostream<_E, _Tr> _Myt;
[snip]
_Myt& operator<<(_Myt& (__cdecl *_F)(_Myt&))
{
return ((*_F)(*this));
}
[snip]
};
I understand that above definition adds a definition that is not part
of the standard. So it would be still right to say that MS's iostream
header is not standard-conformant because it lacks the required
operator that takes standard IO manipulators, wouldn't it?
The *contents* of the ostream header (and any other standard header)
should largely be considered totally non-portable. IOW, you cannot
expect MS's ostream for VC++ to do anything, even compile, on another
platform, even another MS platform, or even a different version of VC+
+.
Nor does what you posted look quite like the code in VC++'s headers,
at least the couple of current versions that I took a look at. From
which version are you getting this? In any event, several definitions
of similar form are passing an explicit this pointer to the passed
function.
Is this MSVC 6? Looking back at that it looks like you pulled the
code from the MSVC6 headers. Note that MSVC6 has a number of
significant deviations in its template support from the final C++
standard. MS, along with several other compiler vendors, got hit by a
late, and significant, change in the standard's definition of
templates. Basically MSVC6 was released before the C++98 standard was
finalized. They implemented template support as it was in the draft
standard, and then (along with several other vendors) got hit when the
standard changed. MS's policy is that they try to avoid source-code-
breaking changes *within* a release, so they never "fixed" the
template support in MSVC6. But they did in the next release (MSVC7
aka "Visual C++ .NET 2.0").
But again, where are you going with this? Have you found some flaw in
VC++'s ostream implementation? Remember, *how* ostream (or anything
else) is implemented is implementation specific, just so long as it
does the right thing, as specified by the standard. How is this
(MSVC internal)code with the calling convention attribute impacting
your code? Or at least a problem from a compiler less than a dozen
years old, and from after the C++ standard was finished?
