(Yeah, I know, I shouldn't drink so much. Sowwy. Let it go, let's move on).
That's a facetious argument. The window is that of compiling source code.
"Not really."
Yes, really. You're not thinking about moving into sales per chance, are
you??
"The window is building an executable from the
sources I wrote."
That's too big of a window. We can easily distinguish between things at the
library level and those at the build level.
" In practice, of course, those sources are
almost never pure C++; who writes out complex table
initializations, when AWK can do it from a simple text file more
easily?"
(Well I probably would, but that's an aside).
"Can you really say that you've created a serious C++
program in which none of the sources are automatically
generated?"
Remember, I'm slowly _replacing_ the standard C++ library!
"Can you really say that you don't use some sort of
source code control, and that your sources aren't necessarily
directly accessible from the compiler?"
I'm not in a team environment currently (yeah me!).
"That you don't use a
data base, or a third party windowing library, or any third
party connectivity software?"
I'm working on all of those.
Pretend it's the last compile before packaging and deployment and not
everything from concept to purchasing shrink-wrapped sofware in a retail
store. But it's not worth talking about. If you think that exotic means of
Me: Using 2 compilers in a chain is for very specialized, very
non-mainstream development scenarios.
You: No it's not.
"You're missing the point."
I don't think so, but I'll listen...
"If you use Comeau, that's the only
"compiler" you have in your chain."
Well I don't know. I've not used it. I thought it required some "hooking up"
to the platform compiler.
"Comeau, of course, may use
other tools, but then, so does g++ on my Solaris machine."
C'mon, a second HLL compiler?? It's a stretch.
"That's Comeau's problem, not mine. And of course, a "compiler"
is simply not the only tool I have in my tool chain. I use lex,
yacc, awk, etc. for code generation. I use third party
libraries for data base accesses. I do depend on multiple
suppliers."
But at different levels of the development process.
"I can't imagine any serious application which
didn't; you don't work in a vacuum, and you certainly aren't
going to redevelop everything yourself."
Well right now, I'm working alone, but no, not in a vacuum (duh, I'm here
right?).
If you like to lump everything into one category, so be it.
Class hierarchy: development tools. Not much of a hierarchy
huh. (We were talking about compilers. USUALLY there is only
one).
"I'm not sure I follow you. You seem to have created an
artificial category: compilers."
Actually you did a month or so ago when you said something like "it's pretty
well accepted that 'compiler' means 'compiler system'". I said something
about how I consider a "compiler" that thing that builds source into object
code, akin to popular vendor commandline compiler offerings. To which you
replied that the standard library is part of the "compiler". Remember?
"The tools I use to "compile"
code are drivers which invoke multiple sub-tools."
I can't go that far. I like the definition Greg put forth.
"In some
cases, all of the sub-tools come from the same supplier, but not
always: g++ under Solaris uses the Sun linker, for example."
I think I'd go as far as "compiler system" meaning: compiler+linker. (Of
course they are separate though).
[...]
It just means that you are jobbing out the difference resolution to Comeau
instead of doing it yourself. Instead of dealing with differences in C++
implementations, you're letting Comeau deal with differences in C
implementations. Of course, doing it in C is an alternative also.
"That's a more or less accurate way of describing it. Just as by
using a high level language, I'm jobbing out the differences in
machine architecture, and by using a commercial database, I'm
jobbing out the incredible amount of work which would be
necessary to write one myself. Anytime I can job work out, I
win."
Different categories noted in your passage above. I can't lump all those
things into one thing. I feel tension and pressure from "compiler" vendors
trying to lock me out of low level development. I'm simply not allowing it.
Comeau will get the code to something platform-specific but not
hardware-specific. That's why I consider it a "front end". Which begs the
question: "Why doesn't Comeau put a back end on it for each platform and
sell a "real" compiler?
"The real question is: why should they?"
Ummm, let me see... staying in business??
" They have something
which works."
It's getting a bit long in the tooth I think if you're outside of the niche.
I don't see potential for marketing outside of that niche (to me for
instance) without becoming a "real compiler" vendor. But hey, that's just
lil ol me.
"They make it available at a very reasonable cost."
VC++ is free. BC++ is free. g++ is free. (Is Watcom still viable?).
"If Greg had to write (or pay someone to write) a machine code
back-end for each platform, the compiler would cost more."
I too believe there is no market in JUST a compiler because there are so
many FREE ones. (The problem is still the language).
"Just
as I use a commercial database, rather than write my own,
because I get a lot better product a lot cheaper that way, Greg
lets the specialists in each machine architecture provide the
back-end for that architecture."
Okies. I guess another Dr. Dobb's article is in order (?).
Nah, it's bad all around (note JohnQ jumping out of the hot
oil): C++ should be implementable.
"It is. EDG has done so, and it certainly has a lot less
resources that companies like MS or Sun."
Even the way you said that is indicative: "had done it" (as if miraculously
has done so).
If it is so bad that one cannot trust that code can be
written to be compiled on any compiler, something else is VERY VERY wrong.
"Something is very, very wrong. Some suppliers have chosen to
ignore the standard, for whatever reasons, and just implement
the parts of it which interest them. Often with in house
extensions added to it."
Or it's just too complex.
1. I think the importance of standard conformance is over-blown relative
to
all development issues.
"That's probably because you've never had to develop professional
level code."
Right.
" What do you base your language understanding on, if
not the standard?"
Common sense and practicality and engineering judgement.
" You have a choice: standard conformance, or
vendor lock in and unportability."
Or something in between or divorced from both extremes.
[...]
I think a better approach is to know what the issues are and then code
around them.
"In theory, you're right. In practice, you have no means of
really knowing in advance what all of the issues are going to
be."
I was refering to such as Dr. Dobb's comparison of C++ compiler conformance.
"Compiler vendors don't advertise up front that they don't
actually do some things correctly."
[...]
Aside: Now may be a good opportunity to list the things (conformance
issues?) that may be of enormous concern to developers that Comeau solves
and the other guys don't. What would be interesting also is a comparison
of
where compilers are at today to where they were yesterday, against the Dr.
Dobb's article someone refernced earlier perhaps. I have a feeling that
I'll
find the issues mostly remote/non-important.
"You, maybe. You've already mentionned that you don't like or
use templates. If you don't like or use templates, then many of
the issues do disappear."
That's good to know.
I've seen you lately too note that some shops
restrict use of templates and seem to be accepting of such. Yet wasn't I a
big thorn saying such blasphemous stuff a few months ago.
" As it happens, I'd like to use
templates, but most companies still forbid them at the
application level, because of portability problems. There are
things in Boost I'd like to use, but some companies still forbid
even the standard library, because of portability concerns (and
in fact, we've had problems recently when porting code from Sun
CC to g++, and vice versa)."
Oh, even the standard library huh. See, I didn't know that there was anyone
out there agreeing with me on that.
"Use Comeau and the Dinkumware libraries everywhere, and this set
of problems disappear. (Use C90, and they disappear as well.
Interestingly enough, use C99, and you run into exactly the same
sort of problems. Which sort of proves that the problem isn't
with the complexity of the language per se, but with the
decision of compiler vendors to more or less ignore the
standard, at least in part, and with compiler users to accept
this without complaint.)"
No, I don't think that proves that C++ isn't too complex.
Again, that's a (THE) problem with C++.
"And C. And Fortran. In the past, it was always a serious
problem with Cobol---today, the only people using Cobol are on
IBM mainframes, so the problem has disappeared."
I think C++ is an escalation of the problem (but I'm not a compiler
developer, so I don't really know how bad it is).
(Unless of course there are inclings
that the platforms are competing with languages with their own APIs and
therefor purposely avoid implementing certain language elements).
"In at least one case (and no, I'm not thinking of Microsoft
here), it's very clear that the vendor would prefer that all
developments use his own language,"
Reference to Sun noted. Free Solaris looked cool until it became just a Java
delivery vehicle.
" rather than C++. More
generally, it is a question of allocation of resources, and it
would seem that most vendors, today, are more concerned with
somehow "locking you in", or at least supplying special platform
specific features, than being standard conformant. So that's
where they put their resources."
As if "C++" was not attempting to do the same.
Now that IS a valid potential use, if one decides that "the
more compilers we run the code through the better". But again,
it's a fundamental language problem IMO.
"A problem shared by most languages today, it would seem. (Ask
about support for C99 in comp.lang.c, for example.)"
The thing is though, the C guys (whoever they are) may be able to execute an
object paradigm that would give the C++ folks shudders.
John
