#Which C++ version?
57 messages in this thread
What wonderful news to have SAS upgrade their C compiler into the 90s. I have
always thought that the Amiga environment would lend itself well to C++.
The big question is, what version of the language will be implemented?
Will it have Templates? Multiple inheritance? How about the non-standard, but
quite useful extension Borland made to their C++, dynamic dispatch:
class { …
void HandleClick() = [MOUSE_CLICK_EVENT];
}
Or do we still have to buy Commeau C++ to get the first two features?
I caught this conversation somewhere in the middle but I was wondering
about SAS C++. My questions are:
1) Availability
2) Cost
3) AT&T Version (2.0 or 3.0)
In addition, I was wondering if any users here have gcc and g++. If so,
I would like to know:
1) What version of gcc/g++
2) Whether or not you can use Manx C/SAS C with g++
3) Associated tools supporting gnu compilers (make, lint, gdb, etc)
Any help in this area would be greatly appreciated.
I am going to be buying an additional hard drive soon so that I will be
able to install either one of those monsters! (I have 1M left on my 50M
drive).
Thanks,
Dan Barber
barber@mdso.vf.ge.com
Hi Dan,
The original schedule for SAS/C C++ called for shipping in September,
but unfortunately that has now slipped four to six weeks, so we'll be
shipping in October or November. It turns out that our page count
estimates for the revised documentation were off by several hundred
pages, and we are going to have to reprint all the manuals instead of
just doing change pages. This required a renegotiated schedule with
the printer. I don't have a firm ship date yet because those
negotiations are still going on.
As for cost, we have not gotten the printers' cost estimates yet, so
we haven't set any prices. I'll be sure to announce it here when we do.
As I just posted in another message, we are compatible with the current
ANSI committee working paper minus templates and exception handling. The
ANSI committee has adopted the C++ 3.0 ARM as a base document, so with the
exception of those two areas, we are C++ 3.0 compatible.
Doug,
Don't you mean the re-release of C++? Didn't Lattice sell a C++ compiler
three or four years ago? I seem to remember AmigaWorld ads with some sort
of dragon/lizard/demon creature. I know SAS is not Lattice, but it is
where the compiler started.
Steve
Steve,
No, it's definately not a re-release, and the SAS/C++ compiler did not
start with the Lattice compiler. The Lattice C++ offering was actually done
as a port of AT&T cfront 1.0 by a third party, and marketed and supported by
Lattice. Royalties were paid to the third party. SAS/C++ is not dependant
on cfront and was done entirely in-house at SAS Institute. Our new release
should rightfully be considered a brand-new product.
We do offer an upgrade from Lattice C++ to SAS/C Version 6.0, just like we
offer an upgrade from Lattice C to Version 6. This will most likely
continue.
–Doug
Thanks for the info Doug. I hope to have an additional hard drive
soon (hopefully before you release your software). I may be in the
market for your product!
Thanks,
Dan Barber
barber@mdso.vf.ge.com
I missed the start of this thread, so this may be asking something
you've already said… Is the C++ compiler you're producing going
to be a wholly seperate product from the SAS C compiler (like the
original Lattice C++ was seperate from Lattice C), or is it going to
be one big integrated program, which compiles both C and C++ code
(like, for example, Microsoft C/C++ 7.0 on the PC…)?
I guess another way of putting it is: Will owners of SAS C 6.0 need to
buy a seperate product for the C++, or will it be an upgrade (ie. SAS
C/C++ 7.0 or something…)?
Since while I dabble in C++, I haven't yet found anything it does that
I can't code in C more clearly and efficiently, I'd probably not go
for a seperate product, but as an upgrade to the C compiler which
just happens to include C++, I probably would.
–>Steve Bennett
>Since while I dabble in C++, I haven't yet found anything it does that I can't
>code in C more clearly and efficiently
That (not clear, not efficient) is definitely contrary to my experience and
in fact one of the reasons I now produce Comeau C++.
Well, to each their own… <grin> I won't argue about the merits of C
vs C++, but I will make a general programming comment: It is
possible to code in ANY language in such a fashion that the code is
clear, efficient, relatively easy to debug and maintain, and can be
picked up and understood by anyone who understands the language it is
written in. It simply takes the correct attitude and a willingness
to spend the time to do the job right. Even FORTH code (my favorite
example…) can be written in such a manner.
On the other side, it is equally possible to code in ANY language so
that it is totally unclear, highly inefficient, impossible to debug
or maintain, and anyone trying to pick up the code and understand it
would be better advised to rewrite it from scratch. ANY language. No
exceptions. Some languages make it more difficult to do it that way,
but anyone determined to write bad code will find a way, by accident
or purpose… Again, it's a matter of additude.
C++ does a very good job of guiding programmers into writing better
code. My biggest problems with it are more personal irritations
rather than flaws in the language. (For example, I happen to be one
of those old C nuts who seriously prefer the old style function
declarations, although seperate prototypes are nice…) I'll
probably end up switching over to C++ in time, and may even get to
the point where I prefer it over C. I already code most of my C code
in such a fashion that switching to C++ would be a fairly trivial
change. But for now, C is good enough for what I need to do.
You just know know know that you're provoking me to post a sexy,
lively, and provocative message, now dontcha! 😉 I gotta leave in
about 5 minutes for a lecture I'm doing in Manhattan, but I can
assure you, a post is still coming 😉
I could swear I've read this same message in several different places
over the last few years. 🙂 And I've read the message Greg will
write in reply several times, too. 🙂
I agree with Greg's side.
Dale Larson
– An Amiga Software Engineer with some time on his hands.
Um… I think I've *written* that same message in several places over the last
few years… <grin>
And I've seen that reply too… <bigger grin>
I don't really mind being in the minority in my opinions of OOPS languages. I
know I'm right… <evil grin> Okay, so maybe I'm *not* right, but it's still
my opinion. At least it's an educated opinion – I've encountered an awful lot
of people over the years who aren't even willing to consider the advantages of
Language X or programming technique Y (How many programmers even *know* what
Data Flow Design is? They don't teach enough nowadays… <sigh>), but haven't
even tried them to see whether it's appropriate or not. I'm usually willing to
give the benefit of the doubt. (Exception – ADA. I read through the early ADA
language specification and gave up on it right there… Probably I'm overdue to
look at it again, but I don't have any excuse or inclination to do so at this
point… 🙂
Keep on trying to convince me, though… There have been times in the last
year where I looked at a piece of code and told myself that it would perfect
for recoding into C++, but I didn't do it because I don't like to do things
half one way and half another. Consistancy is far more important in writing
maintainable code than just about anything else I can think of… IMHO
<snicker>.
–>Steve Bennett
I don't feel any need to convince you to believe the same things I do. We
mostly agree any way — that 90% of the battle is approaching programming
as a small part of an overall engineering process which has
understandabily/maintainablity/etc. as a principle requirement. Whether
the rest of the 10% should include OOPS isn't much of a debate item until
more people are convinced about that 90%.
Dale Larson
– An Amiga Software Engineer with some time on his hands.
>Whether the rest of the 10% should include OOPS isn't much of a debate item
>until more people are convinced about that 90%.
If you mean stuff like attitude, getting to know the problem, researching
alternative, team work, etc, then I'm apt to agree. If you mean something
else, then I might not. That is, as you "get closer" to the solution
domain, thing like OO just can't be slapped on at some point. This is not
to say there isn't leverage in anything, but just that it can matter.
Is this what you meant by the 90/10?
>I've encountered an awful lot of people over the years who aren't even willing
>to consider the advantages of Language X or programming technique Y
Yes. It's a big problem in general. No problem from me when people express
their biases, but I do see some folks not even narrow-minded but more like
ignorant and proud of it, but also still wanted to make a point. Nothing
like trying and not liking, which is tons different that not understanding,
not trying, but still being biased.
> (How many programmers even *know* what
>Data Flow Design is? They don't teach enough nowadays… <sigh>),
They probably never did!
> but haven't even tried them to see whether it's appropriate or not
Exactly part of what I was alluding to above.
>Keep on trying to convince me, though…
Frankly, I think trying to convince is somewhat misguided. One of the
things I like about CIS et al is being able to exchange information.
Only by understanding each other can we continue to grow. So, I'm more
interested in hashing out all the issues and let the facts remain than to
necessarily to convince somebody of something (though agreement might be
nice, I'd rather agree to disagree while understanding the opposing point of
view, than to simply disagree).
>There have been times in the last
>year where I looked at a piece of code and told myself that it would perfect
>for recoding into C++, but I didn't do it because I don't like to do things
>half one way and half another. Consistancy is far more important in writing
>maintainable code than just about anything else I can think of… IMHO
For real stuff, I think this is probably a good thing to do.
However, for the sake of getting to know the nooks and crannies
such a conservative approach might lead to some detriment when that
time finally comes. IOW, time permitting, it's best to toy around with
a bunch of not so serious projects or better even toy projects for when the
time is right.
Heh… Actually, it's only the real serious projects I ever get to thinking
about doing something over in C++. That's because the real projects always
have deadlines and every once in a while something which could have been
designed better gets coded a different way early on, and then when the better
ideas come out, it's too late to change it because too many other things depend
on the original code. I hate it when that happens… <sigh>
With my "fun" projects, there's usually no time pressure, so things tend to end
up cleaner, and tearing code apart to write it a better way happens all the
time. I tend to have all the data constructs and relationships in place in the
design long before I need to code anything for them, so the code ends up much
more elegant that way. Of course, it takes forever to get things done this
way, but where's the rush? <g>
The most likely candidate for me to fool around with new things (languages,
design techniques, etc…) are usually the smaller toys. Unfortunately, these
don't allow enough experimentation. I'll have to get around to trying one of
my larger ideas in C++ at some time, just to see how well it turns out…
–>Steve Bennett
>Heh… Actually, it's only the real serious projects I ever get to thinking
>about doing something over in C++…..
>..The most likely candidate for me to fool around with new things (languages,
>design techniques, etc…) are usually the smaller toys. Unfortunately, these
>don't allow enough experimentation….
Yes, such is life. 😉 Anyway, what is nice even given this is that as you
mention there is no pressures and hence you can get to know lots more about
the features than just the textbook explanations.
I have been looking in the want ads of *many* of the papers in the
northeast, and I have only seen one newspaper that has ads looking for Ada
AT ALL, and that was the Washington Post. It is the only language I know
of where even + is not defined as part of the original language.
John
John –
The function "+" is a predefined operator in Ada. Like the predefined abstract
data types (Integer, Float, Boolean, Character, etc.) and other predefined
operations on these ADT's, it is specified as part of package Standard, and is
included in the Ada Language Reference Manual.
Jeff Schweiger
>It is possible to code in ANY language in such a fashion that the code is
>clear, efficient, relatively easy to debug and maintain, and can be picked
>up and understood by anyone who understands the language it is written in.
That last clause is very supporting. But I am not at all convinced one
can reach that kinda goal with "ANY" language.
>It simply takes the correct attitude and a willingness to spend the time to
>do the job right….
I know what you are speaking of here. Especially when you raise the point
where it is possible to write bad code in any language. However, certainly
some languages are more efficient than others (but probably not to the
extext that say the press would have you believe, for instance, for years it
was touted how efficient C was over other language, and although C is
efficient more or less as a GP lang, indeed so is something like Pascal),
certainly some are cleared and easier the debug and so on. Even some "same"
language are clearer, easier, etc than themselves so to speak. For instance,
1993 BASIC is surely clearer, easier, whereas 1980 BASIC was not. Was it also
make more compilicated? Absolutely. Or take the case of this thread:
C to C++. Surely C++ is more compilicated and continues in C's "ugly"
fashion, however, it capability in "aiding the algorithm" in its power of
expression that class et al gives it certainly is for some sense of clarity
and so on. Re C++ efficiency, on average, it is just as fast (or slow
depending upon your perspective!) as an equivalent C program. Assuming both
are well written whatever that may mean.
>Some languages make
>it more difficult to do it that way, but anyone determined to write bad code
>will find a way, by accident or purpose…
This is all I'm saying but applying it to both ends of the stick.
That is, not only can some language let you sink easier, but IMO some
languages let you swim better too.
> Again, it's a matter of additude.
Definitely one piece to the formula, but the forumla it is not.
>C++ does a very good job of guiding programmers into writing better code. My
>biggest problems with it are more personal irritations rather than flaws in
>the language.
I generally won't contest that one. In fact, as much as I obviously like C
and C++, tons irritates me about both.
>(For example, I happen to be one of those old C nuts who
>seriously prefer the old style function declarations, although seperate
>prototypes are nice…)
I can see you saying that you prefer the K&R function syntax over the ANSI C
syntax (really C++ where it was borrowed from), however, I cannot see you
saying that you prefer the semantics of the K&R style.
I love to disagree. I've programmed in languages ranging from
BASIC to C++ (yes, I've actually got this beast working, somewhat),
and I ALWAYS program clearly. Frankly, I didn't have much choice in
the matter as I would only be three years, at most, in any one duty
station. Someone down the road would have to maintain my code.
Comments were essential.
I do have to completely disagree with your comments with respect
to BASIC. For several years, there were BASIC compilers with all of
the structured programming concepts in place well before they ever
hit the micro-computer environment. I've been using structured
programming concepts in the mini/main-frame enviroment for years, at
least since 1980, well before such concepts hit the micro
environment. I'm sorry that this may dispell some notions of the
progress of computer language developement, but it _is_ true. 1993
BASIC is no clearer, at least in comparison to 1980 BASIC on a
mainframe or a mini. It is, perhaps, more obscure, IMHO.
>I ALWAYS program clearly.
I can't fathom this. Certainly I have always make an effort to program as
clear as possible, however some language straighjackets did not (and still
do not) always let me do it to the extent that I would have liked.
Re BASIC: fine, go back to 1977 then. That wasn't the point.
Nor is it to pick out extensions, etc. Which of these two flavors
is best:
1) id = foo(abc, xyz)
2) t1 = abc
t2 = xyz
gosub blah
id = retval
Or take FORTRAN's: if (…) 100, 200, 200
These are not intended as attacks against these languages. If we're
talking about clear though, that IS NOT. Yes, there are clearer ways
to do this in FORTRAN (sytactically and via convention) but nothing
like literally having blocks and else's. As I understand it in a
conversation I had with somebody who claimed to be well in sync with
the FORTRAN 7x and 9x standards, they still do not have this. Yes, I
know some FORTRAN's do though, I gladly worked with them 15 years
ago. I think you would have too and probably did make the same
choice. Did you? If so, why?
>I'm sorry that this may dispell some notions of the progress of computer
>language developement, but it _is_ true.
Certainly no notions that I have. There's been a lot of stuff for a long
time now. In fact, re true, most of what we're doing is simply rehashes of
earlier things.
>It is perhaps more obscure, IMHO.
There is no doubt that some languages are getting more complicated
syntactically and otherwise, and hence clarity and obscurity can walk
hand in hand in some cases.
At Siggraph, Frederick Brooks stopped by my booth. He was legitimately asking
about our 3D products, but I was stunned to meet him. I'm not impressed by
"celebrities" but Brooks is someone I can respect. A friend of mine started
talking to him about what improvements in languages have been made in recent
years… Brooks said that he didn't think much had truly changed since the
jump from assembler to procedural languages. 🙂
And BTW, I had to fork out for the Metaware / Pharlap 32-bit compiler system
for some PC development. Do you have any consolations or words of advice that
would make me feel better or worse about this $1K purchase? Any thoughts on
Symantec C++ for Windows? It's just the newest version of Zortech, right?
>Brooks said that he didn't think much had truly changed since the
>jump from assembler to procedural languages. 🙂
Similar to one comment I'd made in this thread. In one way we've gone
somewhat full circle on it. The big difference, er effect, and acceptance,
and even perception is what is being presented to and with the masses.
This is not to say other grounds are being trecked on, but some type of
natural frequency gap is merely just closing from what I can see.
>And BTW, I had to fork out for the Metaware / Pharlap 32-bit compiler system
>for some PC development. Do you have any consolations or words of advice that
>would make me feel better or worse about this $1K purchase?
None!
>Any thoughts on Symantec C++ for Windows? It's just the newest version of
>Zortech, right?
Yes and no. It looks like Symantec played their cards right.
If it measures up to appearances, they can regain quite a bit of
the lead they slowly and then rapidly lost. There is of course the
battle of synergy and whether they can whip it or not. They of course
can't blow any lead they might get or else they will blow it for some
years to come (IMO).
Brooks is a neat guy. He chaired my master's oral committee.
He has some really strong opinions on software architecture (of course), and
some real good stories from the "old days".
–Doug
Greg,
and as I pointed out, I did this using comments in ALL my code. I
comment each and every line explaining as I go exactly what I was
attempting to do in that language. While I realize this is not the usual
practice in the industry, I really had no choice in the matter as I was
only serving in any one place for three years, at best. Comments are
always the best weapon against obscure code. I thought this was
self-evident, apparently not. This is an issue that transcends the
particular language under review.
Brian
>as I pointed out, I did this using comments in ALL my code.
Comments DO NOT a clear program make.
Are they important? Yes. Are they they the full formula? Definitely not.
>Comments are always the best weapon against obscure code. I thought this
>was self-evident, apparently not.
Definitely not at all IMO. My experience has led me to want them, however I
don't view them as extremely as you, but as one my piece to the puzzle and
but one more weapon. Which is best depends upon the issue at hand.
You don't buy, in addition to _accurate_ comments, issues like making
code more self-documenting? Or, in some case, rewriting code? Or using a
different algorithm? Or in others, making identifier names more appropriate?
Etc… (all when obsurity is not in order that is).
I thought thesealternatives were self-evident.
>This is an issue that transcends the particular language under review.
Surely. I sense that you are placing too much faith or something in them
though. This is not to dispute that I want to add them in my own code and
see them in somebody else's, but the act of commenting alone is not the
bottom line IMO.
We won't talk about issue like comments that are wrong and stuff like that
either. Oh boy, are they fun! 😉
There are no bad languages, only bad programmers(Of course, you'd have to
shoot me before I wrote one *word* of COBOL code).
John
>There are no bad languages, only bad programmers(Of course, you'd have to
>shoot me before I wrote one *word* of COBOL code).
Jokes aside, I might agree that there are no "bad" languages:
Afterall each was created for in intended purpose and probably met it
in part. OTOH, that doesn't mean they meet the "test of time" and
such so from that perspective they might be "not good" (BTW, by test
of time I do not mean popularity, that's no doubt a bad and bogusy
gauge). There's also the case of using the wrong language for a
given job (though that's another issue).
Anyway, my points are simple: all languages (computer or otherwise,
spoken or written, etc) are not created equal. Certainly some issue
are debatable forever as eye of the beholder issues, others as
contextual, etc, but certainly some are not (and I speak not of just
syntactic issues).
Sheesh, what a thread. Next thing you know someone's going to say APL
has an obscure syntax! Speaking of APL, given the language's inherent
parallelism, am I the only one who thinks it might make a big
comeback with the advent of cheap multiprocessor systems?
Of course APL has an obscure syntax (to the neo, and compared with
some GP langs). But every language has some flavor of obscurity
too. I know a number of folks using APL but don't know if they have
been using it for years or if it was recent events that directed
their decisions.
David,
re: "Speaking of APL, given the language's inherent parallelism"
inherent parallelism ???
I'm going to reply here somewhat indirectly to a number of things in this whole
thread. Anyone who wants to disagree with me, go right ahead… I can take
it. <g>
First off, lets define the practice of coding "clearly". I get the impression
that some people think of this differently than what I consider this to be.
Clearly written code is something which may not look pretty, but is extremely
obvious to just about anyone as to what it does. This should not be confused
with *elegantly* written code, which looks awfully pretty but doesn't
necessarily make it obvious what it actually does. That's not to say that any
given piece of code can't be both clear and elegant, they can. I'm only saying
that these are two seperate things.
And indeed, this may be the whole core of the argument. I prefer to write code
clearly ALWAYS, but elegance is an optional luxury, done if possible, otherwise
tossed to the four winds. More often than not it *is* possible to do both, but
some things just don't turn out that way in all languages.
Now, I'm generalizing a bit here, but in my experience, OOPS languages tend to
make it possible to write elegant code very easily, but also seem to have a
tendency to make code less clear, IMHO. That's inherent in the concepts of
OOPS, by the way.
One of the very concepts of OOPS is to encapsulate data, in essence hiding it
from the rest of the program. Data which is part of an object is operated upon
by code which is also part of the object, and may be hidden from the rest of
the program. Another concept is inheritance, where an object may inherit some
or
all of the data and code of another object. Between these, you may end up with
a higher level object to which the behaviour of simple operations is rather
obscure.
An example (a somewhat lame one…):
Given a very elegant line of code (specific language is irrelevant, anything
would do…):
where_am_i = start + amount_of_travel
…at first glance seems quite clear, but in an OOPS environment you may be
easily misled into thinking you know what the line does, but in fact, it does
something quite different, especially when you look around the program and run
into the fact that where_am_i and start are both GlobalCoordinates and
amount_of_travel is a FlightPath. Only then do you realize that the line might
do something extremely unusual, leading you to go look at the objects
themselves to see how they handle being added together…
On the other hand, a C subroutine:
calc_destination_from_flightpath(&where_am_i, start, flightpath);
is far from elegant, but makes it extremely clear to the reader that something
rather
complicated is occurring whether he knows the types of the variables or not,
and that to find out exactly what is going on he'll have to look at that
function's code.
This isn't to say that all OOPS code looks like my example. A lot of OOPS
programmers probably know better than to do things like that (Heck, I do
myself… <g>), or when they do decide such a thing is desirable, have other
ways of making things clear (I can do that too… :). Nor does all C code
look quite as ugly as that function call. I'm just trying to point out what I
think people have been lumping together here to show that they're two seperate
things. (I think one of my pet nitpicks, not limited to OOPS languages, also
shows through here… I think operator overloading is an unnecessary and
dangerous evil… <g> And no, I *don't* want to argue the point… 🙂
Whew… that's an awfully long message… I think I better climb off the soap
box and let you folks differ with me for a bit before I go onto some of the
other concepts we've been discussing…
–>Steve Bennett
>Whew… that's an awfully long message… I think I better climb off the
>soap box and let you folks differ with me for a bit before I go onto some of
>the other concepts we've been discussing…
Heck no. Perhaps this was just some initial misperspection of terms…..
I say climb right back on that sucker and keep pontificating.
I'll probably come back to this again tonight for the sake of provocating
more healthy discussion and hence nitpick some ;-}, but in general, I don't
think I have any grave serious problem with the gist of what you've said.
Sorry, Steve, you won't get any arguments from me on coding "clearly" vs.
"elegantly", as well OOPS tending to lend itself to the "elegant" moreso
than the "clear".
Robb
>clear… elegant
Of course there are various interpretations of both these words, and their
combo.
>More often than not it *is* possible to
>do both, but some things just don't turn out that way in all languages.
Yes, part of what I've been trying to say!
>Now, I'm generalizing a bit here, but in my experience, OOPS languages tend to
>make it possible to write elegant code very easily, but also seem to have a
>tendency to make code less clear, IMHO. That's inherent in the concepts of
>OOPS, by the way.
I would not dismiss for a second areas where OOP can't measure up etc, however,
I think a level of this is inherent in all approaches. IOW, what I'll
nitpick here is probably the overgeneralization, but not the general
comment.
>One of the very concepts of OOPS is to encapsulate data, in essence hiding it
>from the rest of the program. Data which is part of an object is operated
>upon by code which is also part of the object, and may be hidden from the rest
>of the program. Another concept is inheritance, where an object may inherit
>some or
>all of the data and code of another object. Between these, you may end up
>with a higher level object to which the behaviour of simple operations is
>rather obscure.
Yes, I've seen that occur. In some cases though the designs/authors were at
fault. In others, yes, clearly the mesh between the complexity of the
abstraction and the implementation form, etc. But as in above, I've seen
both these cases in non-OOP considerations as well.
>An example (a somewhat lame one…):
In almost all cases, I am against operator overloading so you have my
support there. However, re things like: "…at first glance seems quite
clear, but in an OOPS environment you may be easily misled into thinking you
know what the line does, but in fact, it does something quite different", I
think again you're pinning way too much on OOP. First OpOv is not formally
OOP anyway. Second, I think all you are doing is demonstrating not only one
problem with user-defined types, but the built-in ones as well. That is, we
"all know what addition is", but I'll claim that almost no one knows the
full rules of + on even fundamental types (no less user defined ones).
>On the other hand, a C subroutine:
> calc_destination_from_flightpath(&where_am_i, start, flightpath);
>is far from elegant, but makes it extremely clear to the reader that something
>rather complicated is occurring
Yes. And going full loop from the comment above, some might say this is
hence clearer. As with all things it depends upon the context though.
Forms of syntactic expression do have their place. They should just not be
abused of course.
But then, the whole point of OOP design is to develop objects and the
functions that act on those objects to be black boxes. Once you build an
object, the only thing another programmer has to worry about is what goes
in and what comes out. Whatever the object does in between is of no
concern to the programmer developing it. If, for example, you define a
objects of stuff and morestuff and have a function in stuff called add,
and a function in morestuff called add, and you have the following bit of
code(in a pseudo-OOP langage):
/*adds stuff and morestuff*/
stuff thisvariable
stuff thatvariable
morestuff thisothervariable
morestuff thatothervariable
thisvariable.add(thatvariable)
thisothervariable.add(thatothervariable)
What "add" does is unimportant to the programmer using add. All the
programmer needs to know to use "add" is what it does, not how it does it,
and that means that reinventing the wheel becomes far less likely, because
good OOP design means you see more black boxes than anything else.
John
John,
Your point is very clear however, it still points out that OOPS tends to
the "elegant" and not the "clear". Sure, black boxes that do what you want
them to are very nice but, they don't tell you what's going on if you need
to figure out what someone else has written or give you any idea where to
find out. (IMHO) I like the concepts of OOPS languages but, I dread the
day when I have to figure out where the documentation is for all those
"black boxes" happens to be, for some 10's of thousands of users who
cannot get to what they need and the original programmer has been canned
to save $$$$.
Robb
>Your point is very clear however, it still points out that OOPS tends to
>the "elegant" and not the "clear". Sure, black boxes that do what you want
>them to are very nice but, they don't tell you what's going on if you need
>to figure out what someone else has written or give you any idea where to
>find out.
I don't understand: are all your programs nothing but sequential
mainline code?
I'm seeing a trend in these last few messages to credit/blame OO for traits
which, while it does have them, that it only has. IMO, it isn't the only
thing to have them. Further, if the task is not to bubblize as much as
possible for isolating functionality/etc, what is the task?
> (IMHO) I like the concepts of OOPS languages but, I dread the
>day when I have to figure out where the documentation is for all those
>"black boxes" happens to be, for some 10's of thousands of users who
>cannot get to what they need and the original programmer has been canned
>to save $$$$.
I can only repeat my statements above. I can't tell you how many non-OO
project I've done under such conditions. This is NO special trait of OO.
If anything, it can be argued that classes are more self-documenting, and as
things are being allow to be fundamentally bubblized, there is no hunting
for things. Blah blah. Anyway, lack of documentation is lack of
documentation. If, as in John's examples, it is not documented what add()
does, no matter what the paradigm, I can only but guess what add() does
(even under the best design and the best named function).
>But then, the whole point of OOP design is to develop objects and the
>functions that act on those objects to be black boxes. Once you build an
>object, the only thing another programmer has to worry about is what goes
>in and what comes out.
That too an extreme position for me. That is, yes, I definitely want black
boxes, and I definitely want encapsultation et al. However, as much as the
interface "is enough" for the thing to work, I may or may not still want a
tailored version. I do want just any chip driving the brakes of my car, but
the one that does. Or more practically, I may not want a fat
implementation, but a slimmer yet slower ones, etc. Also, there are somewhat
different aspects as box author, inheritor, user.
>Whatever the object does in between is of no
>concern to the programmer developing it.
Again, from an abstract sense yes. Following through with the two examples
above: I don't want the chip braking when my foot is not on the brake.
Or, in the second case, I might now want a box doing memory management under
certain situations.
>What "add" does is unimportant to the programmer using add. All the
>programmer needs to know to use "add" is what it does, not how it does it,
>and that means that reinventing the wheel becomes far less likely, because
>good OOP design means you see more black boxes than anything else.
Yes, but let's not just pat OO on the back for this.
I would take OOP out of that last sentence. OTOH, a language
supporting OO will provide some more intrinisic features to allow
this to happen easier/under more contexts/etc.
Actually, you make my point better than I do myself… You're quite right, all
the programmer needs to know is what goes into add and what comes out of it.
But he *HAS* to know that. Which is my whole point. Looking at just the few
lines of code you wrote in your message, I have absolutely no idea what add
does, nor for that matter what stuff or morestuff are. Even assuming I *did*
know what stuff and morestuff are, I could very easily make an incorrect
assumption about what add does based on it's name and what I know about the
data associated with those objects. Even if there's some document somewhere
which goes into excruciating detail on the stuff & morestuff objects, and what
add does with them, a programmer who has had slight experience with those
objects is likely to see "add" and assume one thing, while the object may do
another thing.
One key to how clear and maintainable any piece of code is, is whether any
generic programmer who knows your programming language can look at any given
function or fragment and quickly figure out from the code & it's comments a
rough idea as to what the code is intended to do. Black Boxes are nice at
times for code development (and they can be done in any language…) but aren't
always so nice when it comes time to pass the code onto someone else to take
care of, since the other person needs to learn all the boxes before he can make
sense of the rest of the code.
And more often than not, I find that most Black Box type code doesn't move well
into other projects. I'm *always* finding it necessary to make changes when I
do things like that. (Of course, I'm always designing custom replacements for
things like controls and the like, *especially* in environments like Windows
where the controls are supposedly "object oriented", not to be confused with
anyone else's definition of the term… <g> With the exception of the standard
pushbutton, I've found it necessary under Windows to rewrite nearly every
standard control my own way just to make it behave *slightly* differently…
<sigh>)
–>Steve Bennett
–>Steve Bennett
>But he *HAS* to know that. Which is my whole point. Looking at just the few
>lines of code you wrote in your message, I have absolutely no idea what add
>does, nor for that matter what stuff or morestuff are. Even assuming I *did*
>know what stuff and morestuff are, I could very easily make an incorrect
>assumption about what add does based on it's name and what I know about the
>data associated with those objects. Even if there's some document somewhere
>which goes into excruciating detail on the stuff & morestuff objects, and what
>add does with them, a programmer who has had slight experience with those
>objects is likely to see "add" and assume one thing, while the object may do
>another thing.
Even assuming add is the right name, and chances are good it might not be,
I find this argument weak. A programmer who has less experience is likely
to assume many things whether that "less experience" means a neo programmer
or one not familiar with the app or etc. The object in and of itself is not
the issue to me. Even in non-OO code, I expect anybody writing or
maintaining it to be understanding programming, the app, the language, etc.
>One key to how clear and maintainable any piece of code is, is whether any
>generic programmer who knows your programming language can look at any given
>function or fragment and quickly figure out from the code & it's comments a
>rough idea as to what the code is intended to do.
I'm still not following: IMO a function *IS* one type of black box.
Perhaps you are speaking of stuff like uncommented code here, or large
functions or something, but I think speaking of these thing re black boxes
and OO is misguided.
>Black Boxes are nice at
>times for code development (and they can be done in any language…) but
>aren't always so nice when it comes time to pass the code onto someone else to
>take care of, since the other person needs to learn all the boxes before he
>can make sense of the rest of the code.
But as I mentioned to Robert, the tradeoff is to write straight mainline
sequential code. We don't do that. The intent is always to hide, black
box, etc. Yes, add too much code to that and you may indeed have a monster,
but that's a seperate issue IMO. That's part of good design, experience,
etc.
>And more often than not, I find that most Black Box type code doesn't move
>well into other projects. I'm *always* finding it necessary to make changes
>when I do things like that.
Although dependent upon the context, you have certainly just prescribed
inheritance. That way reuse doesn't always have to == COPY 😉
Seriously though, this gets back to abstracting properly and such.
A black box that does everything is typically a mistake. And don't get me
wrong about reuse either. It's nice, but I won't tout it anything like some
others do (though most of the folks I respect don't tout it wrongly either).
When I lecture, I'll often pull out the following:
"Reuse is a much a myth as a reality" — Greg Comeau
SAS/C Version 6.50 will be the next upgrade to our product, and
C++ will be included in that upgrade. There will not be a seperate
product.
Excellent. I'm looking forward to the upgrade. (It's kindof funny… I got a
letter from SAS today and said to myself "Ah, this must be the upgrade notice
for the C++!"… I opened it and it was just a notice about the availability
of the 6.3 patch… I was slightly dissapointed, but your note makes me a bit
happier… <g>)
–>Steve Bennett
Steve,
Yes, we are notifying all registered customers about the 6.3 patch and
the availability of the 3.0 includes. This will hopefully tide them over
until November, which is when 6.50 will be available.
–Doug
Could you please quote the letter? How do I get the update?
Hi Dan,
I'm a gcc/g++ V2.3.3 user. The g++ compiler is a native code compiler
so it doesn't generate C code which must be compiled afterwards. The
gcc/g++ compiler is based on a UNIX environment and several UNIX tools are
included in the gcc-distribution. Unfortunately the Gnu debugger gdb isn't
ported to the Amiga yet. Included are a shell, make, ar, nm, man (with the
manfiles for the C/C++ functions, UNIX tools) and lots more.
— Freddy
Hi Freddy,
Thanks for the info on g++. I hope to get some experience with it
at work. I will then attempt to get a copy for home. Not having gdb
is a serious disadvantage, but any c++ at home would be great!
Dan Barber
barber@mdso.vf.ge.com
Glad I could help Dan.
BTW, you can find a copy of gcc 2.3.3 right here in library 4, 'gcc1.lha'
and 'gcc2.lha'. They total about 3.5M and you need both archives.
— Freddy
Hi Murray,
Our C++ is compatible with the current ANSI working paper on C++ minus
templates and exception handling. This is roughly equivalent to C++
version 3.0 minus templates and exception handling.
We already have a project started that will allow us to add templates
for a future release, but it just wasn't going to be ready in time.
Templates are difficult to implement, and it will probably be 12 to 18
months before they are ready.
I've never heard of dynamic dispatch. Care to explain it to me?
–Doug
> C++ version 3.0 minus templates and exception handling.
I guess this is reasonable for most users. As I said, if these extra features
are required then there is still the option of Commeau C++.
I find that C++ makes programming 10 times the enjoyment of non-OO languages.
As for dynamic dispatching – I added that as an after thought to my message. I
haven't thought about how useful it would be on the Amiga, but it is used under
Microsoft Windows to bind specific events (like keystrokes & mouseclicks) to
particular objects that represent an element on the screen.
I wouldn't worry about this too much. I think it is better to implement the
standard features of the language rather than add features available only in
one other compiler produced by a company that makes a habit of creating
non-standard languages (Borland).
Funny, but there are discussions of how to do something like this in C
just by using a "userdata" field in each structure as a pointer to the
handler. I think I saw this in AC/tech and/or AmigaWorld Tech Journal
(before it folded…).
Brian — Cruising on AutoPilot…..
>Funny, but there are discussions of how to do something like this in C
>just by using a "userdata" field in each structure as a pointer to the
>handler.
I suspuct the two are different, though both many easily reach the
same goal. That aside, there is the general issue of violating
encapsulation and such as well as that other explicit source code
gymnastics may have to occur. Sometimes valid, sometimes now.
>I have always thought that the Amiga environment would lend itself
well to C++.
And it does.
>How about the non-standard,
>but quite useful extension Borland made to their C++, dynamic dispatch:
>
> class { …
> void HandleClick() = [MOUSE_CLICK_EVENT];
> }
You mean the one that's so useful they're taking away?
>Or do we still have to buy Commeau C++ to get [templates and multiple
>inheritance]?
You almost make that sound like a bad thing! 😉
>> class { … >> void HandleClick() = [MOUSE_CLICK_EVENT]; >> } > >You
mean the one that's so useful they're taking away?
What!?! They better not! I have heaps of code at work that depends
on this!
>>Or do we still have to buy Commeau C++ to get [templates and multiple
>>inheritance]? > >You almost make that sound like a bad thing! 😉
Far be it for me to belittle such a fine and highly regarded product
as yours. I am just grateful that we have it on the Amiga at all.
For some reason, I prefer to use and program my Amiga more than my
IBM (and I do not consider myself a victim of platform loyalty), so
finding a good C++ has become an increasingly urgent priority.
Especially as I am about to embark on a new major project.
In fact, if I were to complain about Commeau C++, it would be that too
few people actually know about it! You need to send more press
releases out to Amiga publications. Especially since you have major
advantages over the soon to be released opposition.
>>> void HandleClick() = [MOUSE_CLICK_EVENT];
>>You mean the one that's so useful they're taking away?
>What!?! They better not! I have heaps of code at work that depends on this!
Let me rephrase: they're not taking it out of the compiler proper, but
it will have an obsolescent flavor to it in that it is coming out of
OWL.