_Complex constant

[Laurent Deniau]

Is there any way to create a constant of type double _Complex without
including <complex.h>?

Why _Complex_I is a macro an not an implementation-defined constant?

Thanks.

a+, ld.

 

[Guest]

Is there any way to create a constant of type double _Complex without
including <complex.h>?

From the C99 rationale:

"An I suffix to designate imaginary constants is not required, as
multiplication by I provides a sufficiently convenient and more
generally useful notation for imaginary terms."

So unless you count implementation-specific extensions, or complex
constants with an imaginary part of zero, then no, probably not.

Why _Complex_I is a macro an not an implementation-defined constant?

Constants can't be used in constant expressions.

#include <complex.h>
const double complex i = I; /* or equivalently, _Complex_I */
double complex v = 1 + 2 * i; /* error: initializer element is not
constant */

 

[Laurent Deniau]

"An I suffix to designate imaginary constants is not required, as
multiplication by I provides a sufficiently convenient and more
generally useful notation for imaginary terms."

So unless you count implementation-specific extensions, or complex
constants with an imaginary part of zero, then no, probably not.




Constants can't be used in constant expressions.

#include <complex.h>
const double complex i = I; /* or equivalently, _Complex_I */
double complex v = 1 + 2 * i; /* error: initializer element is not
constant */

Right. By specifying 'implementation-defined constant' I was thinking to
a special constant like null pointer constant. Something that would
expand to a compiler constant like __builtin_Complex_I for example.

My problem is that even with complex.h included, gcc (4.1.2) gives a
warning in c99 pedantic mode for the code:

const double complex i = _Complex_I;

warning: imaginary constants are a GCC extension

in complex.h we find (as you mention it):

#define _Complex_I (__extension__ 1.0iF)

It seems that this warning is not appropriate, but gcc cannot know with
this definition. Any clue?

Thanks.

a+, ld.

 

[Guest]

Right. By specifying 'implementation-defined constant' I was thinking to
a special constant like null pointer constant. Something that would
expand to a compiler constant like __builtin_Complex_I for example.

Well, that's basically what _Complex_I is required to do already. (Not
explicitly by the standard, but I can't imagine how an implementation
would support it otherwise.) As you show below, GCC uses a compiler
constant itself.

My problem is that even with complex.h included, gcc (4.1.2) gives a
warning in c99 pedantic mode for the code:

const double complex i = _Complex_I;

warning: imaginary constants are a GCC extension

in complex.h we find (as you mention it):

#define _Complex_I (__extension__ 1.0iF)

It seems that this warning is not appropriate, but gcc cannot know with
this definition. Any clue?

That's a long-standing bug in GCC:
http://gcc.gnu.org/PR7263

There's not much else to do but either ignore the warning, or use a
different compiler.

 

[Keith Thompson]

Laurent Deniau wrote: [...]

Why _Complex_I is a macro an not an implementation-defined constant?

Constants can't be used in constant expressions.

#include <complex.h>
const double complex i = I; /* or equivalently, _Complex_I */
double complex v = 1 + 2 * i; /* error: initializer element is not
constant */

Constants can (e.g., 42 and 1.23 are constants); const-qualified
objects cannot.

 

[Guest]

Laurent Deniau wrote: [...]

Why _Complex_I is a macro an not an implementation-defined constant?

Constants can't be used in constant expressions.

#include <complex.h>
const double complex i = I; /* or equivalently, _Complex_I */
double complex v = 1 + 2 * i; /* error: initializer element is not
constant */

Constants can (e.g., 42 and 1.23 are constants); const-qualified
objects cannot.

Right, sorry, I (incorrectly) thought a different meaning of "constant"
was used.

 

[Keith Thompson]

Laurent Deniau wrote: [...]
Why _Complex_I is a macro an not an implementation-defined constant?

Constants can't be used in constant expressions.

#include <complex.h>
const double complex i = I; /* or equivalently, _Complex_I */
double complex v = 1 + 2 * i; /* error: initializer element is not
constant */

Constants can (e.g., 42 and 1.23 are constants); const-qualified
objects cannot.

Right, sorry, I (incorrectly) thought a different meaning of "constant"
was used.

That's a very easy mistake to make, since "const" and "constant" mean
two very different things in C.

 

[Laurent Deniau]

That's a long-standing bug in GCC:
http://gcc.gnu.org/PR7263

There's not much else to do but either ignore the warning, or use a
different compiler.

It brings me to another question. I do a lot of calculation with complex
numbers (making the above warning painful unless I declare my own global
const-qualified _Complex_I) and up to now I was using my own complex
number lib (or gsl lib sometimes) mainly because I wanted the principal
branch of some functions to be compliant with matlab results. I am
planning to move my code to C99 _Complex, but is it widely supported and
conform to the standard by actual compilers? Do you know where I could
find any paper, link or document about comparison of compilers
compiliance to C99, including complex number? Or do think that it would
be wiser to stay with lib gsl for example?

Thanks,

a+, ld.

 

[Guest]

It brings me to another question. I do a lot of calculation with complex
numbers (making the above warning painful unless I declare my own global
const-qualified _Complex_I) and up to now I was using my own complex
number lib (or gsl lib sometimes) mainly because I wanted the principal
branch of some functions to be compliant with matlab results. I am
planning to move my code to C99 _Complex, but is it widely supported and
conform to the standard by actual compilers?

If you wish for your users to be able to compile your code (it sounds
as if you do), I'd first like to point out they don't need to compile
it with GCC's -pedantic option, so this is hardly a problem for them.
That said, ignoring GCC, Intel's and Sun's compilers claim to support
it, and for Windows platforms, lcc-win32 and Pelles C are likely to
support it (although I haven't tested this).

Do you know where I could
find any paper, link or document about comparison of compilers
compiliance to C99, including complex number?

No idea, sorry.

Or do think that it would
be wiser to stay with lib gsl for example?

That depends on your needs. I don't know what sort of code you've
written, but another possibility is to support both, and use only one
(with C99 support to be detected by your build process). This means
your code can be portable to C90 implementations, yet you don't
introduce needless incompatibilities between your own lib and C99's
standard library.

 

[CBFalconer]

.... snip ...

If you wish for your users to be able to compile your code (it sounds
as if you do), I'd first like to point out they don't need to compile
it with GCC's -pedantic option, so this is hardly a problem for them.
That said, ignoring GCC, Intel's and Sun's compilers claim to support
it, and for Windows platforms, lcc-win32 and Pelles C are likely to
support it (although I haven't tested this).

On the contrary, without -ansi -pedantic gcc isn't a C compiler.

 

[Guest]

On the contrary, without -ansi -pedantic gcc isn't a C compiler.

I'll pretend you said -std=c99 -pedantic, and that GCC with those
options conforms to C99. But the users don't need a conforming
compiler. They need a compiler that correctly translates conforming
programs. Without -pedantic, GCC accepts some invalid programs, but it
doesn't reject valid programs.

 

[Kenny McCormack]

On the contrary, without -ansi -pedantic gcc isn't a C compiler.

It is hard to imagine a more dumb, stupid, and thoroughly incorrect
statement.

 

[Laurent Deniau]

That depends on your needs. I don't know what sort of code you've
written, but another possibility is to support both, and use only one
(with C99 support to be detected by your build process). This means
your code can be portable to C90 implementations, yet you don't
introduce needless incompatibilities between your own lib and C99's
standard library.

My code requires C99 anyway (a moderately compliant compiler) for many
reasons (variadic macros, compound litteral and long long are the most
important features I need). But it doesn't means that I should blindly
trust the compiler implementation, even if it claims to be C99 (at least
by the build process detection which cannot go on the compiler's web
site and the list of incomplete features ;-) . Since _Complex must be
have the same representation and alignment as double[2], some
alternative may exist that would solve part of the portability problem.

a+, ld.

 

[CBFalconer]

I'll pretend you said -std=c99 -pedantic, and that GCC with those
options conforms to C99. But the users don't need a conforming
compiler. They need a compiler that correctly translates conforming
programs. Without -pedantic, GCC accepts some invalid programs, but it
doesn't reject valid programs.

gcc with -c99 is neither fish nor fowl. It does not fully comply
with C99, especially when using a C90 library. With -ansi
-pedantic the user is at least warned that some constructs are not
portable and need to be isolated in a system dependant module.
Examples are the z printf modifier, variable arrays, and _Bool.
Also the use of // comments.

 

[Guest]

gcc with -c99 is neither fish nor fowl. It does not fully comply
with C99, especially when using a C90 library. With -ansi
-pedantic the user is at least warned that some constructs are not
portable and need to be isolated in a system dependant module.
Examples are the z printf modifier, variable arrays, and _Bool.
Also the use of // comments.

Please explain to me the point of suggesting invoking gcc in
C90-conforming mode in a thread asking about _Complex.

 

[Richard Heathfield]

Harald van D?k said:

Please explain to me the point of suggesting invoking gcc in
C90-conforming mode in a thread asking about _Complex.

Please explain to me the point of using gcc when clearly what is actually
needed, for _Complex to be considered anything other than an off-topic
extension, is a C99-conforming compiler (which gcc very definitely isn't).

 

[Guest]

Harald van D?k said:


Please explain to me the point of using gcc when clearly what is actually
needed, for _Complex to be considered anything other than an off-topic
extension, is a C99-conforming compiler (which gcc very definitely isn't).

Yes, gcc is not a conforming compiler. However, code written in the
common subset of C99 and what gcc accepts is still on topic here.

 

[Richard Heathfield]

Harald van D?k said:

Yes, gcc is not a conforming compiler. However, code written in the
common subset of C99 and what gcc accepts is still on topic here.

But _Complex is not within that common subset, because gcc does *not* claim
to provide complex or imaginary support in line with the requirements of
C99. See http://gcc.gnu.org/c99status.html if need be.

 

[Guest]

Harald van D?k said:

But _Complex is not within that common subset, because gcc does *not* claim
to provide complex or imaginary support in line with the requirements of
C99. See http://gcc.gnu.org/c99status.html if need be.

That's a fair point, but what it proves is that there are *some*
(actually, very few) uses of _Complex that are outside of that common
subset, not that all uses of it are.

 

[Richard Heathfield]

Harald van D?k said:

That's a fair point, but what it proves is that there are *some*
(actually, very few) uses of _Complex that are outside of that common
subset, not that all uses of it are.

I think we've said all the right mantras now.