Ethan,
Here is a patch to fix the issue with conditional compilation.
Now, I left the curly braces issue as is. If this causes a problem with highlighting in your editor, let me know. It's fine in gvim.
The thing is, I don't want to have conditional compilation in which there is code repeated. That's really bad in this case because there is a big hunk of code two conditions share. Don't really want to make that a function either.
Let me know if you have any ideas to deal with this. Maybe at some point we can choose one version of X11_BINARY_POLYGON and go with that. We could do some speed tests or something. (I think this was for speeding up large pm3ds originally.)
...
I also noticed that the palette code in gplt_x11.c looks so similar to that in color.c. That stuff gets repeated more than it should be. I'm not going to worry about that now.
Dan
Ethan Merritt wrote:
> Daniel:
>
> The #ifdef / #else / #endif blocks in gplt_x11.c are
> horribly unreadable. So much so that they have hidden
> some serious mis-ordering of the statements.
>
>
> Try
> ./configure --with-image --disable-binary-x11-polygon
> cd src
> make gnuplot_x11
>
> and watch everything fall apart.
>
> The nested #ifdef/#endif code blocks that end just before
> line 3050 of gplt_x11.c are clearly incorrect, but I cannot
> see what the original intent was.
>
> Can you please try to clean up this code?
> I suggest that no #ifdef/#endif pair should leave unbalanced
> curly brackets in the code. This sort of thing:
>
> if (A) {
> #ifdef FOO
> if (B)
> {
> blah; blah;
> #else
> yadda; yadda;
> #endif
>
>
> is just asking for trouble.
>
|
