I am working on a C# program that produces a very large piece of C code. It produces a .c file and accompanying header file. On a very basic level, the program accepts a string from the user, then compares it to thousands of other strings that have been placed in the header file during autogen.
The header file contains over 800k lines of code and the .c file contains around 300k. As you can imagine, these are very large files. Now, I realise that having such a large file is bad coding practice. The best thing would be to break this file down into smaller files and compile it that way, but can we assume that this two file structure is necessary for how my project will be used in the grand scheme of things.
With that in mind, I’m having trouble compiling this program in the Visual Studio IDE and with the command line. Infact, that’s not entirely true. It appears to compile okay each time I try it with either method (admittedly it takes a while). However, when I come to run the program, problems develop. It reaches the input loop just fine, but after accepting user input, the program crashes with the following error:
“Unhandled exception at 0x008105f9 in Prototype.exe: 0xC0000005: Access violation writing location 0x00000000.”
I’m fairly sure this is not my code causing the problem. I have run a version of this code generated in debug mode which is a lot smaller and it runs fine. The only difference is the volume of strings that have been written to the header file by the C# program. The size of the smaller files are 14k and 5k lines respectively. Also, the IDE does not allow me to use breakpoints to debug after compiling and running with the full sized code, whereas my smaller code does.
My question would be this: Is there any limit or issue that the C language or the Visual Studio compiler has with single large files that would be causing the error above? If so, is there any way to circumvent this limit while retaining my two-file structure? I have tried increasing heap and stack sizes to 4mb in the properties dialouge, but this does not help.
I realise that this is an abnormal way to produce and run code, but I would be appreciative of any advice.
No, it is not.
Having a file with LOGIC that is MANUALL MAINTAINED like that is bad practice.
Having a hugh file of constants is ARGUABLE,
but having a generated file like that does not show up on coding practices BECAUSE YOU DO NOT CODE IT. You generate it.
There are good points in having few files for generated code, such as ease of generation. VS.ENT does that iteself – EntityFramework etc. generate ONE cs file with tons of classes, all from one input model.
Nothing documented. You likely run into a bug few people ever see. I fear you are in for a rewrite OR – a PSS Support case (Microsoft Support Services), which likely is free if you found a compiler bug.
Alternatively it MAY be your code – if your debug cases are a lot smaller, it may be your code produces an error with the full data set, which IS more likely than a compiler issue.
I would suggest you make a debug run with the FULL files, not a small set. The debugger may point you to a surprising location.