bradley@uiucdcsm.cs.uiuc.edu (11/06/87)
We're doing some OS development on a couple of 286-based machines and are interested in using C++. The type of work we're doing, though, requires that we mix near and far pointers. Unfortunately, the "near" and "far" keywords are not standard C and cfront (correctly) flags them as errors. Does anybody have any suggestions on how we could get around this problem? Ideally the near and far pointer definitions would be hidden in a couple of classes, but the problem of how to define those classes still remains. We have sources for C++ and could, if neccessary, dig into them. David Bradley bradley@a.cs.uiuc.edu Department of Computer Science University of Illinois at Urbana-Champaign
emc@unicus.UUCP (11/10/87)
I too am interested in the state of 80x86 C++ compilers currently on the
market. I have this vague, and likely unfounded, hope that the one of
the two C++ compilers that I know of (Lifeboat and Guidelines) would
hide the entire near/far pointer problem from the C++ code. I was
thinking that cfront could be set up to select which pointers to use and
issue the correct C with near/far keywords. Can anyone inform me of what
these manufacturers have in fact done with this problem? We plan on
getting C++ sources anyway, so if we have to, we could do it ourselves.
I cannot think of any cases where I want C++ to recognize near/far
in applications programming (we are not reimplementing malloc or
anything like that in general). If I really need it, I could always go
to pure C.
Finally, I have heard of subtle incompatabilites between cfront and pcc
when dealing with pure C code. Does a list of known gotchas exist?
--
Eric.M.Carroll@Unicus.COM (Internet)
{uunet!mnetor, utzoo!utgpu!utcsri}!unicus!emc (dumb UUCP)
mnetor!unicus!emc@uunet.UU.NET (dumb ARPA)
"The abscence of tedium IS magic" - Paul Menonmarc@ISO.3Com.COM (Marc Lavine) (11/11/87)
In article <4800003@uiucdcsm> bradley@uiucdcsm.cs.uiuc.edu writes: >We're doing some OS development on a couple of 286-based machines and >are interested in using C++. The type of work we're doing, though, requires >that we mix near and far pointers. Unfortunately, the "near" and "far" >keywords are not standard C and cfront (correctly) flags them as errors. > >Does anybody have any suggestions on how we could get around this problem? If you're developing under MS-DOS you can get Advantage C++ version 1.2 (I'm not sure if it's actually shipping yet; I'm a beta-tester) from Lifeboat (really from Glockenspiel) which properly handles the near and far keywords. I think Glockenspiel is working on an OS/2 port of this compiler; they also have Unix versions, but I don't know if they support the near and far extensions. Lifeboat's phone number is (800) 847-7078. Oasys ((617) 491-4180) sells Glockenspiel's compilers (including non-DOS versions) as Designer C++. This is not an advertisment. I'm just a satisfied customer. Marc Lavine -- Marc Lavine Internet: marc%3Com.COM@Sun.COM Smart mailer: marc@3Com.COM UUCP: ...{oliveb|sun}!3comvax!marc
mjy@sdti.UUCP (Michael J. Young) (11/13/87)
In article <1539@unicus.UUCP> emc@unicus.COM (Eric M. Carroll) writes: > >I too am interested in the state of 80x86 C++ compilers currently on the >market. I have this vague, and likely unfounded, hope that the one of >the two C++ compilers that I know of (Lifeboat and Guidelines) would >hide the entire near/far pointer problem from the C++ code. I was >thinking that cfront could be set up to select which pointers to use and >issue the correct C with near/far keywords. Can anyone inform me of what >these manufacturers have in fact done with this problem? I'm not really familiar with the Lifeboat port, but Guidelines did not put any of the extra keywords (e.g., near, far, cdecl) into the language. They provide a bunch of batch files, each of which compiles source in a different memory model (small, medium, compact, large, huge). The only change in the batch files is which "szal" file is given to cfront for determining size and alignment information. The C compiler is then called with the appropriate memory model switches. Unless you need to do mixed-model programming, their approach is sufficient. We recently ported cfront to OS/2 without difficulty. However, writing C++ programs for OS/2 is the only time I've ever regretted not having the extra keywords: all OS/2 system calls must declared as pascal procedures. In this case, I've created C functions that hide the OS/2 calls, and do everything else in C++. Since the standard c-library functions all work anyway, there aren't too many places where this is necessary. >Finally, I have heard of subtle incompatabilites between cfront and pcc >when dealing with pure C code. Does a list of known gotchas exist? We were told by Dr. Stroustrup that 286 pcc-based compilers have a bug in large model (which we use most often) which makes it almost impossible to port cfront to 286 boxes that rely on pcc. He gave us a simple test case: int *alloc(); int kl() { int s; char *am; (am == 0) ? (am = (char *) alloc((long) s)): 0; } If the above code successfully compiles in large model, you're home free. Pcc-based 286 compilers (ours included) die with an internal compiler error (register allocation error). Unfortunately, this type of construct is frequently generated by cfront. I've been informed that the latest release of Metaware's High-C compiler doesn't have this problem. I don't have their compiler, so I can't verify it. Anyway, if you're going to use cfront on a 286 Unix box, I recommend you consider alternatives to pcc. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779 "What would you do with a brain if you had one?" -- Dorothy, Wiz of Oz
mikem@otc.oz (Mike Mowbray) (11/13/87)
In article <1539@unicus.UUCP>, emc@unicus.UUCP says: > Finally, I have heard of subtle incompatabilites between cfront and pcc > when dealing with pure C code. The only thing we've struck is that one must beware of the temptation to use // style comments on #define lines. Mike Mowbray Systems Development |||| OTC || ACSnet: mikem@otc.oz UUCP: {uunet,mcvax}!otc.oz!mikem Phone: (02) 287-4104 Snail: GPO Box 7000, Sydney 2001, Australia