kanze@gabi-soft.de (James Kanze) wrote
> If it solved a real problem, we could consider it.  But how many cases
> do you know of where the current rules have actually caused a problem?

Good point. With apologies to the Mr. Mang -- it's never been a problem
in my code, and if it was I'd use one of the many simple workarounds.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) wrote
> There are some subtle issues involved, but I really don't think that any
> of this could be changed now, even supposing someone came up with a
> better solution (because although everyone gripes about the current
> state, I've yet to seen any concrete alternative proposals that would
> work).

One obvious proposal would be to do the same thing that APL does. APL
has two different characters for minus; one is used only in negative
numeric literals, while the other is used for both unary negation and
binary subtraction. As a practical matter, it would rarely make any
difference which one was used in C++, except for the specific case
mentioned in this thread (minimum signed values). One obvious drawback
of this proposal is deciding which character to use. APL normally uses
a special font which has extra mathematical operators, so they can use
a "raised minus sign" for negative literals. But when APL is used on
standard ASCII or EBCDIC platforms, these operators turn into something
vaguely similar to trigraphs. It's hard to imagine C++ adopting a new
trigraph (without a printable translation) just for the sake of this
minor issue.

Instead, consider Thomas Mang's proposal (Oct 28 2002) would work. Thomas
is the OP of this thread! Okay, he stated his idea as several questions,
rather than an overt proposal. But the gist of his idea is: "Parse a
leading minus sign as part of the syntax of a numeric literal."

You're right -- there are subtle issues to resolve. For instance, we
wouldn't want to change the meaning of
    a=b-1;
to become a syntax error (b followed by a negative integer with no
operator between). But these are issues that almost every high-level
language has resolved since the Fortran/COBOL days, and I suspect it
wouldn't be that hard for the C++ language experts to resolve them too.
Perhaps something as simple as, "whenever a minus sign followed by
digits can be parsed as a negative literal without causing a syntax
errors, that is how it must be parsed." Or perhaps something more
explicit...

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0211061306.56431f10@posting.google.com>...

> kanze@gabi-soft.de (James Kanze) wrote
> > There are some subtle issues involved, but I really don't think that
> > any of this could be changed now, even supposing someone came up
> > with a better solution (because although everyone gripes about the
> > current state, I've yet to seen any concrete alternative proposals
> > that would work).

> One obvious proposal would be to do the same thing that APL does. APL
> has two different characters for minus; one is used only in negative
> numeric literals, while the other is used for both unary negation and
> binary subtraction.

Having had to develop C and C++ on keyboards without a {, }, etc., the
last thing I want is yet another character:-).

> As a practical matter, it would rarely make any difference which one
> was used in C++, except for the specific case mentioned in this thread
> (minimum signed values). One obvious drawback of this proposal is
> deciding which character to use. APL normally uses a special font
> which has extra mathematical operators, so they can use a "raised
> minus sign" for negative literals. But when APL is used on standard
> ASCII or EBCDIC platforms, these operators turn into something vaguely
> similar to trigraphs. It's hard to imagine C++ adopting a new trigraph
> (without a printable translation) just for the sake of this minor
> issue.

I'll bet we could make do with only a digraph:-).

> Instead, consider Thomas Mang's proposal (Oct 28 2002) would work.
> Thomas is the OP of this thread! Okay, he stated his idea as several
> questions, rather than an overt proposal. But the gist of his idea is:
> "Parse a leading minus sign as part of the syntax of a numeric
> literal."

The problem is that this would either break an incredible lot of
existing code, or introduce context into lexing.  Lexing isn't entirely
free of context today -- there's the business of h-char-sequence and
q-char-sequence -- and I've written scanners that can handle the case
generally, but it's not really something we want to encourage.

> You're right -- there are subtle issues to resolve. For instance, we
> wouldn't want to change the meaning of
>     a=b-1;
> to become a syntax error (b followed by a negative integer with no
> operator between).

Exactly. Under this suggestion, b-1 is two tokens: <symbol> and
<integral-constant>.  It's possible to invent a number of special rules
to handle the case, but is it worth it.  (Or do you think that C++ is
has too few special rules at present?)

> But these are issues that almost every high-level language has
> resolved since the Fortran/COBOL days, and I suspect it wouldn't be
> that hard for the C++ language experts to resolve them too.

Actually, I don't think that many languages have had to resolve them
since the Fortran/Cobol days. Fortran is wicked in this sense :

    do10i=1,10 -> 'do' '10' 'i' '=' '1' ',' '10'
    do10i=1.10 -> 'do10i' '=' '1.10'

(Note that the decision as to how to break up the start of the line
depends on a character than can be arbitrarily further down in the
line.)

I think Cobol has one or two cases of something similar. But language
designers soon realized that this was a mistake, and I can't think of
anything on this level in any language since then.

> Perhaps something as simple as, "whenever a minus sign followed by
> digits can be parsed as a negative literal without causing a syntax
> errors, that is how it must be parsed." Or perhaps something more
> explicit...

The problem is that tokenization should be finished before we start
parsing.  It's bad enough having to backtrack in the parser (in cases of
ambiguity between an expression and a declaration), and we certainly
don't want to have to re-tokenize the line(s) as well.

About the best I can think of right now is something along the lines of
"if a '-' is immediately followed by a digit (no white space) AND the
parse context does not allow returning a subtraction operator, then the
'-' is treated as part of the following numerical constant."  But I'd be
very surprised if there aren't cases that I've missed with this, where
the change would break code.  And even this will raise screams
(justified, IMHO) among compiler implementers, since it introduces a
very undesirable coupling between the scanner and the parser.

If it solved a real problem, we could consider it.  But how many cases
do you know of where the current rules have actually caused a problem?

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 29 Oct 2002 01:13:48 +0000 (UTC), agriff@tin.it (Andrea
Griffini) wrote:

>Actually I can think to an annoying case... suppose we've
>16-bit integers in the common two complement representation...
>Is the text "-32768" legal ? Is the type "int" ?
>The problem is that 32768 isn't in the range for a such
>a 16 bit integer, but -32768 is.

Yes. That's why you usually find things like

  # define INT_MIN  (-32767 - 1)
or
  # define INT_MIN  (-INT_MAX-1)

in your <limits.h>. In your example, the constant -32768 would have
type long int if 32768 (with no sign) could fit in a long int.


Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Mang" <a9804814@unet.univie.ac.at> wrote in message
news:3DC03853.99513493@unet.univie.ac.at...

> In your example, the compiler could use a long. But what about machines where
> sizeof(int) == sizeof(long) ?
> How is it than possible (using literal constants, not std::numeric_limits or
> macros) to express the smallest possible integer value as a literal constant
> ???

-32767 - 1

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) wrote in message news:<3DC03853.99513493@unet.univie.ac.at>...
> Andrea Griffini schrieb:
>
> > On Mon, 28 Oct 2002 18:12:02 +0000 (UTC), a9804814@unet.univie.ac.at
> > (Thomas Mang) wrote:
> >
> > >Now this is a paradoxon:
> > >
> > >a) Either the standard forbids using a sign - char. But why is the
> > >type
> > >of the constant then supposed to be able to hold negative values ?
> >
> > The text "-12" can be seen as a constant *expression* that
> > evaluates to a negative integer. Having negatives in constants
> > doesn't necessarely imply there's a need for negative literals.
>
> Clearly, here it doesn't matter. It's only of theoretical purpose wether this
> is unary operator - applied to "12", or "-12" directly.
>
> >
> >
> > >b) The standard allows negative decimal integers. Why are they then
> > >missing in the syntax ?
> >
> > May be because you can build them with constant expressions.
> >
> > Actually I can think to an annoying case... suppose we've
> > 16-bit integers in the common two complement representation...
> > Is the text "-32768" legal ? Is the type "int" ?
> > The problem is that 32768 isn't in the range for a such
> > a 16 bit integer, but -32768 is.
>
> This hits exactly the point.
>
> The case above (operator negate applied to positive constant or negative
> constant) would not be an issue if negative and positive values would be
> symmetrical (oops, there is the zero, and symmetry is gone), or if the
> absolute value of the smallest representable int-value would be less than the
> largest representable one. Unfortunately, this doesn't hold either.
>
> In your example, the compiler could use a long. But what about machines where
> sizeof(int) == sizeof(long) ?
> How is it than possible (using literal constants, not std::numeric_limits or
> macros) to express the smallest possible integer value as a literal constant
> ???

    MIN_INT                   // with suitable #includes
    numeric_limits<int>min(); // With suitable #includes
Or, if int is known to be 16 bits:
    int(0x8000)
    ((-1)-32767)
    ((-16384)-16384)
    (128*-256)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" schrieb:

> > In your example, the compiler could use a long. But what about machines where
> > sizeof(int) == sizeof(long) ?
> > How is it than possible (using literal constants, not std::numeric_limits or
> > macros) to express the smallest possible integer value as a literal constant
> > ???
>
> -32767 - 1

Exactly. Or (16bit-integer) -32700 - 68, or  -32 * 1000 - 66 - 2...


Now was this the intention of the standard ?

If yes, then everything is fine as it is today (well, almost. We just have to take
a look at a hell lots of code, because there is code out there which simply used
"-32768").

If not (my guess), why not simply prefix a sign-char to numeric literal constants?


best regards,

Thomas

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Mang" <a9804814@unet.univie.ac.at> wrote in message
news:3DC2D619.EC3D208@unet.univie.ac.at...

> > > How is it than possible (using literal constants, not std::numeric_limits or
> > > macros) to express the smallest possible integer value as a literal constant
> > > ???
> >
> > -32767 - 1
>
> Exactly. Or (16bit-integer) -32700 - 68, or  -32 * 1000 - 66 - 2...
>
> Now was this the intention of the standard ?

It was the intention that -32768 would be a different type than -32767 on
a platform where int is 16 bits, yes.

> If yes, then everything is fine as it is today (well, almost. We just have to take
> a look at a hell lots of code, because there is code out there which simply used
> "-32768").

In most contexts, that really doesn't matter. If you're passing an argument
to a function that has no prototype, you'll pass the wrong sized int. Even
that only matters on a big-endian machine. So chances are, only the Standard
C library has to fret about how to get various macros right.

> If not (my guess), why not simply prefix a sign-char to numeric literal constants?

Because the language works well enough without this addition? And
do you really want -32768 to have a different type than - 32768?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger <pjp@dinkumware.com> wrote :
....
> It was the intention that -32768 would be a different type than -32767 on
> a platform where int is 16 bits, yes.
>
> > If yes, then everything is fine as it is today (well, almost. We just have
to take
> > a look at a hell lots of code, because there is code out there which simply
used
> > "-32768").
>
> In most contexts, that really doesn't matter. If you're passing an argument
> to a function that has no prototype, you'll pass the wrong sized int. Even
> that only matters on a big-endian machine. So chances are, only the Standard
> C library has to fret about how to get various macros right.
>
In C++ there are no unprototyped functions, although varargs
are like C unprototyped.  And when that does happen, and in
many cases of unprototyped functions in C (not those which
use max-width registers, or slots), I expect it to affect not only
the one wrong size argument if big-endian but all following ones.

--
- David.Thompson 1 now at worldnet.att.net


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:

The moderators are unable to edit posts in any way.  We can only
accept them as is or reject them.  We cannot delete portions.


===================================== END OF MODERATOR'S COMMENT
[ To mods:

I have posted this message about 4 hours ago, but apparently didn't
find it's way to your server. (Didn't get confirmation of
receivement). If you have received the first message though, don't
post this one.
Also, please remove this note before posting

]




Greetings to all,


In section 2.13.1, the standard describes integer literal constants.

However, nothing seems to describe a sign-char to specify a
positive/negative value.

In the paragraphs following the syntax, it's described that a decimal
integer literal constant (without suffix)  - type will be the first of
int, long int.

Now this is a paradoxon:

a) Either the standard forbids using a sign - char. But why is the
type
of the constant then supposed to be able to hold negative values ?
b) The standard allows negative decimal integers. Why are they then
missing in the syntax ?

Maybe I  am missing here something critical; The current specification
as it does, IMHO, not seem to make much sense.

Note, the same issue applies to floating-point specification too.


best regards,

Thomas

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Mang" <a9804814@unet.univie.ac.at> wrote...
> In section 2.13.1, the standard describes integer literal constants.
>
> However, nothing seems to describe a sign-char to specify a
> positive/negative value.
>
> In the paragraphs following the syntax, it's described that a decimal
> integer literal constant (without suffix)  - type will be the first of
> int, long int.
>
> Now this is a paradoxon:
>
> a) Either the standard forbids using a sign - char. But why is the
> type
> of the constant then supposed to be able to hold negative values ?
> b) The standard allows negative decimal integers. Why are they then
> missing in the syntax ?
>
> Maybe I  am missing here something critical; The current specification
> as it does, IMHO, not seem to make much sense.
>
> Note, the same issue applies to floating-point specification too.


Signs are not part of the literal specification.  They are unary
operators.  What you have when you write -123 is an expression,
which may be evaluated at compile-time.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 28 Oct 2002 18:12:02 +0000 (UTC), a9804814@unet.univie.ac.at
(Thomas Mang) wrote:

>Now this is a paradoxon:
>
>a) Either the standard forbids using a sign - char. But why is the
>type
>of the constant then supposed to be able to hold negative values ?

The text "-12" can be seen as a constant *expression* that
evaluates to a negative integer. Having negatives in constants
doesn't necessarely imply there's a need for negative literals.

>b) The standard allows negative decimal integers. Why are they then
>missing in the syntax ?

May be because you can build them with constant expressions.

Actually I can think to an annoying case... suppose we've
16-bit integers in the common two complement representation...
Is the text "-32768" legal ? Is the type "int" ?
The problem is that 32768 isn't in the range for a such
a 16 bit integer, but -32768 is.

Andrea

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

agriff@tin.it (Andrea Griffini) wrote
> Actually I can think to an annoying case... suppose we've
> 16-bit integers in the common two complement representation...
> Is the text "-32768" legal ? Is the type "int" ?
> The problem is that 32768 isn't in the range for a such
> a 16 bit integer, but -32768 is.

In practice, if -32768 is a long, it will usuall convert into an int
depending on how it's used. One of the few times it will NOT convert
is when you use it as an argument to overloaded functions:

    void foo(int)  { std::cout << 'I' << std::endl; }
    void foo(long) { std::cout << 'L' << std::endl; }
    int main() {
        foo(-32768); // Prints I, not L
    }

If you're worried about this effect, there are lots of ways to generate
the lowest possible signed int (instead of long). Again, assuming int is
16-bits and long is 32-bits:
    MIN_INT      // with suitable #includes
    int(-32768)
    int(0x8000)
    ((-1)-32767)
    (-16384-16384)
...etc.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) writes:

> Maybe I  am missing here something critical; The current specification
> as it does, IMHO, not seem to make much sense.

The negation is a unary operator, see 5.3. So

 -10

is two tokens: the unary operator, and the number 10. It is still a
constant expression, see 5.19.

Regards,
Martin

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrea Griffini schrieb:

> On Mon, 28 Oct 2002 18:12:02 +0000 (UTC), a9804814@unet.univie.ac.at
> (Thomas Mang) wrote:
>
> >Now this is a paradoxon:
> >
> >a) Either the standard forbids using a sign - char. But why is the
> >type
> >of the constant then supposed to be able to hold negative values ?
>
> The text "-12" can be seen as a constant *expression* that
> evaluates to a negative integer. Having negatives in constants
> doesn't necessarely imply there's a need for negative literals.

Clearly, here it doesn't matter. It's only of theoretical purpose wether this
is unary operator - applied to "12", or "-12" directly.

>
>
> >b) The standard allows negative decimal integers. Why are they then
> >missing in the syntax ?
>
> May be because you can build them with constant expressions.
>
> Actually I can think to an annoying case... suppose we've
> 16-bit integers in the common two complement representation...
> Is the text "-32768" legal ? Is the type "int" ?
> The problem is that 32768 isn't in the range for a such
> a 16 bit integer, but -32768 is.

This hits exactly the point.

The case above (operator negate applied to positive constant or negative
constant) would not be an issue if negative and positive values would be
symmetrical (oops, there is the zero, and symmetry is gone), or if the
absolute value of the smallest representable int-value would be less than the
largest representable one. Unfortunately, this doesn't hold either.

In your example, the compiler could use a long. But what about machines where
sizeof(int) == sizeof(long) ?
How is it than possible (using literal constants, not std::numeric_limits or
macros) to express the smallest possible integer value as a literal constant
???


best regards,

Thomas

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrea Griffini wrote:
[...]
> Actually I can think to an annoying case... suppose we've
> 16-bit integers in the common two complement representation...
> Is the text "-32768" legal ? Is the type "int" ?
> The problem is that 32768 isn't in the range for a such
> a 16 bit integer, but -32768 is.

As long has to have at least 32 bits -32768 is a legal constant
expression of type long int. See the first part of 2.13.1-2:
"The type of an integer literal depends on its form, value, and suffix.
If it is decimal and has no suffix, it has the first of these types in
which its value can be represented: int, long int; [...]"

Note that the same paragraph goes on to say: "[...]if the value cannot
be represented as a long int, the behavior is undefined.[...]". So on
the same system -2147483648 invokes undefined behaviour.

Cheers,
Nicola Musatti

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> > If yes, then everything is fine as it is today (well, almost. We just have to take
> > a look at a hell lots of code, because there is code out there which simply used
> > "-32768").
>
> In most contexts, that really doesn't matter. If you're passing an argument
> to a function that has no prototype, you'll pass the wrong sized int. Even
> that only matters on a big-endian machine. So chances are, only the Standard
> C library has to fret about how to get various macros right.
>
> > If not (my guess), why not simply prefix a sign-char to numeric literal constants?
>
> Because the language works well enough without this addition? And
> do you really want -32768 to have a different type than - 32768?

You are right, here only the type may differ.

Actually, I wanted to illustrate the situation where a overflow occurs, because 'long'
isn't able to hold the value:

e.g. 32 bit-machine, sizeof(int) == sizeof(long):

e.g.; #define MININT -2147483648;
and pang, we have a problem.

OTOH, if a leading sign-char would be parsed to be part of the literal constant,
everything would be fine.


best regards,

Thomas

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) wrote in message
news:<3DC03853.99513493@unet.univie.ac.at>...
> Andrea Griffini schrieb:

> > On Mon, 28 Oct 2002 18:12:02 +0000 (UTC), a9804814@unet.univie.ac.at
> > (Thomas Mang) wrote:

> > >Now this is a paradoxon:

> > >a) Either the standard forbids using a sign - char. But why is the
> > >type of the constant then supposed to be able to hold negative
> > >values ?

> > The text "-12" can be seen as a constant *expression* that evaluates
> > to a negative integer. Having negatives in constants doesn't
> > necessarely imply there's a need for negative literals.

> Clearly, here it doesn't matter. It's only of theoretical purpose
> wether this is unary operator - applied to "12", or "-12" directly.

> > >b) The standard allows negative decimal integers. Why are they then
> > >missing in the syntax ?

> > May be because you can build them with constant expressions.

> > Actually I can think to an annoying case... suppose we've 16-bit
> > integers in the common two complement representation...  Is the text
> > "-32768" legal ? Is the type "int" ?  The problem is that 32768
> > isn't in the range for a such a 16 bit integer, but -32768 is.

> This hits exactly the point.

> The case above (operator negate applied to positive constant or
> negative constant) would not be an issue if negative and positive
> values would be symmetrical (oops, there is the zero, and symmetry is
> gone), or if the absolute value of the smallest representable
> int-value would be less than the largest representable
> one. Unfortunately, this doesn't hold either.

> In your example, the compiler could use a long. But what about
> machines where sizeof(int) == sizeof(long) ?

If both int's and long's are 32 bits, then the constant 2147483648
results in undefined behavior.

If int's are 16 bits, and long's 32 bits, then the constant 32768 has a
type long. Whereas the type of 0x8000 is unsigned (although 0x7fff is a
signed int).

There are some subtle issues involved, but I really don't think that any
of this could be changed now, even supposing someone came up with a
better solution (because although everyone gripes about the current
state, I've yet to seen any concrete alternative proposals that would
work).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]