> I've seen this problem already a while ago: MSVC 2003 has a problem with
> strings that are longer than 2KB. Honestly, a compiler that chokes on 2048
> tiny bytes!
>   
Hehe, sounds familiar. I remember struggling with getting VC6 to compile 
template code -- nice to know they kept up their "quality" since then...

> Before I start working on a hack like this, are there other ideas how to deal
> with this problem?
>   
I know very, very little about post-2000 Microsoft stuff. But at least 
in VC6 it was possible (and common) to seperately link in binary 
resource files which was accessed through the Windows API. One could 
have a VC-mode where a ".res"-file is dumped containing strings, and 
these could then be compiled in, and looked up run-time. This should be 
very slightly faster as you get your data linked into the executable in 
one block (don't know what the .NET-equivalent would be though); or at 
least, any overhead is O(1) with respect to string length (unlike your 
approach, which is O(N) -- though probably not noticeable anyway).

Your approach sounds a lot saner though :-) Would be nice if you would 
code it up as a transform, so that we had some transforms to start 
building a pipeline structure around and some real code to work out 
issues with the approach. It is an ideal transform situation -- in goes 
string nodes, out goes addition nodes and string nodes; right after the 
parsing phase which is available now.

In fact, if you don't find a better solution, I'll volunteer to do the 
implementation, since it sounds so incredibly ideal for a simple 
transform demonstration (and it is always nicer to have something real 
than something contrived).

Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to