The standard defines allowed integral promotions in 4.5 [conv.prom].
However, it doesn't say anything about int-to-long promotion. Is this
not a valid integral promotion according to the standard?


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"dk" <newz@grog.net> wrote...
> The standard defines allowed integral promotions in 4.5 [conv.prom].
> However, it doesn't say anything about int-to-long promotion. Is this
> not a valid integral promotion according to the standard?

Did you read 4.7?  According to it, int-to-long is not a promotion,
it's a conversion.

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.research.att.com/~austern/csc/faq.html                ]

"Victor Bazarov" <vAbazarov@dAnai.com> wrote:

> "dk" <newz@grog.net> wrote...
> > The standard defines allowed integral promotions in 4.5 [conv.prom].
> > However, it doesn't say anything about int-to-long promotion. Is this
> > not a valid integral promotion according to the standard?
>
> Did you read 4.7?  According to it, int-to-long is not a promotion,
> it's a conversion.

Apologies. Perhaps I did not make my question clear. I know it is a
conversion and not a promotion. What I want to know is -why- it is
not a promotion (other than "because the standard says so"). What is
the justification for not permitting ints to be promoted to longs?


---
[ 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.research.att.com/~austern/csc/faq.html                ]

dk wrote:
...
> Apologies. Perhaps I did not make my question clear. I know it is a
> conversion and not a promotion. What I want to know is -why- it is
> not a promotion (other than "because the standard says so"). What is
> the justification for not permitting ints to be promoted to longs?

Could you give an example of code where this is a problem? I suspect
that you're misunderstanding the significance of promotions. Promotions
are not "permitted" to occur; when they apply, they're required to
occur. In most circumstances, the fact that ints are permitted to be
converted to longs means that the fact that they don't get promoted to
longs isn't a problem. The integral promotions matter in the following
contexts:

When you call a function that uses a variable number of arguments
through the va_args mechanism, promotions occur to all the arguments
that are variable.
As operands of the ~, <<, and >> operators.
As an argument of switch()
Function overloads that can be matched by promotion are favored over
function overloads that require conversion.
Built-in operators +, -, &, ^, |, % participate in overload resolution
as if they were overloaded functions, but overloaded only for the
promoted types corresponding to built-in scalar types.
Non-type template arguments.

Types larger than 'int' typically involve slower operations. Therefore,
all integral types smaller than 'int' get promoted in certain contexts
to 'int' for greater speed during intermediate computation. They DON'T
get promoted to 'long', for the precise same reason. Promoting to 'long'
would be counter-productive; it's typcially less efficient than 'int'.
Therefore, wherever possible C is set up to work with 'int's
automatically, requiring casts only when you need a different type and
C++ followed that lead.

On some modern implementations, 'long' involves little or no
inefficiency relative to 'int', but that's not universal. In any event,
changing this rule now would break a LOT of legacy code.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"dk" <newz@grog.net> wrote...
> "Victor Bazarov" <vAbazarov@dAnai.com> wrote:
>
> > "dk" <newz@grog.net> wrote...
> > > The standard defines allowed integral promotions in 4.5
[conv.prom].
> > > However, it doesn't say anything about int-to-long promotion. Is
this
> > > not a valid integral promotion according to the standard?
> >
> > Did you read 4.7?  According to it, int-to-long is not a promotion,
> > it's a conversion.
>
> Apologies. Perhaps I did not make my question clear. I know it is a
> conversion and not a promotion. What I want to know is -why- it is
> not a promotion (other than "because the standard says so"). What is
> the justification for not permitting ints to be promoted to longs?

Well, I don't know *exactly* _why_, but I could probably speculate
that it has been done so because 'int' type is natural (see 3.9.1,
para 2) and 'long' may not be.  Since the other types are _smaller_
than int or the same, the promotion comes naturally.  With long it
may not be.  That's my $0.02.

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.research.att.com/~austern/csc/faq.html                ]

"dk" <newz@grog.net> wrote in message
news:99dv6p$s629$1@ID-46268.news.dfncis.de...
> "Victor Bazarov" <vAbazarov@dAnai.com> wrote:
>
> > "dk" <newz@grog.net> wrote...
> > > The standard defines allowed integral promotions in 4.5 [conv.prom].
> > > However, it doesn't say anything about int-to-long promotion. Is this
> > > not a valid integral promotion according to the standard?
> >
> > Did you read 4.7?  According to it, int-to-long is not a promotion,
> > it's a conversion.
>
> Apologies. Perhaps I did not make my question clear. I know it is a
> conversion and not a promotion. What I want to know is -why- it is
> not a promotion (other than "because the standard says so"). What is
> the justification for not permitting ints to be promoted to longs?

I'm not sure but I think the rationale is that promotions are those that will be
needed for processing or that will not lead to less efficiency in hte
processing.

Note that there are basically 4 different "sets" of promotions listed in 4.5 at,
respectively, subs 1, 2, 3 and 4. Also note that subs 2, 3 and 4 refer to
"integrals" that are not "arithmetic". Therefore to (arithmetically) process
them you generally need to somehow convert them.

sub 4 promotes to int, and sub 3 promotes to either int or unsigned int.
sub 1 promotes integrals that are guaranteed to be smaller than int, to int (or
unsigned int). Note that char to short is not a promotion!
Only sub 2 permits a promotion to anything that is larger than int, but only if
strictly needed by the definition of wchar_t.

In other words all promotions have target int unless this cannot represent the
source type. If that's the case unsigned int is the target. The only exeption is
wchar_t. Let's for the moment assume wchar_t is always smaller or equal than
int. Than ALL promotions do promote to int.

Why? Because of 3.9.1 sub 2! The type int (and the unsigned version of it) is
guaranteed to be the best performing (arithmetic) integral of the architecture.
It MAY be the ONLY integral supported (arithmetically) in HW. If the HW supports
longer or shorter integrals (including bytes) it will do it less efficiently (or
at best as efficiently).

Therefore all "promotions" are guaranteed to never loose efficiency and MAY be
actually required by the HW architecture in order to compute.

Longs MAY be the same HW type than ints, but they may be larger. That means they
MAY have (possibly less efficient) HW support or be supported in SW (I'm talking
of arithmetic support). Therefore a conversion from int to long (ar a conversion
to anything but int, for that matter) is possibly leading to non HW support or
reduced efficiency in the HW support.

This leaves open the question of the only promotion that can actually lead to
something larger than int. That is 4.5 sub 2 and has to do with wchar_t. This is
the only non-arithmetic integral type that can be larger than int. The
conversion is to the smallest arithmetic integral type. That is needed to let
you process (arithmetically) a value originating as wchar_t in the most
efficient manner.

Andrea Ferro

---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
> Could you give an example of code where this is a problem?

I never said it was a -problem-; I was just curious. I was
trying to answer a question related to promotions and over-
loading, and we were speculating about the underlying reason
for which integral promotions are required by the standard.
For example, take this (terrbile) little program:

  struct X
  {
      operator short() { return 1; }
  };

  void operator+( const X&, int ) {}

  int main()
  {
      X a, b;
      a + b; // Unambiguous: operator+( const X&, int )
  }

In this case there is no ambiguity because 'b' is converted to
short (by the user-defined conversion operator) and then promoted
to int, which matches my operator+. However, if we change the
program slightly:

  struct X
  {
      operator int() { return 1; } // Now converts to int
  };

  void operator+( const X&, long ) {} // Now expects long

  int main()
  {
      X a, b;
      a + b; // Ambiguous
  }

'b' can be converted to int, but int-to-long is not a valid
promotion, so the compiler cries ambiguity:

    void operator+( const X&, long ) or
    operator+(int,int) <builtin>

At any rate, this all makes sense according to what is written
in the standard, but in my latter example there is no possible
loss of information (i.e., 'b' can be safely -converted- from
int to long, so why not promoted?), so we were curious about
the underlying reason for forbidding *-to-long promotions, even
though they were guaranteed lossless.

But thanks for your answer. I wasn't suggesting that this rule
should change or that it's in any way a problem. I was just
curious about its origins. Thank.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"dk" <newz@grog.net> writes:

|>  "Victor Bazarov" <vAbazarov@dAnai.com> wrote:

|>  > "dk" <newz@grog.net> wrote...
|>  > > The standard defines allowed integral promotions in 4.5
|>  > > [conv.prom].  However, it doesn't say anything about int-to-long
|>  > > promotion. Is this not a valid integral promotion according to
|>  > > the standard?

|>  > Did you read 4.7?  According to it, int-to-long is not a
|>  > promotion, it's a conversion.

|>  Apologies. Perhaps I did not make my question clear. I know it is a
|>  conversion and not a promotion. What I want to know is -why- it is
|>  not a promotion (other than "because the standard says so"). What is
|>  the justification for not permitting ints to be promoted to longs?

Probably just historical reasons.  There are one or two contexts,
however, where promotiions will take place, but other conversions won't;
passing a varg comes to mind, for example.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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.research.att.com/~austern/csc/faq.html                ]