#Comeau C++
14 messages in this thread
>Do you have an educational discount program? Also, what is your ordering
>procedure? Are you selling only through dealers or also selling direct to the
>end user?
We generally don't offer discounts unless on the larger machines where the
prices are higher. Our prices for things like AmigaDos are as low as it
can go for now though, so essentially a discount is already worked in.
Since we are derived from AT&T's cfront C++, we need to contend with a
bunch of licensing and royalty issues and quite frankly we walk away with
very little on the $250 ($20-50 depending upon the exact port believe it
or not). These means will sell direct 9x% of the time and single copies
to dealers will not be discounted.
Our ordering procedure suffers somewhat from this situation as well
as we can't afford to chase down even well intentioned customers (we used
to spend more on long distance calls and mail than we got in profit
since some customers were going to pay, they just wanted to wait 9 months! ;-})
Given that, ordering is as follows: You may mail in a personal check, company
check, or money order upon which we typically ship out the order the same day
it is received. The other choice is COD whereas we must ask that personal and
company checks be certified.
Greg –
Thanks for the information. I asked about an educational discount only
because Lattice (and I believe now, SAS) has one (it was $150 when I bought
5.05), and Borland is peddling their MS-DOS C++ in the $150 range for
certain customers. I'm not challenging your pricing decisions, just asking
what they were. I haven't learned C++ as of yet (my C is bad enough, I
prefer to program in Ada, if possible), and the pricing schedule is a
needed input into a decision to buy.
Jeff Schweiger
Understood. I'm often asked some of these things so instead of
piecemealing it, it just put everything on the table for y'all.
Borland C++ is only in te $150 for previous customers.
Greg,
Nice to see the Amiga version is out, but I'm still using Manx so I guess
I'll have to wait a little longer.
And now for something completely different:
I have been trying to convince some people here that we should be using
C++ for our embedded systems developement. My question is: how compiler
specific is cfront? Would it be possible to use the same cfront with the
host machine's native compiler and a cross compiler? How major an effort is
it to do this?
>I've been trying to convince some people here that we should be using >C++
for our embedded systems development.
We have a number of customers (about 5% of the base) using C++ for embedded
systems. It works fine there. In fact, I just got my mail brought into me
as I logged onto CIS, and I not that one piece is the latest issue of
"Embedded Systems Programming" magazine where Rudyard Merriam (who is
available on other CIS forums here) has an article entitld "Performance vs.
Paradigm" where he design and implemented a data-logging system in C and
C++ and then compares them. His conclusion contain information I and
others have been saying for years: "The … result is that no real
performance difference exists between the two programs" including his
citing that the difference was only on the "order of microseconds" and that
he could make either version the faster by some teeny tweaking.
This jives 100% with a study we (Comeau) conducted last August/September
about the realities of C++ and whether or not it really measure it (FYI,
the response from 100 people was that some 9x people overwhelmigly thought
so). My research is currently available in "executive summary format"
(that is, bullets), but will be appearing in narrative form in the March
issue of "The C++ Report" to be coming out in 2 weeks.
You should make an effort to obtain both these articles as well as others
function in places like past USENIX C++ conference proceedings and past C++
at Work Conference proceedings. BTW, the ESP article mentioned above is
from the March issue.
>I'm still using Manx so I guess I'll have to wait a little longer….
>how compiler specific cfront.
I guess I should qualify more when I say "we don't support Manx yet".
What I mean by that is that *we* have not tailored Comeau C++ to it
yet. That does not mean that *you* would not be able to. Comeau C++
has a few steps in it: (1) run the C preprocessor (2) run cfront
(3) run the respective C compiler to get object code (4) link all
the objects (5) do something we term "static analysis" (6) possibly
compile in a special routine & relink depending upon the results from
(5). The bottom line is that that cfront just reads from stdin and
writes to stdout and doesn't particulary care when it around it so
long as it gets some input. So, it is not compiler specific,
can be used with the host's native C compiler, can be used with
a cross compiler, and can in fact be brought to the target machine
for final cross compiling.
This is not very complicated but is not necessarily without caveats.
For instance, as far as we can see Aztec C does not come with its
own C preprocessor and to date we have not done a port of Comeau C++
where this was the case with a C compiler. We will probably have to write
our our preprocessor in that case. What we like to do a provide a nicely
ties bow with at least a command line driver program and that would be
missing. For instance, we have a command line driver program under
MS-DOS written in C that is 1K line of code which is intimate with
MSC. That of course include error checking and not other whiz-bangy things.
The truth of the matter is that it really only demands a .bat file like so:
cl -I\c2\i /AL /E /D__cplusplus=1 somefile.c > \msc\tmp\preout.c
bcomeau +fsomefile.c +L < \msc\tmp\preout.c > \msc\tmp\frontout.c
cl /AL /Fosomefile.obj -c \msc\tmp\frontout.c
link /map somefile,somefile,somefile,+lcomo21;
stid somefile
cl /AL somefile.obj \msc\tmp\_main.c /link /F +lcomo21
The question about Manx concerned my own personal use.
At work I need to be able to work with multiple Unix platforms (Sun,
Apollo, 386 Unix PC's) and cross compilers from different vendors for
different targets. I've got the Unix boxes internetworked and the compilers
will be executing on different host machines, so it would be nice to use
one cfront and pass the output to the appropriate machine/compiler. This
should make it obvious why I asked about compiler specificity. I looked at
C++ (cfront 1.0) several years ago and the PC version I had was compiler
specific to the point where it wouldn't work going from one version of the
compiler to the next since it massaged the binary output of the compiler
(from your example .bat file it looks like this is still required with
MSC??).
Do you have a port for HP/Apollo Domain/OS?
>…it would be nice to use one cfront and pass the output to the appropriate
>machine/compiler
That would work and is in fact a feature of Comeau C++. Only in rare
situations would I recommend it though.
>I looked at C++ (cfront 1.0) several years ago and the PC version I had was
>compiler specific to the point where it wouldn't work going from one version
>of the compiler to the next since it massaged the binary output of the
>compiler (from your example .bat file it looks like this is still required
>with MSC??).
No, it is not required. We have opted not to produce an executable zapper
on the MS-DOS port for a few reasons (ditto for the Ami port, it doesn't
zap), but instead, our tool (stid) produces an accessory function (the _main.c
file) that gets compiled and replaced a dummy _main.c found in lcomo.lib.
>Do you have a port for HP/Apollo Domain/OS?
Not at the moment. That and another dozen or so port are expected to
occur during the course of this year though. Exactly which ones when have
not been fully pinned down yet.
May I ask why?
Replacing the startup code by relinking is a MUCH better way to handle the
required initialization than massaging the executable. It's unfortunate
that it couldn't simply be done in main(), but of course it's too late by
then.
>>>…it would be nice to use one cfront and pass the output to the appropriate
>>>machine/compiler
>>That would work and is in fact a feature of Comeau C++. Only in rare
>>situations would I recommend it though.
>May I ask why?
Simply because we have found customers find it annoying when doing non-embedded
production systems. Almost always they come back and purchase additional
compilers for the other platforms they have.
>Replacing the startup code by relinking is a MUCH better way to handle the
>required initialization than massaging the executable.
Actually there is a few ways to do it and like all engineering it becomes a
tradeoff of one thing over another. For the vast majority of implementations,
an executable zapper is actually superior. It becomes the least portable
mechanism for us, and hence we stay away from it in general especially on our
non-UNIX ports. Providing alternate scheme implementations is on out "to do"
list but since the relinking works without a hitch, it always ends up getting
a low priority.
>It's unfortunate that it couldn't simply be done in main()… too late by then.
Actually… To give you an idea of some of the alternates, one vendor,
Guidelines (now defunct BTW), would actually figure out the C++ static concerns
during runtime (!!) when the application first started up. That obviously
produced a lot of complains from their customer base. Another mechanism that
is quite beatiful when supported is to place the respective function calls
into a special named area that is the same for each source file and then let
the linker conglamorate them all into a list which the app only need now call
(this obviously demands a linker smarter than we unfortunately typically don't
find!).
Since you brought up ADA, I guess this is an appropriate time for this.
I said it in CO, and here it is again:
How to Determine Which Programming Language You're Using:
The proliferation of modern programming languages which seem to have
stolen countless features from each other sometimes makes it difficult to
remember which language you're using. This guide is offered as a public
service to help programmers in such dilemmas.
C: You shoot yourself in the foot.
Assembly: You crash the OS and overwrite the root disk. The system
administrator arrives and shoots you in the foot. After
a moment of contemplation, the administrator shoots himself
in the foot and then hops around the room rabidly shooting
at everyone in sight.
C++: You accidently create a dozen instances of yourself and shoot
them all in the foot. Providing emergency medical care
is impossible since you can't tell which are bitwise copies
and which are just pointing at others and saying, "that's
me, over there."
Ada: If you are dumb enough to actually use this language, the
United States Department of Defense will kidnap you,
stand you up in front of a firing squad, and tell the
soldiers, "Shoot at his feet."
Modula/2: After realizing that you can't actually accomplish anything
in the language, you shoot yourself in the head.
sh, csh,etc.: You can't remember the syntax for anything, so you spend
five
hours reading man pages before giving up. You then shoot the
computer and switch to C.
Smalltalk: You spend so much time playing with the graphics and windowing
system that your boss shoots you in the foot, takes away your
workstation, and makes you develop in COBOL on a character
terminal.
APL: You hear a gunshot, and there's a hole in your foot, but you
[ MORE ]
[ continuation ]
don't remember enough linear algebra to understand what
happened.
— Ethan
Ethan –
I'd seen other versions of this, but its always worth a chuckle. I note
that you finished the list off with APL, the 'write-only language'.
Jeff Schweiger