Topic: Question Regarding the M$ compiler
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/12 Raw View
This small annoyance has made me mutter a few times:
Is this legal c++?
int x = some_value();
switch(x)
{
case 0:
// Blah, Blah, Blah....
break;
case 1:
int y = some_value();
// Blah, Blah, Blah....
break;
default:
// Blah, Blah, Blah....
break;
}
The compiler complains that the variable y is not inititalized in case the
default label is used.
Is this covered in the spec, or is this a case of Redmond being creative?
(easy 'fix': all I do to fix this is put the new decaraction in a compound
code statement)
--
Ross Driedger
Senior Developer
Kaosworks, Inc.
240 Duncan Mill Road, #301
Toronto, Ontario, Canada
M3B 1Z4
Voice: (416) 385-8040 x305
Fax: (416) 385-0074
Ross@FILTERkaosworks.com
www.kaosworks.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 ]
Author: "Richard Parkin" <rparkin@msi-eu.com>
Date: 2000/07/13 Raw View
"Ross Driedger" <ross@SPAMMENOTkaosworks.com> wrote in message
news:3CZa5.27530$qS3.58377@tor-nn1.netcom.ca...
> This small annoyance has made me mutter a few times:
>
> Is this legal c++?
>
> int x = some_value();
> switch(x)
> {
> case 0:
> // Blah, Blah, Blah....
> break;
> case 1:
> int y = some_value();
> // Blah, Blah, Blah....
> break;
> default:
> // Blah, Blah, Blah....
> break;
> }
>
> The compiler complains that the variable y is not inititalized in case the
> default label is used.
>
> Is this covered in the spec, or is this a case of Redmond being creative?
Section 6.7.3 (apologies if this is an incorrectly formed reference - I only
got my copy of the standard a hour ago). ie 6: Statements; 7 Declaration
Statement. Para 3.
This says roughly, when you jump into a block, you cannot bypass
declarations that have initialisations, and a program is ill-formed if it
does. There is also a note that mentions that a switch to a case label (in
this case default) is considered to be a jump.
Ric
---
[ 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 ]
Author: Bob Withers <bob.withers@news.beasys.com>
Date: 2000/07/13 Raw View
In article <3CZa5.27530$qS3.58377@tor-nn1.netcom.ca>,
ross@SPAMMENOTkaosworks.com says...
> This small annoyance has made me mutter a few times:
>
> Is this legal c++?
>
> int x = some_value();
> switch(x)
> {
> case 0:
> // Blah, Blah, Blah....
> break;
> case 1:
> int y = some_value();
> // Blah, Blah, Blah....
> break;
> default:
> // Blah, Blah, Blah....
> break;
> }
>
> The compiler complains that the variable y is not inititalized in case the
> default label is used.
>
> Is this covered in the spec, or is this a case of Redmond being creative?
>
> (easy 'fix': all I do to fix this is put the new decaraction in a compound
> code statement)
The variable 'y' is in scope from it's definition to the end of the block
it is defined in. As coded this is the end of switch statement. The
warning you receive is telling you that the variable 'y' is in scope in
the default case of your switch but will not be initialized if that
branch is taken.
When you apply the 'fix' you change the block which defines the variable
and eliminate the warning.
The compiler is not required to warn of this situation, particularly
since I assume you don't reference 'y' in the default case. On the other
hand there is nothing that requires them not to issue the warning.
Regards,
Bob
--
Bob Withers
Brainbench C Programming "Most Valuable Professional"
---
[ 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 ]
Author: Ron Natalie <ron@sensor.com>
Date: 2000/07/13 Raw View
Bob Withers wrote:
>
> The variable 'y' is in scope from it's definition to the end of the block
> it is defined in. As coded this is the end of switch statement. The
> warning you receive is telling you that the variable 'y' is in scope in
> the default case of your switch but will not be initialized if that
> branch is taken.
>
It's not really just a warning. The program is ill-formed if you jump
into a scope of a variable beyond it's initialization:
>From 6.7/3 of the standard:
It is possible to transfer into a block, but not in a way that bypasses
declarations with initialization. A program that jumps from a point where a
local variable with automatic storage duration is not in scope to a
point where it is in scope is ill-formed unless the variable has POD type
(3.9) and is declared without an initializer (8.5).
---
[ 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 ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/13 Raw View
"Bob Withers" <bob.withers@news.beasys.com> wrote in message
news:MPG.13d640d0ec95d5c0989690@news.beasys.com...
> In article <3CZa5.27530$qS3.58377@tor-nn1.netcom.ca>,
> ross@SPAMMENOTkaosworks.com says...
> > This small annoyance has made me mutter a few times:
> >
> > Is this legal c++?
> >
> > int x = some_value();
> > switch(x)
> > {
> > case 0:
> > // Blah, Blah, Blah....
> > break;
> > case 1:
> > int y = some_value();
> > // Blah, Blah, Blah....
> > break;
> > default:
> > // Blah, Blah, Blah....
> > break;
> > }
[...]
> The variable 'y' is in scope from it's definition to the end of the block
> it is defined in. As coded this is the end of switch statement. The
> warning you receive is telling you that the variable 'y' is in scope in
> the default case of your switch but will not be initialized if that
> branch is taken.
This is not a warning in VC++: it is an out-right error.
[clip]
> The compiler is not required to warn of this situation, particularly
> since I assume you don't reference 'y' in the default case. On the other
> hand there is nothing that requires them not to issue the warning.
Not being experienced in compiler design, I don't know how easy it would be
to code a parser detect that 'y' is not an issue in the default area because
of the 'break' in the previous area. Is this something horrendously
difficult to implement or is Redmond being lazy?
R.
---
[ 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 ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/13 Raw View
"Richard Parkin" <rparkin@msi-eu.com> wrote in message
news:8khr37$fed$1@suparna.cam.msi-eu.com...
>
> "Ross Driedger" <ross@SPAMMENOTkaosworks.com> wrote in message
> news:3CZa5.27530$qS3.58377@tor-nn1.netcom.ca...
> > This small annoyance has made me mutter a few times:
> >
> > Is this legal c++?
> >
> > int x = some_value();
> > switch(x)
> > {
> > case 0:
> > // Blah, Blah, Blah....
> > break;
> > case 1:
> > int y = some_value();
> > // Blah, Blah, Blah....
> > break;
> > default:
> > // Blah, Blah, Blah....
> > break;
> > }
> >
> > The compiler complains that the variable y is not inititalized in case
the
> > default label is used.
> >
> > Is this covered in the spec, or is this a case of Redmond being
creative?
>
> Section 6.7.3 (apologies if this is an incorrectly formed reference - I
only
> got my copy of the standard a hour ago). ie 6: Statements; 7 Declaration
> Statement. Para 3.
>
> This says roughly, when you jump into a block, you cannot bypass
> declarations that have initialisations, and a program is ill-formed if it
> does. There is also a note that mentions that a switch to a case label (in
> this case default) is considered to be a jump.
Hmmm.... Would this mean that:
int x = some_value();
switch(x)
{
case 0:
// Blah, Blah, Blah....
break;
case 1:
int y;
y = some_value();
// Blah, Blah, Blah....
break;
default:
// Blah, Blah, Blah....
break;
}
is legal? (VC++ likes it)
Thanks. Interesting food for thought....
R.
---
[ 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 ]
Author: Steve Clamage <stephen.clamage@sun.com>
Date: 2000/07/13 Raw View
Ross Driedger wrote:
>
> This small annoyance has made me mutter a few times:
>
> Is this legal c++?
>
> int x = some_value();
> switch(x)
> {
> case 0:
> // Blah, Blah, Blah....
> break;
> case 1:
> int y = some_value();
> // Blah, Blah, Blah....
> break;
> default:
> // Blah, Blah, Blah....
> break;
> }
>
> The compiler complains that the variable y is not inititalized in case the
> default label is used.
>
> Is this covered in the spec, or is this a case of Redmond being creative?
>
As others have explained, the code is ill-formed. If y was of a
type needing destruction, your program would likely crash if the
compiler accepted it.
To make the code valid, either move the declaration of y outside
the switch statment, or put it inside its own block. The latter
preserves what you probably intend:
case 1:
{
int y = ... ;
...
break;
}
--
Steve Clamage, stephen.clamage@sun.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 ]
Author: Jerry Coffin <jcoffin@taeus.com>
Date: 2000/07/13 Raw View
In article <8khr37$fed$1@suparna.cam.msi-eu.com>, rparkin@msi-eu.com
says...
[ ... ]
> Section 6.7.3 (apologies if this is an incorrectly formed reference - I only
> got my copy of the standard a hour ago). ie 6: Statements; 7 Declaration
> Statement. Para 3.
Technically off-topic, but perhaps the moderators will let this by.
You normally want to signify paragraph numbers separately from the
rest of the number. One common method would be to call this "6.7/3"
though if you keep your eyes open, you'll see things like "6.7p3" and
so on.
--
Later,
Jerry.
The universe is a figment of its own imagination.
---
[ 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 ]
Author: "Richard Parkin" <rparkin@msi-eu.com>
Date: 2000/07/13 Raw View
"Ross Driedger" <ross@SPAMMENOTkaosworks.com> wrote in message
news:lj0b5.27569$qS3.58608@tor-nn1.netcom.ca...
>
> "Richard Parkin" <rparkin@msi-eu.com> wrote in message
> news:8khr37$fed$1@suparna.cam.msi-eu.com...
> >
> > Section 6.7.3 (apologies if this is an incorrectly formed reference - I
> only
> > got my copy of the standard a hour ago). ie 6: Statements; 7 Declaration
> > Statement. Para 3.
> >
> > This says roughly, when you jump into a block, you cannot bypass
> > declarations that have initialisations, and a program is ill-formed if
it
> > does. There is also a note that mentions that a switch to a case label
(in
> > this case default) is considered to be a jump.
>
> Hmmm.... Would this mean that:
>
> int x = some_value();
> switch(x)
> {
> case 0:
> // Blah, Blah, Blah....
> break;
> case 1:
> int y;
> y = some_value();
> // Blah, Blah, Blah....
> break;
> default:
> // Blah, Blah, Blah....
> break;
> }
>
> is legal? (VC++ likes it)
>
> Thanks. Interesting food for thought....
Sneaky ;)
As far as I can see, yes, this is ok. At which point, y is in scope, but
uninitialised. (NB y must be a POD)
Similar to
goto Label;
int y;
// y is uninitalised
Label:
// y is uninitalised
verses
goto Label;
int y = 1;
// y is always initalised
Label:
// y is uninitalised
My guess for it being this way is to consider what it could do with
references (and possibly const variables), and then generalise to other
types.
Hmm, this may be a way of preventing people jumping into a block from
unexpected places.
eg
// unable to say goto Label;
{
int gotoLabelBlocker = 1;
// can now
goto Label;
Label:
}
Ric
---
[ 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 ]
Author: wmm@fastdial.net
Date: 2000/07/13 Raw View
In a previous article, "Richard Parkin" <rparkin@msi-eu.com> writes:
>
>Section 6.7.3 (apologies if this is an incorrectly formed reference - I only
>got my copy of the standard a hour ago). ie 6: Statements; 7 Declaration
>Statement. Para 3.
There's no canonical representation of a Standard reference, but
generally people will write this as either 6.7p3 (my personal
preference) or 6.7/3. Since many sections have both paragraphs and
subsections with the same numbers, using periods between section
numbers and paragraph numbers is ambiguous.
-- William M. Miller
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ron Natalie <ron@sensor.com>
Date: 2000/07/13 Raw View
> Hmmm.... Would this mean that:
>
> int x = some_value();
> switch(x)
> {
> case 0:
> // Blah, Blah, Blah....
> break;
> case 1:
> int y;
> y = some_value();
> // Blah, Blah, Blah....
> break;
> default:
> // Blah, Blah, Blah....
> break;
> }
>
> is legal? (VC++ likes it)
>
Yes, y is a POD type and has no initializer, so you can jump over it.
You can't jump over initializations either explicit or implied by constructors.
---
[ 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 ]
Author: Ron Natalie <ron@sensor.com>
Date: 2000/07/13 Raw View
Ross Driedger wrote:
>
> Not being experienced in compiler design, I don't know how easy it would be
> to code a parser detect that 'y' is not an issue in the default area because
> of the 'break' in the previous area. Is this something horrendously
> difficult to implement or is Redmond being lazy?
I have no idea what you are saying. What do you mean by "the deafult area."
Falling through is not the problem. The C++ defines when an auto object is initialized
as when control passes through the declaration. If you jump over the declaration, you
then have a variable that's in scope that escaped initialization.
---
[ 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 ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/13 Raw View
"Ron Natalie" <ron@sensor.com> wrote in message
news:396CA887.FF45990E@sensor.com...
>
>
> Ross Driedger wrote:
> >
> > Not being experienced in compiler design, I don't know how easy it would
be
> > to code a parser detect that 'y' is not an issue in the default area
because
> > of the 'break' in the previous area. Is this something horrendously
> > difficult to implement or is Redmond being lazy?
>
> I have no idea what you are saying. What do you mean by "the deafult
area."
>
> Falling through is not the problem. The C++ defines when an auto object
is initialized
> as when control passes through the declaration. If you jump over the
declaration, you
> then have a variable that's in scope that escaped initialization.
Yes, I see that. Consider, though, that if 'y' is declared and initialized
in two different statements, the code, according to this, is legal. This
leads to the possibility, if there was fall through, of it being used after
the default label without the initialization.
If I'm correct in interpreting what was written, this is not legal:
(a)
switch(x)
{
case 1:
int y = some_value();
break;
default:
// ...
break;
}
and this is:
(b)
switch(x)
{
case 1:
int y ;
y = some_value();
break;
default:
// ...
break;
}
This means this is not legal:
(c)
switch(x)
{
case 1:
int y = some_value();
default: // Fall through
// ...
break;
}
yet this is:
(d)
switch(x)
{
case 1:
int y;
y = some_value();
default: // Fall through
// ...
break;
}
I see the value of this rule in that (c) is not permitted, yet (d) and it is
just as dangerous as (c) would be if it could compile.
My original question restated this: Is it difficult/impossible to parse the
code such that (a) and (b) could be distiguished from (c) and (d) and
permitted, while the dangers of (c) and (d) would cause an error?
--
Ross Driedger
Senior Developer
Kaosworks, Inc.
240 Duncan Mill Road, #301
Toronto, Ontario, Canada
M3B 1Z4
Voice: (416) 385-8040 x305
Fax: (416) 385-0074
Ross@FILTERkaosworks.com
www.kaosworks.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 ]
Author: Ron Natalie <ron@sensor.com>
Date: 2000/07/13 Raw View
Ross Driedger wrote:
>
> Yes, I see that. Consider, though, that if 'y' is declared and initialized
> in two different statements, the code, according to this, is legal.
You are confusing initialization with a subsequent assigment. They are different.
> This
> leads to the possibility, if there was fall through, of it being used after
> the default label without the initialization.
>
> switch(x)
> {
> case 1:
> int y;
> y = some_value();
> default: // Fall through
> // ...
> break;
> }
I'm confused or you are. Even without the fall through, the variable y is
accessible to the code in default. It's an unitialized pod. The code in the
case 1 part doesn't initialize it, it just assigns a value to it.
> My original question restated this: Is it difficult/impossible to parse the
> code such that (a) and (b) could be distiguished from (c) and (d) and
> permitted, while the dangers of (c) and (d) would cause an error?
The issue is INITIALATION is not severable from object creation. If you attempt
to do so, it is illegal. However, it is perfectly legal to leave certain types of
variables uninitialized.
---
[ 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 ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/13 Raw View
"Ron Natalie" <ron@sensor.com> wrote in message
news:396CC4D1.F818E0AE@sensor.com...
>
>
> Ross Driedger wrote:
> >
> > Yes, I see that. Consider, though, that if 'y' is declared and
initialized
> > in two different statements, the code, according to this, is legal.
>
> You are confusing initialization with a subsequent assigment. They are
different.
Am I really or are you just infering that from the context of the question?
(Hint: I don't think I'm that thick.)
> > This
> > leads to the possibility, if there was fall through, of it being used
after
> > the default label without the initialization.
> >
> > switch(x)
> > {
> > case 1:
> > int y;
> > y = some_value();
> > default: // Fall through
> > // ...
> > break;
> > }
>
> I'm confused or you are. Even without the fall through, the variable y is
> accessible to the code in default. It's an unitialized pod. The code in
the
> case 1 part doesn't initialize it, it just assigns a value to it.
I got this. The two operations are different, though with simple data
types, the effects are very similar (not necessarily so with classes where
initialization and assignment can lead to very different object states).
> > My original question restated this: Is it difficult/impossible to parse
the
> > code such that (a) and (b) could be distiguished from (c) and (d) and
> > permitted, while the dangers of (c) and (d) would cause an error?
>
> The issue is INITIALATION is not severable from object creation. If you
attempt
> to do so, it is illegal. However, it is perfectly legal to leave certain
types of
> variables uninitialized.
Got this, too. If I presume to read the intent of the paragraph originally
presented, I would say it is to prevent a variable/object from being used
that is initialized from not being initialized because of the mechanics of a
jump (which I see as a Good Thing(tm) ). If this is the reason, then might
it not be possible for a compiler (and the spec) to distinguish between:
switch(x)
{
case 1:
int y = some_value();
default: // Fall through
// ...
break;
}
which is not safe, and this:
switch(x)
{
case 1:
int y = some_value();
break; // or return from a function
default: // Fall through
// ...
break;
}
which is?
I've never worked on a compiler project, and it's been awhile since my
compiler theory class in university, so I have only the faintest idea of the
complexities involved is accurately parsing modern c++ source.
Still, the question remains: Is this possible? Practical? Desirable?
R.
---
[ 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 ]
Author: Craig Powers <enigma@hal-pc.org>
Date: 2000/07/13 Raw View
Ross Driedger wrote:
[...]
> Got this, too. If I presume to read the intent of the paragraph originally
> presented, I would say it is to prevent a variable/object from being used
> that is initialized from not being initialized because of the mechanics of a
> jump (which I see as a Good Thing(tm) ). If this is the reason, then might
> it not be possible for a compiler (and the spec) to distinguish between:
> switch(x)
> {
> case 1:
> int y = some_value();
> default: // Fall through
> // ...
> break;
> }
> which is not safe, and this:
> switch(x)
> {
> case 1:
> int y = some_value();
> break; // or return from a function
> default: // Fall through
> // ...
> break;
> }
>
> which is?
I see no difference in safety. The addition of the break doesn't
alter the status of y after the default statement. While it makes
it apparent that you intend the two pieces to be separate, absent
containing braces they aren't.
I'll illustrate by returning to a modification of the contrasting case
where y is declared as an uninitialized, then assigned separately:
switch(x) {
case 1:
int y;
// ...
break;
default:
y = some_value();
// ...
break;
}
As far as I know, this is legal. Right? (I suspect that most of the
gurus here would consider it very poor style, and I don't think I'd
ever do it myself.) In the preceding two cases, the scope of y is
the same as in this case, hence the issues. Are you suggesting
changing the scoping in case statements? I really don't see the
point, considering that it can all be resolved by adding braces
enclosing the code for "case 1:".
--
Craig Powers
cpowers@lynx.neu.edu
enigma@hal-pc.org
---
[ 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 ]
Author: wmm@fastdial.net
Date: 2000/07/13 Raw View
In a previous article, "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
writes:
>
>"Ron Natalie" <ron@sensor.com> wrote in message
>news:396CC4D1.F818E0AE@sensor.com...
>>
>>
>> Ross Driedger wrote:
>> >
>> > Yes, I see that. Consider, though, that if 'y' is declared and
>initialized
>> > in two different statements, the code, according to this, is legal.
>>
>> You are confusing initialization with a subsequent assigment. They are
>different.
>
>Am I really or are you just infering that from the context of the question?
You said "declared and initialized in two different statements."
That's not possible. Initialization can only be done in the
declaration; anything else is assignment. (Speaking here, of
course, of complete objects; a member or base subobject
initialization is different, but that's not what we were talking
about here.)
>Got this, too. If I presume to read the intent of the paragraph originally
>presented, I would say it is to prevent a variable/object from being used
>that is initialized from not being initialized because of the mechanics of a
>jump (which I see as a Good Thing(tm) ). If this is the reason, then might
>it not be possible for a compiler (and the spec) to distinguish between:
>
>
> switch(x)
> {
> case 1:
> int y = some_value();
> default: // Fall through
> // ...
> break;
> }
>
>which is not safe, and this:
>
> switch(x)
> {
> case 1:
> int y = some_value();
> break; // or return from a function
> default: // Fall through
> // ...
> break;
> }
>
>which is?
>From the perspective of this topic, there is no difference
between the two; neither is "safer" than the other, and the
presence or absence of the fall-through is irrelevant. For
instance, the commented text in your "safer" case might
be expanded something like:
switch (x) {
case 1:
int y = some_value();
break;
default:
x = y + 3; // "y" was not initialized!
break;
}
The rule is intended to prevent regions of text in which the
name is in scope but the expressed initialization is skipped.
The only way to determine that such a construct is "safe" is
to ensure that no references to the name occur in the region
in which the initialization was skipped. There's no good
reason to support such code, so why bother to special case
the rule ("it's only okay to jump over an initialization if
the initialized variable isn't referenced in the region to
which the jump occurs")?
-- William M. Miller
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/13 Raw View
"Craig Powers" <enigma@hal-pc.org> wrote in message
news:396CDAC6.358CCC4F@hal-pc.org...
> Ross Driedger wrote:
>
> [...]
>
>
> > switch(x)
> > {
> > case 1:
> > int y = some_value();
> > default: // Fall through
> > // ...
> > break;
> > }
>
> > which is not safe, and this:
>
> > switch(x)
> > {
> > case 1:
> > int y = some_value();
> > break; // or return from a function
> > default: // Fall through
> > // ...
> > break;
> > }
> >
> > which is?
>
> I see no difference in safety.
How is this not safe? One thing I've missed is specifying that 'y' not
referenced after the default, but this is also presumed in the example where
the variable was declared and assigned.
> The addition of the break doesn't
> alter the status of y after the default statement. While it makes
> it apparent that you intend the two pieces to be separate, absent
> containing braces they aren't.
>
> I'll illustrate by returning to a modification of the contrasting case
> where y is declared as an uninitialized, then assigned separately:
>
> switch(x) {
> case 1:
> int y;
> // ...
> break;
> default:
> y = some_value();
> // ...
> break;
> }
>
> As far as I know, this is legal. Right?
According to the paragraphs of the standard quoted here, this is.
> (I suspect that most of the
> gurus here would consider it very poor style, and I don't think I'd
> ever do it myself.)
I'm not even in sight of guru-status, and it makes me cringe.
> In the preceding two cases, the scope of y is
> the same as in this case, hence the issues. Are you suggesting
> changing the scoping in case statements? I really don't see the
> point, considering that it can all be resolved by adding braces
> enclosing the code for "case 1:".
My point was about the disallowing of initializations in a context where a
jump may cause the variable to be in scope, yet uninitialized. This is, as
I see it a good thing. I was wondering, out loud (so to 'type'), whether
this could be extended to cover a situation that, at least for simple data
types, is very similar.
I guess the moral of the story is that you can't force programmers into
writing good code through the language 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
Date: 2000/07/14 Raw View
<wmm@fastdial.net> wrote in message news:8kip58$j12$1@news.netmar.com...
> In a previous article, "Ross Driedger" <ross@SPAMMENOTkaosworks.com>
> writes:
> >
> >"Ron Natalie" <ron@sensor.com> wrote in message
> >news:396CC4D1.F818E0AE@sensor.com...
> >>
> >>
> >> Ross Driedger wrote:
> >> >
> >> > Yes, I see that. Consider, though, that if 'y' is declared and
> >initialized
> >> > in two different statements, the code, according to this, is legal.
> >>
> >> You are confusing initialization with a subsequent assigment. They are
> >different.
> >
> >Am I really or are you just infering that from the context of the
question?
>
> You said "declared and initialized in two different statements."
> That's not possible.
I admit my use of language here isn't precise.
> Initialization can only be done in the
> declaration; anything else is assignment. (Speaking here, of
> course, of complete objects; a member or base subobject
> initialization is different, but that's not what we were talking
> about here.)
>
> >Got this, too. If I presume to read the intent of the paragraph
originally
> >presented, I would say it is to prevent a variable/object from being used
> >that is initialized from not being initialized because of the mechanics
of a
> >jump (which I see as a Good Thing(tm) ). If this is the reason, then
might
> >it not be possible for a compiler (and the spec) to distinguish between:
> >
> >
> > switch(x)
> > {
> > case 1:
> > int y = some_value();
> > default: // Fall through
> > // ...
> > break;
> > }
> >
> >which is not safe, and this:
> >
> > switch(x)
> > {
> > case 1:
> > int y = some_value();
> > break; // or return from a function
> > default: // Fall through
> > // ...
> > break;
> > }
> >
> >which is?
>
> >From the perspective of this topic, there is no difference
> between the two; neither is "safer" than the other, and the
> presence or absence of the fall-through is irrelevant. For
> instance, the commented text in your "safer" case might
> be expanded something like:
>
> switch (x) {
> case 1:
> int y = some_value();
> break;
> default:
> x = y + 3; // "y" was not initialized!
> break;
> }
I was using an assumed premise that 'y' is not used after the default. In
that context, my contention of safe/not safe remains (as do the
legality/illegality of the code).
> The rule is intended to prevent regions of text in which the
> name is in scope but the expressed initialization is skipped.
> The only way to determine that such a construct is "safe" is
> to ensure that no references to the name occur in the region
> in which the initialization was skipped. There's no good
> reason to support such code, so why bother to special case
> the rule ("it's only okay to jump over an initialization if
> the initialized variable isn't referenced in the region to
> which the jump occurs")?
Which is a round-about way of answering my question (ie: would this be
difficult to implement in the spec and a compiler). Thanks.
R.
---
[ 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 ]
Author: wmm@fastdial.net
Date: 2000/07/14 Raw View
In article <ztib5.27958$qS3.59526@tor-nn1.netcom.ca>,
"Ross Driedger" <ross@SPAMMENOTkaosworks.com> wrote:
>
> might
> > >it not be possible for a compiler (and the spec) to distinguish
between:
> > >
> > >
> > > switch(x)
> > > {
> > > case 1:
> > > int y = some_value();
> > > default: // Fall through
> > > // ...
> > > break;
> > > }
> > >
> > >which is not safe, and this:
> > >
> > > switch(x)
> > > {
> > > case 1:
> > > int y = some_value();
> > > break; // or return from a function
> > > default: // Fall through
> > > // ...
> > > break;
> > > }
> > >
> > >which is?
> >
> > From the perspective of this topic, there is no difference
> > between the two; neither is "safer" than the other, and the
> > presence or absence of the fall-through is irrelevant. For
> > instance, the commented text in your "safer" case might
> > be expanded something like:
> >
> > switch (x) {
> > case 1:
> > int y = some_value();
> > break;
> > default:
> > x = y + 3; // "y" was not initialized!
> > break;
> > }
>
> I was using an assumed premise that 'y' is not used after the
default. In
> that context, my contention of safe/not safe remains (as do the
> legality/illegality of the code).
The point I was making is that the presence or absence of the
fallthrough is completely irrelevant to this issue: the code
following "default:" might or might not have a reference to "y",
regardless of whether there is a "break" preceding the label.
If there's no reference to "y", the fallthrough case is as "safe"
as the one with the break; if there is a reference to "y", both
are equally flawed.
--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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 ]