#SAS dumps Amiga
12 messages in this thread
>I can see how C++ in general will result in larger and slower code
I cannot. This is not to imply that certain features in C++ do not
have performance or size tradeoffs: some unequivocally do.
However, the issue on the table is not to compare features
(but even at this, some C++ features do not have an issue even though
"but they must") but to compare what happens when the same problem
ends up being respectively coded in each (realizing a slight glitch
because "C is C++" (almost)). The end result in general is that
C++ code is just as fast, but larger.
>(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents:
Eh? Or do you popularity-wise?
>- Even though my code is bigger and generally slower, I think the benefits
>of using C++ (or Object Oriented Languages) outway the performance
>degradation.
That might be a valid compromise for some other language since it is not
slower, this conclusion is not valid.
>- After writting your code, you can always find the areas that are
>performance sensitive and write pieces of that code in assembly. If you
>find yourself rewritting everything, then I think there is a problem in
>the design.
Both of these points have _always_ been true no matter what the language,
so singling out C++ here is bogus. (And a nit: going to assembly is
not the only course of action, but certain one that many should consider).
>- You can right class specific 'new' and 'delete' operators to increase
>performance in the creation and destruction of classes that do not need
>the extras that come with 'new' and 'delete'.
If that is deemed to be a problem for a specific app: absolutely.
Greg,
Hi :-). Your late response to my message took my response completley out
of context. In my message, I was describing 'politely' how C++ is NOT
BASIC and performance degradation is not even an issue in my case. So
when I said "I can see how C++ in general will result in larger and slower
code", I was just being polite when responding to a message describing C++
as a language only for super computers.
The following is a list of my messages OUT OF context with the real
context in capital letters:
-1- I can see how C++ in general will result in larger and slower code.
I WAS BEING POLITE, NOTICE THE WORD 'GENERAL'.
-2-(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents.
HERE I WAS REALLY SURPRISED WHEN I READ THE MESSAGE, SO I WROTE THE ABOVE
SENTENCE.
-3- Even though my code is bigger and generally slower, the benefits of
using C++ (or Object Oriented Languages) outway the performance
degradation.
THE BENEFITS OUTWAY THE PERFORMANCE DEGRADATION (WHICH ARE MINISCULE)!.
Ok now that I am little bit in context, I'll respond to some of your
points, followed by a question:
>I cannot. This is not to imply that certain features in C++ do not have
>performance or size tradeoffs: some unequivocally do.
>However, the issue on the table is not to compare features
The issue was that C++ will result in super slow code and the language is
bad and decreasing in popularity which resulted in my message. C++ is NOT
a language for super computers only and its NOT decreasing in popularity.
As a matter of fact, one of the main reasons its increasing in popularity
at a much higher rate than SmallTalk for example, is because of the
speed.
—————————————–
>C++ code is just as fast, but larger.
I agree, but I guess 'just as fast' will depend on your compiler.
Sometimes 'larger' implies 'slower'.
—————————————–
>>(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents:
>Eh? Or do you popularity-wise?
Yes popularity wise. I get very discouraged when I see messages from
leading Amiga developers discrediting an entire language. I would like to
have RogueWave's libraries ported to the Amiga. I would like ZINC, ZAPP
and XVT crossplatform development tools include the Amiga as one of the
platforms. I would like an Amiga that I buy in the store that has
networking and mail built in. How about OpenDoc on the Amiga. But when
your leading Amiga developers campain for assembly as the only true
langage, then the only way is popularity-wise. (and in this case its not
C= who is hurting the Amiga).
——————————————-
>>- Even though my code is bigger and generally slower, I think the
>>benefits of using C++ (or Object Oriented Languages) outway the
>>performance degradation.
>That might be a valid compromise for some other language since it is not
>slower, this conclusion is not valid.
THERE IS a performance degradation. Pick a program or several programs
that we will both code to the best of our abilities in C and C++ then
compile using SAS (cfront 2.1 :-)) and we'll see the difference.
——————————————-
>>- After writting your code, you can always find the areas that are
>>performance sensitive and write pieces of that code in assembly. If you
>>find yourself rewritting everything, then I think there is a problem in
>>the design.
>Both of these points have _always_ been true no matter what the language,
>so singling out C++ here is bogus. (And a nit: going to assembly is not
>the only course of action, but certain one that many should consider).
If the points are true for all laguages that means its true for C++.
Since we were talking about C++, singling out C++ is NOT bogus.
And finally the question:
The thread started with SAS dumping the Amiga and someone saying that
SAS's work is anyway complete. Then I responded that as far as C++, its
not really complete since I miss templates and expection handling and a
few other things. Then a bunch of messages were added about how bad C++
for the Amiga is. Are you against or with C++ development on the Amiga
platform? or are you just discussing langages in general?
Hani
>Hi :-). Your late response to my message took my response completley out
>of context. In my message, I was describing 'politely' how C++ is NOT
>BASIC and performance degradation is not even an issue in my case. So
>when I said "I can see how C++ in general will result in larger and slower
>code", I was just being polite when responding to a message describing C++
>as a language only for super computers.
I think I took your message less out of context than you think.
I think the difference in my style of posting might be at issue.
When I post, I must unfortunately wear a number of hats and am
often provocative.
>The following is a list of my messages OUT OF context with the real
>context in capital letters:
>
>-1- I can see how C++ in general will result in larger and slower code.
>I WAS BEING POLITE, NOTICE THE WORD 'GENERAL'.
My disagreeing by saying it might be larger, and won't be slower,
in general, is neither polite or impolite, it is the technical issue at hand.
Nothing is out of context here.
>-2-(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents.
>HERE I WAS REALLY SURPRISED WHEN I READ THE MESSAGE, SO I WROTE THE ABOVE
>SENTENCE.
I didn't even have a statement on this, it was a question with _no_
indication of a statement from me whatsoever.
So nothing was out of context here either.
>-3- Even though my code is bigger and generally slower, the benefits of
>using C++ (or Object Oriented Languages) outway the performance
>degradation.
>THE BENEFITS OUTWAY THE PERFORMANCE DEGRADATION (WHICH ARE MINISCULE)!.
They — in general — are not miniscule, they are statistically
non-existance, hence, again, there is nothing happening out of context here.
>Ok now that I am little bit in context, I'll respond to some of your
>points, followed by a question:
Just saying you're in context does not make you so.
I am not trying to be a wise guy here, I just see you trying to
defend your point of view on some technical issues with non-technical
arguments. I am glad we are now going into those issues below.
>>I cannot. This is not to imply that certain features in C++ do not have
>>performance or size tradeoffs: some unequivocally do.
>>However, the issue on the table is not to compare features
>
>The issue was that C++ will result in super slow code and the language is
>bad and decreasing in popularity which resulted in my message. C++ is NOT
>a language for super computers only and its NOT decreasing in popularity.
>As a matter of fact, one of the main reasons its increasing in popularity
>at a much higher rate than SmallTalk for example, is because of the
>speed.
So if I gather right, you are agreeing with me? Great then.
>>C++ code is just as fast, but larger.
>
>I agree, but I guess 'just as fast' will depend on your compiler.
Yes, so this is a non-issue per se. I often say that it is "just as fast,
or slow, as C" as well, which of course means the same thing from another
facet.
>Sometimes 'larger' implies 'slower'.
Sometimes. Two common issues involving this include:
(1) "process" load time under some OS's/environments
(2) things like virtual memory
They can indeed be real issues, but as well, in general,
there is an aspect to it that transcends the language so it
does tend to become more an OS et al specific issue.
This of course does not imply throwing it out the window though.
>>>(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents:
>>Eh? Or do you popularity-wise?
>
>Yes popularity wise. I get very discouraged when I see messages from
>leading Amiga developers discrediting an entire language. I would like to
>have RogueWave's libraries ported to the Amiga. I would like ZINC, ZAPP
>and XVT crossplatform development tools include the Amiga as one of the
>platforms. I would like an Amiga that I buy in the store that has
>networking and mail built in. How about OpenDoc on the Amiga. But when
>your leading Amiga developers campain for assembly as the only true
>langage, then the only way is popularity-wise. (and in this case its not
>C= who is hurting the Amiga).
Again, I only asked a question and I had no indication as to what you meant.
I totally agree with some of this things you've just said. In fact,
I very strongly agree.
>>>- Even though my code is bigger and generally slower, I think the
>>>benefits of using C++ (or Object Oriented Languages) outway the
>>>performance degradation.
>
>>That might be a valid compromise for some other language since it is not
>>slower, this conclusion is not valid.
>
>THERE IS a performance degradation. Pick a program or several programs
>that we will both code to the best of our abilities in C and C++ then
>compile using SAS (cfront 2.1 :-)) and we'll see the difference.
THERE ISN'T. And one program isn't going to show this. Nonetheless,
you pick the program, code it for us in both languages, and
report the results. And please do keep the programs in context.
That is, definitely discard that C is part of C++, that C or C++
can be shown to be faster/slower than itself, etc.
Anyway, I'm confused: you agree above that it is just as fast, albeit
somewhat larger. Instead of getting into details on saying I'm taking
you out of context again instead of simply considering that I don't
understand what you mean yet then, let's just do the _information exchange_
on it (that's what I'm here for) to get at the roots of the issue.
>>>- After writting your code, you can always find the areas that are
>>>performance sensitive and write pieces of that code in assembly. If you
>>>find yourself rewritting everything, then I think there is a problem in
>>>the design.
>
>>Both of these points have _always_ been true no matter what the language,
>>so singling out C++ here is bogus. (And a nit: going to assembly is not
>>the only course of action, but certain one that many should consider).
>
>If the points are true for all laguages that means its true for C++.
Correct.
>Since we were talking about C++, singling out C++ is NOT bogus.
That's not the way I interpreted the original statement,
and still don't, so I have to continue to say it is bogus.
Even if I have misinterpreted, my statement remains valid as you've
just said in the above paragraph ("…true for all langs…").
>And finally the question:
>
>The thread started with SAS dumping the Amiga and someone saying that
>SAS's work is anyway complete. Then I responded that as far as C++, its
>not really complete since I miss templates and expection handling and a
>few other things. Then a bunch of messages were added about how bad C++
>for the Amiga is. Are you against or with C++ development on the Amiga
>platform? or are you just discussing langages in general?
Both. I am always for discussing language in general.
Furthermore, I am responsible for the most widely availabe commercial
C++ anywhere: Comeau C++ 3.0 With Templates. As we have an Amiga port,
and we are not withdrawning it, I'm very much for C++ development on the
Amiga.
Hani –
A couple of comments:
SAS/C++ is *not* a port of cfront 2.1. It is a C++ translator
developed from scratch in-house at SAS Institute.
Even if SAS/C++ is not as efficient as SAS/C, that won't prove anything
about the C++ *language* in general, just our implementation. In point of
fact, I would expect SAS/C++ to be marginally slower (5%, say) on the same
program compiled in both modes (after all, C code is C++ code, so it is
possible to compare apples to apples.) Some C++ features could be used
without adding to the execution-time cost – for example, function overloading
is a practically free feature of C++. Others could be used without added
cost if certain conditions are met – for example, member functions are free if
your C functions all work with passed-in structures instead of updating lots
and lots of global variables. The global variables are faster, but harder to
extend and maintain. Basically access to member variables is by an
indirection, so if you're going to have the indirection anyway, it doesn't
hurt you to use C++.
It is possible to write object-oriented code in C, with enough
PROGRAMMER discipline. The language doesn't help you much, but it's
possible. I believe that the same object-oriented design in C and C++ will
be very close to the same speed.
Much of C++'s bad rep for size/speed comes from the iostream library and
the basic startup overhead for very simple programs. These are not good
real-world test cases for size and speed. It doesn't really matter to me
whether there is 1k or 40 bytes of startup overhead in a 100k program, since
if I don't have it, I'll probably end up reinventing most of it anyway.
–Doug
Doug,
> SAS/C++ is *not* a port of cfront 2.1. It is a C++ translator
>developed from scratch in-house at SAS Institute.
Hmmm, I did not know that it was developed from scratch!.
> Even if SAS/C++ is not as efficient as SAS/C, that won't prove
>anything about the C++ *language* in general, just our implementation.
Agree. Its the implemetation that matters. My experience showed me that
when confronted with a problem, I can come up with considerable different
solutions (given a time limit, i.e deadlines) when I aproach the problem
using procedural methods (using C), or object oriented methods (using
C++). My object oriented aproach results in a solution that supports more
functions for the present and is more expandable for the future, compared
to the procedural aproach even though the requirement is the same. But
guess what?, my C++ code is larger and supports more functionality and
sometimes executes slower. But I'm coding for the next project or the
class library that can be used by others.
I found that going through the process of object oriented analysis, by
nature forces me to provide more functionality within the problem domain.
I also found that the procedural aproach is more 'implementation' oriented
which results in solutions that are specific to the problem but not to the
general case.
So I was not saying that C++ results in slower code than C because its
C++, but because I have a better tool (C++) to aproach problems.
> It is possible to write object-oriented code in C, with enough
>PROGRAMMER discipline. The language doesn't help you much, but it's
>possible. I believe that the same object-oriented design in C and C++
>will be very close to the same speed.
Yes Indeed.
Hani
>when confronted with a problem, I can come up with considerable different
>solutions (given a time limit, i.e deadlines) when I aproach the problem
>using procedural methods (using C), or object oriented methods (using
>C++).
Yes, many find this.
>My object oriented aproach results in a solution that supports more
>functions for the present and is more expandable for the future, compared
>to the procedural aproach even though the requirement is the same. But
>guess what?, my C++ code is larger and supports more functionality and
>sometimes executes slower. But I'm coding for the next project or the
>class library that can be used by others.
So, IOWs, you are not coding to the requirement. That of course can be ok,
since you know your needs and goals. This is of course a delicate balance,
since you don't want to overspecify too quickly and will no doubt iterate
through enough of it.
>I found that going through the process of object oriented analysis, by
>nature forces me to provide more functionality within the problem domain.
In my experience, I do not find that the result of just my OOA.
If reuse is my goal, it might be indicative though.
As well, I feel providing even a little more has potential problems
unless tredded on lightly. I'd be interested in hearing more about
your situations.
>I also found that the procedural aproach is more 'implementation' oriented
>which results in solutions that are specific to the problem but not to the
>general case.
This could be the result of many things, but I find this less so per se.
OTOH, yes, since say C doesn't have some of the capabilities of say C++,
some of those "natural solutions" have different centrics, and so with
things like focus on algorithms vs data, etc, things might appear this way.
>So I was not saying that C++ results in slower code than C because its
>C++, but because I have a better tool (C++) to aproach problems.
I don't understand.
Greg,
>>So I was not saying that C++ results in slower code than C because its
>>C++, but because I have a better tool (C++) to aproach problems.
>I don't understand.
As an example, suppose the problem is to write a program that runs on my
Unix box, and is used by users on remote systems, and I need to write a
TCP/IP interface for my comunication. So I start thinking about CTCPComm
(Class TCPComm). With a little more thinking I know that someone will
eventually march down the hall and ask : 'Hani, how can we connect our
users over X.25 to connect and use your nice program?'.
So I say, no problem CX25Comm. But I realize that CX25Comm and CTCPComm
have a similar interface requirement from the program, methods like:
Connect()
Disconect()
Read()
Write()
…
..
Then I notice, hey this is similar to a serial connection (CSerial), that
will satisfy the next person marching down the hall asking how can we
support users using serial connections. After an hour and 10 cigarettes,
I have a class diagram with an abstract base class CComm and CTCPComm,
CX25Comm, CSerial derived from CComm, expect that, all of them (the
derived classes) have different operating parameters, where in some cases
they are similar and in others they are very different. Eventually I
solve all these problems and complete my generic comm library which in
time could grow (CX25Vendor1, CX25Vendor2, CFile,..).
Using C, I would not have gone to all this extent. Not because you cannot
write a full fledge libray using C that will handle different types of
connections but because the object oriented aproach, by NATURE, made it
easier for me to go to that extent. In C, I don't even have to write a
library, just open the socket and read and write to it, and wait for
someone to march down the hall :-).
The result is more C++ code that C, not because its C++ but because I have
now more fucntionality.
Hani
>So I was not saying that C++ results in slower code than C because its
>C++, but because I have a better tool (C++) to aproach problems.
>…
>The results is more C++ code that C, not because its C++ but because I have
>now more functionality.
Thanks for your elaboration. _It is excellent_ and I do now have a better
understanding of your perspective. I think a point of difference, if I'm
understanding your correctly though, is:
>Using C, I would not have gone to all this extent.
Many would have. Although it is very true that:
>In C, I don't even have to write a library, just open the socket…
If I may, this can be equally true in C++ — and often is. (Yes, I know you
didn't say it wasn't). As well (and you didn't say this wasn't either,
but I'd like your thoughts on it) one _can_ take an OO approach in C.
In addition, some of this has nothing to do with OO at al.
Agreed C does not have as many "natural" features to support the
implementation of such designs "directly", and so
"might less force you to do so", but such forethought, etc, should always
be the concerns of any programmer. That is to say, although the language
"is just a tool", it does interfere with some of these things in part.
Equally though, especially earlier on, it should transcend them,
including to the point of being non-issues.
IOW, what I'm saying is that good design is good design.
That it might be easier (but I'd rather not even say that) for say a
C programmer to just "plop down and go" I think that was always just an
indication of a poor programmer (and I'm NOT talking about somebody who
spent X's of hours of forethought/prototyping/etc figuring it out in their
head first, _appearing_ to just be hacking).
And ok, for many, this is what the so-called "paradigm shift" is about
when moving from say C to C++ (and BTW, there _are_ more paradigm shifts
than the ones many realize when first going to C++). Once realized,
ignoring pragmatic, practical, legacy, etc issues, I believe there is
no reason to ignore those shifts/lessons/realities/awakenings because
it might be convenient to do so (whether even still in C++ or some other
language). These are the kinds of things that many C++ programmers mean
when they say that C++ made them better C programmers. Not only has it
helped them understand C better (for instance, syntactically) but it
has made them a better programmer in general. As this is all about
a creative, complex, cognitive, human thought process, I think it is
great even if they never use C++ again (I _don't_ want to single out C++
for the reason here, but it is in part an example, especially since it
is part of what we're talking about).
Greg,
>… As well (and you didn't say this wasn't either, but I'd like your
>thoughts on it) one _can_ take an OO approach in C. In addition, some of
>this has nothing to do with OO at al.
Yes, OO technics can be employed in C and they have been. Data
abstraction, encapsulation and user defined virtual tables for dynamic
binding can be accomplished. Of course it a lot easier when these
technics are built in to the language.
>…These are the kinds of things that many C++ programmers mean when they
>say that C++ made them better C programmers. Not only has it helped them
>understand C better (for instance, syntactically) but it has made them a
>better programmer in general.
Absolutely agree. I wonder if C++ should be a required prerequisit course
when learning C :-).
Hani
>I wonder if C++ should be a required prerequisite course when learning C
>:-)
🙂
Seriously though, there is some merit to that. It's not so much the
language itself as the additional all around cognitive issues that can
come up.
Actually, if you look at the market for programmers these days, it SHOULD be.
-Karl
Perhaps.