AllanW@my-dejanews.com wrote:
....
> In article <3675B694.27D6A59A@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > Section 6.7.3, p7:
> >
> > "An object that is accessed through a restrict-qualified pointer has a
> > special association with that pointer. This association, defined in
> > 6.7.3.1 below, requires that all accesses to that object use, directly
> > or indirectly, the value of that particular pointer.104) The intended
> > use of the restrict qualifier (like the register storage class) is to
> > promote optimization, and deleting all instances of the qualifier from a
> > conforming program does not change its meaning (i.e., observable
> > behavior)."
> >
> > Not clear from the above summary, but explained in 6.7.3.1, is that the
> > restriction implied by 'restrict' applies only within a particular block
> > of code. The definition of that block is similar to the definition of
> > the scope of the correpsonding pointer; since you only want a summary I
> > won't go into more detail.
>
> If I understand this properly, it's like "lite references" (with 33%
> less calories). You can refer to the object through this pointer, but
> changing it's value or doing pointer arithmetic would be banned. Like
> the semantics (but not the syntax) of C++ references.

It's not about what you can do through that pointer; it's about what you
can't do through other means to the object it points at. The restricted
pointer can have its value changed; however, any object that it (or any
expression derived from it) happens to point to must not be modified by
any means except through that pointer (or expressions derived from it),
within the relevant block of code.

 int i,j;

 int * func(restrict *p)
 {
  *p=i;
  // Compiler can assume that p doesn't originally point at i or j
  p = &j;
  *p = i;
  return p;
 }

 void func2(void)
 {
  int *q = func(&i); // Therefore, this is illegal.
  func(q);  // and so is this.
 }

> One would put this in the function definition, but not the prototype,
> true?

One of the primary examples of a place where it's used, is in the
prototypes for the standard library:

void *memcpy(void * restrict s1,
 const void * restrict s2,
 size_t n);

void *memmove(void *s1, const void *s2, size_t n);

The difference in the declarations implies the restriction that s1 and
s2 should not point to overlapping objects for memcpy(), but they can
for memmove(). This restriction existed in C89 as well, but now it can
be implied using part of the language itself.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> AllanW@my-dejanews.com wrote:
> ....
> > In article <3675B694.27D6A59A@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > > Section 6.7.3, p7:
> > >
> > > "An object that is accessed through a restrict-qualified pointer has a
> > > special association with that pointer. This association, defined in
> > > 6.7.3.1 below, requires that all accesses to that object use, directly
> > > or indirectly, the value of that particular pointer.104) The intended
> > > use of the restrict qualifier (like the register storage class) is to
> > > promote optimization, and deleting all instances of the qualifier from a
> > > conforming program does not change its meaning (i.e., observable
> > > behavior)."
> > >
> > > Not clear from the above summary, but explained in 6.7.3.1, is that the
> > > restriction implied by 'restrict' applies only within a particular block
> > > of code. The definition of that block is similar to the definition of
> > > the scope of the correpsonding pointer; since you only want a summary I
> > > won't go into more detail.
> >
> > If I understand this properly, it's like "lite references" (with 33%
> > less calories). You can refer to the object through this pointer, but
> > changing it's value or doing pointer arithmetic would be banned. Like
> > the semantics (but not the syntax) of C++ references.
>
> It's not about what you can do through that pointer; it's about what you
> can't do through other means to the object it points at. The restricted
> pointer can have its value changed; however, any object that it (or any
> expression derived from it) happens to point to must not be modified by
> any means except through that pointer (or expressions derived from it),
> within the relevant block of code.
>
>         int i,j;
>
>         int * func(restrict *p)
>         {
>                 *p=i;
>                 // Compiler can assume that p doesn't originally point at i or j
>                 p = &j;
>                 *p = i;
>                 return p;
>         }
>
>         void func2(void)
>         {
>                 int *q = func(&i);      // Therefore, this is illegal.
>                 func(q);                // and so is this.
>         }
>
> > One would put this in the function definition, but not the prototype,
> > true?
>
> One of the primary examples of a place where it's used, is in the
> prototypes for the standard library:
>
> void *memcpy(void * restrict s1,
>         const void * restrict s2,
>         size_t n);
>
> void *memmove(void *s1, const void *s2, size_t n);
>
> The difference in the declarations implies the restriction that s1 and
> s2 should not point to overlapping objects for memcpy(), but they can
> for memmove(). This restriction existed in C89 as well, but now it can
> be implied using part of the language itself.

This would impose an interesting question for C++: Should overloading
on restrict be possible?

The pro would be that overloading on restrict would allow you
to write optimized functions to be called when the compiler
finds out it is safe to do so. Example:

void limited_copy(char* a, char const* b)
{
  char* c=new char[strlen(b)+1];
  strcpy(c,b);
  char* d=c;
  while(*a && *d)
    *a++=*d++;
  delete[] c;
}

void limited_copy(char* retrict a, char const* restrict b)
{
  while(*a && *a++=*b++);
}

void foo()
{
  char x[]="aaaa";
  char y[]="bbbbbbb";

  limited_copy(x,y); // calls restrict version
  limited_copy(x+2, x); // call non-restrict version
}

The downside is, of course, that the function called depends
on the analysis capability of the compiler (and therefore
not all compilers may give the same result for the same program).
However, we have a similar situation with copy elimination today.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7567rv$j0v$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:

> > AllanW@my-dejanews.com wrote:
> > > Would someone who knows please summarize the meaning of the restrict
> > > keyword? Either explain a likely usage, or at least describe the
> > > problem it solves.

> If I understand this properly, it's like "lite references" (with 33%
> less calories). You can refer to the object through this pointer, but
> changing it's value or doing pointer arithmetic would be banned. Like
> the semantics (but not the syntax) of C++ references.

No, it is a bit different.

Normally a compiler has to assume that two pointers (or references, or a
pointer and a reference) could refer to the same actual object, unless the
compiler can prove that this is not the case. Typically, if I write a
function like

   int f (int* p, int* q, int& r);

and the compiler doesnt know how this function is called, it must assume
that *p, *q and r might all be the same object. Therefore the compiler is
forced to produce (possibly slower) code that will work correctly whether
*p, *q and r are the same objects or not, instead of (possibly faster)
code that assumes they are different objects.

But if you write in C9X

   int f (int* restrict p, int* q);

you give a guarantee to the compiler that any object that is modified
through the pointer p or a pointer derived from p, like p+1 or p+n or ++p,
is not accessed in any other way. "Derived from p" means roughly
"calculated in a way that involved p itself". If you write code that
violates this guarantee, you will have undefined behavior.

In many cases, a clever compiler has complete knowledge about all pointers
derived from p. Therefore I could write

   int f (int* restrict p, int* q)
   {
      int* r = p + 4;            /* Derived from p */
      int* s = r - 2;            /* Derived from p */
      int* t = *q == 0 ? q : r;  /* Dont know if it is derived from p or not */

      *q = 1;                    /* *q is 1 */
      *p++ = 2;                  /* This cannot change *q */
      *p++ = 3;                  /* This cannot change *q */
      *p++ = 4;                  /* This cannot change *q */
      *r = 5;                    /* This cannot change *q */

      return *q;
   }

and the compiler could assume that at this point *q is equal to 1. Without
the "restrict" qualifier it would have to read *q and return whatever it
finds.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <753vfl$kvq$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
> Would someone who knows please summarize the meaning of the restrict
> keyword? Either explain a likely usage, or at least describe the
> problem it solves.

restrict is a qualifier for a pointer that tells the C compiler that
the pointer is the only access mechanism to get to what it points.  Its
main use is on arguments to a function -- with this, the compiler can
assume that there is no aliasing for the restrict objects, which can
allow significant speedups.

> Would it solve any C++ problems?

Not too many -- you could use it to signal your code that two objects
were different, but its primary usefulness is in arrays of simple
objects.

> Does it conflict with anything in C++ (other than the usual
> new-keyword problem: possible name collisions with user-selected
> identifiers such as variables)?

I can't think of any conflicts.
--
Ben Combee <bcombee@metrowerks.com> -- x86/Win32/NetWare CompilerWarrior


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> > In article <747hm2$bs4@panix.com>
> >            comeau@comeaucomputing.com "Greg Comeau" writes:
> > >We've had 'restrict' working for some time in Comeau C/C++,
> > >but have only enabled it in some custom ports.  Think it's worth
> > >making it generally available?
>
> In article <913586410snz@genesis.demon.co.uk>,
>   fred@genesis.demon.co.uk wrote:
> > I'd take care, there's still a good discussion going on about
> > how restrict should be defined.
>
> Would someone who knows please summarize the meaning of the restrict
> keyword? Either explain a likely usage, or at least describe the
> problem it solves.

Section 6.7.3, p7:

"An object that is accessed through a restrict-qualified pointer has a
special association with that pointer. This association, defined in
6.7.3.1 below, requires that all accesses to that object use, directly
or indirectly, the value of that particular pointer.104) The intended
use of the restrict qualifier (like the register storage class) is to
promote optimization, and deleting all instances of the qualifier from a
conforming program does not change its meaning (i.e., observable
behavior)."

Not clear from the above summary, but explained in 6.7.3.1, is that the
restriction implied by 'restrict' applies only within a particular block
of code. The definition of that block is similar to the definition of
the scope of the correpsonding pointer; since you only want a summary I
won't go into more detail.

Note that the restrict keyword can simply be ignored wherever it is
legal.

> Would it solve any C++ problems?

It would allow the same optimizations that it would allow a C9X
implementation. However, it might be less useful - the nature of C++
encourages greater use of pointers and references than in C code. That
would make it harder to find places where those optimizations are safe.

> Does it conflict with anything in C++ (other than the usual
> new-keyword problem: possible name collisions with user-selected
> identifiers such as variables)?

Within C++, restrict should treat references and pointers as equivalent.
I can't think of anything else.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn77bnq4.7o.bcombee@bcombee.metrowerks.com>,
  bcombee@metrowerks.com (Ben Combee) wrote:
>
> In article <753vfl$kvq$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
> > Would someone who knows please summarize the meaning of the restrict
> > keyword? Either explain a likely usage, or at least describe the
> > problem it solves.
>
> restrict is a qualifier for a pointer that tells the C compiler that
> the pointer is the only access mechanism to get to what it points.  Its
> main use is on arguments to a function -- with this, the compiler can
> assume that there is no aliasing for the restrict objects, which can
> allow significant speedups.
>
> > Would it solve any C++ problems?
>
> Not too many -- you could use it to signal your code that two objects
> were different, but its primary usefulness is in arrays of simple
> objects.
>
> > Does it conflict with anything in C++ (other than the usual
> > new-keyword problem: possible name collisions with user-selected
> > identifiers such as variables)?
>
> I can't think of any conflicts.

At the very least, it would be necessary to extend the mechanism to
references.

Note that, at least as I understand it, the proposal introduces yet
another possibility of undefined behavior.

--
James Kanze                                           GABI Software, S   rl
Conseils en informatique orient    objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> AllanW@my-dejanews.com wrote:
> > Would someone who knows please summarize the meaning of the restrict
> > keyword? Either explain a likely usage, or at least describe the
> > problem it solves.

In article <3675B694.27D6A59A@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Section 6.7.3, p7:
>
> "An object that is accessed through a restrict-qualified pointer has a
> special association with that pointer. This association, defined in
> 6.7.3.1 below, requires that all accesses to that object use, directly
> or indirectly, the value of that particular pointer.104) The intended
> use of the restrict qualifier (like the register storage class) is to
> promote optimization, and deleting all instances of the qualifier from a
> conforming program does not change its meaning (i.e., observable
> behavior)."
>
> Not clear from the above summary, but explained in 6.7.3.1, is that the
> restriction implied by 'restrict' applies only within a particular block
> of code. The definition of that block is similar to the definition of
> the scope of the correpsonding pointer; since you only want a summary I
> won't go into more detail.

If I understand this properly, it's like "lite references" (with 33%
less calories). You can refer to the object through this pointer, but
changing it's value or doing pointer arithmetic would be banned. Like
the semantics (but not the syntax) of C++ references.

One would put this in the function definition, but not the prototype,
true?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn77bnq4.7o.bcombee@bcombee.metrowerks.com>,
  bcombee@metrowerks.com (Ben Combee) wrote:
>
> In article <753vfl$kvq$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
> > Would someone who knows please summarize the meaning of the restrict
> > keyword? Either explain a likely usage, or at least describe the
> > problem it solves.
>
> restrict is a qualifier for a pointer that tells the C compiler that
> the pointer is the only access mechanism to get to what it points.  Its
> main use is on arguments to a function -- with this, the compiler can
> assume that there is no aliasing for the restrict objects, which can
> allow significant speedups.
>
> > Would it solve any C++ problems?
>
> Not too many -- you could use it to signal your code that two objects
> were different, but its primary usefulness is in arrays of simple
> objects.
>
> > Does it conflict with anything in C++ (other than the usual
> > new-keyword problem: possible name collisions with user-selected
> > identifiers such as variables)?
>
> I can't think of any conflicts.

If I understand you correctly, the main point is anti-aliasing.
So, one use of this would be in memcpy, to specify that the source
and destination pointers shouldn't refer to the same object.
Is that right?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7567rv$j0v$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>If I understand this properly, it's like "lite references" (with 33%
>less calories). You can refer to the object through this pointer, but
>changing it's value or doing pointer arithmetic would be banned. Like
>the semantics (but not the syntax) of C++ references.

Nothing like it at all.  The current version (the UK is in the process
of negotiating a version with more helpful constraints) of restrict
specifies that within the current scope the pointer in question is the
ONLY way that the object addressed can be accessed.  This is an
assertion by the programmer and if it is broken the result is undefined
behaviour.

The purpose of restrict is to support certain optimisations that are
desirable in numerically intense programs.

The version the UK favours can be loosely summarised as

either 1) as above
or 2) There is no mechanism in the current scope of changing the state
of the object pointed to.  In other words there might be several
variables providing access but none of them will be used to provide
write access (and that includes global pointers if you are silly enough
to have such things in your code)

No diagnostic is required but good code analysis tools should be able to
assist in detecting potential breeches.


>
>One would put this in the function definition, but not the prototype,
>true?

No,  I need it in the prototype if diagnostic tools are to have a
fighting chance of being helpful.

e.g.

void fn (char * restrict source, char * restrict dest);

int main(){
char buffer[100] = "Help";
fn(buffer, buffer);   // diagnosable error under current rules
// rest of code
}

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <747hm2$bs4@panix.com>
           comeau@comeaucomputing.com "Greg Comeau" writes:

>
>In article <jayz-3011981643270001@snd.intelligentparadigm.com>, Jay wrote:
>> C) Are there any C++ compilers that also implement the C9x "restrict" type
>> qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
>> are the restrict type qualifiers simply omitted for C++ implementations.
>
>We've had 'restrict' working for some time in Comeau C/C++,
>but have only enabled it in some custom ports.  Think it's worth
>making it generally available?

I'd take care, there's still a good discussion going on about
how restrict should be defined.

--
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> In article <747hm2$bs4@panix.com>
>            comeau@comeaucomputing.com "Greg Comeau" writes:
> >We've had 'restrict' working for some time in Comeau C/C++,
> >but have only enabled it in some custom ports.  Think it's worth
> >making it generally available?

In article <913586410snz@genesis.demon.co.uk>,
  fred@genesis.demon.co.uk wrote:
> I'd take care, there's still a good discussion going on about
> how restrict should be defined.

Would someone who knows please summarize the meaning of the restrict
keyword? Either explain a likely usage, or at least describe the
problem it solves.

Would it solve any C++ problems?

Does it conflict with anything in C++ (other than the usual
new-keyword problem: possible name collisions with user-selected
identifiers such as variables)?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <jayz-3011981643270001@snd.intelligentparadigm.com>, Jay wrote:
> C) Are there any C++ compilers that also implement the C9x "restrict" type
> qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
> are the restrict type qualifiers simply omitted for C++ implementations.

We've had 'restrict' working for some time in Comeau C/C++,
but have only enabled it in some custom ports.  Think it's worth
making it generally available?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
> In article <36634D40.F092489@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
....
>     #ifdef __CPLUSPLUS
>     #define __RESTRICT
>     #else
>     #define __RESTRICT restrict
>     #endif
>
> Now you can use __RESTRICT as if it were a keyword in C, and it
> will automatically be ignored in C++.

In practise, it's better (if you can) to have the compiler handle
__RESTRICT as a real keyword.  Then you get a performance increase
even if the compiler is in C++ or C89 mode.

[Assuming, of course, that the C++ and C89 standards don't allow those
pointers to be aliased.  I think that in practise any program that
does try to use aliased pointers in situations where C9x will prohibit
it, is probably not going to work even in current implementations.]

--
Geoff Keating <Geoff.Keating@anu.edu.au>


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <jayz-3011981643270001@snd.intelligentparadigm.com>, Jay wrote:
> These questions are asked to shed light on how portable it is to use
> <inttypes.h/cinttypes> from C++:
>
> A) What C++ implementations ship with, or will soon ship with
> <inttypes.h/cinttypes>.

CodeWarrior Pro4 has both <inttypes.h> and <cinttypes> header files.
Our <cinttypes> Our inttypes.h header includes <cinttypes>, which will
define the typedefs in namespace std, then it importes namespace std.
This behavior will be fixed in some future version to just import the
items declared in cinttypes into the default namespace.  So, we
followed your option of assuming new C9X headers as if they were in
the original C89 specification, and treating them accordingly.

> C) Are there any C++ compilers that also implement the C9x "restrict" type
> qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
> are the restrict type qualifiers simply omitted for C++ implementations.

We plan on having support for a restrict-like qualifier for both C and
C++ compilation, although for C++ mode, we might call it __restrict
unless the user explicitly requests C9X keyword support; this allows
us to compile Standard C++ programs that use "restrict" as an
identifier.

I do not yet know what version of CW will be the first to implement
full restrict semantics, but Pro4 does accept it as a qualifier in
you've used our undocumented "#pragma c9X on", and it accepts
"__restrict" in any context.  The Pro4 release of the compiler did not
use that information to generate better code, and our library headers
have not been updated to match C9X in including the restrict keyword.

--
Ben Combee <bcombee@metrowerks.com> -- x86/Win32/NetWare CompilerWarrior


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36634D40.F092489@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> Jay wrote:
> >
> > Has the C9x committee proposed rules for <inttypes.h> when used in a mixed
> > C/C++ implementation. Specifically:
> >
> > 1) For C++ should the include file be <cinttypes> instead of <inttypes.h>
> > (in the spirit of the other <cfilename> headers)?
> >
> > 2) For C++ should the type identifiers such as int8_t be in the std
> > namespace (e.g. std::int8_t, just like std::size_t)?
>
> The C9X committee has no authority to legislate on such things. The C++
> committee does, but the C++ standard is now fixed for the next several
> years, so it won't be happening any time soon.

This is true. But there are de-facto standards; in fact, the primary
mission of the next C++ standard will probably be to standardize
existing practice.

I would think that including these identifiers in the std namespace
would fit the spirit of the rest of the C++ standard. Furthermore,
I think that it would not need to be conditional; I don't believe
that implementing them there could break any legal C++ programs.

> > These questions are asked to shed light on how portable it is to use
> > <inttypes.h/cinttypes> from C++:
>
> It should be pretty trivial to write an <inttypes.h> that will work in
> both environments. However, since it's not part of the C++ standard, any
> use of it will be non-portable.

One solution to portability is to use
    #include "cinttypes"
instead of
    #include <cinttypes>
Then you can make your own header file (cinttypes). On platforms that
have a 'real' header available, you simply define cinttypes to be
    #include <cinttypes>
which then includes the production version. On platforms that do not
have a 'real' cinttypes header available, you simply implement it
yourself -- defining whatever symbols are needed by your program.
Be sure to be compatible with the 'real' version, of course.

> > C) Are there any C++ compilers that also implement the C9x "restrict" type
> > qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
> > are the restrict type qualifiers simply omitted for C++ implementations.
>
> The 'restrict' qualifiers would have to be omitted, which is one reason
> why an <inttypes.h> not written with C++ in mind will not work in a C++
> environment.

    #ifdef __CPLUSPLUS
    #define __RESTRICT
    #else
    #define __RESTRICT restrict
    #endif

Now you can use __RESTRICT as if it were a keyword in C, and it
will automatically be ignored in C++.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <36634D40.F092489@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
...
> I would think that including these identifiers in the std namespace
> would fit the spirit of the rest of the C++ standard. Furthermore,
> I think that it would not need to be conditional; I don't believe
> that implementing them there could break any legal C++ programs.

Strictly conforming C++ programs can't #include <inttypes.h>, so they
won't be broken.

The macros defined in inttypes.h all lie in the name space reserved for
users by C++. Therefore, a legal C++ program can use those symbols,
possibly in ways incompatible with the inttypes.h definition. Thus, any
implementation that wishes to not break legal C++ programs had better
make sure that none of the standard header files #include's
<inttypes.h>.

The typedefs in inttypes.h also violate the user's name space for C++,
unless they're moved up into namespace std.

...
> One solution to portability is to use
>     #include "cinttypes"
> instead of
>     #include <cinttypes>
> Then you can make your own header file (cinttypes). On platforms that
> have a 'real' header available, you simply define cinttypes to be
>     #include <cinttypes>
> which then includes the production version. On platforms that do not
> have a 'real' cinttypes header available, you simply implement it
> yourself -- defining whatever symbols are needed by your program.
> Be sure to be compatible with the 'real' version, of course.

Note: what you've just defined is non-portable code. You have to change
the header file depending upon where you port it to. Even the main file
isn't completely portable, because "cinttypes" needn't be a valid file
name on any given system.

...
> > The 'restrict' qualifiers would have to be omitted, which is one reason
> > why an <inttypes.h> not written with C++ in mind will not work in a C++
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > environment.
>
>     #ifdef __CPLUSPLUS
>     #define __RESTRICT
>     #else
>     #define __RESTRICT restrict
>     #endif
>
> Now you can use __RESTRICT as if it were a keyword in C, and it
> will automatically be ignored in C++.

To be useful, __RESTRICT must used inside the inttypes.h file. That
makes it a file "written with C++ in mind".

Let me summarize: any support of C9X inttypes.h by a C++ implementation
will be an extension. Any program that uses extensions is non-portable,
by definition.
That doesn't mean it's not a good idea. It does mean that you may have
to pay for this good idea with a lot of work whenever you try to port it
to a new system.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Has the C9x committee proposed rules for <inttypes.h> when used in a mixed
C/C++ implementation. Specifically:

1) For C++ should the include file be <cinttypes> instead of <inttypes.h>
(in the spirit of the other <cfilename> headers)?

2) For C++ should the type identifiers such as int8_t be in the std
namespace (e.g. std::int8_t, just like std::size_t)?


These questions are asked to shed light on how portable it is to use
<inttypes.h/cinttypes> from C++:

A) What C++ implementations ship with, or will soon ship with
<inttypes.h/cinttypes>.

B) Are there any C++ implementations shipping with <inttypes.h> that do
*not* have <cinttypes> and do not put the identifiers in the std
namespace?

C) Are there any C++ compilers that also implement the C9x "restrict" type
qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
are the restrict type qualifiers simply omitted for C++ implementations.

Thanks,
Jay

-----------------------------------------------------
(Remove the .no.spam from my e-mail address to reply)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jay wrote:
>
> Has the C9x committee proposed rules for <inttypes.h> when used in a mixed
> C/C++ implementation. Specifically:
>
> 1) For C++ should the include file be <cinttypes> instead of <inttypes.h>
> (in the spirit of the other <cfilename> headers)?
>
> 2) For C++ should the type identifiers such as int8_t be in the std
> namespace (e.g. std::int8_t, just like std::size_t)?

The C9X committee has no authority to legislate on such things. The C++
committee does, but the C++ standard is now fixed for the next several
years, so it won't be happening any time soon.

> These questions are asked to shed light on how portable it is to use
> <inttypes.h/cinttypes> from C++:

It should be pretty trivial to write an <inttypes.h> that will work in
both environments. However, since it's not part of the C++ standard, any
use of it will be non-portable.

> C) Are there any C++ compilers that also implement the C9x "restrict" type
> qualifier as used in <inttypes.h> conversion functions (WG14/7.8.2), or
> are the restrict type qualifiers simply omitted for C++ implementations.

The 'restrict' qualifiers would have to be omitted, which is one reason
why an <inttypes.h> not written with C++ in mind will not work in a C++
environment.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]