Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Does the standard specify calling conventions?

Reply
Thread Tools

Does the standard specify calling conventions?

 
 
Stuart Redmann
Guest
Posts: n/a
 
      09-16-2010

[snipped discussion about whether calling convention modifiers make
code non-standard compliant]

On Sep 15, Stuart Redmann wrote:
> > 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?



On 15 Sep., robertwessel2 wrote:
> 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+
> +.


Right. I think the error I made was that I assumed that declarations
of standardized STL classes from MS's STL headers would be portable.
Now I realize that they are not (even though they boil down to the
standard declaration when we strip off MS's extensions). I should bear
that in mind when I copy supposedly standard-compliant code from MS's
headers. I think that I got the picture now.

Thanks.

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


This is from VC6.0 as well as VC 2008 (without any Platform SDK).

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


I just posted some code of mine to someone else who has a different
compiler. I didn't realize that my code was full of MS's extensions
that would not work on his compiler. My mistake.

Many thanks,
Stuart
 
Reply With Quote
 
 
 
 
Stuart Redmann
Guest
Posts: n/a
 
      09-16-2010
Stuart Redmann wrote:
> > 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?


On 15 Sep., Bo Persson wrote:
> No, __cdecl is the default calling convention, so if you provide a
> function with a stream reference parameter and return value, it will
> be usable as a stream manipulator (inserting the function into the
> stream, calls the function with the stream as a parameter).


I see. So MS's definition of operator<< pretty much boils down to the
standard declaration of the operator<<. I guess what confused me the
most is that __cdecl only appears at this place (in my opinion it
should either appear everywhere or not at all).

Many thanks,
Stuart
 
Reply With Quote
 
 
 
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      09-16-2010
On Sep 16, 2:16*am, Stuart Redmann <(E-Mail Removed)> wrote:
> Right. I think the error I made was that I assumed that declarations
> of standardized STL classes from MS's STL headers would be portable.
> Now I realize that they are not (even though they boil down to the
> standard declaration when we strip off MS's extensions). I should bear
> that in mind when I copy supposedly standard-compliant code from MS's
> headers. I think that I got the picture now.



As a general comment, in the implementation supplied headers there
isn't necessarily any "standard-compliant" code at all, except what
the implementation needs to perform the functions defined to be
performed by the inclusion of that header. There is no "supposedly
standard-compliant code" in any of the implementation supplied
headers, MS or otherwise, except by coincidence.

Some headers are actually defined to require non-portable contents -
the definition of the offsetof macro, for example, *cannot* be defined
in standard C or C++, but the implementation is obligated to supply
some mechanism nonetheless.

Also note that the standard headers don't even have to exist as files
that you can copy stuff from - the standard basically defines what
happens when you #include ostream, what the implementation does to
carry that out is *not* defined. A very popular approach, of course,
is to have a file called ostream somewhere, and paste that into the
source code. But that is certainly not required (at the very least we
could imagine the standard headers supplied in a pre-compiled format
and embedded in the compiler executable).

And while I've never seen anyone* raise a stink over a line or two of
a header being copied, remember that most of these header are actually
copyrighted, so copying anything from them at all is a theoretical
legal issue as well.

IOW, slap yourself on the wrist, and don't do that again!


*except perhaps SCO in their Linux lawsuits against IBM
 
Reply With Quote
 
Stuart Redmann
Guest
Posts: n/a
 
      09-17-2010
On 16 Sep., 22:30, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> On Sep 16, 2:16*am, Stuart Redmann <(E-Mail Removed)> wrote:
>
> > Right. I think the error I made was that I assumed that declarations
> > of standardized STL classes from MS's STL headers would be portable.
> > Now I realize that they are not (even though they boil down to the
> > standard declaration when we strip off MS's extensions). I should bear
> > that in mind when I copy supposedly standard-compliant code from MS's
> > headers. I think that I got the picture now.

>
> As a general comment, in the implementation supplied headers there
> isn't necessarily any "standard-compliant" code at all, except what
> the implementation needs to perform the functions defined to be
> performed by the inclusion of that header. *There is no "supposedly
> standard-compliant code" in any of the implementation supplied
> headers, MS or otherwise, except by coincidence.
>
> Some headers are actually defined to require non-portable contents -
> the definition of the offsetof macro, for example, *cannot* be defined
> in standard C or C++, but the implementation is obligated to supply
> some mechanism nonetheless.
>
> Also note that the standard headers don't even have to exist as files
> that you can copy stuff from - the standard basically defines what
> happens when you #include ostream, what the implementation does to
> carry that out is *not* defined. *A very popular approach, of course,
> is to have a file called ostream somewhere, and paste that into the
> source code. *But that is certainly not required (at the very least we
> could imagine the standard headers supplied in a pre-compiled format
> and embedded in the compiler executable).
>
> And while I've never seen anyone* raise a stink over a line or two of
> a header being copied, remember that most of these header are actually
> copyrighted, so copying anything from them at all is a theoretical
> legal issue as well.
>
> IOW, slap yourself on the wrist, and don't do that again! *


Believe it or not, but MS's ostream header does not have a copyright
disclaimer in it!!! OTOH, I think that my copying should be covered by
Fair Use.

Regards,
Stuart
 
Reply With Quote
 
Stuart Redmann
Guest
Posts: n/a
 
      09-17-2010
> On 2010-09-17 Stuart Redmann said:
> > Believe it or not, but MS's ostream header does not have a copyright
> > disclaimer in it!!!


On 17 Sep., Pete Becker wrote:
> First, the term is "copyright notice". A copyright disclaimer would be
> an announcement that copyright doesn't apply.


(*putting ashes on my head*) Thanks.

> But works are covered by copyright even if they don't have a copyright notice.


I thought this only worked in Europe, but apparently I was wrong. The
nit-picker in me wonders how I'm supposed to decide whether something
is copyrighted or not since the threshold of originality cannot be
assessed in an objective way.

Stuart
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-17-2010
Stuart Redmann <(E-Mail Removed)>, on 17/09/2010 08:17:36, wrote:

>> On 2010-09-17 Stuart Redmann said:
>>> Believe it or not, but MS's ostream header does not have a copyright
>>> disclaimer in it!!!

>
> On 17 Sep., Pete Becker wrote:
>> First, the term is "copyright notice". A copyright disclaimer would be
>> an announcement that copyright doesn't apply.

>
> (*putting ashes on my head*) Thanks.
>
>> But works are covered by copyright even if they don't have a copyright notice.

>
> I thought this only worked in Europe, but apparently I was wrong. The
> nit-picker in me wonders how I'm supposed to decide whether something
> is copyrighted or not since the threshold of originality cannot be
> assessed in an objective way.


I think the safest thing to do is to assume that everything is
copyrighted, and hence not reproducible, unless you find an explicit
notice that allows you to reproduce/reuse the material in some or some
other way.

I think that the "fair use" (reproducing small parts for commenting
about them) is fine even with fully copyrighted materials; though,
reusing even just a single line in an actual program may not be allowed
to claim the "fair use" to its defence, I suppose.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-18-2010
On Sep 17, 4:17 pm, Stuart Redmann <(E-Mail Removed)> wrote:
> > On 2010-09-17 Stuart Redmann said:
> > > Believe it or not, but MS's ostream header does not have a
> > > copyright disclaimer in it!!!


> On 17 Sep., Pete Becker wrote:


> > First, the term is "copyright notice". A copyright
> > disclaimer would be an announcement that copyright doesn't
> > apply.


> (*putting ashes on my head*) Thanks.


> > But works are covered by copyright even if they don't have a
> > copyright notice.


> I thought this only worked in Europe, but apparently I was
> wrong. The nit-picker in me wonders how I'm supposed to decide
> whether something is copyrighted or not since the threshold of
> originality cannot be assessed in an objective way.


The easy answer is: if there is an explicit statement that the
work is not copyrighted, or that the work is public domain, it's
not copyrighted (maybe---someone could easily add such a
statement to a copyrighted work). Otherwise, if the original
author has been dead for more than 50 years (I think), it's not
copyrighted. (Don't know how this works in the case of
collaborative efforts. But it certainly doesn't apply to much
C++ code.) Otherwise, it's copyrighted. Originality (at least
in the classical sense) is not necessary; when copyright law
says that the work must be "original", it means that it's not a
verbatim copy of some other work. (Again, I think. But as I
understand it, if a work is based on some other work, it may be
in violation of the copyright on that other work, but it is
still, as far as copyright law goes, a different, copyrightable
work.)

The important thing to remember is that copyright covers the
expression of the ideas, not the ideas themselves.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-18-2010
On Sep 17, 5:42 pm, Pete Becker <(E-Mail Removed)> wrote:
> On 2010-09-17 11:17:36 -0400, Stuart Redmann said:


> > The
> > nit-picker in me wonders how I'm supposed to decide whether something
> > is copyrighted or not since the threshold of originality cannot be
> > assessed in an objective way.


> Copyright doesn't depend on originality; if it's published and you
> didn't write it, don't copy it without the author's permission. Unless,
> of course, you can establish that it's in the public domain, typically
> by showing that it was written a hundred years or so ago.


Or the author has explicitly put in in the public domain?

Not at all relevant to C++, of course, but the thought occurs to
me: what about Shakespeare. Obviously, his original work is no
longer copyrighted. But normally, when I read Shakespeare, it's
not his original work, but text "established" by an editor,
based on the various extant older versions of his work. I
rather suspect that this "established" text is copyrighted, by
the editor (but I'm not sure).

Also, I thought (but I'm definitely no specialist in this
domain) that the time lapse was from the author's death, and not
from when the work was written.

--
James Kanze
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
standard libraries don't behave like standard 'libraries' Sriram Srinivasan Python 13 11-12-2009 06:05 PM
What are the standard network functions provided in standard C? disappearedng@gmail.com C Programming 5 06-10-2008 08:57 PM
when using regex object, does one specify "^" as a modifiier? Jake Barnes Javascript 6 04-09-2006 12:53 PM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM



Advertisments