# fatal error C1202: recursive type or function dependency context too complex

This topic is 4760 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm doing some templatized recursion for an arbitrary NxN matrix: (summarizing)
template<class type, int N>
class MatrixNxN
{
// component-wise copy
template<int N>
static void copy(type* out, const type* u){
*out = *u; copy<N-1>(out+1, u+1);}
template<>
static void copy<1>(type* out, const type* u){
*out = *u;}
..
};


So, I need to create a 64x64 matrix by MatrixNxN<float,64*64>, but I get the error: fatal error C1202: recursive type or function dependency context too complex. I'm using Visual Studio.NET 2003. Does someone know if I can turn this off, or get around it in some way (other than doing the recursion at run-time)? Is there an option I didn't find in project settings or something? Thanks

##### Share on other sites
Recursion depth is a setting of most compilers, often it limited to a depth of 20.

Cheers
Chris

##### Share on other sites
Yeah, I fully understand the problem. My question is how do I get around it and still get the compile-time optimization.

Any Ideas?

##### Share on other sites
How about unrolling the copy function? So, for example, handle four iterations simultaneously and specialize for sizes 1 to 4.

Also, wouldn't it be a lot safe just to write a loop and let the compiler unroll it for you? This seems like a nasty template hack anyway, I bet it's going to create some interesting 4-page identifiers :)
Your main performance consern should be to inform the compiler of any aliasing restrictions anyway..

[Edited by - doynax on February 12, 2005 1:02:45 AM]

##### Share on other sites
If the loop needs unrolling, the compiler will unroll it for you. Under certain circumstances, this manual unrolling will slow things down. Don't do this sort of thing.

##### Share on other sites
Quote:
 Original post by SneftelIf the loop needs unrolling, the compiler will unroll it for you. Under certain circumstances, this manual unrolling will slow things down. Don't do this sort of thing.

Quoted for emphisis. I would be extremely suprized if this method worked better in ANY circumstance.

Also, your class or arguments are very poorly named. MatrixNxN implies that the matrix is N x N in size, whereas providing N=64*64 is used in your example supposedly creates a 64x64 matrix instead of a 4096x4096.

Further, this code is at best very innefficent for a copy. You'll suffer an extreme performance hit in debug mode, because for every copy you'll be passing two arguments and calling. Plus, your codepage and EXE size will jump as the maximum size of your array does. In the best case scenario during release mode (which is nearly guaranteed not to happen is my 2 cents) it'll have the same effect as the correct unrolling of your loop, which your compiler knows more than you about and will do for you. In the worse case scenario it'll be just as bad as debug mode.

Furhter, a generic copy function does not belong in a matrix class. To implement your own you'd want to write it as a normal function. However, you may want to use std::copy or std::copy_n, both of which were written by people who know more about this than you do. No offense, it's just that they're professionals, and there's no sense in reinventing the wheel.

##### Share on other sites

At the risk of sounding defensive, I'm actually doing this as part of a school project, so the point is to gain first hand knowledge about the advantages and disadvantages. I guess maximum size goes under the disadvantage column.