MSVC++ Grammar issues?!?!
has anybody EVER experienced a problem with MS visual c++ finding errors in your code? for example my program is console based and can output anything just fine except ONE LINE of code. the program crashes on some weird things like if there is an extra space between "<< endl;" or something like it. everything compiles fine. my program just crashes. any ideas? should i reinstall msvc++?
Sometimes if you are playing with pointers and manage to
corrupt your heap, the program will crash in odd places seemingly
unrelated to your code. Say, if you allocate memory in a constructor
and declare a global object as follows:
I did this once, and my program crashed when I stepped into a totally
unrelated and very inane looking line of code. Took quite awhile to find
the error, since I was not aware of this behavior in global objects.
corrupt your heap, the program will crash in odd places seemingly
unrelated to your code. Say, if you allocate memory in a constructor
and declare a global object as follows:
class CMyClass {public: int *Data; MyClass() { Data = new int[50]; }};// Global Declaration //CMyClass MyObject; // <-- Badness ensues since MyObject.Data // // not actually alloc'd //
I did this once, and my program crashed when I stepped into a totally
unrelated and very inane looking line of code. Took quite awhile to find
the error, since I was not aware of this behavior in global objects.
If you post the code here, we can take a look at it. You can try reinstalling MSVC++, but chances are very high that your code is at fault rather than the compiler. The chances of something that particular messing up in an install is highly unlikely :-) It probably just appears that an extra space causes the error, when in fact it may just be a seg fault that occurs randomly due to an error elsewhere in your code. To make sure this is the case, try the most basic of program (eg such a cout) and see if it induces the space error consistently.
This probably also belongs in a more appropriate forum, such as General Programming.
This probably also belongs in a more appropriate forum, such as General Programming.
<not directly relating to the OP's question>
Global objects will be instantiated properly. The problem here is likely that you had a second static object depend on MyObject being initialised. Static initialisation order between translation units is not defined.
Under BCC if I compile (after adding a main function) as:
I get the output 7, but if I compile as:
I get an illegal operation, because the Borland compiler happens to instantiate global objects in the order it sees them. Therefore if I compile file1.cpp before file2.cpp then object1 is instantiated before object 2, but if I compile file2.cpp before file1.cpp then object2 is instantiated before object1. Since object2 depends on object1 being instantiated this causes a run-time error.
</not directly relating to the OP's question>
OP: Is your code entirely deterministic? I.e. does it always have exactly the same data, with nothing that could vary between runs (time, user input, random numbers etc.). If so, then I would recommend a reinstall, since fully deterministic programs should be identical regardless of whitespace in the source. If it's not fully deterministic then you've almost certainly got a heap or stack corrupting bug in there somewhere. I believe Visual C++ should be able to catch these in debug mode (don't use it, so I don't know the details).
Enigma
Quote:
Original post by Cryoknight
Sometimes if you are playing with pointers and manage to
corrupt your heap, the program will crash in odd places seemingly
unrelated to your code. Say, if you allocate memory in a constructor
and declare a global object as follows:class CMyClass {public: int *Data; MyClass() { Data = new int[50]; }};// Global Declaration //CMyClass MyObject; // <-- Badness ensues since MyObject.Data // // not actually alloc'd //
I did this once, and my program crashed when I stepped into a totally
unrelated and very inane looking line of code. Took quite awhile to find
the error, since I was not aware of this behavior in global objects.
Global objects will be instantiated properly. The problem here is likely that you had a second static object depend on MyObject being initialised. Static initialisation order between translation units is not defined.
// file1.hclass Test1{ public: Test1() : pointer(new int) { *pointer = 7; } int* pointer;};extern Test1 object1;// file2.h#include <iostream>#include "file1.h"class Test2{ public: Test2(Test1 object) : pointer(object.pointer) { std::cout << *pointer << '\n'; } int* pointer;};// file1.cpp#include "file1.h"Test1 object1;//file2.cpp#include "file2.h"Test2 object2;
Under BCC if I compile (after adding a main function) as:
bcc32 file1.cpp file2.cpp
I get the output 7, but if I compile as:
bcc32 file2.cpp file1.cpp
I get an illegal operation, because the Borland compiler happens to instantiate global objects in the order it sees them. Therefore if I compile file1.cpp before file2.cpp then object1 is instantiated before object 2, but if I compile file2.cpp before file1.cpp then object2 is instantiated before object1. Since object2 depends on object1 being instantiated this causes a run-time error.
</not directly relating to the OP's question>
OP: Is your code entirely deterministic? I.e. does it always have exactly the same data, with nothing that could vary between runs (time, user input, random numbers etc.). If so, then I would recommend a reinstall, since fully deterministic programs should be identical regardless of whitespace in the source. If it's not fully deterministic then you've almost certainly got a heap or stack corrupting bug in there somewhere. I believe Visual C++ should be able to catch these in debug mode (don't use it, so I don't know the details).
Enigma
I've barely looked at it and have found three problems:
should be
fstream.h and iomanip.h are not a part of the C++ standard. They are an implementation detail for your particular compiler. The proper headers are fstream and iomanip. Similarly stdio.h and stdlib.h were superceeded in C++ by cstdio and cstdlib.
You use std::cout but never include iostream. If appears that in your implementation one of the other headers you are including is itself including iostream. You should not depend on this.
This is an error. I'm guessing you're using MSVC++ 6? If you're using version 7 please find and turn on conformant for loop behaviour. A variable defined in a for loop is local to the loop according to the standard. A workaround that will work on conforming and nonconforming compilers is to predeclare the variable:
While I'm at it, typedef'd structs are redundant in C++. You can use the struct name without having to use the struct keyword.
I'll post back if I find any other errors.
Enigma
#include <iomanip.h>#include <conio.h>#include <stdio.h>#include <stdlib.h>#include <fstream.h>#include <vector>
should be
#include <iomanip>#include <conio.h>#include <cstdio>#include <cstdlib>#include <fstream>#include <vector>
fstream.h and iomanip.h are not a part of the C++ standard. They are an implementation detail for your particular compiler. The proper headers are fstream and iomanip. Similarly stdio.h and stdlib.h were superceeded in C++ by cstdio and cstdlib.
You use std::cout but never include iostream. If appears that in your implementation one of the other headers you are including is itself including iostream. You should not depend on this.
for(int x=0; x<mesh.NumVert; x++) cout << mesh.Vert[x].x << ' ' << mesh.Vert[x].y << ' ' << mesh.Vert[x].z << endl; cout << "indices:\n"; for(x=0; x<mesh.NumFace; x++) cout << mesh.Face[x].x << ' ' << mesh.Face[x].y << ' ' << mesh.Face[x].z << endl;
This is an error. I'm guessing you're using MSVC++ 6? If you're using version 7 please find and turn on conformant for loop behaviour. A variable defined in a for loop is local to the loop according to the standard. A workaround that will work on conforming and nonconforming compilers is to predeclare the variable:
int x; for(x=0; x<mesh.NumVert; x++) cout << mesh.Vert[x].x << ' ' << mesh.Vert[x].y << ' ' << mesh.Vert[x].z << endl; cout << "indices:\n"; for(x=0; x<mesh.NumFace; x++) cout << mesh.Face[x].x << ' ' << mesh.Face[x].y << ' ' << mesh.Face[x].z << endl;
While I'm at it, typedef'd structs are redundant in C++. You can use the struct name without having to use the struct keyword.
I'll post back if I find any other errors.
Enigma
Another big problem that isn't causing your crash, plus the cause of your crash:
What do you think is going to happen when I enter this_is_a_very_long_filename_for_a_file_which_probably_doesnt_exist_but_thats_not_the_point_now_really_is_it_I_just_want_your_code_to_fall_over_and_die_If_I_was_feeling_really_horrible_I_could_try_and_insert_some_instructions_here_to_really_test_if_you_have_a_security_leak.txt?
You're indexing into vert_face[y] even though vert_face[y] has not been resized. You're also calling the capacity() member function, when you should be using size() and you should be indexing with size() - 1 if you want the last element.
I'm going to rewrite your code for you in full C++ rather that the C with a little bit of C++ that you're using just so you can see how much cleaner it is.
Enigma
char filename[256]; printf("input a filename with extension...\n"); scanf("%s", filename);
What do you think is going to happen when I enter this_is_a_very_long_filename_for_a_file_which_probably_doesnt_exist_but_thats_not_the_point_now_really_is_it_I_just_want_your_code_to_fall_over_and_die_If_I_was_feeling_really_horrible_I_could_try_and_insert_some_instructions_here_to_really_test_if_you_have_a_security_leak.txt?
if(mesh.Face[y].x == x) { vert_face.resize(vert_face.capacity()); vert_face[y][vert_face.capacity()] = x; } if(mesh.Face[y].y == x) { vert_face.resize(vert_face.capacity()); vert_face[y][vert_face.capacity()] = x; } if(mesh.Face[y].z == x) { vert_face.resize(vert_face.capacity()); vert_face[y][vert_face.capacity()] = x; }
You're indexing into vert_face[y] even though vert_face[y] has not been resized. You're also calling the capacity() member function, when you should be using size() and you should be indexing with size() - 1 if you want the last element.
I'm going to rewrite your code for you in full C++ rather that the C with a little bit of C++ that you're using just so you can see how much cleaner it is.
Enigma
Oh, and one more thing:
is not a valid entry point in C++. Use
or
or equivalents.
Enigma
void main()
is not a valid entry point in C++. Use
int main()
or
int main(int argc, char** argv)
or equivalents.
Enigma
WOW!!! i never realized how f***ed up my code really was?!?! i took 2 compsci class 3 years ago and my teachers NEVER told us the importance behind using the right datatypes. on top of that i have had to teach myself traditional c like using printf instead of cout.
thank you guys SOOO much!
if any of you guys realize what i have going on in my function CalVertexNormals, and could offer any more optimization suggestions, PLEASE TELL ME!
thank you guys SOOO much!
if any of you guys realize what i have going on in my function CalVertexNormals, and could offer any more optimization suggestions, PLEASE TELL ME!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement