468,463 Members | 2,022 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

Left shift

Hi,

in the header of my class I've a constant

static const int a = ( 1 << 32 ) - 1;

When compiling the code, g++ issues the warning
"warning: left shift count >= width of type"

Why? And how can I get rid of that?

Thank you.
Chris
Aug 23 '06
56 14434
Jerry Coffin wrote:
In article <ed**********@murdoch.acc.Virginia.EDU>, jk********@gmx.net
says...

[ ... ]
>I in this context, I would read compiling as "producing the executable".
I agree that the language could be more decisive, however I think, the
intent or at least the desire for compile-time diagnostics is clear.

In $1.9/1, they say:

This International Standard places no requirement on the
structure of conforming implementations. In particular,
they need not copy or emulate the structure of the abstract
machine. Rather, conforming implementations are required to
emulate (only) the observable behavior of the abstract
machine as explained below.

My guess is that it's a relatively simple situation: most of the authors
are sufficiently accustomed to a compiler type of implementation that
they more or less take it for granted in their writing, even though they
clearly don't intend that it be a requirement.
I don't see how that quote says anything about whether interpreters are
allowed. It seems to be more concerned to give an explicit license to
compile C++ into native code instead of compiling it into some
pseudo-machine language for an emulator of the abstract machine.

I agree, though, that this quote does state that code generation can be
trivial (the identity map on the program) provided execution is done by an
interpreting engine. That, however, is inconsequential for whether
diagnostics are do be issued before execution or may be postponed until
run-time.
[ ... ]
>This program is ill-formed, however, a naive run-time check will only
flag that for certain inputs. I think the standard does not give license
to only flag those ill-formed lines that are executed for a particular
input.

I think from a viewpoint of conformance, this is almost entirely a QOI
issue. The requirement is ($1.4/2):

If a program contains a violation of any diagnosable rule,
a conforming implementation shall issue at least one
diagnostic message, except that If a program contains a
violation of a rule for which no diagnostic is required,
this International Standard places no requirement on
implementations with respect to that program.

Strictly from a viewpoint of conforming, that's trivial to meet: simply
issue a diagnostic before commencing interpretation of anything. If you
wanted to conform without modifying your code, change the documentation
to say your copyright notice was a "diagnostic" and you'd be done.
I agree. Note that in this implementation you do not even need to issue any
further diagnostics at run-time. You can just execute

int* p = 1;

in any way you like (as an extension).
I'll openly admit that's probably not what anybody wanted or intended,
but I can't think of any part of the standad it'd violate either...
True, if you put a catch all error message up front, you are free do do
whatever you please as long as you correctly execute conforming programs.

Still, a C++ interpreter (in the usual sense of the word: something that
reads a program line by line, executes what is to be executed and complains
about errors along the way) would not qualify as a conforming
interpretation. That does not mean that such C++ interpreters are a bad
thing. It just means that they are not conforming. (And it also means that
from a few successful runs of a program in an interpreter, you cannot
deduce that the program is well-formed; if a conforming compiler succeeds
without diagnostics, you have some assurance.)
Best

Kai-Uwe Bux
Aug 31 '06 #51
In article <ed**********@murdoch.acc.Virginia.EDU>, jk********@gmx.net
says...

[ ... ]
I don't see how that quote says anything about whether interpreters are
allowed.
It seems to be that "interpreter" describes the structure of an
implementation. To repeat: "This International Standard places no
requirement on the structure of conforming implementations."

I don't see how that could be read as anything short of explicit
permission for an implementation to be an interpreter.
It seems to be more concerned to give an explicit license to
compile C++ into native code instead of compiling it into some
pseudo-machine language for an emulator of the abstract machine.
It explicitly places NO requirement on the structure of a conforming
implementation. How can that possibly be read as limiting the range of
possible implementations in any way?
Strictly from a viewpoint of conforming, that's trivial to meet: simply
issue a diagnostic before commencing interpretation of anything. If you
wanted to conform without modifying your code, change the documentation
to say your copyright notice was a "diagnostic" and you'd be done.

I agree. Note that in this implementation you do not even need to issue any
further diagnostics at run-time. You can just execute

int* p = 1;

in any way you like (as an extension).
I agree.
Still, a C++ interpreter (in the usual sense of the word: something that
reads a program line by line, executes what is to be executed and complains
about errors along the way) would not qualify as a conforming
interpretation.
I still really don't agree in this respect. When you read "Having done
so, however, they can compile and execute such programs." as meaning
"the diagnostic must take place before execution, but can take place
during or after compilation" it sounds extremely strained to me --
you're taking exactly the same words to specify extremely tight
sequencing requirements in one part, but virtually no sequencing
requirements in the other part.

It seems to me that when the exact same words are applied to two things
(compilation and execution) they have to be applied in the same way to
both. If this is taken as meaning that any required diagnostic must be
issued before execution begins, then it also requires that it be issued
before compilation begins. If it means it can be issued sometime during
compilation, then it also means it can be issued sometime during
execution.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 2 '06 #52
Jerry Coffin wrote:
In article <ed**********@murdoch.acc.Virginia.EDU>, jk********@gmx.net
says...

[ ... ]
>I don't see how that quote says anything about whether interpreters are
allowed.

It seems to be that "interpreter" describes the structure of an
implementation. To repeat: "This International Standard places no
requirement on the structure of conforming implementations."

I don't see how that could be read as anything short of explicit
permission for an implementation to be an interpreter.
Interpreters (in the traditional meaning of the term) could be ruled out by
requirements of the standard upon the *behavior* and not upon the
*structure* of an implementation.

>It seems to be more concerned to give an explicit license to
compile C++ into native code instead of compiling it into some
pseudo-machine language for an emulator of the abstract machine.

It explicitly places NO requirement on the structure of a conforming
implementation. How can that possibly be read as limiting the range of
possible implementations in any way?
I guess, I was not clear about this. I think we are in agreement here. I
already said, in the part you snipped,
>>that this quote does state that code generation can be trivial (the
identity map on the program) provided execution is done by an
interpreting engine ...
In other words an interpreter is clearly a possible structure for an
implementation.

However, whether the implementation has to issue all required diagnostics
independently of whether a program is executed or whether it is allowed to
issue some of those diagnostics while the program is running and maybe even
only when flow control takes certain paths, this question is about behavior
not structure; and the standard clearly imposes restrictions on the
behavior of conforming implementations.

So even an interpreter could be required to perform static analysis of a
program before execution (or at least independently of execution) so that
an ill-formed program will be diagnosed as such even if the path of
execution never hits upon the ill-formed line. I think that the standard
actually requires that explicitly when it asks that for every ill-formed
program there has to be at least one diagnostic message. (We already agree
in the next paragraph that this is easy to satisfy: however an interpreter
in the traditional sense would not do so.)

Strictly from a viewpoint of conforming, that's trivial to meet: simply
issue a diagnostic before commencing interpretation of anything. If you
wanted to conform without modifying your code, change the documentation
to say your copyright notice was a "diagnostic" and you'd be done.

I agree. Note that in this implementation you do not even need to issue
any further diagnostics at run-time. You can just execute

int* p = 1;

in any way you like (as an extension).

I agree.
>Still, a C++ interpreter (in the usual sense of the word: something that
reads a program line by line, executes what is to be executed and
complains about errors along the way) would not qualify as a conforming
interpretation.

I still really don't agree in this respect. When you read "Having done
so, however, they can compile and execute such programs." as meaning
"the diagnostic must take place before execution, but can take place
during or after compilation" it sounds extremely strained to me --
you're taking exactly the same words to specify extremely tight
sequencing requirements in one part, but virtually no sequencing
requirements in the other part.
I already provided a reading of "compilation" that does not run into this
kind of problem (namely compilation=code generation). It is a good principle
to interpret terms so that the provisions of the standard come out
meaningfully. The reading I propose does that.

However, I admit that this reading is called into question by the
admissibility of non-compiling implementations. Note, however, that the
possibility of non-compiling implementations makes it somewhat hard to take
the term "compilation" in this paragraph too serious at all. That, however,
does not apply to the term "execution". (I am not inclined to
treat "compile and execute" as a compound phrase: for one, it is clearly
possible that the implementation compiles a program but does not execute
it; for a second reason, refer to the my response to the next paragraph.)
It seems to me that when the exact same words are applied to two things
(compilation and execution) they have to be applied in the same way to
both. If this is taken as meaning that any required diagnostic must be
issued before execution begins, then it also requires that it be issued
before compilation begins. If it means it can be issued sometime during
compilation, then it also means it can be issued sometime during
execution.
I admit that this is a possible interpretation. However, it throws the
words "Having done so, ..." right out of the window. And I think, the
rational you provide is shaky: you want to apply the phrase "Having done
so, however, they can do X" equally to "compile " and to "execute".
However, you end up not applying the phrase at all -- you end up ignoring
it. All that because your reading of "compile" renders a part of the
provision unenforcible.

I disagree with this approach: One of the principles in interpreting
normative materials such as laws or contracts is that the inapplicability
of one provision does not, in itself, void any other. Even if there are
compelling reasons to read the term "compilation" in a way that makes it
impossible to issue diagnostics before, then this renders only a certain
normative aspect of this clause non-sensical. Any other aspect of this
clause should be unaffected: and it *is* possible to issue diagnostics
before execution regardless of how you read the term "compilation". The
idea behind this hermeneutic guideline is to preserve as much of the
normative force of the wording as possible.
Best

Kai-Uwe Bux
Sep 2 '06 #53
In article <ed**********@murdoch.acc.Virginia.EDU>, jk********@gmx.net
says...

[ ... ]
I already provided a reading of "compilation" that does not run into this
kind of problem (namely compilation=code generation).
Except that 1) we both know that's NOT what compile really means, and 2)
it still wouldn't work that way. For example, if you call a function but
never define it, that isn't actually diagnosed until the very end of
_linking_, which normally follows code generation. Therefore, we can't
even treat it as code generation -- we have to treat it as the final
step of linking.

By the time you're done, you've simply played a nice little word game in
which you define before as "before the end of" for one term, but as
"before the beginning of" for the other.

This seems to me a simple situation where you've pre-decided the
outcome, and you're re-defining things as much as necessary to fit that
conclusion.
It is a good principle
to interpret terms so that the provisions of the standard come out
meaningfully. The reading I propose does that.
Your reading still renders the past tense part of "having done that"
meaningless -- the compile and link process has to run virtually to
completion before some required diagnostics can be issued (short of the
previously mentioned cheat of simply issuing some "diagnostic" at the
very beginning of every attempt, which applies equally to interpreters
and compilers).

The fact of the matter is that no matter what words you use to try to
change it, you're still reading it as saying that before means "before
the beginning of" in one case, and "before the end of" in the other. I
maintain that if you're going to read it as "before the end of" in one
case, that it must also mean "before the end of" in the other case as
well.

To me, it looks like you started with a particular conclusion, and
you're willing to re-define some thing things and ignore others
completely to support the conclusion you want. I have little doubt you
see my position similarly. I think each of us understands the other's
position, and simply disagree as to the wisdom of drawing one conclusion
vs. another from the same data (which I think we can also agree is
somewhat ambiguous about the point we're discussing).

That being the case, unless the data changes (e.g. different wording in
the new C++ standard), I see little point in continuing the discussion.
I think we've reached the point at which we're clearly going to disagree
on this point, and our only choice is whether to do so in a friendly or
unfriendly fashion; personally, I'd rather discontinue the discussion
rather than let it degenerate into something unfriendly.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 2 '06 #54
Jerry Coffin wrote:
In article <ed**********@murdoch.acc.Virginia.EDU>, jk********@gmx.net
says...

[ ... ]
>I already provided a reading of "compilation" that does not run into this
kind of problem (namely compilation=code generation).

Except that 1) we both know that's NOT what compile really means, and 2)
it still wouldn't work that way. For example, if you call a function but
never define it, that isn't actually diagnosed until the very end of
_linking_, which normally follows code generation. Therefore, we can't
even treat it as code generation -- we have to treat it as the final
step of linking.
Ah, you are right: I didn't think about linking.
By the time you're done, you've simply played a nice little word game in
which you define before as "before the end of" for one term, but as
"before the beginning of" for the other.

This seems to me a simple situation where you've pre-decided the
outcome, and you're re-defining things as much as necessary to fit that
conclusion.
>It is a good principle
to interpret terms so that the provisions of the standard come out
meaningfully. The reading I propose does that.

Your reading still renders the past tense part of "having done that"
meaningless -- the compile and link process has to run virtually to
completion before some required diagnostics can be issued (short of the
previously mentioned cheat of simply issuing some "diagnostic" at the
very beginning of every attempt, which applies equally to interpreters
and compilers).

The fact of the matter is that no matter what words you use to try to
change it, you're still reading it as saying that before means "before
the beginning of" in one case, and "before the end of" in the other. I
maintain that if you're going to read it as "before the end of" in one
case, that it must also mean "before the end of" in the other case as
well.
Ok, I agree that compilation after diagnostics does not fly.
To me, it looks like you started with a particular conclusion, and
you're willing to re-define some thing things and ignore others
completely to support the conclusion you want. I have little doubt you
see my position similarly. I think each of us understands the other's
position, and simply disagree as to the wisdom of drawing one conclusion
vs. another from the same data (which I think we can also agree is
somewhat ambiguous about the point we're discussing).
Yes, we can agree on that. This is not the first time that the standard is a
little wanting with regard to clarity.
That being the case, unless the data changes (e.g. different wording in
the new C++ standard), I see little point in continuing the discussion.
I think we've reached the point at which we're clearly going to disagree
on this point, and our only choice is whether to do so in a friendly or
unfriendly fashion; personally, I'd rather discontinue the discussion
rather than let it degenerate into something unfriendly.
During this whole discussion, I never had the feeling that we were in danger
of getting unfriendly. I also share your feeling that we will have to just
disagree. Let's abandon this thread. Thanks a lot for this exchange.
Best

Kai-Uwe Bux
Sep 2 '06 #55
Jerry Coffin <jc*****@taeus.comwrote:
>To me, it looks like you started with a particular conclusion, and
you're willing to re-define some thing things and ignore others
completely to support the conclusion you want. I have little doubt you
see my position similarly. I think each of us understands the other's
position, and simply disagree as to the wisdom of drawing one conclusion
vs. another from the same data (which I think we can also agree is
somewhat ambiguous about the point we're discussing).
>That being the case, unless the data changes (e.g. different wording in
the new C++ standard), I see little point in continuing the discussion.
I think we've reached the point at which we're clearly going to disagree
on this point, and our only choice is whether to do so in a friendly or
unfriendly fashion; personally, I'd rather discontinue the discussion
rather than let it degenerate into something unfriendly.

Your posts on this thread have not been "unfriendly" (in my view),
they have just been slow to consider as a serious question
that leaving the evaluation of this particular form of ill-formed
program to runtime might be incorrect.

Here, "incorrect" means not just conformance to the standard,
but also conformance to engineering best practices as applied to
language translators.

I offered up the question because I believe it to be meaningful
to language implementors and users.

Steve
Sep 3 '06 #56
In article <ed**********@blue.rahul.net>, sp*****@speedymail.org says...

[ ... ]
Here, "incorrect" means not just conformance to the standard,
but also conformance to engineering best practices as applied to
language translators.
If there was ever a mention of correctness beyond conformance, I missed
it. I completely agree that it's by far best for problems to be
diagnosed as early as possible.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 3 '06 #57

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Kevin | last post: by
2 posts views Thread by Saber S | last post: by
11 posts views Thread by Kenneth Lantrip | last post: by
19 posts views Thread by aurgathor | last post: by
1 post views Thread by jonathanmcdougall | last post: by
4 posts views Thread by sandhya | last post: by
15 posts views Thread by Christopher Layne | last post: by
4 posts views Thread by G Iveco | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kmladenovski | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.