On Sat, 9 Sep 2017 22:50:33 -0700
"John R. Hogerhuis" <[email protected]> wrote:
> That's a bummer.
>
> Funny what people leave out of a C-ish implementation. The
> preprocessor has to be one of the easiest pieces.
Obviously the preprocessor hasn't been really been expanded on since the
days this compiler had to run on a 16K CP/M box.
>
> So can you even make a struct that maps to a BASIC variable data
> structure given what you're saying? What is the limitation regarding
> "order"?
I just messed around with this more, and I think I might see what it's
doing.
I *think* what's happening is that if there's more than one globally
defined but not allocated struct, the compiler gets confused.
so this...
/*blah blah*/
struct whatever {/*blah*/};
main(){
struct whatever foo;
foo.element=0;
/*blah blah*/
}
works fine.
BUT this:
/*blah blah*/
struct thing {/*blah blah*/);
struct whatever {/*blah*/};
main(){
struct whatever foo;
foo.element=0;
}
confuses the compiler.
Also works fine:
struct thing {/*blah blah*/) bar;
struct whatever {/*blah*/} foo;
main(){
foo.element=0;
}
So it looks like I can't have a header file that defines all the
structs rather they're used or not...
We could use #define to sorta fake having typedef. Or would it be
preprocessor abuse to say:
#define STRING struct vs{..}
main(){
STRING foo;
}
??????
Yay, talking about the problem helped me at least clearly define it!
Also, I cry "Compiler Bug!".
Willard
--
Willard Goosey [email protected]
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
-- R.E. Howard
