www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/08/07:22:54

Message-ID: <003d01c091c9$d762bc00$fb4b893e@oemcomputer>
From: "Stephen Silver" <djgpp AT argentum DOT freeserve DOT co DOT uk>
To: "DJGPP Workers" <djgpp-workers AT delorie DOT com>
Subject: Re: stddef.h - namespace std patch
Date: Thu, 8 Feb 2001 12:22:43 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> On Wed, 7 Feb 2001, Stephen Silver wrote:
>
> > This is the stddef.h patch.

> > The only complication here is that 'offsetof' needs a different
> > definition in C++ (using std::size_t instead of size_t).
>
> Hmm... I feel uneasy about this.  Won't this backfire with
> older/newer/different versions of the C++ compiler,

What is the oldest version of GCC that C++ users will be using
with DJGPP 2.04?  If the version of GCC is so old that it doesn't
understand namespaces, then it won't even get past the "namespace std {"
line at the beginning.  If this is a consideration, then I need to
protect all the namespace std stuff from ancient versions of GCC.
Is it really necessary to do this?

> and won't it break if users use namespaces not to the letter
> of The Law?

No, there's no problem here.  The compiler only sees the offsetof
macro if stddef.h (or cstddef) is #included, and in this case size_t
will be defined in namespace std, so offsetof will work properly.
The user has no opportunity to get anything wrong.

> Anyway, what bad things happen if we leave offsetof's definition as it
> is now?  This survived unchanged for many years, and I don't think
> I've ever seen a problem report about it.

There wouldn't have been any problems with it before, because DJGPP
has always defined size_t in the global namespace.  But if size_t
is defined in namespace std (as it should be) then offsetof needs
to look for it there, otherwise it may not find it.

As an example, consider the following:

#include <cstddef>

struct somestruct {
    int a, b, c;
};

int main()
{
    offsetof(somestruct, b);
}

If offsetof is defined with size_t instead of std::size_t, then I
get the following when attempting to compile the above program:

C:\tmp>gpp offset.cc -c -fhonor-std
offset.cc: In function `int main()':
offset.cc:9: `size_t' undeclared (first use this function)
offset.cc:9: (Each undeclared identifier is reported only once
offset.cc:9: for each function it appears in.)

This wouldn't happen with the stock GCC cstddef, but I'm using
one that #defines __dj_via_cplusplus_header_ in order to get
greater standard compliance.  If offsetof is not defined correctly,
then no-one would have the choice of using a more compliant form
of cstddef.

Stephen

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019