georgep@cscnj.csc.COM (George Petrou) (01/23/90)
Hi there,
I hope you NEXT and GNU C gurus out there can answer the following
questions :
What C compilers are available on the NEXT box ? Do all of them
support NEXT-Step graphical interface calls? I heard that the
GNU C compiler has been hosted on the NEXT. Is this the case ?
How robust/reliable is the port ? How close is GNU C to the
ANSI standard? In particular can anyone comment on the compatability
between Microsoft C 5.1 and GNU C ?
I am not a NEXT user ( I wish :) !) but the answers to these
questions may make me one :). We are considering porting a MS-Windows
application to a NEXT box. I would also appreciate any comments as
to the wisdom of such an endeavor.
I would appreciate any feedback ! Thanks in advance
George
---------
George Petrou Computer Sciences Corporation Piscataway, NJ 08854
....!rutgers.rutgers.edu!cscnj!georgep
--
---------
George Petrou Computer Sciences Corporation Piscataway, NJ 08854
....!rutgers.rutgers.edu!cscnj!georgeprfg@ics.uci.edu (Ron Guilmette) (01/24/90)
In article <642@cscnj.csc.COM> georgep@cscnj.csc.COM (George Petrou) writes: >Hi there, >I hope you NEXT and GNU C gurus out there can answer the following >questions : > > What C compilers are available on the NEXT box ? Do all of them > support NEXT-Step graphical interface calls? I heard that the > GNU C compiler has been hosted on the NEXT. Is this the case ? Yes. I believe that a modified (and not quite current) version of GCC is their "default" C compiler. > How robust/reliable is the port ? How close is GNU C to the > ANSI standard? Reliability is in the eye of the beholder. GCC is probably about as ANSI a compiler as you could find (except that it supports numerous extensions). > In particular can anyone comment on the compatability > between Microsoft C 5.1 and GNU C ? What has that got to do with ANSI? Are you suggesting that Microsoft C 5.1 is ANSI compliant? Are you sure about that? I doubt it. > I am not a NEXT user ( I wish :) !) but the answers to these > questions may make me one :). We are considering porting a MS-Windows > application to a NEXT box. I would also appreciate any comments as > to the wisdom of such an endeavor. Sounds entirely bizzare. I'm not a `graphical interface' kinda guy, so I should not really be commenting (because I don't know squat about MS-Windows or about the windowing system on the NeXT... which I believe is X11) but let me just say that it sounds like a gigantic hassle to be changing windowing systems. I won't say anymore because rms doesn't like people discussing "propritary" software (e.g. the Microstuff stuff) here in the Gnuse groups. One footnote. I have recently learned that the NeXT system has become incompatible with current versions of the GNU C compiler. The problem is that NeXT invented (or borrowed) a new type of preprocessor directive that GCC doesn't know how to deal with (and never will). The directive is called "#import" and according to reports I have recieved, this directive is being used within (at least some of) NeXT's "system" include files (perhaps many of them). You know... the files that you often have to include in typical C programs like <sys/file.h>, etc. Since GCC does not recognize this directive (for good resons that are described below), their use within system include files makes it virtually impossible to use the latest (and most robust/reliable) version(s) of GCC on your NeXT to compile anything but the most trivial programs. The #import directive is just like a #include directive *except* that it tells the compiler not to try to include that same file again during that particular compilation. Recent versions of GCC have a different (and better) way of implementing these same semantics. It is called `#pragma once'. For each file which should only be included one time (at most) during any given compilation, GCC allows you to explicitly give the preprocessor this information via the use of `#pragma once'. This pragma is placed *into* any file that should only be included one time (at most). The `#pragma once' has two important advantages over NeXT's `#import' solution for the same problem. First, *any* solution to this general problem will be inheriently non-standard (because ANSI C doesn't specify any mechanism for implementing such semantics). Using `#pragma once' however mimimizes the potentially negative effects of having non-standard code because ANSI *does* require that compiler which do not recognize a given type of #pragma should simply ignore such #pragmas. In many (most?) cases this will mean that you could still compile code containing `#pragma once' with other ANSI C compilers, and that the only negative effect would be that your compile would run a bit slower. The second advantage may be difficult for some people (who have not maintained large software system) to see, but is is an important one anyway. The problem with the #import directive is that it scatters important information about a particular `properity' of a given include file all over your code (and in particular into many otherwise `independent' files). The `property' I refer to could be called `once-ness', i.e. that property of an include files that allows it to be included either once only, or multiple times, with exactly the same (intended) effect. It is obvious that the `once-ness' of a given include file is a property of that file *only* and *not* a property of any of its `users'. Thus, when necessary, you should be able to change the compiler's understanding of the `once-ness' of a given include file by modifying that file *only*. This works with `#pragma once'. It doesn't work with `#import'. Richard Stallman (the creator and maintainer of the GNU C compiler) fully understands these issues and has told me that he intends to support `#pragma once' in his current and future releases of GCC. He specifically rules out any support for `#import' which seems to be a kludge. I suggest that it is time for NeXT to take account of these facts and to get their include files into a GCC compatible form. Otherwise, their users will suffer an inability to use newer versions of GCC. Mr. Jobs, are you listening? // rfg the case. // rfg
davis@groucho.ucar.edu (Glenn P. Davis) (01/25/90)
In article <25BCC24E.10018@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes: > >The directive is called "#import" and according to reports I have recieved, >this directive is being used within (at least some of) NeXT's "system" >include files (perhaps many of them). You know... the files that you >often have to include in typical C programs like <sys/file.h>, etc. > .... more bashing of the #import directive. A perusal of the documentation will put the blame where it belongs. The #import directive is inherited from Mach, specifically documented in the section where the format of remote procedure call specification files is discussed. Personally, I don't fault NeXT for using this mechanism. Its does solve a problem and has the historical precedent in Mach. It works in the context of their system. After all, code like [object message:arg] ; Won't work with gcc on other systems either. -glenn
telfeyan@dip.eecs.umich.edu (Roland Telfeyan) (02/15/90)
In article <25BCC24E.10018@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes: >Sounds entirely bizzare. I'm not a `graphical interface' kinda guy, so I >should not really be commenting (because I don't know squat about MS-Windows >or about the windowing system on the NeXT... which I believe is X11) but Please! Why are you writing in a NeXT group if you don't even know what the screen looks like! >One footnote. I have recently learned that the NeXT system has become >incompatible with current versions of the GNU C compiler. > >The problem is that NeXT invented (or borrowed) a new type of preprocessor >directive that GCC doesn't know how to deal with (and never will). > >The directive is called "#import" and according to reports I have recieved, >this directive is being used within (at least some of) NeXT's "system" >include files (perhaps many of them). You know... the files that you >often have to include in typical C programs like <sys/file.h>, etc. Please! The #include directive is specific to Objective-C and only appears in appkit, musickit, and soundkit files, NOT any standard Unix files like sys/file.h! The cc on the NeXT is totally ANSI and will compile any vanilla C programs that you can compile in gcc on a Sun, for example. This is a hidden beauty of the NeXT object-oriented C language, Objective-C: that it is a PROPER SUPERSET of C, unlike ... (you're going to yell at me for comparing again) C++ (ahh, I said it). Roland Telfeyan Center for Performing Arts & Technology University of Michigan