#Lattice & Aztec code dif
17 messages in this thread
Hi
Does anybody know what is different about writing code for Aztec versus
the Lattice(SAS) compilers. What should I watch out for??
I am fairly new to C programming and have been using the Lattice 5.1
package, but it seems that programs written for Aztec dont compile under
Lattice very often. The problems seem to be in reference to differences in
data types ie. different interpretations of Longs & Shorts. There may be
other things but I think, but that is a start.
Thanks in advance for any Info Received.
Real Amigas Have Keyboard Garages !!
John Lemoine 75320,143
John,
Most code that I've seen that was written for Manx compiles OK with
SAS/Lattice. The big thing that you have to watch out for is the
statement:
#include <functions.h>
which is a Manx include file that doesn't exist on the Lattice system. The
(almost) equivalent SAS #include file is <proto/all.h>. The other
difference that I've seen when converting to SAS (or Lattice, which is the
same only an older version) is that many programs generate a lot of
compiler warning messages (but not necessarily errors). The SAS compiler
is a lot fussier than Manx (particularly the older Manx compiler), and
consequently gives warnings on the same code that Manx didn't complain
about at all. Both compilers are "right" – the code _usually_ works,
although there is something that's not quite right – for example, the
following code would generate this type of warning with SAS:
struct IntuiMessage *msg;
if (msg = GetMsg(mywindow->UserPort))
{
ReplyMsg(msg);
}
Now, this code works correctly (except it doesn't do much <grin>, but the
compiler will complain because the GetMsg() function returns a pointer to a
Message structure, not an IntuiMessage structure, and the ReplyMsg()
function needs a pointer to a Message structure as a passed argument. Now,
the IntuiMessage structure is really the same as a Message structure,
except that it has more data tacked on to the end of it, so the above code
is not really incorrect (which is why Manx doesn't complain), but SAS is
correct also in that you are not referencing the "correct" variable types.
You can get around this with the use of C casts, which temporarily override
the "type" of variable being referenced. As such:
struct IntuiMessage *msg;
if (msg = (struct IntuiMessage *) GetMsg(mywindow->UserPort)
{
ReplyMsg((struct Message *)msg);
}
Hope this helps…
…BobR
Actually it is interesting that you choose this example because there is an
option on the SAS/C compiler -cq which specifically eliminates these
warnings for 'equivalent' structures. As long as the one structure is a
proper subset of the other it will suppress the warning. reply
John,
I am aware of the new switch, but I've gotten in the habit of doing the
casts, so don't generally use it. I thought of the option when I was
writing the message, but felt that things were confusing enough as it was,
and didn't want to further muddy the waters. Besides, when I last
converted Manx code to Lattice, that option wasn't available. I guess some
of us are slower to change. <grin> I still compile from the CLI, too.
…BobR
Many people have grown tired of the casts where the data type was 'obvious'
to someone who had read 10 manuals and that is why it is in there. I have
grown quite acustomed to it as it does make the code a bit cleaner without
all the casts in it. The same goes for the workbench environment. It did
not take too long for me to become set in the ways of the new methods.
John,
I agree totally with the reasoning for putting that switch in, as I used
to swear frequently at "you guys" when the Lattice compiler first included
function prototypes and I had to learn to put in all those casts. Problem
(for me) is that I've gotten used to doing the casting and have maintained
the habit. I never meant to imply that the compiler shouldn't have that
command-line switch. I'm just being resistant to change. <Grin>
As to the CLI vs. WorkBench thing, for me it's mostly the same
resistance to change. However, I still see at least one shortcoming to the
WB approach -at least in relation to the manner in which I'm accustomed to
setting up my projects. I use a lot of pseudo-targets in my makefile, and
also tend to use a lot of macros in my makefile. Consequently, I am
constantly running LMK and specifying specific targets to be "made", and
frequently invoking LMK with macro-value overrides. I don't think there's
a way yet to adapt this easily to the iconic approach. I probably could
set up a bunch of ICONX scripts to do this, but it seems like more bother
than it's worth. Also doesn't give me quite as much flexibility as I'd
need to anticipate every possible combination I may want.
Still, I have no real complaints with the direction you are taking the
compiler product. I'm a believer. 🙂
…BobR
But there is the ability to specify multiple lmkfile from the workbench and
even to have pseudo-targets. Just set the default tool in the project to
be LMK instead of LSE and it will run LMK on that file. If you shift click
on an icon from workbench it will use that as the pseudo-target (which
means you would need the additional icons to stand for the pseudo-targets
you are interested in)
butting in; I'm another one of those neanderthals that likes the command
line operation. I just work faster when all 10 fingers are busy.
PS> More interesting threads these days; excellent!
Mike Haynie
Bob,
I tried the WB environment — under 2.0 I could get used to it 'cept for
a couple of things. I've got a real problem with LSE. It could be the best
editor in the world, but I'm used to CEDPro. I've run into the same
problem you've mentioned with using LTOCED to use CEDPro instead — CEDPro
opens up on the wrong directory. But, the biggie, for me, is that I tend
to modularize a lot. The current program I'm working on has over 40
modules. Waiting for 40+ module icons, plus the build, makefile, .h, etc.
icons to be read from disk and then displayed is a real pain. Heaven
forbid you should have "show all files" selected and the .o files show up
with icons too. -sja
There are actually a couple of ways to deal with this. The simplest is to
use smaller icons. We deliberately shipped large ones for the general
market, but with smaller icons they will come up much quicker. You can also
divide things into several sub directories and let the lmkfile locate them
and build them.
John,
Has LMK been fixed/enhanced to deal with targets and dependencies
existing in different directories? I've tried to set this up in the past
(with previous versions of the Compiler environment) with little to no
success. I prefer to keep my source files in a separate directory from my
object files. Can I now do this with 5.10A?
Thanks…
…BobR
We haven't done much to improve the defaults, but it does work with
explicit (or relative paths) and we use it with NET: all the time. If you
have specific examples of failure please let me know and we will put it on
the list for 6.0.
Steve,
I have the same problem as you, except that I'm up to about 75 modules
<grin>. I think I'll be resistant for a while longer.
…BobR
We have C++ under the environment with about 55 modules. In general I have
around 40 modules or so in the largest I do and around 15 on the average.
We are playing with the environment to learn the limits and experimenting
with tricks to improve the limits.
Hi Bob
Thanks for the tips on the Compiler stuff. I guess my biggest problem is
I dont know the difference between one data type and another and when it is
safe to do a cast to another type.
I find the myriad varieties of data types and structs on the Amiga to be
fairly overwhelming. I have bought quite a few books on C as well as on
programming on the Amiga but I find the effort required to write a program
to do a simmple thing can take such a long time in C that I sometimes end
up doing it in AREXX just to get it done so I can get on with life.
I also find many examples on the BBS's of C code that people include
with their programs but I find that often these programs wont compile
without creating the exact environment the programmer was using, or else
wont compile because of some of the afore mentioned differences between
Lattice and Aztec. Whew , some much code so little time!!!
Real Amigas Have Keyboard Garages !!
John Lemoine 75320,143
That difficulty is thanks to the advent of ANSI C, I think. ANSI vs K&R 1st
ed. gives me heartburn at work as well. ( a very small flame )
Mike Haynie
Mike,
Personally, I think it is a GOOD THING. Yes, it imposes "discipline" on
us, but I know that for me, that discipline has saved my butt many more
times than it provided a pain in the same location. <grin>
…BobR