I was reading a theoretical schematic of the precalculation of some lists of something we have to make and it happend to come up my mind that in order to succeed I would have to use such an order of loops within loops that (by a certain estimation)
it would result in approximatly 1000 000 loops.
I know many of you think "WTF???"
so did I, but uhm, there is just no alternative.
Now to my question, non-syntacticaly spoken, can C++ handle this, more importantly, can a general CPU (aproximatly 1 Ghz or lower) - company based pc - handle this within a certain acceptable time (less then 30 minutes) and without running out of memory or crashing?
(note that it does need to do more than simple operations, but in general each small operation will take little time but has severl subtasks. think of nested loops within nested loops)

Well, C++ as a language will definatly have no limitation stopping you from doing it. As you ask, it'll be down to whether the computer running your program can handle it or not...

Personally, unless you're trying to do some recurisve thing that will cause memory to run out easily or something, I don't see a problem with it. The best advice is probably, try it and see :D

ah :D
the first good thing I hear in a long time.

as long as it won't generate a System.OutOfMemoryException like vb .NET for creating a method that uses more than 64K memory :P

Just did wrote matrix multiplication.

Two 100 * 100 arrays.

Therefore the loop is 100 * 100 * 100 = 1 000 000 iterations.

Runs quicker than I can blink.

Tried increasing the size to 500 * 500.
But that caused a problem with stack allocation.
500 * 500 * 4 = 1 000 000 bytes == 1 000 K == 1M per array.

Three 1M objects on the stack did'nt work.

Changed the code to dynamically allocate the arrays.
100 * 100 arrays 1 000 000 iterations (quicker than I can blink)
500 * 500 arrays 25 000 000 iterations (2.3 seconds)
1000 * 1000 arrays 1 000 000 000 iterations (17.7 seconds)

:blink:
amazing
and what exactly did it do wih these arrays?

Martix Multiplication:

But on a bigger scale.
Matrix Multiplication has a complexity of O(n^3)

So the size of the problem goes up quickly.

aha :)
then normally, in case of using a GUI, doing heavy calculation beind the scenes should work pretty well :)
nifty :)

(I still wonder why m$ put the mem limitation on though :?, yet another reason not to use .net.....)

I don't think its a MS limitation on memory.

There is just a physical limit to the size of a StackFrame.
Remember that all local variables are placed in the current stack frame (NB This is an implementation detail and could be done differently by different compilers).

Problem was easily solved by allocating on the Heap.

PS I was using gcc (though I would bet MSVC would have the same problem though I have not verified that).

As for doing heavy calculations behind the senes. For normal type of work you should be fine. Though generally when I am working in an event driven environment I break out of a my loops every 1000 -> 10,000 cycles to check the event que so that an app remain responsive to the user. The actual break point will depend on how heavy the work load is.

A rule of thum I use is that a user should not have to wait for more than 1/60 of a second for a responce to an action. That can drop to 1/10 of a second if you inform the user he has just requested a computaionaly intensive operation.

a suggestion did you try using heap allocation. (you can allocate a larger block of memory)
and/or try using ASM most asm assemblers let you specify your stack size. if you continue having trouble with the stack size you can always try modifying the PE (for windows based programs) to allow a larger stack.

well, about those response times, the user is informed alright :)
and he is given a progress bar too (well, I plan to implement that) since they like some interaction