Hello,
I am having an error while compiling a program containing the same iteration variable 'i' in two different 'for' loops as in the following:
...for(int i=0;i<3;i++) {manager[i].getdata();}
...for(i=0;i<5;i++) {staff[i].getdata();}
The above code fragment compiles and runs perfectly in other compilers(VC++, Turbo C 3.0).
What is wrong with Dev-C++(4.9.9.0)
Your help is greatly appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-14
I think you should ask "wat is wrong with those other compilers" because what Dev-C++ (or more exactly GCC is doing is exactly correct. In the ISO standard, a variable declared in the initialisation statement of a for loop is in scope only within the for loop.
but this would only work correctly in ISO compliant compilers. To ensure portability, it is better to do it like:
int i ;
for(i=0;i<3;i++) {manager[i].getdata();}
for(i=0;i<5;i++) {staff[i].getdata();}
The second is better for several reasons besides portability. In ISO compliant compilers it is marginally more efficient, but more importantly in non-ISO compilers, it makes clear the scope intended of i, and moreover is more robust in the face of code maintenance. In your example, if you removed the forst loop, i would no longer be declared for the second.
Alternatively, if you have a lot of code that relies on the 'traditional' scope rule, or you don't wish to change your nasty habits, you can specify the command line option: -fno-for-scope
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That was exactly what I was looking for. I will follow your advice and forgive my 'nasty' habits because I am just a beginner to C++.
Thank you for your academic response, Clifford.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had to work through long "production" programs that had this issue in them.
Ack!
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-14
I was not intending to offend with the 'nasty habits' comment, it was not meant rhetorically not personally.
Unfortunately this style of programming is very common, because the major compiler vendors have allowed it. They are a almost a defacto standard, whereas ISO is the real standard. It is helpful to be aware of both and then code in a way that works with both.
While many code to the ISO standard with smug confidence, the day may come when they are forced either by corporate standards or compiler availability to use a less noble compiler, so coding for portability and coding to ISO standards are not the same thing. For portability ISO code is necessary, but not all ISO semantics work in non-ISO compilers. This being a common example.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is right. I started a programming course few months ago on the much obsolete Borland Turbo C++ 3.0 compiler. But most of the books I was refering use standard ANSI/ISO C++. Since I could not stand anymore the archaic text mode IDE of TC and to avoid learning the bells and wistles of MS VC++ 6.0, I went to search on the Internet for a simple and easy to learn graphical IDE. That is where I came to know about Bloodshed's Dev-C++.
I am using now Dev-C++ 4.9.8.0 which serves the purpose, despite the lack of an on-line language reference for a quick lookup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, I found Dev-C 4.9.9.0 to be much slower than 4.9.8.0 on my Compaq Presario laptop(AMD-K6, 64MB RAM,Win98). That is why I reverted to 4.9.8.0. Are there specific optimizations to make 4.9.9.0 load and compile faster?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I said "loading" I meant that launching or opening Dev-C++ 4.9.9.0 IDE takes longer than 4.9.9.8.
When I said "compile faster" I meant that I found compiling and running(F9) source codes using 4.9.8.0 to be faster than using 4.9.9.0.
You might prove otherwise but this is what I experienced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not seek to prove otherwise, simply to understand what you are telling me.
By the way, there is no 4.9.9.8 :-)
I'm kidding you!
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-15
I think waynes point was that Dev-C++ (in the sense of the whole development system, rather than just the IDE) is not a single program, it is a collection of programs (IDE, compiler, linker, resource compiler, librarian, make utility etc.). He was trying to determine which part your were finding slower, which was not clear.
Only the IDE is actually Bloodshed software, the other components are mostly part of the MinGW project, which is a Win32 native implementation of the GNU toolchain. Most users want the latest versions, and the performance may vary between releases for a number of reasons. It may be best to take this up with www.mingw.org. With respect to IDE start-up I have seen little difference.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am having an error while compiling a program containing the same iteration variable 'i' in two different 'for' loops as in the following:
...for(int i=0;i<3;i++) {manager[i].getdata();}
...for(i=0;i<5;i++) {staff[i].getdata();}
The above code fragment compiles and runs perfectly in other compilers(VC++, Turbo C 3.0).
What is wrong with Dev-C++(4.9.9.0)
Your help is greatly appreciated.
I think you should ask "wat is wrong with those other compilers" because what Dev-C++ (or more exactly GCC is doing is exactly correct. In the ISO standard, a variable declared in the initialisation statement of a for loop is in scope only within the for loop.
In your case you could change it to:
for(int i=0;i<3;i++) {manager[i].getdata();}
for(int i=0;i<5;i++) {staff[i].getdata();}
but this would only work correctly in ISO compliant compilers. To ensure portability, it is better to do it like:
int i ;
for(i=0;i<3;i++) {manager[i].getdata();}
for(i=0;i<5;i++) {staff[i].getdata();}
The second is better for several reasons besides portability. In ISO compliant compilers it is marginally more efficient, but more importantly in non-ISO compilers, it makes clear the scope intended of i, and moreover is more robust in the face of code maintenance. In your example, if you removed the forst loop, i would no longer be declared for the second.
Alternatively, if you have a lot of code that relies on the 'traditional' scope rule, or you don't wish to change your nasty habits, you can specify the command line option: -fno-for-scope
Clifford
That was exactly what I was looking for. I will follow your advice and forgive my 'nasty' habits because I am just a beginner to C++.
Thank you for your academic response, Clifford.
It is not that academic an issue.
I have had to work through long "production" programs that had this issue in them.
Ack!
Wayne
I was not intending to offend with the 'nasty habits' comment, it was not meant rhetorically not personally.
Unfortunately this style of programming is very common, because the major compiler vendors have allowed it. They are a almost a defacto standard, whereas ISO is the real standard. It is helpful to be aware of both and then code in a way that works with both.
While many code to the ISO standard with smug confidence, the day may come when they are forced either by corporate standards or compiler availability to use a less noble compiler, so coding for portability and coding to ISO standards are not the same thing. For portability ISO code is necessary, but not all ISO semantics work in non-ISO compilers. This being a common example.
Clifford
That is right. I started a programming course few months ago on the much obsolete Borland Turbo C++ 3.0 compiler. But most of the books I was refering use standard ANSI/ISO C++. Since I could not stand anymore the archaic text mode IDE of TC and to avoid learning the bells and wistles of MS VC++ 6.0, I went to search on the Internet for a simple and easy to learn graphical IDE. That is where I came to know about Bloodshed's Dev-C++.
I am using now Dev-C++ 4.9.8.0 which serves the purpose, despite the lack of an on-line language reference for a quick lookup.
"I am using now Dev-C++ 4.9.8.0"
hmm... in case you didnt notice. Dev-C++ 4.9.9.0 has been out for a while.
It uses GCC 3.3.1 instead of GCC 3.2.x though.
By the way, I found Dev-C 4.9.9.0 to be much slower than 4.9.8.0 on my Compaq Presario laptop(AMD-K6, 64MB RAM,Win98). That is why I reverted to 4.9.8.0. Are there specific optimizations to make 4.9.9.0 load and compile faster?
"I found Dev-C 4.9.9.0 to be much slower than 4.9.8.0 on my Compaq Presario laptop"
Slower in what way? What do you mean by load and compile faster? Specifics can really help us check on things better.
Wayne
When I said "loading" I meant that launching or opening Dev-C++ 4.9.9.0 IDE takes longer than 4.9.9.8.
When I said "compile faster" I meant that I found compiling and running(F9) source codes using 4.9.8.0 to be faster than using 4.9.9.0.
You might prove otherwise but this is what I experienced.
I do not seek to prove otherwise, simply to understand what you are telling me.
By the way, there is no 4.9.9.8 :-)
I'm kidding you!
Wayne
I think waynes point was that Dev-C++ (in the sense of the whole development system, rather than just the IDE) is not a single program, it is a collection of programs (IDE, compiler, linker, resource compiler, librarian, make utility etc.). He was trying to determine which part your were finding slower, which was not clear.
Only the IDE is actually Bloodshed software, the other components are mostly part of the MinGW project, which is a Win32 native implementation of the GNU toolchain. Most users want the latest versions, and the performance may vary between releases for a number of reasons. It may be best to take this up with www.mingw.org. With respect to IDE start-up I have seen little difference.
Clifford