Compiler switch to allow for (int i;;); for (int i;;); ?
J Donner
I'm using VC6, and I've heard there's a switch that allows std C++
for (;;) loop local scoping, eg
for (int i = 0; i < 5; i++)
blah;
// normally gives redefinition of i error
for (int i = 0; i < 17; i++)
blah;
etc.
but didn't see it in the documentation.
Anyone know what it is?
Thanks,
Jeff
Jonathan Dodds
Extensions that MFC depends on. You can not use this option with an MFC
based project.
J Donner wrote in message ...
Mathew Hendry
: I'm using VC6, and I've heard there's a switch that allows std C++
: for (;;) loop local scoping, eg
:
: for (int i = 0; i < 5; i++)
: blah;
:
: // normally gives redefinition of i error
: for (int i = 0; i < 17; i++)
: blah;
:
: etc.
:
: but didn't see it in the documentation.
:
: Anyone know what it is?
/Za turns off all Microsoft extensions, not just this one. But it's as
close as you get, unfortunately. If you want a temporary solution,
try,
#define for if(0);else for
This rearranges the code above into
if (0)
;
else
for (int i = 0; i < 5; i++)
blah;
if (0)
;
else
for (int i = 0; i < 17; i++)
blah;
Note how the two iteration variables are now forced into separate
scopes.
-- Mat.
Doug Harrison
>/Za if I recall correctly. Unfortunately this option disables Microsoft
>Extensions that MFC depends on. You can not use this option with an MFC
>based project.
Nor can you use it with VC's (draft) Standard C++ Library, which also
requires the extensions. Here's a macro that gives you the new behavior:
#define for if (0) ; else for
Cute as it is, I don't really recommend this.
--
Doug Harrison
dHar...@worldnet.att.net
Jonathan H Lundquist
// Make 'for' standard conforming
#if _MSC_VER <= 1200
#pragma warning(disable:4127) // Conditional expression is constant
#define for if(0);else for
#endif
Doug Harrison wrote in message ...
Doug Harrison
>Not sure why you don't recommend it, I do... Mine looks like:
>
>// Make 'for' standard conforming
>#if _MSC_VER <= 1200
>#pragma warning(disable:4127) // Conditional expression is constant
>#define for if(0);else for
>#endif
I'd have to qualify that a bit by saying it may make a lot of sense if
you're porting code from a compiler that implements the modern rule. The
reason I don't recommend it in general is that it uses the preprocessor to
change the language semantics implemented by VC. For example, the following
is legal with and without the macro, but it means different things:
int i = 5;
void fun(int);
void fun()
{
for (int i = 0; i < 10; ++i) {}
fun(i);
}
Have I ever written anything like that? Probably not, but I can't be sure,
and when bringing old code into a new compiler that implements the modern
rule, I would want a warning that the i in my fun call depends on the
for-scope rule that's in effect. egcs implements the new rule and gives such
a warning, but if you use the macro in VC, you'll just get a silent change
in behavior. That's why I'm waiting for MS to implement the new rule in a
useful way.
--
Doug Harrison
dHar...@worldnet.att.net
Frank Schnabel
int i;
for(i = 0; i < 5; i++) blah;
for(i = 0; i < 17; i++) blah;
This would also be more efficient because you're only allocating the memory
for i once rather than each time a loop is executed.
J Donner wrote in message ...
>Hi
>
> I'm using VC6, and I've heard there's a switch that allows std C++
>for (;;) loop local scoping, eg
>
>for (int i = 0; i < 5; i++)
> blah;
>
>// normally gives redefinition of i error
>for (int i = 0; i < 17; i++)
> blah;
>
>etc.
>
>but didn't see it in the documentation.
>
>Anyone know what it is?
>
>Thanks,
>
>Jeff
>
>
Jessie
// Do stuff
{
for(int i = 0; i < SomeVariable; i++)
{
// blah
}
}
{
for(int i = 0; i < AnotherVariable; i++)
{
// blah
}
}
The above will make variable i local-scoped and it is much easier to
understand.
-- Jessie
Hernandez
Mathew Hendry
: Why don't you just make life easier by doing the following:
: // Do stuff
: {
: for(int i = 0; i < SomeVariable; i++)
: {
: // blah
: }
: }
:
: {
: for(int i = 0; i < AnotherVariable; i++)
: {
: // blah
: }
: }
:
Because it's ugly.
-- Mat.
Mathew Hendry
: Wouldn't it be simpler to define i outside of the loops.
:
: int i;
: for(i = 0; i < 5; i++) blah;
: for(i = 0; i < 17; i++) blah;
It might be simpler, but 'i' doesn't belong out there. I don't like
having to adjust my programming style to work around compiler bugs.
: This would also be more efficient because you're only allocating the memory
: for i once rather than each time a loop is executed.
In fact, identical code is generated.
-- Mat.
Doug Harrison
>Wouldn't it be simpler to define i outside of the loops.
>
>int i;
>for(i = 0; i < 5; i++) blah;
>for(i = 0; i < 17; i++) blah;
It's best to limit scope wherever possible, and the above exposes i
everywhere. Also, consider:
for (Vec::iterator i = v.begin(); ...
for (Map::iterator i = m.begin(); ...
>This would also be more efficient because you're only allocating the memory
>for i once rather than each time a loop is executed.
Most compilers will reuse stack space required by one block in another block
that is outside it, so you typically wouldn't save any stack space.
--
Doug Harrison
dHar...@worldnet.att.net
Jay Bazuzi
> Wouldn't it be simpler to define i outside of the loops.
> int i;
> for(i = 0; i < 5; i++) blah;
> for(i = 0; i < 17; i++) blah;
> This would also be more efficient because you're only allocating the
> memory for i once rather than each time a loop is executed.
You're falling victim to that old spectre of hand-optimization. I
hope you're not worrying about an extra local int inside a virtual
function! The overhead to a virtual call won't be optimized away, but
extra stack variables will be. Compilers optimize better than you or
me. Write code for readability, let the compiler be. It turns out
that a lot of slowness in programs is due to a programmer's failed
attempt at "pre-emptive optimization". Here's an example. Which is
faster:
strcpy (char* s1, char* s2)
{
while (*s1++ = *s2++);
}
strcpy (char* s1, char* s2)
{
int i1, i2;
i1 = 0;
i2 = 0;
/* while we're not at the end of s2 */
while (s2[i2] != '\0')
{
/* copy current position from s2 to s1 */
s1[i1] = s2[i2];
/* move to the next position in both strings */
i1++;
i2++;
}
}
Answer: Neither. They'll optimize to the same set of instructions.
But which is easier to read?
The correct method of attaining speed is to
1) Use a good design. Avoid heavyweight technologies when
unneccesary; design an efficient architecture; don't bite off more
than you can chew.
2) Profile. After you've written readable code, analyze it with a
profiler and clean up the code that is taking too long.
--
Jay Bazuzi <jba...@j.slac.com>
Doug Harrison
>Write code for readability, let the compiler be. It turns out
>that a lot of slowness in programs is due to a programmer's failed
>attempt at "pre-emptive optimization". Here's an example. Which is
>faster:
>
>strcpy (char* s1, char* s2)
>{
> while (*s1++ = *s2++);
>}
>
>strcpy (char* s1, char* s2)
>{
> int i1, i2;
>
> i1 = 0;
> i2 = 0;
>
> /* while we're not at the end of s2 */
> while (s2[i2] != '\0')
> {
> /* copy current position from s2 to s1 */
> s1[i1] = s2[i2];
> /* move to the next position in both strings */
> i1++;
> i2++;
> }
>}
>
>Answer: Neither. They'll optimize to the same set of instructions.
That's far from assured. They don't in VC6, and looking at the assembly
code, I don't know offhand which one is faster. The first version generates
a loop that is one instruction longer than the second, but the second uses
more complicated addressing modes.
What isn't necessarily true is that pointer iteration is any faster than
index-based iteration, so I generally agree that it isn't worth going out of
one's way to use pointer techniques, unless profiling proves otherwise.
However, pointer iteration is the more natural technique for writing the
function above, and that's what I would use.
>But which is easier to read?
The first one employs a common idiom and is far easier to read for someone
experienced in C or C++, who can tell at a glance it's a copy loop. IMO, the
second version isn't any clearer; it's just longer, with its comments that
document what you've already said quite clearly in the code, its redundant
i2 variable, and its use of indexing. Also, it isn't equivalent to your
first example, because it doesn't nul-terminate the copy.
>The correct method of attaining speed is to
>
>1) Use a good design. Avoid heavyweight technologies when
>unneccesary; design an efficient architecture; don't bite off more
>than you can chew.
>
>2) Profile. After you've written readable code, analyze it with a
>profiler and clean up the code that is taking too long.
Choosing appropriate data structures and algorithms is certainly the most
important thing.
--
Doug Harrison
dHar...@worldnet.att.net
Frank Schnabel
Mathew Hendry wrote in message <3644fe36....@news.sol.co.uk>...
>"Frank Schnabel" <fran...@interlog.com> wrote:
>
>: Wouldn't it be simpler to define i outside of the loops.
>:
>: int i;
>: for(i = 0; i < 5; i++) blah;
>: for(i = 0; i < 17; i++) blah;
>
>having to adjust my programming style to work around compiler bugs.
Well, no it doesn't belong there, but if you've ever programmed in MFC
you're probably doing a lot of things that aren't programmatically ideal.
For example, MFC's way of getting data to and from dialog boxes (i.e.
writing to and reading from member variables in a dialog class) is a big no
no in object oriented programming where the data should be hidden from
outside classes. So, as long as you're not writing long meandering
functions, defining i outside of the loops is a simple (albeit unpleasant)
way of working around the bug.
>
>: This would also be more efficient because you're only allocating the
memory
>: for i once rather than each time a loop is executed.
>
>In fact, identical code is generated.
The improved efficiency (be it real or imagined) was a secondary
consideration added as an afterthought.
Eric Gunnerson
>"Frank Schnabel" <fran...@interlog.com> wrote:
>
>: Wouldn't it be simpler to define i outside of the loops.
>:
>: int i;
>: for(i = 0; i < 5; i++) blah;
>: for(i = 0; i < 17; i++) blah;
>
>It might be simpler, but 'i' doesn't belong out there. I don't like
>having to adjust my programming style to work around compiler bugs.
Bug? Hmm. It is non-standard behavior, but changing the scoping is widely
considered to not have been a very smart idea, because it breaks lots of
existing code. The problem is that a lot of people used the new format when
writing search loops:
for (int i = 0; i < pObject->GetSize(); i++)
{
if (condition)
break;
}
(do something with i)
which changing behavior breaks.
I think it is unlikely that VC will change the default behavior on this;
I'll explore getting a separate flag to control the behavior.
Matt McLelland
What does this mean "explore"? This is in the standard now. The issue was
"explored" before it became part of the standard, and it was decided that the
value of changing it outweighed considerations of reliance on the old rule.
Now fix the damn compiler.
As for using switches, I personally think you should have the default behavior
of the compiler conform to the standard. I realize that it can be alot of work
to add an extra switch to existing projects, but who said that upgrading
compilers would be seamless? Besides, what about all of the people who are
porting from conforming compilers? If for some reason Microsoft decides that
it would rather leave this as default behavior, then can we at least just have
one simple switch to make the compiler conform to the standard _completely_?
Mathew Hendry
>Mathew Hendry wrote in message <3644fe36....@news.sol.co.uk>...
>>"Frank Schnabel" <fran...@interlog.com> wrote:
>>: Wouldn't it be simpler to define i outside of the loops.
>>:
>>: int i;
>>: for(i = 0; i < 5; i++) blah;
>>: for(i = 0; i < 17; i++) blah;
>>
>>It might be simpler, but 'i' doesn't belong out there. I don't like
>>having to adjust my programming style to work around compiler bugs.
>
>Bug? Hmm. It is non-standard behavior, but changing the scoping is widely
>considered to not have been a very smart idea, because it breaks lots of
>existing code. The problem is that a lot of people used the new format when
>writing search loops:
>
>for (int i = 0; i < pObject->GetSize(); i++)
>{
> if (condition)
> break;
>}
>
>(do something with i)
>
>which changing behavior breaks.
On the other hand, with impending standardisation of C++, you are
likely to find more and more code using the new scoping rule. The
decision on whether to change the default must surely depend upon the
ratio
amount of code using new scoping rule
-------------------------------------
amount of code using old scoping rule
I think it's only a matter of time before that ratio becomes > 1.
>I think it is unlikely that VC will change the default behavior on this;
>I'll explore getting a separate flag to control the behavior.
Flags to disable/enable specific warnings would be even more useful,
and, presumably, not too difficult to add.
-- Mat.
Matt McLelland
> likely to find more and more code using the new scoping rule. The
> decision on whether to change the default must surely depend upon the
> ratio
>
> amount of code using new scoping rule
> -------------------------------------
> amount of code using old scoping rule
>
> I think it's only a matter of time before that ratio becomes > 1.
I think this ratio is irrelevent. People are not going to write code with the
new rule if thier compiler doesn't support it. If they are smart, they will
stick to code which works under either rule, but as long as the compiler does
not support the correct scoping rule, non-conforming code will continue to be
written. More importantly to me, I will not get to write code specific to the
new, more elegant rule.
Eric Gunnerson
>Eric Gunnerson wrote:
>
>> Mathew Hendry wrote in message <3644fe36....@news.sol.co.uk>...
>> >"Frank Schnabel" <fran...@interlog.com> wrote:
>> >
>> >: Wouldn't it be simpler to define i outside of the loops.
>> >:
>> >: int i;
>> >: for(i = 0; i < 5; i++) blah;
>> >: for(i = 0; i < 17; i++) blah;
>> >
>> >It might be simpler, but 'i' doesn't belong out there. I don't like
>> >having to adjust my programming style to work around compiler bugs.
>>
>> Bug? Hmm. It is non-standard behavior, but changing the scoping is widely
>> considered to not have been a very smart idea, because it breaks lots of
>> existing code. The problem is that a lot of people used the new format
when
>> writing search loops:
>>
>> for (int i = 0; i < pObject->GetSize(); i++)
>> {
>> if (condition)
>> break;
>> }
>>
>> (do something with i)
>>
>> which changing behavior breaks.
>>
>> I'll explore getting a separate flag to control the behavior.
>
>"explored" before it became part of the standard, and it was decided that
the
>value of changing it outweighed considerations of reliance on the old rule.
>Now fix the damn compiler.
>
>As for using switches, I personally think you should have the default
behavior
>of the compiler conform to the standard. I realize that it can be alot of
work
>to add an extra switch to existing projects, but who said that upgrading
>compilers would be seamless? Besides, what about all of the people who are
>porting from conforming compilers? If for some reason Microsoft decides
that
>it would rather leave this as default behavior, then can we at least just
have
>one simple switch to make the compiler conform to the standard
_completely_?
We get conflicting messages from our customers. They want us to be as
conformant as possible while at the same time not wanting us to break
existing code. They would very much rather us *not* change something that
might require them to modify every project or makefile that they have. It's
even worse for us to make changes that require them to edit lots of their
source. Because of this, we have to carefully consider each improvement we
make because somebody may be depending on the current behavior.
As for it being decided that the value in changing it outweighed backwards
compatibility issues, that is not what happened. In this specific case, the
standards committee did not agree that this was a change worth making; it
was (and still is, in the minds of some) a contentious issue. You argument
seems to be that I should do something that I know will make my users very
unhappy because somebody else decided it was the standard.
As for porting from a conforming compiler, I'm not aware that there *are*
any truly conforming compilers out there, since there isn't - as far as I
know - any approved validation suite. I think it's fair to say that
different compilers conform in different areas.
Explore means that I'm not going to commit to us doing something in a
specific timeframe unless I'm sure we are going to be able to deliver, but
that I do think it is something we should try to do.
Doug Harrison
>Bug? Hmm. It is non-standard behavior, but changing the scoping is widely
>considered to not have been a very smart idea, because it breaks lots of
>existing code. The problem is that a lot of people used the new format when
>writing search loops:
>
>for (int i = 0; i < pObject->GetSize(); i++)
>{
> if (condition)
> break;
>}
>
>(do something with i)
>
>which changing behavior breaks.
Look at how egcs implements the modern rule. Changes in interpretation due
to application of the modern rule elicit a warning. IMO, that's the main
thing to worry about, not the minor inconvenience of flipping a compiler
switch to restore the old rule, or, (gasp) moving declarations that never
really belonged in for-init-statements out of them.
>I think it is unlikely that VC will change the default behavior on this;
>I'll explore getting a separate flag to control the behavior.
This has been part of draft standards at least as far back as Apr-95. The
default behavior of VC++ should be to implement Standard C++, and no, I'm
not suggesting eliminating all extensions in this mode, just ones that break
code that is valid under the Standard. Currently, VC6 is non-compliant on a
number of issues that were pretty much set in stone between 3 to 6 years
ago. Here are a few of the simpler ones, off the top of my head:
1. It doesn't implement the modern for-scope rule.
2. operator new returns 0 upon failure instead of throwing std::bad_alloc.
3. Calling set_new_handler causes a program to abort. You have to use the
non-standard _set_new_handler declared in <new.h>.
4. Exception handling is turned off by default.
5. RTTI is turned off by default.
6. Covariant return types aren't supported.
7. std::min and std::max don't exist.
You have to jump through quite a few hoops to set VC6 up to compile a
language resembling Standard C++. I think that's a problem.
--
Doug Harrison
dHar...@worldnet.att.net
Matt McLelland
> conformant as possible while at the same time not wanting us to break
> existing code. They would very much rather us *not* change something that
> might require them to modify every project or makefile that they have. It's
> even worse for us to make changes that require them to edit lots of their
> source. Because of this, we have to carefully consider each improvement we
> make because somebody may be depending on the current behavior.
> As for it being decided that the value in changing it outweighed backwards
> compatibility issues, that is not what happened. In this specific case, the
> standards committee did not agree that this was a change worth making; it
> was (and still is, in the minds of some) a contentious issue. You argument
> seems to be that I should do something that I know will make my users very
> unhappy because somebody else decided it was the standard.
Why do you care if you make your customers unhappy? You are Microsoft, what
are they going to do, switch to the competition?
I understand that backward compatibility is important. But, here is the
thing: You either plan to conform with the standard eventually or you do not
plan to conform. If you do plan to conform with the standard eventually, then
you will be doing *all* of your customers a favor by providing conformity with
the standard as soon as possible, even if it does require a switch. As long as
the compiler does not conform to the standard, new code will continue to be non
conforming. i.e., by not providing compliance now, you are making the problem
worse.
It is possible that you do not ever plan to conform. You indicate that just
because "somebody else" made a standard you don't think you should try to comply
with it if that makes your customers unhappy. Most c++ programmers now-a-days
are ignorant of the new language features. One major reason for this is that
has not been a standard. Noone wants to use or even learn to use features which
are not portable across the board. This is the reason that standards are so
very important. Microsoft is doing damage to the software industry by not
conforming. The new features of c++ make the language much more elegant,
flexible, and powerful than Visual C++. If the new standard actually becomes
standard (i.e., Universally supported), then I think people will take the time
to learn the new features and will be thankful that you provided them.
I would personally like to see a rewrite of MFC, DirectX... and all software
libraries using contemporary c++ methodologies, or at least see wrappers for
these libraries. But I imagine it will be a cold day in hell before Microsoft
would consider something like that.
> As for porting from a conforming compiler, I'm not aware that there *are*
> any truly conforming compilers out there, since there isn't - as far as I
> know - any approved validation suite. I think it's fair to say that
> different compilers conform in different areas.
Come on. Visual C++, as you have explained, does not hold conformance as a high
priority. Very soon, if not now, compilers which do will conform in most areas
significantly better than Visual C++.
> Explore means that I'm not going to commit to us doing something in a
> specific timeframe unless I'm sure we are going to be able to deliver, but
> that I do think it is something we should try to do.
You guys really need to put full conformance on your calendar.
William DePalo [MVP]
> Why do you care if you make your customers unhappy? You are Microsoft,
what
>are they going to do, switch to the competition?
ROFLMAO.
Regards,
Will
J.T. Anderson
Eric Gunnerson wrote in message ...
>I think it is unlikely that VC will change the default behavior on this;
>I'll explore getting a separate flag to control the behavior.
So, are you saying that it is unlikely that Microsoft will ever produce a
C++ standard compliant compiler?
Eric Gunnerson
>> conformant as possible while at the same time not wanting us to break
>> existing code. They would very much rather us *not* change something that
>> might require them to modify every project or makefile that they have.
It's
>> even worse for us to make changes that require them to edit lots of their
>> source. Because of this, we have to carefully consider each improvement
we
>> make because somebody may be depending on the current behavior.
>
>> As for it being decided that the value in changing it outweighed
backwards
>> compatibility issues, that is not what happened. In this specific case,
the
>> standards committee did not agree that this was a change worth making; it
>> was (and still is, in the minds of some) a contentious issue. You
argument
>> seems to be that I should do something that I know will make my users
very
>> unhappy because somebody else decided it was the standard.
>
what
>are they going to do, switch to the competition?
I - and the whole VC unit - cares about what our customers want, and whether
they are happy. There are clearly other alternatives out there - both on the
Windows platform, and other platforms.
> I understand that backward compatibility is important. But, here is the
>thing: You either plan to conform with the standard eventually or you do
not
>plan to conform. If you do plan to conform with the standard eventually,
then
>you will be doing *all* of your customers a favor by providing conformity
with
>the standard as soon as possible, even if it does require a switch. As
long as
>the compiler does not conform to the standard, new code will continue to be
non
>conforming. i.e., by not providing compliance now, you are making the
problem
>worse.
I understand the argument, and *personally* I agree with you, but our
customer responses when we've done things like that have indicated that our
customers don't all consider it a *favor* that we are making them revisit
code that was already functioning correctly.
> It is possible that you do not ever plan to conform. You indicate that
just
>because "somebody else" made a standard you don't think you should try to
comply
>with it if that makes your customers unhappy.
So you think I *should* make my customers unhappy to support a standard,
even when they've written the way I told them to before? If that's true,
then my job has just gotten a lot easier; I can fail large amounts of code
that used to pass - and produce correct results - and my users will thank me
for it.
>Most c++ programmers now-a-days
>are ignorant of the new language features. One major reason for this is
that
>has not been a standard. Noone wants to use or even learn to use features
which
>are not portable across the board. This is the reason that standards are
so
>very important. Microsoft is doing damage to the software industry by not
>conforming. The new features of c++ make the language much more elegant,
>flexible, and powerful than Visual C++. If the new standard actually
becomes
>standard (i.e., Universally supported), then I think people will take the
time
>to learn the new features and will be thankful that you provided them.
I agree that standards are important; the challenge is to figure out how you
can move people towards a standard with the minimum of pain.
> I would personally like to see a rewrite of MFC, DirectX... and all
software
>libraries using contemporary c++ methodologies, or at least see wrappers
for
>these libraries. But I imagine it will be a cold day in hell before
Microsoft
>would consider something like that.
What do you mean by "contemporary C++ methodologies"?
>> As for porting from a conforming compiler, I'm not aware that there *are*
>> any truly conforming compilers out there, since there isn't - as far as I
>> know - any approved validation suite. I think it's fair to say that
>> different compilers conform in different areas.
>
>Come on. Visual C++, as you have explained, does not hold conformance as a
high
>priority. Very soon, if not now, compilers which do will conform in most
areas
>significantly better than Visual C++.
I said that in a specific conformance case it was a difficult decision to
make, I did not say that it was not a high priority.
The exact priority of specific conformance depends upon what we hear from
our customers and what other features and areas we must do support for.
>> Explore means that I'm not going to commit to us doing something in a
>> specific timeframe unless I'm sure we are going to be able to deliver,
but
>> that I do think it is something we should try to do.
>
>You guys really need to put full conformance on your calendar.
It is Microsoft policy not to comment on unannounced products. At times,
that makes things very difficult for us, and I'm sure it's annoying for you
as well. But I don't make that rule, and in the long run, I think it's a
good rule; you may be exasperated at not having any information, but you'd
be pissed off for sure if I said that something would be there, and it
didn't show up.
Having said that, I appreciate the feedback.
Eric Gunnerson
>
>>Bug? Hmm. It is non-standard behavior, but changing the scoping is widely
>>considered to not have been a very smart idea, because it breaks lots of
>>existing code. The problem is that a lot of people used the new format
when
>>writing search loops:
>>
>>for (int i = 0; i < pObject->GetSize(); i++)
>>{
>> if (condition)
>> break;
>>}
>>
>>(do something with i)
>>
>>which changing behavior breaks.
>
>Look at how egcs implements the modern rule. Changes in interpretation due
>to application of the modern rule elicit a warning. IMO, that's the main
>thing to worry about, not the minor inconvenience of flipping a compiler
>switch to restore the old rule, or, (gasp) moving declarations that never
>really belonged in for-init-statements out of them.
>
>>I'll explore getting a separate flag to control the behavior.
>
>default behavior of VC++ should be to implement Standard C++, and no, I'm
>not suggesting eliminating all extensions in this mode, just ones that
break
>code that is valid under the Standard. Currently, VC6 is non-compliant on a
>number of issues that were pretty much set in stone between 3 to 6 years
>ago. Here are a few of the simpler ones, off the top of my head:
>
>1. It doesn't implement the modern for-scope rule.
>2. operator new returns 0 upon failure instead of throwing std::bad_alloc.
>3. Calling set_new_handler causes a program to abort. You have to use the
>non-standard _set_new_handler declared in <new.h>.
>4. Exception handling is turned off by default.
>5. RTTI is turned off by default.
>6. Covariant return types aren't supported.
>7. std::min and std::max don't exist.
>
>You have to jump through quite a few hoops to set VC6 up to compile a
>language resembling Standard C++. I think that's a problem.
#1 and #2 I agree with you, but I think that #2 is more of a problem
supporting existing source than even #1 is. A change in behavior on #2 would
be silent, and bad.
#3 I don't know enough about to comment meaningfully on.
#4 and #5: The standard really doesn't address that you must do certain
things by default. Both of these are turned off by default because of strong
customer comments, from customers who didn't like the increased overhead.
#6, #7 you are correct.
So, can you answer a question for me:
Is your last comment referring to compliance, or to the fact that it may
take extra effort to get your code to compile in a more compliant state?
Eric Gunnerson
J.T. Anderson wrote in message ...
>
>Eric Gunnerson wrote in message ...
>
>>I think it is unlikely that VC will change the default behavior on this;
>>I'll explore getting a separate flag to control the behavior.
>
>
>C++ standard compliant compiler?
Do you think that being compliant with the standard means that the compiler
must be fully compliant by default?
And what would "default" mean in that case - does it mean running the
compiler from the command line, on new projects within the IDE, or existing
projects?
Having talked a bit more with others and read a few more comments, I think
it is possible that we will change the default behavior on this in the
future.
Doug Harrison
>#1 and #2 I agree with you, but I think that #2 is more of a problem
>supporting existing source than even #1 is. A change in behavior on #2 would
>be silent, and bad.
Re #2, operator new throwing exceptions: I can't disagree, as it would break
just about every COM example I've ever seen. :( However, this rule was in
drafts dating back several years, and the longer it's put off, the more
painful it is to apply the modern rule.
>#3 I don't know enough about to comment meaningfully on.
Here's a reference to a message I wrote on this topic on 4/5/97, concerning
VC5, which I believe I also reported through the Web bug report form:
Newsgroups: microsoft.public.vc.language
Subject: VC5 Bug: Failed new returns 0 and other problems
Message-ID: <3347b663...@netnews.worldnet.att.net>
(You can find it by using Deja News Message-ID search.)
>#4 and #5: The standard really doesn't address that you must do certain
>things by default. Both of these are turned off by default because of strong
>customer comments, from customers who didn't like the increased overhead.
But for practically every project I write, I have to enable EH and RTTI.
That's especially annoying when I'm writing little command line test
programs, which I do nearly every day, because I always forget -GX. It's
less of a problem for IDE projects, but I still have to remember to enable
RTTI.
The standard defines the C++ language; EH and RTTI are optional components
to exactly the same extent if-statements are optional. That is, they aren't
optional at all. IMO, the more useful approach is to compile C++, but
provide an out for people who want to compile the leanest C++ possible, even
if it means sacrificing standard features that happen to be unnecessary for
a given project.
>#6, #7 you are correct.
>
>So, can you answer a question for me:
>
>Is your last comment referring to compliance, or to the fact that it may
>take extra effort to get your code to compile in a more compliant state?
I suppose I'm referring to both. Some things you can work around, but others
you can't. While I would prefer VC7 to compile standard C++ by default,
compared to the current situation with VC6, I'd be satisfied with some
master switch that enables it, without also disabling MS extensions that
don't conflict with it (1). Library issues such as operator new seem harder,
but I think it's very undesirable to require people to install a new-handler
to deal with it. We need an easier, more automatic solution.
(1): I wouldn't want to disable an extension that doesn't affect code that
doesn't use it. For example, allowing an array "int a[];" at the end of a
class definition is what I'd call a pure extension; it doesn't prevent
compliant code from compiling, though using it does render your code
non-compliant.
--
Doug Harrison
dHar...@worldnet.att.net
J.T. Anderson
Eric Gunnerson wrote in message ...
>
>J.T. Anderson wrote in message ...
>>
>>Eric Gunnerson wrote in message ...
>>
>>>I think it is unlikely that VC will change the default behavior on this;
>>>I'll explore getting a separate flag to control the behavior.
>>
>>
>>So, are you saying that it is unlikely that Microsoft will ever produce a
>>C++ standard compliant compiler?
>
>
>Do you think that being compliant with the standard means that the compiler
>must be fully compliant by default?
I don't know about "must", but that would certainly be my preference. I
think Doug Harrison, as usual, has it right. The default behavior should be
to correctly compile compliant programs. This doesn't preclude enabling
extensions that don't break compliant programs. Enabling old behaviors that
are contrary to the standard should require options.
>
>And what would "default" mean in that case - does it mean running the
>compiler from the command line, on new projects within the IDE, or existing
>projects?
>
Voting again, I'd say yes, compliance should be the default for CL.
Compliance should also probably be the default for the generic project types
(Win32 Application, Win32 Console Application, Win32 Dynamic-Link Library
and Win32 Static Library). The more specialized project types could set the
defaults they need, but with a preference toward compliant.
>Having talked a bit more with others and read a few more comments, I think
>it is possible that we will change the default behavior on this in the
>future.
I'm glad to hear that. Almost every version of Microsoft C/C++ that I've
used over the last 12 or so years has required some changes to some of the
old code that I deal with, as the compiler has been brought more into line
with standards or current practices. By no means do I consider this an
undue hardship.
Now, what I REALLY want to know is why VC++ 6.0 doesn't yet support
covariant return types? Is there some controversy about this too?
Eric Gunnerson
>Eric Gunnerson wrote:
>>#4 and #5: The standard really doesn't address that you must do certain
>>things by default. Both of these are turned off by default because of
strong
>>customer comments, from customers who didn't like the increased overhead.
>
>But for practically every project I write, I have to enable EH and RTTI.
>That's especially annoying when I'm writing little command line test
>programs, which I do nearly every day, because I always forget -GX. It's
>less of a problem for IDE projects, but I still have to remember to enable
>RTTI.
>
>The standard defines the C++ language; EH and RTTI are optional components
>to exactly the same extent if-statements are optional. That is, they aren't
>optional at all. IMO, the more useful approach is to compile C++, but
>provide an out for people who want to compile the leanest C++ possible,
even
>if it means sacrificing standard features that happen to be unnecessary for
>a given project.
Just remembered another reason we keep these off by default.
It is inordinately hard to get magazine reviewers to use comparable switches
when comparing compilers; they often use the product right as it comes out
of the box. If you leave EH and RTTI turned on by default, your code is
bigger and slower than without them, and unless the person running the
benchmark understands this, you look bad.
We've tried to change this, and to move from benchmarks to more reasonable
sets of code, but with little success.
Eric Gunnerson
>
>Eric Gunnerson wrote in message ...
>>
>>J.T. Anderson wrote in message ...
>>>
>>>Eric Gunnerson wrote in message ...
>>>
>>>>I think it is unlikely that VC will change the default behavior on this;
>>>>I'll explore getting a separate flag to control the behavior.
>>>
>>>
>>>So, are you saying that it is unlikely that Microsoft will ever produce a
>>>C++ standard compliant compiler?
>>
>>
>>Do you think that being compliant with the standard means that the
compiler
>>must be fully compliant by default?
>
>I don't know about "must", but that would certainly be my preference. I
>think Doug Harrison, as usual, has it right. The default behavior should
be
>to correctly compile compliant programs. This doesn't preclude enabling
>extensions that don't break compliant programs. Enabling old behaviors
that
>are contrary to the standard should require options.
See my comment to Doug elsewhere in the thread re: EH and RTTI
>>And what would "default" mean in that case - does it mean running the
>>compiler from the command line, on new projects within the IDE, or
existing
>>projects?
>>
>
>Voting again, I'd say yes, compliance should be the default for CL.
>Compliance should also probably be the default for the generic project
types
>(Win32 Application, Win32 Console Application, Win32 Dynamic-Link Library
>and Win32 Static Library). The more specialized project types could set
the
>defaults they need, but with a preference toward compliant.
>
>>Having talked a bit more with others and read a few more comments, I think
>>it is possible that we will change the default behavior on this in the
>>future.
>
>I'm glad to hear that. Almost every version of Microsoft C/C++ that I've
>used over the last 12 or so years has required some changes to some of the
>old code that I deal with, as the compiler has been brought more into line
>with standards or current practices. By no means do I consider this an
>undue hardship.
That's useful feedback; I fear that we have at times been overly influenced
by those who have complained.
>Now, what I REALLY want to know is why VC++ 6.0 doesn't yet support
>covariant return types? Is there some controversy about this too?
Not that I am aware of, and I don't have any real reason that I can tell
you.
Dennis
As I recall, when you moved from Visual C++ 2.x to Visual C++ 4.0, there
was existing code which got broken due to stricter conformance with the
standard. I can look up the specific cases if you like, although as you work
in the VC++ group, you probably know much better than I.
While it may be a contentious issue, of the sort 'should a language support
goto', it IS part of the standard.
Now, while the compiler does indeed support the standard behavior if you
disable the language extensions, it's extremely difficult to write a Windows
or MFC program with the extensions disabled :-)
While I don't like breaking existing code,
a) there's a precedent - eg the changes from 2.x to 4.x (and 5.x?)
b) executable code would be unaffected. Only during builds.
c) the users can keep the existing compiler (pre-6.x) for code that depends
on current behavior if they don't want to change.
Since you're interested in what your customers think...here's my list
a) Standards compliance and bug fixes
b) add edit and continue support for static link libs
c) proprietary changes (MFC, direct X, etc)
d) UI changes
The MAIN reason I did not upgrade to visual C++ 6.0 is that it does NOT
address standards compliance!
Dennis
Eric Gunnerson wrote in message ...
Dennis
While I understand your points, you'd look much better in your review if
they could say
"By default, Visual C++ is 100% ANSI compliant, right out of the box!" ;-)
Seriously though, I would hope that someone reviewing such a sophisticated
tool as a compiler would be much more udnerstanding of the tools being used.
If not, how could they give a good review?
Is there a 'reviewer's guide' for Visual C++?
Dennis
Eric Gunnerson wrote in message ...
Eric Gunnerson
>Put the information in the readme?
HaHaHa.
In my experience, readme information is something people look at (sometimes)
when they have a problem. The number who read them before they use the
software is small.
>
>While I understand your points, you'd look much better in your review if
>they could say
>"By default, Visual C++ is 100% ANSI compliant, right out of the box!" ;-)
>
>Seriously though, I would hope that someone reviewing such a sophisticated
>tool as a compiler would be much more udnerstanding of the tools being
used.
>If not, how could they give a good review?
I would hope, too, and some reviewers are quite good. Others...
>Is there a 'reviewer's guide' for Visual C++?
Yes. That helps, but we still run into cases where people don't know what
they're doing.
The surprising part is how rarely they will ask us for assistance.
The real driver, I think, is that most reviewers have lots of other work to
do, and it's hard work doing good comparisons of build speed, execution
speed, generated code size, etc. It's very tempting to just grab a benchmark
and say, "let's just use this".
Dennis
files for my products prior to installation :-)
So be confident that at least one person does take the effort :-)
further comments below
Regardless, it is nice to have you available to answer questions :-)
Eric Gunnerson wrote in message ...
>Dennis wrote in message ...
>>Put the information in the readme?
>
>
>HaHaHa.
>
>In my experience, readme information is something people look at
(sometimes)
>when they have a problem. The number who read them before they use the
>software is small.
>
>>
>>While I understand your points, you'd look much better in your review if
>>they could say
>>"By default, Visual C++ is 100% ANSI compliant, right out of the box!" ;-)
>>
>>Seriously though, I would hope that someone reviewing such a sophisticated
>>tool as a compiler would be much more udnerstanding of the tools being
>used.
>>If not, how could they give a good review?
>
>
>I would hope, too, and some reviewers are quite good. Others...
Hmm...and if you 'retaliate' against the 'bad' reviewers, based off
improprieties in the review, you'd appear heavy-handed and like you're
complaining about the results, and not the methodology of the test.
>
>>Is there a 'reviewer's guide' for Visual C++?
>
>Yes. That helps, but we still run into cases where people don't know what
>they're doing.
>
>The surprising part is how rarely they will ask us for assistance.
>
>The real driver, I think, is that most reviewers have lots of other work to
>do, and it's hard work doing good comparisons of build speed, execution
>speed, generated code size, etc. It's very tempting to just grab a
benchmark
>and say, "let's just use this".
And when they just do that, they do themselves, their magazine,and most
importantly, their readers a great disservice.
Doug Harrison
>Just remembered another reason we keep these off by default.
>
>It is inordinately hard to get magazine reviewers to use comparable switches
>when comparing compilers; they often use the product right as it comes out
>of the box. If you leave EH and RTTI turned on by default, your code is
>bigger and slower than without them, and unless the person running the
>benchmark understands this, you look bad.
But when the reviewer #includes <iostream> and gets a slew of C4530's, or
dynamic_casts and gets his C4541's, it can't look good, especially if he
realizes he'll have to remember to use -GX and -GR every time he needs them.
It will look really bad if he uses -GR on one module but not another,
because that can lead to "abnormal program termination" error messages when
he runs the resulting executable. IMO, the overriding concerns should be
completeness and correctness, and ideally, one should get both by default.
--
Doug Harrison
dHar...@worldnet.att.net
Ross Smith
>
>>covariant return types? Is there some controversy about this too?
>
>Not that I am aware of, and I don't have any real reason that I can tell
>you.
For what it's worth, which probably isn't much...
I use VC5 currently. I will definitely not be upgrading to VC6; it
won't gain me anything, so why bother? I might conceivably upgrade to
VC7 if it has genuine improvements, except that by then Nathan Myers
& co will probably have released Libstdc++ V3 so I'll have switched to
EGCS.
So, not putting any improvements in VC6 *has* demonstrably lost you at
least one customer. I'm probably not the only one in a similar
position.
--
Ross Smith ................................... mailto:ros...@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
* * * * *
"We're bored. We're armed. And we're off the medication."
Eric Gunnerson
>Eric Gunnerson wrote in message ...
>>J.T. Anderson wrote in message
>>
>>>Now, what I REALLY want to know is why VC++ 6.0 doesn't yet support
>>>covariant return types? Is there some controversy about this too?
>>
>>Not that I am aware of, and I don't have any real reason that I can tell
>>you.
>
>For what it's worth, which probably isn't much...
>
>I use VC5 currently. I will definitely not be upgrading to VC6; it
>won't gain me anything, so why bother? I might conceivably upgrade to
>VC7 if it has genuine improvements, except that by then Nathan Myers
>& co will probably have released Libstdc++ V3 so I'll have switched to
>EGCS.
>
>So, not putting any improvements in VC6 *has* demonstrably lost you at
>least one customer. I'm probably not the only one in a similar
>position.
If your only concern is C++ conformance, then I agree with your estimation.
But there *are* significant improvements in programmer productivity
available in VC6.
Eric Gunnerson
>>>While I understand your points, you'd look much better in your review if
>>>they could say
>>>"By default, Visual C++ is 100% ANSI compliant, right out of the box!"
;-)
>>>
>>>Seriously though, I would hope that someone reviewing such a
sophisticated
>>>tool as a compiler would be much more udnerstanding of the tools being
>>used.
>>>If not, how could they give a good review?
>>
>>
>>I would hope, too, and some reviewers are quite good. Others...
>
>Hmm...and if you 'retaliate' against the 'bad' reviewers, based off
>improprieties in the review, you'd appear heavy-handed and like you're
>complaining about the results, and not the methodology of the test.
Perhaps, although the cases in which I've been involved in it's been tough
to contact them and find out what they actually did. Most magazines are
willing to correct if they've made an error, but the original estimation was
in the middle of a big article, and the correction is buried somewhere in
the magazine.
I think this *really* sucks if your a small software company and it happens
to you.
>>
>>>Is there a 'reviewer's guide' for Visual C++?
>>
>>Yes. That helps, but we still run into cases where people don't know what
>>they're doing.
>>
>>The surprising part is how rarely they will ask us for assistance.
>>
>>The real driver, I think, is that most reviewers have lots of other work
to
>>do, and it's hard work doing good comparisons of build speed, execution
>>speed, generated code size, etc. It's very tempting to just grab a
>benchmark
>>and say, "let's just use this".
>
>And when they just do that, they do themselves, their magazine,and most
>importantly, their readers a great disservice.
I agree.
Katy Mulvey
>If your only concern is C++ conformance, then I agree with your estimation.
>But there *are* significant improvements in programmer productivity
>available in VC6.
Those improvements would be better appreciated if they weren't so
slow.
Now certainly, I don't have an absolute top-of-the-line system, but
really, a 200Mhz Pentium with 96MB of RAM running NT4 shouldn't be
so sluggish when running VC6. Some specific problems introduced with
the VC6 IDE:
* Opening files (e.g. File|Open, or double-clicking on an error
in the output window), an operation which was nearly instantaneous
in the VC5 IDE, now takes several seconds.
* Intellisense, a cool, usefull, programmer productivity feature
often takes several seconds to come up. Meanwhile, I've typed
ahead three lines of code, and have to recover from any typos
I've made after the IDE unfreezes.
* The ClassView window is sluggish. Really sluggish. It takes several
long, painful seconds to expand the tree. The tree scrolls slowly.
It's now faster to do Alt-F O "filename.h" <enter> than to find
the class name in the tree and double-click it.
* A greater proportion of the time, the IDE just loses track of
things, and double clicking on a function name in the class
view tree doesn't do anything but pop up a dialog box saying
that the definition of the function can't be found.
* The HTML help is slower than molasses in January at the North
Pole. In the VC4 IDE, help was pretty close to instantaneous.
In the VC5 IDE, and the move to HTML-based help, things slowed
down somewhat, but were still usable. Now with VC6, which uses
the full-blown HTMLHelp, you hit F1, wait three seconds for the
separate help program to launch, and another seven seconds for
the index to get loaded up. It's really, really, really slow --
slow enough to make Intellisense worthwhile... if only THAT
weren't so slow.
* Add to that not being able to copy/paste examples from the
online help, and it gets even more frustrating. (You can't
copy/paste from the regular window, and you can't copy/
paste from View Source either, because the code gets filled
with < and >).
Katy
--
Katy Mulvey Please post support questions - I won't answer emailed ones.
Software Development Engineer ORMEC Systems http://www.ormec.com
MVP/VC++ What's an MVP? See
<http://www.microsoft.com/supportnet/SupportPartners/MVPs/brochuregeneral.asp>
Eric Gunnerson
>Eric Gunnerson <ericgu@micro_nospam_soft.com> wrote:
>>If your only concern is C++ conformance, then I agree with your
estimation.
>>But there *are* significant improvements in programmer productivity
>>available in VC6.
>
>Those improvements would be better appreciated if they weren't so
>slow.
You shouldn't see the kind of slowness that you've been seeing below. For a
specific project, try deleting the classview files (.cl something), and the
.ncb files. Then restart, and see if it isn't better.
>
>Now certainly, I don't have an absolute top-of-the-line system, but
>really, a 200Mhz Pentium with 96MB of RAM running NT4 shouldn't be
>so sluggish when running VC6. Some specific problems introduced with
>the VC6 IDE:
>* Opening files (e.g. File|Open, or double-clicking on an error
> in the output window), an operation which was nearly instantaneous
> in the VC5 IDE, now takes several seconds.
>
>* Intellisense, a cool, usefull, programmer productivity feature
> often takes several seconds to come up. Meanwhile, I've typed
> ahead three lines of code, and have to recover from any typos
> I've made after the IDE unfreezes.
We are working on addressing this in future versions...
>* The ClassView window is sluggish. Really sluggish. It takes several
> long, painful seconds to expand the tree. The tree scrolls slowly.
> It's now faster to do Alt-F O "filename.h" <enter> than to find
> the class name in the tree and double-click it.
>
>* A greater proportion of the time, the IDE just loses track of
> things, and double clicking on a function name in the class
> view tree doesn't do anything but pop up a dialog box saying
> that the definition of the function can't be found.
>
>* The HTML help is slower than molasses in January at the North
> Pole. In the VC4 IDE, help was pretty close to instantaneous.
> In the VC5 IDE, and the move to HTML-based help, things slowed
> down somewhat, but were still usable. Now with VC6, which uses
> the full-blown HTMLHelp, you hit F1, wait three seconds for the
> separate help program to launch, and another seven seconds for
> the index to get loaded up. It's really, really, really slow --
> slow enough to make Intellisense worthwhile... if only THAT
> weren't so slow.
>
>* Add to that not being able to copy/paste examples from the
> online help, and it gets even more frustrating. (You can't
> copy/paste from the regular window, and you can't copy/
> paste from View Source either, because the code gets filled
> with < and >).
I apologize for these last two.
Alan Griffiths
dHar...@worldnet.att.net "Doug Harrison" writes:
> Eric Gunnerson wrote:
[snip]
>
> Re #2, operator new throwing exceptions: I can't disagree, as it would break
> just about every COM example I've ever seen. :( However, this rule was in
> drafts dating back several years, and the longer it's put off, the more
> painful it is to apply the modern rule.
Does this really affect any code - on a machine with "virtual memory" the
problem tends to occur when one tries to _use_ memory, not when reserving
some address space.
FWIW I'd much prefer the standard behaviour.
[snip]
> >#4 and #5: The standard really doesn't address that you must do certain
> >things by default. Both of these are turned off by default because of strong
> >customer comments, from customers who didn't like the increased overhead.
>
> But for practically every project I write, I have to enable EH and RTTI.
> That's especially annoying when I'm writing little command line test
> programs, which I do nearly every day, because I always forget -GX. It's
> less of a problem for IDE projects, but I still have to remember to enable
> RTTI.
Likewise, basically it is a real pain that I cannot set the defaults for
my environment (I also want "-W4 -WX" by default). I really don't care what
the "out of the box" defaults are, so long as I can configure them for my
development team, and that I can compile conforming programs (which I can't
with VC5).
I would prefer it if all the supplied headers _compiled clean_ with any
supported mode of the compiler. (I've no problem with "compiler magic" that
enables extensions in files supplied by the vendor - the standard doesn't
even requre them to be in C++.)
[snip]
> I suppose I'm referring to both. Some things you can work around, but others
> you can't. While I would prefer VC7 to compile standard C++ by default,
> compared to the current situation with VC6, I'd be satisfied with some
> master switch that enables it, without also disabling MS extensions that
> don't conflict with it (1). Library issues such as operator new seem harder,
> but I think it's very undesirable to require people to install a new-handler
> to deal with it. We need an easier, more automatic solution.
Me too.
There is nothing in VC6 that justifies the upgrade. (The proportion of code
that the code generator produces for me is small and CodeWright meets my
editing needs.)
--
Alan Griffiths | Senior Systems Consultant, Experian
alan.gr...@experian.com (agrif...@ma.ccngroup.com, Tel. +44 115 934 4517)
Jay Bazuzi
> There is nothing in VC6 that justifies the upgrade. (The proportion
> of code that the code generator produces for me is small and
> CodeWright meets my editing needs.)
Edit and Continue does it for me. It doesn't matter if you use VC
projects, makefiles, or (gasp) batch files. It works.
--
Jay Bazuzi <jba...@j.slac.com>