Dev C++ Compiler Hangs

[David]

Hi there, I've started using Dev C++ in the last couple of days. I normally use VS2005, but I wanted to play with Dev C++ because it seems simpler and has a profiler (VS2005 doesn't).

I have a large data structure (a C++ class that has several large data members which themselves are classes). One member of this class is an array of objects and it has 3 million entries. i.e. an array of 3 million structures each of which is 78 bytes big.

So this is trying to dynamically allocate around 176 MB for this particular array. With the other bits I am using around 500 MB all up. I have 1GB of RAM.

The problem is not with running the code tho, it's with compiling it! If I set the array size down to say 30,000, everything complies and runs well (and I can solve some small problems). If I increase the array length to 300,000 or what i really want, 3,000,000, the complier hangs. It grabs around 750MB of memory (I can see the compiler process in the Task Manager) and hangs. I have waited for 1/2 an hour, no joy. It does this every time. I have to end the process in the Task Manager to stop it. Pressing the cancel button doesn't help.

By way of providing more info: What I'm doing is an A* search. The long array is the open list. Each entry on the open list is a state from a search tree. I can post sample code if that would help.

If anyone has had any similar problems, any help would be appreciated.

[David]

Soma, thanks very much for trying.

I'll try to get a newer compiler and see how I go.

[David]

Hi all, I have managed to sort this out.

It appears there is a limit on the size of any 1 object in Dev C++ (or more accurately I suspect, MinGW's g++). I think it may be 2^16 i.e. 65536 bytes. This is for stack based objects.

So what I did was just dynamically allocate my open list array (3 million entries each 78 bytes = approx 176 MB) and it all works hunky dory.

So the outstanding issues are:
1) The compiler should report an error, not hang.
2) This limitation doesn't seem to be documented anywhere (unless I just haven't found it!).

Cheers

David

[Wayne Keen]

David,

Keep in mind we do not put out the compiler, we just use it.

:)

Wayne

[David]

Yes, I understand, ta.

Dev C++ is actually really good. I have been very impressed with it so far.

[Wayne Keen]

I made that point because there are in fact a number of folks
who post here who think that we produce the "Dev-C++ compiler"
There are even those that seem to think that there is a Dev-C++
language. They don't realize that Dev-C++ is just an IDE, and
that GCC is the compiler - so I repeat myself a lot in the hope
that people read it who stop in on threads like this.

Wayne

[Anonymous]

>> I wanted to play with Dev C++ because it seems simpler and has a profiler (VS2005 doesn't).

I would say that a decent debugger is worth more and VC++ has one, Dev-C++'s is not worth s**t. It is simpler though ;)

>> I can post sample code if that would help.

Yes it would help. Make it as simple as possible, the smallest amount of code that reproduces the problem.

>> It appears there is a limit on the size of any 1 object in Dev C++
>> (or more accurately I suspect, MinGW's g++). I think it may be 2^16 i.e.
>> 65536 bytes. This is for stack based objects.

The stack is a limited resource regardless of which compiler you use. In Windows the total stack size is typically 2Mb, so your array would always blow the stack. But this should cause a runtime error not a compiler problem. You really need to post the code so we can reproduce this. You saud each object was just 78 bytes, where did the >65536 object come from.

>> So what I did was just dynamically allocate my open list array
>> (3 million entries each 78 bytes = approx 176 MB) and it all works hunky dory.

You said in your original post that they were dynamically allocated - what's different now!?

You could have cleared this up much faster if you had posted the code, but several things about your assertions do not ring true. You are right the compiler should not hang even if creating a 176Mb array on the stack is a dumb idea (on any platform or compiler) - the compiler knows nothing about such runtime restrictions. Post some code so we can verify your finding.

>> 1) The compiler should report an error, not hang.

Yes, but until you post an example, we cannot reproduce the problem.

>>2) This limitation doesn't seem to be documented anywhere (unless I just haven't found it!).
It is a normal limitation in any C/C++ compiler. The stack is a resource that is allocated to a process for the entire time that process is running regardless of actual usage. Imagine if all processes required a 200Mb stack; you would not be able to run very many! Most processes get a moderately large stack of about 2Mb. Take a look at the Task manager process list, you will see that few processes have a memory usage much less than 2Mb regardless of how simple they are! Some compilers allow you to set a processes stack size, but even then setting it to an arbitrarily large size is not good practice, it does not play well with other processes and is likly to cripple your system with constant disk swapping. I don't think GCC supports setting the stack size.

I dont't recognise your suggested 2^16 limitation - what drew you to that conclusion; again post the code!

Clifford

[Anonymous]

PS, use a std::vector object instead of an array and your problem will also go away. The vector object can be on the stack since the object manages its own memory by dynamically the necessary space. It is a good idea to pre-specify the necessary capacity otherwise it may cause a lot of memory thrashing.

Clifford

[David]

Clifford:

1) Yes you're right I did initially say I was dynamically allocating this array. That was a mistake. It was initially statically allocated, I have now changed it to dynamic. I must have been tired when I wrote that. I also got the size wrong because it's around 223 MB.
2) I came to the 2^16 limitation thru trial and error. This was with the statically allocated array. I just kept changing the size of the array upwards and downwards (like a binary search) until I found it would compile at 64,500 elements, but no higher. I remember reading somewhere recently that the gcc compiler (which is C) can only handle objects 65,536 in size. Not sure where I read this or how accurate it is. I'm also using g++ which is a different kettle of fish and of course my array is of objects so the total size is way bigger than 65,536 but it does seem suspicious that i can get very close to this figure, but no higher. I could be quite wrong about this I guess.
3) Stack size: I have always assumed the stack size would be adjusted by the compiler at compile time. So if it detects that you're declaring large objects, it just increases the stack size to match. This code works in VS2005 and I don't have to set any stack size parameters etc. Interestingly I have other quite large objects in this program decalared statically which seem to be OK.
4: Code: I can't post it all, it's quite long but I can post the offending .h and .cpp file. Openlist.h and Openlist.cpp. I'll have to change them back to how they were and post them here. Just simply compiling Openlist.cpp will reproduce it the problem. What is the best way to post code here?

[David]

Clifford:

1) Yes you're right I did initially say I was dynamically allocating this array. That was a mistake. It was initially statically allocated, I have now changed it to dynamic. I must have been tired when I wrote that. I also got the size wrong because it's around 223 MB.
2) I came to the 2^16 limitation thru trial and error. This was with the statically allocated array. I just kept changing the size of the array upwards and downwards (like a binary search) until I found it would compile at 64,500 elements, but no higher. I remember reading somewhere recently that the gcc compiler (which is C) can only handle objects 65,536 in size. Not sure where I read this or how accurate it is. I'm also using g++ which is a different kettle of fish and of course my array is of objects so the total size is way bigger than 65,536 but it does seem suspicious that i can get very close to this figure, but no higher. I could be quite wrong about this I guess.
3) Stack size: I have always assumed the stack size would be adjusted by the compiler at compile time. So if it detects that you're declaring large objects, it just increases the stack size to match. This code works in VS2005 and I don't have to set any stack size parameters etc. Interestingly I have other quite large objects in this program decalared statically which seem to be OK.
4: Code: I can't post it all, it's quite long but I can post the offending .h and .cpp file. Openlist.h and Openlist.cpp. Compiling Openlist.cpp with reproduce the problem. What is the best way to post code? Just paste it in?

[David]

Sorry for the double post.

PS: I dont' want to use a STL vector because as you point out it will be allocating memory all the time. And if I tell it how big to make itself from the start, then this is no different to just statically allocating the large array anyway.

[Anonymous]

1) Statically allocated would have been ok as well. There three forms of memory allocation, static, dynamic, and automatic. Local variables are by default auto variables - stored on the stack. Statically variables are either globals or explicitly defined using the static keyword.

2) Ah - 2^ elements, not 2^16 bytes. Now if your elements were 78 bytes and you had 2^16 elements, that is nearly 5Mbytes. Now statically allocated that should be OK (if not necessarily good practice), but you seem confused about the terms static, dynamic, and automatic, and if the array was an auto array it would be expected to fail.

3) No it won't. The compiler cannot predict maximum stack size without some very complex and expensive static analysis, and even then it would have to assume worst case possible calling patterns - which if you have recursive function calls code could be very large. Moreover if the code were multi-threaded it becomes more complex - the compiler is not aware of threads and the effect one might have on another.

4) You don't need to post it all. If it always hangs when you allocate a large array of elements of a certain size, it would not be too hard to devise a simple example of just that. I would also like to see an example of a large array that fails at 2^16 elements.

For example, the following code compiles and runs without error:

include <stdlib.h>

struct element
{
char x[78] ;
} ;

static element y[1024*64] ;

int main()
{
y[0].x[0] = 1 ;
system( "pause" ) ;

return 0;
}

However, if the array is changed to

static element y[1024 * 1024 * 27] ;

wheras,

static element y[1024 * 1024 * 26] ;

is OK

it yields a "size of variable 'y' is too large" error message. Now that is far larger than 64k lements (in fact 26M elements), or nearly 2Gb. Given the architecture of the x86 processor and memory management in the Windows OS, I would suggest that the size limit for a single element is 2Gb, which sounds far more likely.

So the conclusion must be that whatever is happening in your case is unique to you. Without an example that reproduces the error or some information about how your development environment differs from the norm, you probably cannot be helped.

Re. vector - it is better for many reasons.

Clifford

[David]

OK Clifford:

Yes I was thinking last night that I could create a simpler example too. So I have done this. Create a console app and add the following code. It consists of 5 small files:

//**********
//**********
// Main.cpp: Test main. Shows MinGW g++ compiler hang.
//
//**********
//**********

include <vector>

using namespace std;

include "GameState.h"

include "OpenList.h"

int main(int argc, char *argv[])
{

COpenList theOpenList;
theOpenList.Initialise();

system("PAUSE");
return EXIT_SUCCESS;

}

//***********
//***********

//************
//************
// OpenList.cpp: Implementation of the COpenList class.
// Created by DNB 12Jan07:
//
//************
//************

include <vector>

using namespace std;

include "GameState.h"

include "OpenList.h"

//************
// Constructor
// Initialise class data members
//************
COpenList::COpenList()
{
} // Constructor

//************
// Destructor
//************
COpenList::~COpenList()
{
} // Destructor

//************
// Init data members.
//************
bool COpenList::Initialise()
{
} // Initialise

//************
//************

//************
//************
// OpenList.h: Interface for the COpenList class.
// Created by DNB 12Jan07:
//
//************
//************

pragma once

//************
// Class COpenList
//************
class COpenList
{
// Enums
public:
enum OPEN_LIST_ENUMS { OPEN_LIST_LENGTH = 3000};

// Data Members

public:
CGameState m_OpenList[OPEN_LIST_LENGTH];

// Methods

public:
COpenList();
~COpenList();

bool Initialise();

};
//************
//************

//************
//************
// GameState.cpp: implementation of the CGameState class.
// Created by DNB 11Mar03:
//
//************
//************

include <vector>

using namespace std;

include "GameState.h"

//************
// Constructor
// Initialise class data members
//************
CGameState::CGameState()
{
// Member m_Moves initialised already.

} // Constructor

//************
// Destructor
//************
CGameState::~CGameState()
{
} // Destructor

//************
//************

//************
//************
// GameState.h: interface for the CGameState class.
// Created by DNB 12Mar03:
//
//************
//************

//************
// Class CGameState
//*************
class CGameState
{

// Data Members
public:

vector <char> m_Moves;            // A list of moves taken to get to this state.

// Methods
public:
CGameState();
~CGameState();

};

The program is greatly pared down for space reasons, so it doesn't do anything. It just declares a variable of type COpenList.

The length of the open list (in OpenList.h) is set to 3000. This compiles and runs. If you change the length of the open list to 30,000, everything is fine, it still compiles and runs. If you change the length to 300,000, this does not compile and the only error message is: "C:\Documents and Settings\123\My Documents\DEVC++ Projects\Test2\Makefile.win [Build Error] [main.o] Error 1 " Which is not terribly helpful.

AND, if you change the open list length to 3,000,000 the compiler hangs. BTW I am running windows XP SP2. I have Dev C++ version 4.9.9.2.

Note also that whenever I build, I use Ctrl+F11 i.e. full rebuild. If you change the enum and hit F9, it doesn't do the full recompile and so you're just running the last fully built exec.

Also note that the size of elements in the open list array are now smaller, and so the overall open list size I previously reported etc. would be smaller. I pruned out other bits to make the code as small as possible whilst still exhibiting the behaviour I was talking about.

If you remove the vector from the CGameState class, and change it to a standard C++ array, all the compiler problems go away... but I want a vector there...

[Anonymous]

Don't put your project in "C:\Documents and Settings\123\My Documents\DEVC++ Projects", spaces in paths can trip the make utility. You would have been told this in the "PLEASE READ BEFORE POSTING A QUESTION" thread.

Earlier you said "the complier hangs", now you are suggesting that it reports an error message, which can only occur if teh build finished (i.e. does not hang!). Which is it!?

The "[Build Error] [main.o] Error 1" message merely indicates that a command issued by make has failed. Normally the command that failed will have issued its own error message, and this will appear earlier in teh log. You are supposed to read the log from top-to-bottom. That said, with spaces in your project path, all bets are off, and you may indeed see no error message.

You will have also read in "PLEASE READ BEFORE POSTING A QUESTION" that you should post the entire log, not just that part you regard as important. If you knew that you might not have the problem! Posting the log is the most often fastest way to get a problem solved; I never asked before because you said it hung, so I assumed you had no log to post!

BTW "5 small files" is hardly simple - it is asking people to work much harder. Generally we should be able to copy & paste to a single empty file and build. I might take a look at the five files, but at the moment cannot take the time. However for the time being I note that theOpenList is an auto variable of a class containing a large array - so the large array is on the stack (not statically or dynamically allocated). This is not necessarily a problem, but is not what you said earlier.

Clifford

[Anonymous]

Ok, your code as one file looks like this:

---

include <vector>

using namespace std;

class CGameState
{

// Data Members
public:

vector <char> m_Moves; // A list of moves taken to get to this state.

// Methods
public:
CGameState();
~CGameState();

};

CGameState::CGameState()
{
// Member m_Moves initialised already.

} // Constructor

CGameState::~CGameState()
{
} // Destructor

class COpenList
{
// Enums
public:
enum OPEN_LIST_ENUMS { OPEN_LIST_LENGTH = 3000};

// Data Members
public:
CGameState m_OpenList[OPEN_LIST_LENGTH];

// Methods
public:
COpenList();
~COpenList();

bool Initialise();

};

COpenList::COpenList()
{
} // Constructor

COpenList::~COpenList()
{
} // Destructor

bool COpenList::Initialise()
{
} // Initialise

int main(int argc, char *argv[])
{

COpenList theOpenList;
theOpenList.Initialise();

system("PAUSE");
return EXIT_SUCCESS;
}

---

Before we continue you should tell me if that fails to build for you. Here it gives:

---

Compiler: Default compiler
Building Makefile: "C:\projects\Makefile.win"
Executing make clean
rm -f main.o Project1.exe

g++.exe -D__DEBUG__ -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -Wextra -Wall -Wformat -g3

main.cpp: In member function `bool COpenList::Initialise()':
main.cpp:60: warning: control reaches end of non-void function
main.cpp: At global scope:
main.cpp:63: warning: unused parameter 'argc'
main.cpp:63: warning: unused parameter 'argv'

g++.exe -D__DEBUG__ main.o -o "Project1.exe" -L"C:/Dev-Cpp/lib" -Wl,-Map,mapfile.map -g3

Execution terminated

It is a good idea to post clean code without warnings - but I guess you got no warnings!? If it works, it has nothing to do with the code and you should post the log from your five file version.

I took another look at your code, #pragma directives are compiler specific, unrecognised pragmas are simply ignored. I am not sure that #pragma once is recognised by GCC; you should use portable include guards using standard pre-processor constructs. Also if you use a symbol such as vector in a header you should include the appropriate header in the header rather than assume the including source has done it for you. You should also not assume the including source has declared "using namespsce std ;" and use explicit scope resolution (e.g. std::vector) in the headers. This will make your headers portable and safe. Moving symbols to teh global namespace in a header also does so fro all the code that follows the inclusion - which rather misses the point of namespaces.

Clifford

[David]

Yeah Clifford, you haven't read my post. And your comments are opinions, not fact. If you don't want to help, don't.

1) Whether the compiler completes with no errors, completes with errors or indeed hangs, depends on the length you give the open list as I did in fact state quite plainly above.
2) You said you wanted the code, now you're complaining about it being 5 very small (tiny in fact) files instead of one. I pared this down from several thousand lines, all the time checking the problems were still occurring. It took several hours. It would have taken you a few minutes to create a project and add the code as 5 small files.
3) I don't get any errors ir warnings when compiling with the open list size set to 3000. So it compiles cleanly.
4) The spaces in my project path? Well ok. Has absolutely nothing to do with the cause(s) of the error I'm trying to point out, but I agree it is mentioned in the "posting good questions" section.
5) I've been programming for years and know all about header file inclusion and namespace pollution. I don't need advice in this regard thanks. I have it this way on purpose. I'm also not porting the code anywhere else, so I don't need portability thanks.
6) There are only 2 places variables are located in Windows. On the stack or on the heap. Static/Automatic are on the stack, dynamically allocated variables are on the heap. I know this, you know this, why split hairs?
7) Compile logs: I didn't include them because they show nothing useful. Here is the compile log for the above single file piece of code, in a directory with no spaces, with the open list set to 3000, 30,000, 300,000 and 3,000,000:

3000:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

make.exe: *** [Test3/main.o] Error 1

Execution terminated

30,000:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

g++.exe Test3/main.o -o "Test3.exe" -L"C:/Dev-Cpp/lib"

Execution terminated
Compilation successful

300,000:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

make.exe: *** [Test3/main.o] Error 1

Execution terminated

3,000,000: After I have halted the cc1plus.exe process in the task manager:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

make.exe: *** [Test3/main.o] Error 1

Execution terminated

And yes it still hangs! Try it for yourself.

David

[Nobody/Anonymous]

"If you don't want to help, don't."

Clifford offered a solution, the correct one as it happens, to the root of the problem ages ago. That you refuse to accept it makes you a fool.

"I dont' [...] large array anyway."

Are you sure you've been coding for years? Only a newbie would think this and explains why you have this "problem".

"You said [...] occurring. It took several hours."

The fact that I had no intention of examining this issue further, solved with competence in the seventh post, until Clifford's post of your source says a lot.

"There are [...] why split hairs?"

C++ has five distinct memory areas. Not two. Not three.

"I've been [...] portability thanks."

And yet, by using such dissimilar compilers as MSVC2k5 and GCC 3.4.2 you will have to deal with portability issues.

"And yes it still hangs! Try it for yourself."

No, it doesn't. Try it for yourself. (For the completely bloody stupid in the audience, it isn't actually hanging. The problem as presented is irrelevant because the version of GCC in question will eventually crash and the executable from the source in question will very likely crash if normally compiled with any other compiler, including recent versions of GCC.)

For the recored, the memory area associated with a C++ object has to do with when and how the object is created and destroyed.

Soma

[David]

For an open list of length 300 the compile log is in fact:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

g++.exe Test3/main.o -o "Test3.exe" -L"C:/Dev-Cpp/lib"

Execution terminated
Compilation successful

[David]

Soma:

I was merely trying to point out a bug with the compiler. I realise this is not a Dev C++ issue so much as a GCC issue, however I thought it might be something I was doing and/or people in this community might be interested in seeing this. Obviously not. What a bunch of defensive, pedantic types you are here!

I regularly post on other C++ forums, mostly helping others but also seeking help from time to time. I haven't seen this sort of hostility and "I know better than you..." kind of attitude anywhere.

The complier definitely hangs for me on my machine. I have never seen this before in around 20 years of programming (I've been a hobyist for the last 7).

I found the solution to this myself, which I explained, I can just dynamcially create the array (using new) BUT the issue is even if I'm being dumb and trying to create a large array in some other way, the compiler should not hang. Whatever I do, the compiler should not hang. And also errors like "make.exe: *** [Test3/main.o] Error 1" aren't a whole lot better.

In the short time I've been using DevC++ I've noticed a few other things that need fixing (definitely DevC++ IDE related) which I was going to point out. But I won't now as I'll just get slammed and/or told I don't know what I'm doing. Fine. It's all perfect, keep your heads in the sand you bunch of insular know it alls.

[Anonymous]

I am posting what I believe to be the solution ahead of other comments, because I am about to counter your rudeness with extreme vitriol and you may otherwise stop reading before you get to the answer which would be a shame:

The problem is that you have created your projects in a sub-folder of c:\dev-cpp, and for a reason that is a complete mystery to me this sometimes but not always causes Dev-C++ to behave in this way. It is a known problem, it probably should be in the "Read First" thread, but is probably not. Had you posted the logs (the ones that "show nothing useful" according to you), I would have spotted it immediately. This is an apparent bug in Dev-C++ and is very strange, however it is a bad idea in any case IMO - after all you would not keep your Word documents in MS Office's installation folder would you!?

The failure to build probably has little or nothing to do with array size since despite your assertions the log you posted for '3000' clearly shows a build failure. As I said it sometimes but not always fails an the array size changes may have been merely coincidence, and any (or no) change may have triggered the problem.

Regarding your dumb comments:

1) No, you said "If you change the length to 300,000, this does not compile and the only error message is: "C:\Documents and Settings\123\My Documents\DEVC++ Projects\Test2\Makefile.win [Build Error] [main.o] Error 1 " Which is not terribly helpful. ". Nothing about hanging there, and you did not post the full log which was rather my point. It seem it is you that does not want help rather than me not helping. I thought that was exactly what I was trying to do. I was merely trying to clarify an apparent inconsistency. I cannot read minds or see what you are seeing, flying blind needs accurate and clear information. If it is not clear to me for whatever reason be it stupidity or language or semantics or whatever, it is in your interest to make it so, "Sorry perhaps I was not clear" will get you much further than "you haven't read my post". You can be a diplomat or an arrogant tosser, but I can assure you that I will give it back while at the same time managing to maintain my credibility.

2) No because creating a single blank file is a breeze, creating 5 separate files and adding them to a project, naming them, creating a folder to put them etc. is a relative pain. You are expecting free help from volunteers. If I decide it is too much effort, I am under no obligation to do anything, so it pays you to make it as easy as possible. I keep a project specifically for testing posted code - it has one file, I just replace the code as necessary.

3) Lucky you, that's not what I asked. The log for anything that fails is what I was after. Incidentally the log you posted for 3000 clearly shows it failing to build. I wonder how you missed that!?

4) How do you know that? Given the probable cause of this problem, I would suggest that all bets are off - weird bugs happen. The point is that the best way forward is to remove all the known potential problems so that you can concentrate on the real problem confident that it is a new or unique issue and not a side effect of a known issue.

5) Yeah right!? I guess you understood nothing I just said; "#pragma once" is ignored by GCC. Bu portability I include reuse in other projects - you restrict this because the headers have prerequisites to inclusion rather than being self-contained. Moreover, this was supposed to be a minimal example; if you choose over complicate your examples and introduce additional errors or flaws or unconventional or poor coding style, and then post it publicly you kind of invite additional comments (generally intended as helpful). The way to avoid that is to truly post the minimum code necessary - if you cannot do that, you probably don't understand the code.

6) Static are on the stack are they!? Ha! You really aught to check your facts before you make such assertions or you will just look foolish (you just did!). That's the funniest thing I have heard since the guy that asserted that Borland defined the standard for C and C++! A little research would have saved your credibility (e.g. http://annwm.lbl.gov/~leggett/vars.html http://www.glenmccl.com/tip_018.htm ). Static data (i.e. globals, static locals, and static members) are allocated space and located by the linker at build time.

7) As I said, you are the one who cannot get the tool to work, so who are you to decide what is useful and what is not!? It turned out that it was very useful - it revealed where you were putting your project.

Clifford

[Anonymous]

You all posted during my last composition. I would like you to describe how it is "hanging". It implies that the compiler does not terminate but you persist in posting logs that clearly show make.exe terminating which implies the compiler terminates.

Don't jump to conclusions, the evidence that it is a bug in the compiler is not yet conclusive - at least not how you have described it.

Let's be clear, is it sometimes hanging and other times not!?

Is it possible that we are you have more than one problem? One known one caused by your location of project files (moved from one ill-advised location to another - although you were not necessarily to know about the second), and one real one to do with array sizes?

As I said if we can fix the known problems, perhaps we can be talking about just one problem. Your last set of logs clearly exhibited the symptoms of the "placement under c:\dev-cpp" bug.

And yes this is a relatively "robust" forum, but it is just writing, toughen up (actually I reckon you can take it). Besides from where I am it looks distinctly as if you started the abuse, presumably due to some misinterpretation of something I had said, since I had no intention to offend (but I hope that I have made up any deficiency in that respect since).

Clifford

[David]

Clifford, forgetting about all of the above have you tried to compile the code? Are you able to reproduce the hang or not? You have pointed out a whole bunch of stuff - but seem to not want to actually look at the issue I was raising.

You have regailed us all with your knowledge about memory allocatation, portability issues etc. etc. Is this to help me and others or just to point out how much you know? Let's leave all that (the #pragmas, the std:: conventions etc.). If it hangs for you, fine say so, if it doesn't then can't you just say "Tried this, it works fine for me".

I realise I'm asking for free help from volunteers. That's why I said if you don't want to help, don't. Heaps of others will have read the start of this thread and decided not to help because they weren't interested or couldn't help or perhaps they thought I hadn't provided enough info. But you decided to just point out a whole bunch of unrelated things you think I'm not doing right. This is not really helping me - it's just you spouting off, trying to elevate yourself by showing up something I am doing wrong. Which is of course just small minded.

I noticed this yesterday with your response to "Nobody/Anonymous" with his post "Getting Help for Programming a Game". Yes the guy is starting from nowhere and he is asking the earth by asking others to tell him how to "program a game". But youngsters ask this sort of thing all the time. Others replied and gently tried to steer him towards simpler things. You told him he was naiive. How does this help him? Again if you felt his post was so silly, just ignore it, you don't have to tell him he's naiive and he's got a long way to go. Just go about your day and perhaps help with another topic. Cripes.

[David]

It only hangs when the array size is set to 3000000. I still don't understand why.

The rest of the time it either compiles and runs ok (array size = 300, 3000 or 30,000) or it does not compile - but the compiler terminates with an error message (array size = 300,000)

By 'hangs' I mean the compilation does not terminate. The only way to stop it is to end the cc1plus.exe process in the task manager. Somehow things then go on to produce a compile log. I just did it again to be sure:

Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Projects\Makefile.win"
Executing make clean
rm -f Test3/main.o Test3.exe

g++.exe -c Test3/main.cpp -o Test3/main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

make.exe: *** [Test3/main.o] Error 1

Execution terminated

I will try this again by shifting my test3 project to a third location. I will post the results.

[Nobody/Anonymous]

"I was merely trying to point out a bug with the compiler."

O_o

I very seriously doubt that. The fact that you asked for help resolving the issue without citations indicates that you hadn't researched the issue. And for future reference: Reporting a bug, or worse a "bug", by first stating "this software doesn't behave as I think it should", omitting virtually all information, providing misinformation, not offering a repeatable test case, misusing technical jargon, and using an old version of the software in questions is not nearly as helpful as you seem to think it might be.

Soma

[David]

I shifted my project to C:\Test3. I get the exact same behaviour. Here's the code log:

Compiler: Default compiler
Building Makefile: "C:\Test3\Makefile.win"
Executing make clean
rm -f main.o Test3.exe

g++.exe -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"

make.exe: *** [main.o] Error 1

Execution terminated