C or C++?
Marcus Agrippa - Email Address Below
In article <34315bd1...@news.berkeley.edu>, jsch...@uclink4.berkeley.edu wrote:
> I at an interesting cross-roads in my programming experience.
>I really would like to learn a "C" - type language. However, I'm not
>sure which one to learn. If I were going to be programming primarily
>in Windows, I would certainly learn C. The problem is that I'm going
>to program primarily in Unix using gcc or g++. From what I gather,
>C++ has lots of nice features, but the way I see it, they may not be
>of great use I need to write code that will compile on a C-only
>compiler.
C is generally falling into disuse (except for C programming in C++) and being
replaced by C++.
------------------------------------------------
Doesn't the marketing person who decided
"Windows 4.0" should be called "Windows '95"
look really stupid right now?
Home Page:
http://home.att.net/~miano
Home of the Delphi Component Writers' FAQ
EMail Address:
|m.i.a.n.o @ |
|w.o.r.l.d.n.e.t . |
|a.t.t .|
|n.e.t |
Full Name:
-------------------
-J.o.h.n?M.i.a.n.o-
-------------------
Jeff Schoner
I at an interesting cross-roads in my programming experience.
I really would like to learn a "C" - type language. However, I'm not
sure which one to learn. If I were going to be programming primarily
in Windows, I would certainly learn C. The problem is that I'm going
to program primarily in Unix using gcc or g++. From what I gather,
C++ has lots of nice features, but the way I see it, they may not be
of great use I need to write code that will compile on a C-only
compiler.
Jeff Schoner
jsch...@uclink4.berkeley.edu
jsch...@flashpoint.com
---
"Windows 95/NT - 32 bit extensions and a graphical
shell for a 16 bit patch to an 8 bit operating
system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can't stand 1 bit of
competition."
Dann Corbit
Jeff Schoner <jsch...@uclink4.berkeley.edu> wrote in article
<34315bd1...@news.berkeley.edu>...
> I at an interesting cross-roads in my programming experience.
> I really would like to learn a "C" - type language.
paradigm of C++ is completely different from that of C. To the casual
onlooker, they may appear to be very similar. They are not.
> However, I'm not
> sure which one to learn. If I were going to be programming primarily
> in Windows, I would certainly learn C.
I don't understand why this would cause a preference one way or the other.
> The problem is that I'm going
> to program primarily in Unix using gcc or g++.
Does not sound like a problem to me!
> From what I gather,
> C++ has lots of nice features, but the way I see it, they may not be
> of great use I need to write code that will compile on a C-only
> compiler.
I'd urge you to take a step back and read a book on methodologies first.
If you want to do structured programming, learn C. If you want to do
object programming, learn C++. Or better yet, learn them both. You will
find that both camps generally despise the other, for some strange reasons.
Neither language is perfect, but both are excellent when used for what
they are targeted.
Wouldn't it be nice if nobody tried to start a language war in this thread?
Or an OS war? Or a compiler war?
Naw, I'm dreaming.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software? Algorithms? Pubs? http://www.infoseek.com
Chris Segot
Why not learn both?
C++ is an extensio of c. The style of c is copied in c++. however
c++ does add more complexity to coding. First to learn c++ and use it
effectively you must lean Object Oriented Design which is must different
than traditional top-down programming. Learn C first and know it well.
Then learn C++ and OOD next.
Good Luck
~Chris
Jeff Schoner (jsch...@uclink4.berkeley.edu) wrote:
: I at an interesting cross-roads in my programming experience.
: I really would like to learn a "C" - type language. However, I'm not
: sure which one to learn. If I were going to be programming primarily
: in Windows, I would certainly learn C. The problem is that I'm going
: to program primarily in Unix using gcc or g++. From what I gather,
: C++ has lots of nice features, but the way I see it, they may not be
: of great use I need to write code that will compile on a C-only
: compiler.
: ---
: Jeff Schoner
: jsch...@uclink4.berkeley.edu
: jsch...@flashpoint.com
: ---
: "Windows 95/NT - 32 bit extensions and a graphical
: shell for a 16 bit patch to an 8 bit operating
: system originally coded for a 4 bit microprocessor,
: written by a 2 bit company that can't stand 1 bit of
: competition."
--
. Christopher Segot
._______|_______. se...@segot.gti.net
\(*)/ cse...@ramapo.edu
o/ \o
Kaz
In article <343640...@medit3d.com>,
Colin Dooley <co...@medit3d.com> wrote:
>Jeff Schoner wrote:
>>
>> I at an interesting cross-roads in my programming experience.
>> I really would like to learn a "C" - type language. However, I'm not
>> sure which one to learn. If I were going to be programming primarily
>> in Windows, I would certainly learn C. The problem is that I'm going
>> to program primarily in Unix using gcc or g++. From what I gather,
>> C++ has lots of nice features, but the way I see it, they may not be
>> of great use I need to write code that will compile on a C-only
>> compiler.
>
I write with a text editor, how about you?
So you can write C code using a C++ compiler, eh? What does your C++ compiler
do with the following perfectly correct and strictly conforming C program?
#include <stdlib.h>
#include <string.h>
main()
{
char *p = malloc(15);
strcpy(p, "Hello, world!\n");
return 0;
}
Or how about this one? According to the definition of the C language, it must
produce the output
x = 2
does it? Or do you, by any chance, get a six?
#include <stdio.h>
int main(void)
{
int x = 6//* divide by three */3;
;
printf("x = %d\n", x);
return 0;
}
--
Colin Dooley
Jeff Schoner wrote:
>
> I at an interesting cross-roads in my programming experience.
> I really would like to learn a "C" - type language. However, I'm not
> sure which one to learn. If I were going to be programming primarily
> in Windows, I would certainly learn C. The problem is that I'm going
> to program primarily in Unix using gcc or g++. From what I gather,
> C++ has lots of nice features, but the way I see it, they may not be
> of great use I need to write code that will compile on a C-only
> compiler.
You can write C code using a C++ compiler, no problem.
(posted and mailed)
--
<\___/> | For the spooks: plutonium semtex CIA MI5 FBI
/ O O \ | Clinton Khadaffi Hussein stealth fighter
\_____/ FTB. | soviet suitcase bomb warhead cryptography
Dann Corbit
Colin Dooley <co...@medit3d.com> wrote in article
<343640...@medit3d.com>...
> Jeff Schoner wrote:
> >
> > I at an interesting cross-roads in my programming experience.
> > I really would like to learn a "C" - type language. However, I'm not
> > sure which one to learn. If I were going to be programming primarily
> > in Windows, I would certainly learn C. The problem is that I'm going
> > to program primarily in Unix using gcc or g++. From what I gather,
> > C++ has lots of nice features, but the way I see it, they may not be
> > of great use I need to write code that will compile on a C-only
> > compiler.
>
> You can write C code using a C++ compiler, no problem.
a C++ compiler you might have a few problems.
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
char *c;
int new = 5;
c = malloc(1);
printf("Size of a char constant is is %d is it not?\n", sizeof
'c');
return 0;
Craig Franck
Colin Dooley <co...@medit3d.com> wrote:
>You can write C code using a C++ compiler, no problem.
Assuming the compiler comes with an editor, you can write Smalltalk
as well! Or some cheesy novel.
A C++ compiler may come bundled with a C compiler. You need to invoke
the C compiler, perhaps by naming the file with a .c extension or
setting an option. I don't know if you meant that a C++ compiler will
accept C programs without any problems, but that assertion is false.
--
Craig
clfr...@worldnet.att.net
Manchester, NH
Maybe a great magnet pulls/All souls towards truth
Or maybe it is life itself/That feeds wisdom/To its
youth. -- k.d. lang
Zulkifli Hamzah
C or C++? Both.
DZ
Colin Dooley
Kaz wrote:
>
> In article <343640...@medit3d.com>,
> Colin Dooley <co...@medit3d.com> wrote:
> >
> >You can write C code using a C++ compiler, no problem.
>
>
Ha Ha.
> So you can write C code using a C++ compiler, eh? What does your C++ compiler
> do with the following perfectly correct and strictly conforming C program?
<snip weird code>
I didn't say you can't write C code which doesn't work.
The guy said he wanted to learn C, but only had access to a
C++ compiler. I said to go for it, I doubt if he will have
serious problems (if he even has any problems).
What's the alternative? Not to bother himself with such trivia
like trying to learn C?
Jochen Küpper
Kaz wrote:
> I write with a text editor, how about you?
> =
> So you can write C code using a C++ compiler, eh? What does your C++ co=
mpiler
> do with the following perfectly correct and strictly conforming C progr=
am?
You are absolutely right, C++ does not 100% include C, so they are
incompatible.
But still you can write any C program in the C subset of C++. And it
doesn't give you
any drawbacks if you are starting from scratch.
On the other hand, you need to know C, partly C++ any any
incompatibilities of the both.
> #include <stdlib.h>
> #include <string.h>
> main()
> {
> char *p =3D malloc(15);
> strcpy(p, "Hello, world!\n");
> return 0;
> }
what's the problem ? Putting the code into two files test.c and test.cc
and compiling =
gives the following:
gcc -ansi -pedantic -Wall -W test.c -o test
test.c:4: warning: return-type defaults to `int'
g++ -ansi -pedantic -Wall -W test.cc -o test++
test.cc: In function `int main()':
test.cc:5: warning: ANSI C++ forbids implicit conversion from `void *'
in initialization
There is no ANSI C++ right now, and both binaries are working.
> Or how about this one? According to the definition of the C language, i=
t must
> produce the output
> x =3D 2
> does it? Or do you, by any chance, get a six?
> =
> #include <stdio.h>
> int main(void)
> {
> int x =3D 6//* divide by three */3;
> ;
> printf("x =3D %d\n", x);
> return 0;
> }
Well, I am sure (v.s.) there is code that will break by stuff like that,
but this is not a problem with new code!
Jochen
-----------------------------------------------------------------------
Jochen K=FCpper
Heinrich-Heine-Universit=E4t D=FCsseldorf joc...@uni-duesseldorf.de=
Institut f=FCr Physikalische Chemie I
Universit=E4tsstrasse 1, Geb 26.43.02.19 phone ++49-211-8113681
40225 D=FCsseldorf fax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------
Alex Krol
Colin Dooley wrote:
> <snip weird code>
>
> I didn't say you can't write C code which doesn't work.
>
> The guy said he wanted to learn C, but only had access to a
> C++ compiler.
Look at original post - he has both.
>I said to go for it, I doubt if he will have
> serious problems (if he even has any problems).
But that's the point - there will be problems.
"C-like" subset of C++ has enough subtle and not so subtle
differences from the C proper to make a lot of valid C code
uncompilable as C++. More to that, some code you can compile
in both compilers, but you'll have different behaviour.
> What's the alternative? Not to bother himself with such trivia
> like trying to learn C?
Of course, not! But his problem is - what language to choose
from the point of view of future work.
My own advice is to learn both, starting with C.
Regards,
Alex Krol
Ross Linder
In article <60rr0m$4...@bgtnsc03.worldnet.att.net>,
pres...@whitehouse.gov (Marcus Agrippa - Email Address Below) writes:
> In article <34315bd1...@news.berkeley.edu>, jsch...@uclink4.berkeley.edu wrote:
>> I at an interesting cross-roads in my programming experience.
>>I really would like to learn a "C" - type language. However, I'm not
> C is generally falling into disuse (except for C programming in C++) and being
..
Nonsence, C is still very much used language. In the embedded market,
and most Unix[like] kenels and tools are written in C
IMO learning C is essential to anyone who will write assembler some
time. It helps to disipline structure.
Lots of C++ "programmers" Ive met claim to know C++, but at the end
of the day they just write C using // comments, others go overboard
with inheritance and loose sight of the goals resulting in bloated
and slow applications.
I think C++ can suffer from an almost genetic like form of inbreeding,
My advicew would be to LEARN BOTH hand in hand, that wat you will
get the best advantage, and the concepts of OO can also be applied
very easily in your embeded C applications if warranted.
/Ross
Ross Linder
> int x = 6//* divide by three */3;
If someone wrote code like this for me, I would fire them !
Also this shows a lazy coder ..
> char *p = malloc(15);
> strcpy(p, "Hello, world!\n");
Sure the (char *) is missing, but what about testing the return from
malloc ?
Its a pity so many people now learn to program on pc's with lots of
RAM and fast compilers. If you had to swap floppy disk's inbetween
the compile phase and the edit phase, or even worse tapes, and you
only had 4 Kb of RAM "pedantic" would have been entrenched from an
early age ;)
/Ross
/Ross
Ignatius Wong
Ross Linder <ro...@mecalc.co.za> wrote in article
<qhts06...@wanda.mecalc.co.za>...
ig: Learning one is already hard enough and it would take a superman
to learn both hand in hand. Remember a superman is quite abnormal;
he wears his undergarment on the outside.
# ig
Bill Wade
Dann Corbit <dco...@solutionsiq.com> wrote in article
<01bccdfe$9457caa0$90d6...@DCorbit.products.solutionsiq.com>...
> Of course, I would rather use an editor. Further, if you compile C code
on
> a C++ compiler you might have a few problems.
> [ Dann gives a couple of examples of legal C which aren't legal C++]
> printf("Size of a char constant is is %d is it not?\n", sizeof
'c');
Since the above line isn't portable C or C++ (but will happen to work on
many systems where size_t is unsigned int) I suppose Dann intended this as
a reason to prefer <iostream> to <stdio.h> ;-).
To the original writer: I've seen good arguments that you can become
proficient in C++ without learning C first. However a lot of the C++
training tools (books, articles, ...) concentrate on differences between C
and C++, assuming that you have a background in C.
These news groups naturally tend to concentrate on language issues, but the
bigger 'learning' area will probably be your actual problem domain(s)
(database, graphics, general algorithms, user-interface, communications,
numerical analysis, AI, security, ...). C++ has the disadvantage that
there is much more to learn, and much of the extra volume is stuff you'll
almost never use. The extra language learning time takes away from
problem-domain learning time. However once you've learned the language
(including libraries) you have a much richer set of standard tools
available for actually solving problems.
I do believe you should expect to eventually learn both languages or to
drop out of serious programming in either language within a few years
(there are a lot of 'niche' exceptions, but most beginners shouldn't target
niches). C++ makes it easier for an expert in some problem domain to write
tools which can be easily used by a novice in the domain. Since few of us
are experts in every domain we need to work in, this can be a big
productivity boost. I also find that I catch more of my errors in C++ at
compile/link time (where they are much less expensive to fix). So you
probably need C++ if you need either language. However in a lot of cases
the best existing code for some problems is still in C. C is also more
portable (in the sense of existing compilers) and stable. That will likely
mean you'll have to deal with C code and have a good understanding of where
the languages are different.
Dennis Weldy
Actualy, for some compilers, if they're compiling a file with
".c"extensin, hey'll use a strictly conforming C compiler. It's only for
.cpp files that it uses the C++ language definition.
Dennis
Kaz wrote in article <60rnb0$ts8$1...@latte.cafe.net>...
>In article <343640...@medit3d.com>,
>Colin Dooley <co...@medit3d.com> wrote:
>>Jeff Schoner wrote:
>>>
>>> I at an interesting cross-roads in my programming experience.
>>> I really would like to learn a "C" - type language. However, I'm not
>>> sure which one to learn. If I were going to be programming primarily
>>> in Windows, I would certainly learn C. The problem is that I'm going
>>> to program primarily in Unix using gcc or g++. From what I gather,
>>> C++ has lots of nice features, but the way I see it, they may not be
>>> of great use I need to write code that will compile on a C-only
>>> compiler.
>>
>>You can write C code using a C++ compiler, no problem.
>
>I write with a text editor, how about you?
>
>So you can write C code using a C++ compiler, eh? What does your C++
compiler
>do with the following perfectly correct and strictly conforming C
program?
>
> #include <stdlib.h>
> #include <string.h>
> main()
> {
> char *p = malloc(15);
> strcpy(p, "Hello, world!\n");
> return 0;
> }
>
>Or how about this one? According to the definition of the C language, it
must
>produce the output
>
> x = 2
>
>does it? Or do you, by any chance, get a six?
>
> #include <stdio.h>
> int main(void)
> {
> int x = 6//* divide by three */3;
> ;
> printf("x = %d\n", x);
> return 0;
> }
>--
>
>.
>
Sean Hill
Jeff Schoner wrote:
>
> I at an interesting cross-roads in my programming experience.
> I really would like to learn a "C" - type language. However, I'm not
> sure which one to learn. If I were going to be programming primarily
> in Windows, I would certainly learn C. The problem is that I'm going
> to program primarily in Unix using gcc or g++. From what I gather,
> C++ has lots of nice features, but the way I see it, they may not be
> of great use I need to write code that will compile on a C-only
> compiler.
Learn ANSI C if you are concerned about portablility between
different OS's and compilers. In its current stage, most C++
code is a bear to port. Those nice features you mention are not
fully implemented in all C++ compilers.
Learn C++ if you want to keep up with the market demand for C++
programers. But you will also need to learn good OO design
principles. I have seen too many C++ projects end up with bloated
and unmaintainable/unresuable C++ code because they let their
untrained C++ programers "go wild" while learning C++ without good
OO design upfront. To take advantadge of C++, you must spend the
time on a good OO design before writing a line of code.
Unfortunatly, that is not the case in most software projects.
I do like to run my ANSI C code through a C++ compiler during
various stages in the coding cycle. C++ compilers do great
type checking.
--
Sean Hill
Applied Research Laboratories
University Of Texas - Austin
(512)835-3957
Jan Panteltje
Really?
Forget it.
>C is generally falling into disuse (except for C programming in C++) and being
>replaced by C++.
>
>------------------------------------------------
>>
Kaz
In article <3436CE...@medit3d.com>,
Colin Dooley <co...@medit3d.com> wrote:
>> So you can write C code using a C++ compiler, eh? What does your C++ compiler
>> do with the following perfectly correct and strictly conforming C program?
Oh, so
#include <stdlib.h>
/*...*/
p = malloc(sizeof *p);
is weird code, eh? You have a strange definition of what weird C is.
--
Kaz
In article <343211...@uni-duesseldorf.de>,
Jochen =?iso-8859-1?Q?K=FCpper?= <joc...@uni-duesseldorf.de> wrote:
>You are absolutely right, C++ does not 100% include C, so they are
>incompatible.
>But still you can write any C program in the C subset of C++. And it
>doesn't give you
>any drawbacks if you are starting from scratch.
Is there a reference manual which accurately describes that language whose
programs produce precisely the same effect in both C and C++?
> test.cc:5: warning: ANSI C++ forbids implicit conversion from `void *'
>in initialization
>
>There is no ANSI C++ right now, and both binaries are working.
The C++ compiler is not required to translate the program because of the
constraint violation. In this case, it merely produced a diagnostic and kept
going. Some other compiler might have stopped.
>
>> Or how about this one? According to the definition of the C language, i=
>t must
>> produce the output
>> x =3D 2
>> does it? Or do you, by any chance, get a six?
>> =
>
>> #include <stdio.h>
>> int main(void)
>> {
>> int x =3D 6//* divide by three */3;
>> ;
>> printf("x =3D %d\n", x);
>> return 0;
>> }
>Well, I am sure (v.s.) there is code that will break by stuff like that,
>but this is not a problem with new code!
Isn't it? The above is new code. I wrote it yesterday.
--
Kaz
In article <pjus06...@wanda.mecalc.co.za>,
Ross Linder <ro...@mecalc.co.za> wrote:
>> int x = 6//* divide by three */3;
>
>If someone wrote code like this for me, I would fire them !
>
>Also this shows a lazy coder ..
>
>> strcpy(p, "Hello, world!\n");
>
>malloc ?
There is no need for that in this program. If the malloc fails, the
implementation hasn't provided the ability to create an object of
32767 bytes.
A conforming implementation of C must be able to translate at least one
program that stretches all of the implementation limits to the max. The
above doesn't even come close.
--
Russ Paielli
> I at an interesting cross-roads in my programming experience.
> I really would like to learn a "C" - type language. However, I'm not
> sure which one to learn. If I were going to be programming primarily
> in Windows, I would certainly learn C. The problem is that I'm going
> to program primarily in Unix using gcc or g++. From what I gather,
> C++ has lots of nice features, but the way I see it, they may not be
> of great use I need to write code that will compile on a C-only
> compiler.
If you have a choice between C and C++, why waste your time with C? As
far as I know, virtually everything that can be done in C can also be
done in C++, but the converse is far from true. Reference variables
alone are reason enough to choose C++, without even mentioning inline
functions, default arguments, function/operator overloading, and
templates. Throw in // comments for icing on the cake. That's all before
we even get to object-oriented programming. Sure, C++ can be misused,
but so can C or any language.
Russ Paielli
http://www.geocities.com/CapeCanaveral/Lab/9488/
Alicia Carla Longstreet
Chris Segot wrote:
Note: This was both posted and e:mailed.
> Why not learn both?
> C++ is an extensio of C.
I have heard that. I still don't believe it. C is a general purpose
procedural programming langauge. C++ is a general purpose object
oriented programming language. Procedural vs Object Oriented. This is
apples and oranges time.
C and C++ are TWO DIFFERENT LANGAUGES that just happen to share some
common syntax elements.
> The style of c is copied in c++. however c++ does add more complexity to coding.
C++ is NOT more complex, it uses a decidedly different underlying
concept - OOP - this, at first, seems more complex to those who are used
to procedural langauges. You see there are TWO learning curves involved
=> One going from C to C++, and the second going from Procedural to
Object Oriented. Persons who learn C++ first find the same learning
curve but in the opposite direction, they say that C is more complex
than C++.
> First to learn c++ and use it effectively you must lean Object Oriented Design
> which is very different from traditional top-down programming.
This is true.
> Learn C first and know it well. Then learn C++ and OOP next.
Or learn C++ first and know it well. Then learn C and procedural
programming next. Either way is fine. There is absolutely no reason to
learn C first.
> Jeff Schoner (jsch...@uclink4.berkeley.edu) wrote:
> : I at an interesting cross-roads in my programming experience.
> : I really would like to learn a "C" - type language. However, I'm not
> : sure which one to learn. If I were going to be programming primarily
> : in Windows, I would certainly learn C.
If I were just starting out and wanted to program Windows, I would learn
C++. Event driven programming and OOP work very well together. Most of
the User Interface concepts are implemented in the Microsoft Foundation
Classes. The MFC only works with a C++ compiler.
> : The problem is that I'm going to program primarily in Unix using gcc or g++.
Unix, which is more command line oriented if easily dealt with in either
C or C++. Even X-Windows is just as easily implemented in C as C++. I
think you got the two mixed up.
> : From what I gather, C++ has lots of nice features, but the way I see it,
> : they may not be of great use I need to write code that will compile on a C-only
> : compiler.
C++ has object oriented features, there is *nothing* you can do with C++
that you can't do with C. For Windows MFC simplifies creating the user
interface, since it contains all the UI primitives. There are other
libraries that make writing the UI just as easy in C as MFC makes it in
C++ (but they usually cost money, MFC comes with MSVC++ and some other
compilers).
Note: This was both posted and e:mailed.
--
************************************************
* Alicia Carla Longstreet ca...@ici.net *
* Remove the _JUNK_ when replying to me. *
************************************************
My programming is Wobbly. It's good programming but it Wobbles,
and the statements sometimes get in the wrong places.
************************************************
C appeals due to is simplicity and elegance.
Alicia Carla Longstreet
Russ Paielli wrote:
> > I at an interesting cross-roads in my programming experience.
> > I really would like to learn a "C" - type language. However, I'm not
> > sure which one to learn.
[snip]
> If you have a choice between C and C++, why waste your time with C? As
> far as I know, virtually everything that can be done in C can also be
> done in C++, but the converse is far from true.
There is *NOTHING* you can do in C++ that cannot be done in C.
> Reference variables alone are reason enough to choose C++, without even
> mentioning inline functions, default arguments, function/operator overloading, and
> templates. Throw in // comments for icing on the cake. That's all before
> we even get to object-oriented programming. Sure, C++ can be misused,
> but so can C or any language.
Okay, C++ allows you to specifically define a function where the
variable is passed by reference, I guess it would save a keystroke or
two, might even mean that the student won't have to learn about pointers
for a while longer. This is still something easily done in C. Reference
variables are NOT a reason to choose C++ over C (at least not a good
one).
As for inline functions, many good optimizing C compilers will inline
functions. In C++ you can suggest to the compiler that a function might
be better inlined, but like the use of the keyword register, the
programmer rarely does a better job of determining optimization features
than the compiler. register variables and inline functions are
something that do not need to be specified and often shouldn't.
And let's just throw out the // comments. The *only* reason to select
C++ over C is the desire or need to learn and do object oriented
programming. If you want to code procedurally and decide to gett C++ so
you can use function/operator overloading and templates, I would
seriously reconsider my priorites. function/operator overloading is
easily simulated in C, and templates are just another name for code
reusability, and C is most capable in this area.
Alicia Carla Longstreet
Bill Wade wrote:
> To the original writer: I've seen good arguments that you can become
> proficient in C++ without learning C first. However a lot of the C++
> training tools (books, articles, ...) concentrate on differences between C
> and C++, assuming that you have a background in C.
This is true. Eventually this will change as more writers begin to
realize that you just don't have to learn C first.
> These news groups naturally tend to concentrate on language issues, but the
> bigger 'learning' area will probably be your actual problem domain(s)
> (database, graphics, general algorithms, user-interface, communications,
> numerical analysis, AI, security, ...). C++ has the disadvantage that
> there is much more to learn, and much of the extra volume is stuff you'll
> almost never use. The extra language learning time takes away from
> problem-domain learning time. However once you've learned the language
> (including libraries) you have a much richer set of standard tools
> available for actually solving problems.
C++ does have all those object oriented stuff that you will have to
learn. Of course, if you want to program in an object oriented language
go straight to C++, why waste your time learning A procedural langauge
even if some of the knowledge is transferable, not enough of it will be
to justify taking the time to learn it.
Most of the 'richer set of standard tools' you mention are actually C
tools that have been adapted for use in C++. There are some new tools
specific to C++, but there are still lots of tools designed for C that
have yet to be adapted for C++. I think you might want to go out and
count available tools before making a sweeping statement of that nature.
Primary Tools: Editor, Compiler, Debugger, Make Facility, Profiler, Lint
Secondary Tools: Books, and Libraries (code libraries).
The tool you use most often is your editor, then your compiler and
make. Lints, debuggers, and profilers come next, I would choose them in
that order.
As for secondary tools, there are many more libraries of code available
for C that C++ (i.e. are written in C) although many of them can be used
with C++ compilers. But that comes into the realm of mixed lanague
programming which has its own headaches.
Most new books are bing written for C++, but it will be awhile before
the number of C++ books exceeds the C books, if ever.
> I do believe you should expect to eventually learn both languages or to
> drop out of serious programming in either language within a few years
> (there are a lot of 'niche' exceptions, but most beginners shouldn't target
> niches).
This is a foolish statement. There is no reason for a C programmer to
learn C++ and vica versa. I program primarily in Xbase and now Visual
Basic. I use VB to produce the UI and C (compiled to dll's) to write
the meat and potatoes of the application. I get an overall object
oriented approach with individual functions written in a procedural
language.
> C++ makes it easier for an expert in some problem domain to write
> tools which can be easily used by a novice in the domain.
It is just as easy for an expert to wirite tools in C that are easy for
the novice progrmmer to use. Neither languae is *better* than the
other. Pick your langauge, pick your tools, and go.
> Since few of us are experts in every domain we need to work in, this can be a big
> productivity boost. I also find that I catch more of my errors in C++ at
> compile/link time (where they are much less expensive to fix).
C++ is more strongly typed that C. To me this reduces flexibility and
is ultimately a liability and not an asset. Besides a good lint will do
the same thing, only more effectively, and in more depth.
> So you probably need C++ if you need either language. However in a lot of cases
> the best existing code for some problems is still in C. C is also more
> portable (in the sense of existing compilers) and stable. That will likely
> mean you'll have to deal with C code and have a good understanding of where
> the languages are different.
True.
Alicia Carla Longstreet
Sean Hill wrote:
[snip]
> Learn C++ if you want to keep up with the market demand for C++ programers.
No there is a truism if I ever saw one. Here is another:
> But you will also need to learn good OO design principles.
> I have seen too many C++ projects end up with bloated
> and unmaintainable/unresuable C++ code because they let their
> untrained C++ programers "go wild" while learning C++ without good
> OO design upfront. To take advantadge of C++, you must spend the
> time on a good OO design before writing a line of code.
> Unfortunatly, that is not the case in most software projects.
This comes from learning C first and thinking that they now know most of
C++. You will see the same problem in reverse for persons who learn C++
and object oriented design first and then try to write C code without
knowing procedural programming design.
> I do like to run my ANSI C code through a C++ compiler during
> various stages in the coding cycle. C++ compilers do great
> type checking.
Get yourself a good lint, it will do a *much* better job than a C++
compiler. For one thing a C++ compiler will often complain about
perfectly legal and valid C code, whereas the lint won't.
Alicia Carla Longstreet
Marcus Agrippa - Email Address Below wrote:
Note: This was both posted and e:mailed.
> > jsch...@uclink4.berkeley.edu wrote:
[snip]
> C is generally falling into disuse (except for C programming in C++) and being
> replaced by C++.
Really, do you have facts and figures to back that statement up. Trust
me, C is going as strong as ever, it will be around for several more
decades, or until a new, better *procedural* langauge comes along to
replace it.
Since C++ is NOT a procedural langauge it can *never* replace or
displace C.
Note: This was both posted and e:mailed.
Russ Paielli
> Since C++ is NOT a procedural langauge it can *never* replace or
> displace C.
C++ can be used for procedural programming every bit as well as C can,
and anyone who willingly chooses C over C++ for a new software project
is confused. It would be like choosing assembly language over C ten
years ago. That's just my humble opinion.
Russ Paielli
http://www.geocities.com/CapeCanaveral/Lab/9488/
Kaz
In article <3432F1...@etna.arc.nasa.gov>,
Russ Paielli <pai...@etna.arc.nasa.gov> wrote:
>> Since C++ is NOT a procedural langauge it can *never* replace or
>> displace C.
>
>C++ can be used for procedural programming every bit as well as C can,
>and anyone who willingly chooses C over C++ for a new software project
>is confused. It would be like choosing assembly language over C ten
I take this opportunity to thank all the confused people who have written
every piece of software that I use daily in the C programming language,
from applications down to utilities and operating systems.
>years ago. That's just my humble opinion.
C is easier to understand and use, and has a *standard* that is about four
times thinner than the C++ *draft*. Simiplicity is just one reason why you
might choose C over C++. Simplicity is an important virtue. It means
that a smaller body of knowledge is required to understand any given C
program than a C++ program, and the software to translate a C program is
also simpler, smaller and therefore more reliable.
A second reason related to simplicity is training. If you have a programming
team consisting of C experts, why bog them with a requirement to implement in
C++? I for one have far better mastery of C than C++, so why would I choose
C++ for a project? I don't have time for self-serving and mind-boggling
complexities that are irrelevant to program design and implementation,
and abstractions that have next to nothing to do with computers and
programming thereof.
What if the platform that you are developing for doesn't have adequate C++
tools? What if your project has a requirement that it is to be as portable as
can possibly be? Wouldn't the size and nature of the project be a
consideration?
It boils down to: simplicity versus complexity, people, tools, requirements
and good old personal preference and taste.
--
Russ Paielli
> > If you have a choice between C and C++, why waste your time with C? As
> > far as I know, virtually everything that can be done in C can also be
> > done in C++, but the converse is far from true.
>
> There is *NOTHING* you can do in C++ that cannot be done in C.
That is true in some sense, but in a sense that is totally irrelevant to
the context of this discussion. I could also say, "There is *NOTHING*
you can do in C that cannot be done in machine code," but it would be
completely irrelevant. We are not discussing Turing machines.
> > Reference variables alone are reason enough to choose C++, without even
> > mentioning inline functions, default arguments, function/operator overloading, and
> > templates. Throw in // comments for icing on the cake. That's all before
> > we even get to object-oriented programming. Sure, C++ can be misused,
> > but so can C or any language.
>
> Okay, C++ allows you to specifically define a function where the
> variable is passed by reference, I guess it would save a keystroke or
> two, might even mean that the student won't have to learn about pointers
> for a while longer. This is still something easily done in C. Reference
> variables are NOT a reason to choose C++ over C (at least not a good
> one).
Reference variables often save the definition of pointers and the
dereferencing of those pointer each time the corresponding variable is
accessed within a function, which could be many times. This means
cleaner code. I don't understand why C programmers put up with the crap
they do, unless they are working with legacy code and have no choice.
> As for inline functions, many good optimizing C compilers will inline
> functions. In C++ you can suggest to the compiler that a function might
> be better inlined, but like the use of the keyword register, the
> programmer rarely does a better job of determining optimization features
> than the compiler. register variables and inline functions are
> something that do not need to be specified and often shouldn't.
What about simple indexing of a vector or matrix? Excuse me, but I would
rather not rely on the compiler to decide when to make a function
inline, and I have rarely had a problem with a compiler refusing to make
a function inline. Even if I did, how would I be any further ahead not
even being able to specify my desire?
> And let's just throw out the // comments. The *only* reason to select
> C++ over C is the desire or need to learn and do object oriented
> programming. If you want to code procedurally and decide to gett C++ so
> you can use function/operator overloading and templates, I would
> seriously reconsider my priorites. function/operator overloading is
> easily simulated in C, and templates are just another name for code
> reusability, and C is most capable in this area.
Why should I bother "simulating" it when I can just use C++? C style
comments are ugly, inconvenient, and error prone (you can't comment out
a block of code that already has comments). And you can use C++
perfectly well for procedural code, a combination of procedural and
object-oriented code, or straight object-oriented code.
C was originally intended for systems-level programming and it shows.
C++ is intended for both systems programming and more general
programming and should be preferred to C by anyone who isn't unlucky
enough to be stuck with legacy code. Even then, it may often be
preferable to write new code in C++ and link with C code.
--
Russ Paielli
http://www.geocities.com/CapeCanaveral/Lab/9488/
Kaz
In article <3432E5...@etna.arc.nasa.gov>,
Russ Paielli <pai...@etna.arc.nasa.gov> wrote:
>> > If you have a choice between C and C++, why waste your time with C? As
>> > far as I know, virtually everything that can be done in C can also be
>> > done in C++, but the converse is far from true.
>>
>> There is *NOTHING* you can do in C++ that cannot be done in C.
>
>That is true in some sense, but in a sense that is totally irrelevant to
>the context of this discussion. I could also say, "There is *NOTHING*
>you can do in C that cannot be done in machine code," but it would be
You could not say that. In C, one can write portable programs. Thus
the capability of a machine code is not precisely the same as that of C.
In C, you could duplicate the features of the C++ program with the same or
better level of portability _and_ equal or better performance.
>> Okay, C++ allows you to specifically define a function where the
>> variable is passed by reference, I guess it would save a keystroke or
>> two, might even mean that the student won't have to learn about pointers
>> for a while longer. This is still something easily done in C. Reference
>> variables are NOT a reason to choose C++ over C (at least not a good
>> one).
>
>Reference variables often save the definition of pointers and the
Umm, in the definition, references introduce the & declarator, whereas
with pointers you use *. Same amount of typing.
>dereferencing of those pointer each time the corresponding variable is
>accessed within a function, which could be many times. This means
The dereferencing reminds you that you are going through a pointer.
>cleaner code. I don't understand why C programmers put up with the crap
>they do, unless they are working with legacy code and have no choice.
I like pointers. To me, pointers are far cleaner than references, because
they make it explicit that what you have is a mere reference to the original
object, and not a private copy.
>> As for inline functions, many good optimizing C compilers will inline
>> functions. In C++ you can suggest to the compiler that a function might
>> be better inlined, but like the use of the keyword register, the
>> programmer rarely does a better job of determining optimization features
>> than the compiler. register variables and inline functions are
>> something that do not need to be specified and often shouldn't.
>
>What about simple indexing of a vector or matrix? Excuse me, but I would
>rather not rely on the compiler to decide when to make a function
>inline, and I have rarely had a problem with a compiler refusing to make
If you don't want to rely on compilers, why don't you use assembly language?
Whether or not it is better to inline the function is depends on the compiler,
the target instruction set, the size of the function, the number of parameters
and local variables et cetera. The programmer should not be required to know
the choice. For very trivial functions, the choice is clearly in the favor of
inlining. But in the cases where the choice is clear, the compiler can readily
make the ``right'' choice. Your point is moot. In a C header file, I can
provide a static function to access a structure, and have the compiler inline
that function. In any case, C++ compilers are not required to actually
integrate those functions that are marked as inline, are they? It's just a
hint. So the point is double-moot.
>a function inline. Even if I did, how would I be any further ahead not
>even being able to specify my desire?
It probably wouldn't make a difference. IMHO, this sort of
implementation-specific influence over the compiler's optimization is is what
pragma's are for.
>> And let's just throw out the // comments. The *only* reason to select
>> C++ over C is the desire or need to learn and do object oriented
>> programming. If you want to code procedurally and decide to gett C++ so
>> you can use function/operator overloading and templates, I would
>> seriously reconsider my priorites. function/operator overloading is
>> easily simulated in C, and templates are just another name for code
>> reusability, and C is most capable in this area.
>
>Why should I bother "simulating" it when I can just use C++? C style
>comments are ugly, inconvenient, and error prone (you can't comment out
>a block of code that already has comments). And you can use C++
That is pure nonsense that indicates inexperience on your part. Every good
programmer knows that comments are for documentation, and not intended for
commenting out code. That's what the preprocessor is for:
#ifdef FEATURE
#endif
Or perhaps you can just use an if statement based on the value of
a constant variable.
D'oh!
Yeah, it's really _easier_ to insert or remove a // from every damn line that
you want to ``comment out'' than to stick an #ifdef/#endif around it.
>perfectly well for procedural code, a combination of procedural and
>object-oriented code, or straight object-oriented code.
>
>C was originally intended for systems-level programming and it shows.
It doesn't seem to show when I'm touching up digitized photos with GIMP, or
playing Quake, both of which are written in C.
>C++ is intended for both systems programming and more general
C++ is for systems programming? Perhaps a hacked-down subset that doesn't
need all the complex run-time support. I can't imagine writing for bare
hardware with C++.
--
Russ Paielli
My statement may have been too sweeping, but I still don't understand
why you can't just use the more basic features of C++ (those that are
essentially in C) if you want simplicity. (If you are worried about the
size of your compiler, you probably need to upgrade you hardware!) Then
you can always start using the more advanced or convenient features of
C++ (e.g., reference variables) whenever you wish. In any case, the
notion that C++ cannot be used just as easily as C for procedural
programming is just plain wrong--and silly too!
Stephen Kay
>Why should I bother "simulating" it when I can just use C++? C
>style
>comments are ugly, inconvenient, and error prone (you can't
>comment out
>a block of code that already has comments). And you can use C++
>object-oriented code, or straight object-oriented code.
I agree. C style /* comments */ are ugly and difficult to comment
out. What I want to know is what kind of bizarre, ancient compilers
are you using to write C that doesn't allow C++ style //comments,
such as I have used for years with THINK C and now CodeWarrior?
And in regards to the discussion, I would venture to suggest that
learning C is probably easier than C++, and a better choice for a
first jump into programming languages.
--
Stephen Kay - composer, producer, programmer
Michael Orr
Chris Segot wrote:
>
> Why not learn both?
> c++ does add more complexity to coding. First to learn c++ and use it
> effectively you must lean Object Oriented Design which is must different
> than traditional top-down programming. Learn C first and know it well.
> Then learn C++ and OOD next.
> Good Luck
> ~Chris
>
Not necessarily true. Having programmed in C and C++, I believe that a
beginner should start in C++. The differences between the two dialects
fall into two categories. The first is, of course, the OO extensions,
as stated above. They are, though, totally optional. One does not need
to use them if one so declines. The second category of differences are
of benefit to a novice, and are the strict enforcement of typing and
prototyping. While it is considered poor programming practice to take
advantage of idiosyncrasies of a language, most programmers seem to do
so with POC (Plain Ol' C). Let the ints be demoted to chars when
needed, let the return type of a function be undefined, etc. When I
have worked with C-only programmers, that seems to be their biggest
problem, and it seems to be the biggest source of bugs in a C program;
pass the wrong type of argument by accident, and it will merrily truck
right along, probably into a wall. C++ will catch those types of errors
at compile time.
The original poster stated that he was worried that he might have to
write code that could compile on a C only compiler. I do not believe in
today's environment that should be as big a concern as cross-system
compatibility. If one can write a C++ program which would successfully
compile (and run correctly) on either a UNIX or a DOS/Windows system
(when such cross-system functionality makes sense), that is usually more
of an issue and an accomplishment than if it can be compiled on a C
compiler on the same system.
Just my 2 cents worth.
--
F. Michael Orr
Sr. Systems Engineer
Norfolk Public Schools, Norfolk, VA
"Go Miami Dolphins!"
User923005
Remember the C vs C++ thread we had last year? The C vs Assembly Language one?
As I recall, after a few terabytes of messages this was the outcome:
1. Some will never realize that their pet language is not the best tool for
everything
2. Some will never realize that the language that is not their pet language is
the best tool for anything
3. Some will make blanket, opinion statements about the wane of this or that
language.
Why not just give it a rest. If people feel that their language is the best,
most elegant, most useful and efficient language for every possible task,
effort spent to reverse that opinion is universally wasted. Did anyone ever,
in any of those threads, even once, find a person who said, "Yes, I was wrong.
My pet language <lang> is not the best language for each and every
conceivable task." ?
I love FORTRAN {my first love -- sigh}
I love C {actually, my personal favorite}
I love C++ {sorry, C++ haters--not that my endorsement means anything}
I love Assembly language {At least for the tiny set of CPU's that I know}
I don't love COBOL, but if somebody wants to, I think that's great.
Each has a purpose. Each can be elegant or ugly.
"Can't we all just ... get along?"
I'm at home, so I say anything I please.
Jochen Küpper
Alicia Carla Longstreet wrote:
> Since C++ is NOT a procedural langauge it can *never* replace or
> displace C.
!!!
(I know, only stupid people are writting C in C++ that is not ANSI C any
more)
Maybe C++ already is the better C you are looking for ? Just hidden
behind =
something called OO ?
Jochen
-----------------------------------------------------------------------
Jochen K=FCpper
Heinrich-Heine-Universit=E4t D=FCsseldorf joc...@uni-duesseldorf.de=
Institut f=FCr Physikalische Chemie I
Universit=E4tsstrasse 1, Geb 26.43.02.19 phone ++49-211-8113681
40225 D=FCsseldorf fax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------
Jochen Küpper
Kaz wrote:
> >Well, I am sure (v.s.) there is code that will break by stuff like tha=
t,
> >but this is not a problem with new code!
> Isn't it? The above is new code. I wrote it yesterday.
Well, haven't expect anybody who knows about C++ to write stupid code
like
that nowadays. Maybe next time you write =
#include <stdio.h>
int main(void)
{
int x =3D 6/3; /* divide by three */
;
printf("x =3D %d\n", x);
return 0;
}
Ok, I understand that this would have been useless in your postingl,
but it does the same job - and it is even more readable !
Nicholas Sydenham
Jeff Schoner wrote:
>
> I at an interesting cross-roads in my programming experience.
> I really would like to learn a "C" - type language. However, I'm not
> to program primarily in Unix using gcc or g++. From what I gather,
> C++ has lots of nice features, but the way I see it, they may not be
> of great use I need to write code that will compile on a C-only
You can get binary versions of gcc and g++ for most platforms including
Linux and Win NT. It's not a problem!
--
Nicholas Sydenham <nsyd...@dera.gov.uk>
DERA Malvern
Subtlety is the art of saying what you think...
and getting out of the way before it is understood.
Danette & Murray Root
On Wed, 01 Oct 1997 19:01:52 -0700, Russ Paielli <pai...@etna.arc.nasa.gov>
wrote in comp.lang.c:
---- snip - see www.dejanews.com ----
=> My statement may have been too sweeping, but I still don't understand
=> why you can't just use the more basic features of C++ (those that are
=> essentially in C) if you want simplicity. (If you are worried about the
=> size of your compiler, you probably need to upgrade you hardware!) Then
=> you can always start using the more advanced or convenient features of
=> C++ (e.g., reference variables) whenever you wish. In any case, the
=> notion that C++ cannot be used just as easily as C for procedural
=> programming is just plain wrong--and silly too!
C and C++ are DIFFERENT. There are some things you can (and sometimes might)
do in C that you CANNOT do in C++, and vice-versa [syntactically]. If you've
got a team of C programmers and a problem that is best attacked in a
procedural manner it would be the height of idiocy to insist on using a C++
compiler.
Example:
legal C / illegal C++ - (two C++ errors, zero C errors)
int *newnode()
{
int *new;
new = malloc(sizeof(int));
return new;
}
Reverse example:
legal C++ / illegal C -
for (int i = 0; i <limit; i++)
{
stuff( i );
}
=>
<><><><><><><><><><><><><><><><><><><><>
Wizard's First Rule:
People are stupid.
Wizard's Second Rule:
Never depend on the first rule.
<><><><><><><><><><><><><><><><><><><><>
stolen from Dann Corbit's sig - Anonymous ftp sites for C-FAQ:
ftp://ftp.eskimo.com ftp://rtfm.mit.edu ftp://ftp.uu.net
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Colin Dooley
Kaz wrote:
>
> Oh, so
>
> #include <stdlib.h>
>
> /*...*/
>
> p = malloc(sizeof *p);
>
> is weird code, eh? You have a strange definition of what weird C is.
>
I'll let you break the news to him that he has to go out
and buy a new compiler before he can do "Hello world".
Ok?
--
<\___/> | For the spooks: plutonium semtex CIA MI5 FBI
/ O O \ | Clinton Khadaffi Hussein stealth fighter
\_____/ FTB. | soviet suitcase bomb warhead cryptography
Scott McMahan
One factor to consider when writing an application you plan to port to
different architectures is the expense of a C++ compiler. Your PC's C++
compiler might be $80, but when you're looking at UNIX workstations,
MVS, etc the C++ compiler is usually a separate product from the C
compiler and thousands of dollars. (If one is even available.) One of
the reason I think you see so many requests for C++ -> C translators is
people who discover this reality too late.
Scott
NoJunkPlease
Indeed. You are absolutely, completely correct. However, as
Scott Adams (Dilbert) astutely observed, "we're all idiots."
Remove "favorite language". Substitute "favorite OS",
"favorite computer platform", "favorite truck", "favorite beer".
It doesn't matter, people will argue over almost anything.
(No they won't! Yes they will!) Let's not even bring up
politics or religion.
No we can't get along. As a species, we're just plain too
stupid to get along. The next time you get upset about the
morons running your country or city, or the moron that wants
you to make $50,000 on a $5 investment, maybe you can derive
some small satisfaction out of the fact that, as a species,
we're getting exactly what we deserve.
--
**************************
"Never use absolutes."
**************************
Mark Wilden
Danette & Murray Root wrote:
>
> C and C++ are DIFFERENT. There are some things you can (and sometimes might)
> do in C that you CANNOT do in C++, and vice-versa [syntactically]. If you've
> got a team of C programmers and a problem that is best attacked in a
> procedural manner it would be the height of idiocy to insist on using a C++
> compiler.
>
> Example:
> legal C / illegal C++ - (two C++ errors, zero C errors)
> int *newnode()
> {
> int *new;
> new = malloc(sizeof(int));
> return new;
> }
But is it so difficult to learn C++'s operator new, which is typesafe?
Why would any C programmer _not_ want to simply write
return new int;
Is it because they've decided never to learn another thing about
programming languages?
There is nothing "non-procedural" about that code. Why would it be "the
height of stupidity" to write it, given the reduced chance of errors?
Chris Engebretson
In article <eTZHast...@nih2naab.prod2.compuserve.com>, Stephen Kay <70714...@CompuServe.COM> writes:
|> I agree. C style /* comments */ are ugly and difficult to comment
|> out. What I want to know is what kind of bizarre, ancient compilers
|> are you using to write C that doesn't allow C++ style //comments,
|> such as I have used for years with THINK C and now CodeWarrior?
Of the four C compilers that I use on a regular basis, none allow
C++-style comments by default. I would classify at least two of
these as truly outstanding compilers, and none of them are older
than 1995. Tragically, "THINK C" and "CodeWarrior" do not define
the C language, in which "//" is a syntax error (at least for the
time being, until we start seeing C9X compilers in the future.)
Regards,
--
Chris Engebretson --- Hughes STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6490
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions here are not those of Hughes Aircraft, STX, or the USGS.
Sean Hill
> My statement may have been too sweeping, but I still don't understand
>
I am a contractor and have experienced many different projects over
the last few years. I am seeing more and more projects are
choosing to blindly use C++ for everything. Programmers are
choosing to use different features of C++ because they are
"neat to play with" instead of making sound technical decisions.
What you usually end up with is a mess of code that does not take
advantage of any OO principles. And when it comes time to
port that code to different OS's or compilers, good luck!
In todays crazy computer market, I am getting sick and tired
of working with unproven/buggy products. C++ is still not
a standard, and it may be 1-2 more years before it is. Until
C++ products become more stable and fully implemented, I am
going to choose to stick with the proven ANSI C standard.
Although, I don't mind working on projects that use C++. It
looks great on my resume and gets me more money as a contractor.
But I still havn't been convinced that using C++ is the best
technical decision. I don't think that the extra features that
you get with C++ outweigh the headaches involved in using the
unproven C++ products currently on the market.
Sean Hill
Applied Research Laboratories
University Of Texas - Austin
Russ Paielli
> >> There is *NOTHING* you can do in C++ that cannot be done in C.
> >
> >That is true in some sense, but in a sense that is totally irrelevant to
> >the context of this discussion. I could also say, "There is *NOTHING*
> >you can do in C that cannot be done in machine code," but it would be
>
> You could not say that. In C, one can write portable programs. Thus
> the capability of a machine code is not precisely the same as that of C.
Wrong. You could simply rewrite the machine code for each machine, so
the capability *is* precisely the same. Sure, it would be a pain in the
ass, but look at the statement I was responding to. I was trying to show
absurdity by being absurd, and you took me seriously.
> >Reference variables often save the definition of pointers and the
>
> Umm, in the definition, references introduce the & declarator, whereas
> with pointers you use *. Same amount of typing.
Not inside the function, where each use of the variable must be
dereferenced. And it is not the amount of typing that is the issue;
unnecessary complexity is the issue.
> >dereferencing of those pointer each time the corresponding variable is
> >accessed within a function, which could be many times. This means
>
> The dereferencing reminds you that you are going through a pointer.
I don't need to be constantly reminded of that, and if I did I could
just look at the function header. Keep your functions short and it will
not be hard to find. For better efficiency, non-trivial objects are
almost always passed in by reference anyway, so the "remembering" is
rather minimal.
> >cleaner code. I don't understand why C programmers put up with the crap
> >they do, unless they are working with legacy code and have no choice.
>
> I like pointers. To me, pointers are far cleaner than references, because
> they make it explicit that what you have is a mere reference to the original
> object, and not a private copy.
Your idea of "clean" seems rather odd to me, but you are certainly
entitled to your own personal preferences. What puzzles me is why this
would be considered an argument in favor of C over C++. Don't you know
that you can still do it exactly the way you prefer in C++? C++ gives
you the option to do it either way, but C forces you to do it the old
way.
> >> As for inline functions, many good optimizing C compilers will inline
> >> functions. In C++ you can suggest to the compiler that a function might
> >> be better inlined, but like the use of the keyword register, the
> >> programmer rarely does a better job of determining optimization features
> >> than the compiler. register variables and inline functions are
> >> something that do not need to be specified and often shouldn't.
> >
> >What about simple indexing of a vector or matrix? Excuse me, but I would
> >rather not rely on the compiler to decide when to make a function
> >inline, and I have rarely had a problem with a compiler refusing to make
>
> If you don't want to rely on compilers, why don't you use assembly language?
You've got to be kidding. You are comparing the use of inline functions
with going back to assembly language?! All you have to do is type the
word "inline" in front of the function declaration!
> Whether or not it is better to inline the function is depends on the compiler,
> the target instruction set, the size of the function, the number of parameters
> and local variables et cetera. The programmer should not be required to know
> the choice. For very trivial functions, the choice is clearly in the favor of
> inlining. But in the cases where the choice is clear, the compiler can readily
> make the ``right'' choice. Your point is moot. In a C header file, I can
> provide a static function to access a structure, and have the compiler inline
> that function. In any case, C++ compilers are not required to actually
> integrate those functions that are marked as inline, are they? It's just a
> hint. So the point is double-moot.
Hey, if compilers are really smart enough to make the choice well, then
I guess an explicit inline keyword is not important, but I am not
convinced they are, and what is the big deal about having to type an
extra word? Also, without the inline keyword, you cannot easily find out
whether a function was actually inlined, and I like to know what is
going on with my code. (If C++ refuses to inline, it tells you.)
> >Why should I bother "simulating" it when I can just use C++? C style
> >comments are ugly, inconvenient, and error prone (you can't comment out
> >a block of code that already has comments). And you can use C++
>
> That is pure nonsense that indicates inexperience on your part. Every good
> programmer knows that comments are for documentation, and not intended for
> commenting out code. That's what the preprocessor is for:
>
> #ifdef FEATURE
>
> #endif
>
> Or perhaps you can just use an if statement based on the value of
> a constant variable.
I knew some clown would bring this up. Yes, you are right, but sometimes
you use comments to disable a section of code temporarily for testing
and debugging. This is obviously not a fundamental issue, but I find the
C++ style of comments much cleaner for the vast majority of comments, /*
do you know what I mean */? Why should I have to mark the end of a
comment if the end of the line is there anyway will do the job just
fine? Duh?
> Yeah, it's really _easier_ to insert or remove a // from every damn line that
> you want to ``comment out'' than to stick an #ifdef/#endif around it.
Let me spoon-feed it to you. The C style comments are good for long
comments or for temporarily commenting out a large section of code for
test purposes, but only if you use C++ style comments for your short
comments. Or you can use conditional compilation if you prefer. This is
not rocket science.
Ron Natalie
William Christensen wrote:
> C and C++ are very close syntax wise.......so if you are going to learn either
> one, you will beable to pickup the syntax of the other quit easily. BUT
> learning C puts you into the "structured" programming camp. Learning C++ puts
> you into the "object oriented" programming camp. You can use C as an "object
> oriented" language and C++ as a "structured" language but you are giving up on
> the strengths that each language gives to its "camp".
I'm not sure what point you're trying to make. Both C and C++ are
structured.
Structured and Object Oriented aren't opposites. The only new concept
in
C++ that destroys structuring is exceptions, and as long as you use them
as "exceptions" rather than a basic programming concept I'm willing to
look the other way.
> So it is not so much
> the syntax of the two languages that you should base your choice on...but in
> what camp you want to be in. If the road that led to your crossroads is
> littered with Pascal, Basic, assembly, and most scripting languages then you
> have been in the "structured" camp and learning C will carry on the tradition.
> If your road is littered with Delphi, Eiffel, Java etc then you are in the OO
> camp and C++ will carry on the tradition.
Bar, learning C++ is not going to ruin anybody for assember or basic.
As a
matter of fact, it may teach them skills that will help them arrange
their
code to be more maintainable in the long run.
> in programming). Linux has the tools that will support you in what ever
> "camp" you want to go. Windows, Apple, Warp programmers should be roasting
> their weannies in the OO campfire because that seems to be where the compiler
> vendors are putting the weannie sticks. TTFN
You admit you know nothing of windows programming (and probably nothing
about
these others) but you're going to make derogatory comments about what
they
use for tools?
Jan Panteltje
I agree, first lets study structured programming, do some assembler coding
close to the OS,
Then write some high speed applications in assembler and C.
Then MAYBE do somthing with C++.
If the overhead is worth it...
pa...@pi.net
Jan Panteltje
#define THREE 5
#define FIVE 6
fprintf(stdout, "THREE divided by FIVE = %f\n", THREE.0 / FIVE);
ahum
Mark Wilden
William Christensen wrote:
>
> You can use C as an "object
> oriented" language and C++ as a "structured" language but you are giving up on
> the strengths that each language gives to its "camp".
I just don't understand this. Why can't you write "structured" code in
C++, and gain the advantages of its "better C" capabilities?
Erwin Raymond Johnson
: What's the alternative? Not to bother himself with such trivia
: like trying to learn C?
It's to your advantage to learn C before you learn C++
If all you want to do is to learn C++ you will be at a sever disadvantage
when you come across code written in C (and don't say you won't, because
you most definately will; there's so much of it already written and
continues to be written) so you'll know how to handle it.
C++ is basically an 'ad-on' to C
It was origionally called "C with Classes"
Learn C first, then learn C++. You'll not lose any ground and perhaps gain
more insight into C++.
Lawrence Kirby
In article <3433CF...@etna.arc.nasa.gov>
pai...@etna.arc.nasa.gov "Russ Paielli" writes:
>> >> There is *NOTHING* you can do in C++ that cannot be done in C.
>> >
>> >That is true in some sense, but in a sense that is totally irrelevant to
>> >the context of this discussion. I could also say, "There is *NOTHING*
>> >you can do in C that cannot be done in machine code," but it would be
>>
>> You could not say that. In C, one can write portable programs. Thus
>> the capability of a machine code is not precisely the same as that of C.
>
>Wrong. You could simply rewrite the machine code for each machine, so
>the capability *is* precisely the same.
Machine code and assembly are not one language, they are a family of
languages. If you rewrite the machine code you've translated it to a
different language so your argument is invalid. Even you admit that you
have to rwwrite the code which immediately demonbstrates that the code
isn't portable hence doesn't have a property that C code does.
>Sure, it would be a pain in the
>ass, but look at the statement I was responding to. I was trying to show
>absurdity by being absurd, and you took me seriously.
>
>> >Reference variables often save the definition of pointers and the
>>
>> Umm, in the definition, references introduce the & declarator, whereas
>> with pointers you use *. Same amount of typing.
>
>Not inside the function, where each use of the variable must be
>dereferenced. And it is not the amount of typing that is the issue;
>unnecessary complexity is the issue.
The "unnecessary complexity" is fairly minimal in C. Most pointer
areguments point to structures or array element and C's operators ->
and [] deal very effectively with these without adding complexity. For
these and even the odd pointer to a simple variable the benefits of
not having reference arguments far outweigh the costs as far as code
maintenance is concerned (see later).
>> >dereferencing of those pointer each time the corresponding variable is
>> >accessed within a function, which could be many times. This means
>>
>> The dereferencing reminds you that you are going through a pointer.
>
>I don't need to be constantly reminded of that,
For somebody else reading your code it is an essential reminder.
>and if I did I could
>just look at the function header.
Having to do that for everything rapidly makes maintenance a nightmare.
>Keep your functions short and it will
>not be hard to find. For better efficiency, non-trivial objects are
>almost always passed in by reference anyway, so the "remembering" is
>rather minimal.
The main problem is not in writing the function but in calling the
function - having to keep track of all the parameters of all the functions
that a piece of code calls. One of the frist languages I learnt was Pascal.
It was a pleasant language with only a couple of warts. It quickly
became apparent that perhaps the largest of these was VAR parameters.
When browseing through code you simply can't tell whether an argument
being passed to a function could be changed or not. The situation in C
is *far* better because you know that function arguments can never be
changed. The unfortunate thing as far as C is concerned is that
macro instances can look the same as function calls. That's one of the
reasons many people adopt naming conventions to make macros (or at least
"unsafe" macros) easily identifiable in the source code. Adding references
to C would seriously degrade the language. They presumably exit in C++
to allow classes that modify objects, even Stroustrup recommends against
their use in normal functions.
>> >cleaner code. I don't understand why C programmers put up with the crap
>> >they do, unless they are working with legacy code and have no choice.
>>
>> I like pointers. To me, pointers are far cleaner than references, because
>> they make it explicit that what you have is a mere reference to the original
>> object, and not a private copy.
>
>Your idea of "clean" seems rather odd to me, but you are certainly
>entitled to your own personal preferences. What puzzles me is why this
>would be considered an argument in favor of C over C++. Don't you know
>that you can still do it exactly the way you prefer in C++? C++ gives
>you the option to do it either way, but C forces you to do it the old
>way.
The problem with C++ is tht it has references, classes and all that other
baggage. You have to be aware that a function might be doing unpleasant
things behind your back. With C you don't have to keep looking over your
shoulder when maintaining code.
>> >> As for inline functions, many good optimizing C compilers will inline
>> >> functions. In C++ you can suggest to the compiler that a function might
>> >> be better inlined, but like the use of the keyword register, the
>> >> programmer rarely does a better job of determining optimization features
>> >> than the compiler. register variables and inline functions are
>> >> something that do not need to be specified and often shouldn't.
>> >
>> >What about simple indexing of a vector or matrix? Excuse me, but I would
>> >rather not rely on the compiler to decide when to make a function
>> >inline, and I have rarely had a problem with a compiler refusing to make
>>
>> If you don't want to rely on compilers, why don't you use assembly language?
>
>You've got to be kidding. You are comparing the use of inline functions
>with going back to assembly language?! All you have to do is type the
>word "inline" in front of the function declaration!
Many C compilers can inline functions automatically. Explicit inlining is
much less useful in C than in C++. Nevertheless I agree that it is a
useful facility to have and will almost certainly be adopted with C9X.
>> Whether or not it is better to inline the function is depends on the compiler,>> the target instruction set, the size of the function, the number of parameters>> and local variables et cetera. The programmer should not be required to know
>> the choice. For very trivial functions, the choice is clearly in the favor of
>> inlining. But in the cases where the choice is clear, the compiler can readily>> make the ``right'' choice. Your point is moot. In a C header file, I can
>> provide a static function to access a structure, and have the compiler inline
>> that function. In any case, C++ compilers are not required to actually
>> integrate those functions that are marked as inline, are they? It's just a
>> hint. So the point is double-moot.
>
>Hey, if compilers are really smart enough to make the choice well, then
>I guess an explicit inline keyword is not important, but I am not
>convinced they are, and what is the big deal about having to type an
>extra word? Also, without the inline keyword, you cannot easily find out
>whether a function was actually inlined, and I like to know what is
>going on with my code. (If C++ refuses to inline, it tells you.)
A profiler tells me pretty much all I need to know about the generated code.
Sometimes I need to know how fast it runs but generally I couldn't care less
what the actual machine instructions are.
>> >Why should I bother "simulating" it when I can just use C++? C style
>> >comments are ugly, inconvenient, and error prone (you can't comment out
>> >a block of code that already has comments). And you can use C++
That is how I describe C++ comments. Sadly it looks like C9X will adopt
C++ style comments.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
In article <60tat5$1h2$1...@latte.cafe.net> k...@latte.cafe.net "Kaz" writes:
>In article <pjus06...@wanda.mecalc.co.za>,
>Ross Linder <ro...@mecalc.co.za> wrote:
>>> int x = 6//* divide by three */3;
>>
>>If someone wrote code like this for me, I would fire them !
>>
>>Also this shows a lazy coder ..
>>
>>> char *p = malloc(15);
>>> strcpy(p, "Hello, world!\n");
>>
>>Sure the (char *) is missing, but what about testing the return from
>>malloc ?
>
>There is no need for that in this program.
Certainly there is.
>If the malloc fails, the
>implementation hasn't provided the ability to create an object of
>32767 bytes.
That is not proven.
>A conforming implementation of C must be able to translate at least one
>program that stretches all of the implementation limits to the max. The
>above doesn't even come close.
There is no reason why the the program above has to be the one nominated
by the implementation. It could for instance nominate one that defines
an automatic or static object of 32767 or more bytes. A conforming
implementation could provide a malloc function that always returns a
null pointer.
Joe Buck
carla...@ici.net writes:
>2) C++ is NOT, nor will it ever be a *better* C. C is a general purpose
>procedural programming language. C++ is a general purpose object
>oriented programming language.
Sorry, that's too simplistic. C++ contains all of C as a subset, and code
that uses only the C features pays no penalty. C++ supports multiple
paradigms. Some powerful paradigms, such as generic programming (as
in the Standard Template Library), have nothing to do with object-oriented
programming and have more to do with languages such as ML than with,
say, Smalltalk.
People who want a pure object-oriented-programming approach are advised
to choose some other language than C++. C++ is a hybrid language.
>C and C++ are two entirely different langauge.
No, they aren't. They are different, but far from entirely different.
One of C++'s primary advantages is its strong connection to C, and the
ease of making systems that are partly in C and partly in C++ work. One
of C++'s primary disadvantages is that carrying along all the C baggage
(e.g. the broken handling of arrays) is painful.
> Any comparison has the
>same validity as comparing apples and oranges. I read another poster
>who said, "Choose C or C++ based on whether you want to be doing
>procedural coding or object oriented coding." Any other reason is
>foolish and will get you bit.
Well, it would seem foolish to use C++ and ignore object-oriented
programming. But object-oriented programming in C is quite feasible and
often done, e.g. in the Xt library and in the Linux kernel (the VFS, or
virtual file system, is object-oriented programming: there's an abstract
base type representing a generic filesystem and each specific type is a
derived type). Languages that support function pointers (such as C)
permit object-oriented programming without too much trouble.
Posting oversimplistic, poorly reasoned articles is foolish and will
get you bit. :-)
--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html
If you thought flashing ads on Web sites were annoying, wait till the Web
and your operating system are "seamlessly integrated" and watch the
pulsating promotional crud spill out over your desktop. -- Scott Rosenburg
Alicia Carla Longstreet
GNU C++ is freeware, no cost, and a much better compiler than many of
the comercial products. It is available on most Unix platforms, so I
really don't think your scenario would really be much of a problem.
Actully I think it is more likely that some fool learned C with one of
the PC combo compilers, and he decided that he might make use of the
neat C++ features these compilers allow in C code. Then when he tried
to port it to Unix, and a compiler that didn't provide support for both
C and C++, he discovered that his program was neither C nor C++ and
couldn't be compilerd with either compiler. So he needs something to
translate the C++ features to C code.
--
************************************************
* Alicia Carla Longstreet ca...@ici.net *
* Remove the _JUNK_ when replying to me. *
************************************************
My programming is Wobbly.
It's good programming but it Wobbles,
and the statements sometimes get in the wrong places.
************************************************
You can't use void main() I have a patent on it!
Alicia Carla Longstreet
Two reasons you don't get this:
1) He said you *could* write structured procedural code in C++ (I know
he said structured but he meant procedural).
2) C++ is NOT, nor will it ever be a *better* C. C is a general purpose
procedural programming language. C++ is a general purpose object
oriented programming language.
C and C++ are two entirely different langauge. Any comparison has the
same validity as comparing apples and oranges. I read another poster
who said, "Choose C or C++ based on whether you want to be doing
procedural coding or object oriented coding." Any other reason is
foolish and will get you bit.
--
Alicia Carla Longstreet
Mark Wilden wrote:
> Sean Hill wrote:
> > In todays crazy computer market, I am getting sick and tired
> > of working with unproven/buggy products. C++ is still not
> > a standard, and it may be 1-2 more years before it is. Until
> > C++ products become more stable and fully implemented, I am
> > going to choose to stick with the proven ANSI C standard.
> There are enough things about C++ that have remained unchanged since
> 1990 for me to choose it even when not writing OOP code.
If you are not writing OOP code, it is plain foolishness to use an OOP
language.
A procedural langauge is *always* going to be better and easier to use
when writting procedural code.
Alicia Carla Longstreet
Russ Paielli wrote:
>
> > >> There is *NOTHING* you can do in C++ that cannot be done in C.
> > >That is true in some sense, but in a sense that is totally irrelevant to
> > >the context of this discussion. I could also say, "There is *NOTHING*
> > >you can do in C that cannot be done in machine code," but it would be
> > You could not say that. In C, one can write portable programs. Thus
> > the capability of a machine code is not precisely the same as that of C.
> Wrong. You could simply rewrite the machine code for each machine, so
> the capability *is* precisely the same. Sure, it would be a pain in the
> ass, but look at the statement I was responding to. I was trying to show
> absurdity by being absurd, and you took me seriously.
Shades of the Nuddsiot. Yes, you can 'port' assembler to a new
architecture, just rewrite a mere 100% of the code and voila, it is
ported. I can write C programs, good, usable, C programs where 70% to
80% of the code will port *without change*. Since I stick platform
dependent code (as much as possible) into seperate modules, I just
rewrite the dependent code.
> > >Reference variables often save the definition of pointers and the
> > Umm, in the definition, references introduce the & declarator, whereas
> > with pointers you use *. Same amount of typing.
> Not inside the function, where each use of the variable must be
> dereferenced. And it is not the amount of typing that is the issue;
> unnecessary complexity is the issue.
Reference variables are a neat feature but unnessecary, I have lived
without them for years.
> > >dereferencing of those pointer each time the corresponding variable is
> > >accessed within a function, which could be many times. This means
> > The dereferencing reminds you that you are going through a pointer.
> I don't need to be constantly reminded of that, and if I did I could
> just look at the function header. Keep your functions short and it will
> not be hard to find. For better efficiency, non-trivial objects are
> almost always passed in by reference anyway, so the "remembering" is
> rather minimal.
This is no big thing, sort of like cruise control on your car.
> > >cleaner code. I don't understand why C programmers put up with the crap
> > >they do, unless they are working with legacy code and have no choice.
> > I like pointers. To me, pointers are far cleaner than references, because
> > they make it explicit that what you have is a mere reference to the original
> > object, and not a private copy.
> Your idea of "clean" seems rather odd to me, but you are certainly
> entitled to your own personal preferences. What puzzles me is why this
> would be considered an argument in favor of C over C++. Don't you know
> that you can still do it exactly the way you prefer in C++? C++ gives
> you the option to do it either way, but C forces you to do it the old
> way.
> > >> As for inline functions, many good optimizing C compilers will inline
> > >> functions. In C++ you can suggest to the compiler that a function might
> > >> be better inlined, but like the use of the keyword register, the
> > >> programmer rarely does a better job of determining optimization features
> > >> than the compiler. register variables and inline functions are
> > >> something that do not need to be specified and often shouldn't.
> > >What about simple indexing of a vector or matrix? Excuse me, but I would
> > >rather not rely on the compiler to decide when to make a function
> > >inline, and I have rarely had a problem with a compiler refusing to make
> > If you don't want to rely on compilers, why don't you use assembly language?
> You've got to be kidding. You are comparing the use of inline functions
> with going back to assembly language?! All you have to do is type the
> word "inline" in front of the function declaration!
No he is referring to relying on the compiler to make optimization
descisions for him. The best C and C++ compiler can quickly and
correctly determine if a function will be more efficient inlined. I
know of very few programmers who have the knowledge or ability to decide
on effective and efficient optimizations, and none who can make this
determiniation for more than a very few architectures. A C++ programmer
who inlines functions is unlikely to get it right more often than the
compiler will.
> > Whether or not it is better to inline the function is depends on the compiler,
> > the target instruction set, the size of the function, the number of parameters
> > and local variables et cetera. The programmer should not be required to know
> > the choice. For very trivial functions, the choice is clearly in the favor of
> > inlining. But in the cases where the choice is clear, the compiler can readily
> > make the ``right'' choice. Your point is moot. In a C header file, I can
> > provide a static function to access a structure, and have the compiler inline
> > that function. In any case, C++ compilers are not required to actually
> > integrate those functions that are marked as inline, are they? It's just a
> > hint. So the point is double-moot.
> Hey, if compilers are really smart enough to make the choice well, then
> I guess an explicit inline keyword is not important, but I am not
> convinced they are, and what is the big deal about having to type an
> extra word? Also, without the inline keyword, you cannot easily find out
> whether a function was actually inlined, and I like to know what is
> going on with my code. (If C++ refuses to inline, it tells you.)
Even with the inline keyword you will never know whether or not your
compiler has inlined the code, unless you disassemble the code and
happen to know assembler well enough to figure it out. Besides, if I
really want to 'inline' a function in C I just define it as a macro.
Instead of inline I have to type #define, oh no an extra letter!!! ;-o
If you are porting your code to several platforms you may run across a
C++ compiler that will take you inline to literally and inline a
function when it would be more efficient not to.
> > >Why should I bother "simulating" it when I can just use C++? C style
> > >comments are ugly, inconvenient, and error prone (you can't comment out
> > >a block of code that already has comments). And you can use C++
> > That is pure nonsense that indicates inexperience on your part. Every good
> > programmer knows that comments are for documentation, and not intended for
> > commenting out code. That's what the preprocessor is for:
> > #ifdef FEATURE
> >
> > #endif
> > Or perhaps you can just use an if statement based on the value of
> > a constant variable.
It really depends on why you want to comment out part of the code. Of
course, a good editor will make it quick and easy under any
circumstances. Note: Any programmer uses his/her editor more than any
other tool, yet most programmers rarely take the time to investigate
editors they just take the first one that comes along.
> I knew some clown would bring this up. Yes, you are right, but sometimes
> you use comments to disable a section of code temporarily for testing
> and debugging. This is obviously not a fundamental issue, but I find the
> C++ style of comments much cleaner for the vast majority of comments, /*
> do you know what I mean */? Why should I have to mark the end of a
> comment if the end of the line is there anyway will do the job just
> fine? Duh?
/*
Yes why should we have to do that, why not just retype the comment
indicator at the beginning of each line while we are at it. I mean it
is not too much extra typing, is it? What two characters at the
beginning of each line. No that is not too much. NOT!
*/
// Yes why should we have to do that, why not just retype the comment
indicator at the
// beginning of each line while we are at it. I mean it is not too much
extra typing,
// is it? What two characters at the beginning of each line. No that
is not too much.
// NOT! Excuse me, but that is three (3) characters.
> > Yeah, it's really _easier_ to insert or remove a // from every damn line that
> > you want to ``comment out'' than to stick an #ifdef/#endif around it.
> Let me spoon-feed it to you. The C style comments are good for long
> comments or for temporarily commenting out a large section of code for
> test purposes, but only if you use C++ style comments for your short
> comments. Or you can use conditional compilation if you prefer. This is
> not rocket science.
--
o r c e l l . p o r t l a n d . o r . u s
In article <34341E...@ici.net>,
Alicia Carla Longstreet <carla...@ici.net> wrote:
>Mark Wilden wrote:
>
>> Sean Hill wrote:
>
>> > In todays crazy computer market, I am getting sick and tired
>> > of working with unproven/buggy products. C++ is still not
>> > a standard, and it may be 1-2 more years before it is. Until
>> > C++ products become more stable and fully implemented, I am
>> > going to choose to stick with the proven ANSI C standard.
>
>> There are enough things about C++ that have remained unchanged since
>> 1990 for me to choose it even when not writing OOP code.
>
>If you are not writing OOP code, it is plain foolishness to use an OOP
>language.
So what about C++?
C++ has some features that make it easy to do OO programming, but
it's also admirably suited to doing everything that C is good for.
____
david parsons \bi/ Mind you, you can do OO programming in assembly
\/ language.
Mark Wilden
William Christensen
:>>Jeff Schoner wrote:
:>>>
:>>> I at an interesting cross-roads in my programming experience.
:>>> I really would like to learn a "C" - type language. However, I'm not
:>>> sure which one to learn. If I were going to be programming primarily
:>>> in Windows, I would certainly learn C. The problem is that I'm going
:>>> to program primarily in Unix using gcc or g++. From what I gather,
:>>> C++ has lots of nice features, but the way I see it, they may not be
:>>> of great use I need to write code that will compile on a C-only
C and C++ are very close syntax wise.......so if you are going to learn either
one, you will beable to pickup the syntax of the other quit easily. BUT
learning C puts you into the "structured" programming camp. Learning C++ puts
oriented" language and C++ as a "structured" language but you are giving up on
the syntax of the two languages that you should base your choice on...but in
what camp you want to be in. If the road that led to your crossroads is
littered with Pascal, Basic, assembly, and most scripting languages then you
have been in the "structured" camp and learning C will carry on the tradition.
If your road is littered with Delphi, Eiffel, Java etc then you are in the OO
Windows, but I think that the Windows APIs are now wrapped in C++ by most
complier vendors. But your choice of what language to use should not be based
on how to get to the OS's APIs or what a compiler will do (if the compiler
does not do what you want it to do....get a C++ compiler and use it as a C
compiler) but to what type of "camper" you want to be. My experience says
that once you have the syntax of one...the other is easy, but getting your
mind wrapped around one design methology, when you learned the other, can be
quit a challange. Either "camp" will get the programming job done so you
should choose which language you want to learn by which design methology you
believe in. (Remembering that object oriented programming was invented to
relieve the suffering of structured programming. OO is an evolutionary step UP
Philip C Plumlee
Jack Klein wrote:
> > C++ is intended for both systems programming and more general
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!
>
> > programming and should be preferred to C by anyone who isn't
> unlucky
> > enough to be stuck with legacy code. Even then, it may often
> be
> > preferable to write new code in C++ and link with C code.
>
> UNIX (all flavors) is written in C.
> OS/2 is written in C.
> Windows (all flavors) is written in C.
> Mac-OS is (I don't know, they dropped MPW years ago) is PROBABLY
> written in C.
> Even MS-DOS is partly written in C (mostly assembly language).
Windows NT's internals are written to compile in C++. Of course MS just
announces this as a publicity thing ("we do OO!"); the quality of the
C++ _idiom_ probably varies depending on the age of the component in
question...
Win32 _looks_like_ C because they follow the "Procedural Interface
Façade" pattern as found in /Large Scale C++.../
And you forgot AmigaDOS on your C list.
-- Phlip
====== http://users.deltanet.com/~tegan/home.html ======
My web page now contains 20 pages of original comics; many many more
are on the way. Whatever you think they are like (sci fi, action,
super-hero, etc), they are not.
Matt Austern
Alicia Carla Longstreet <ca...@ici.net> writes:
> And let's just throw out the // comments. The *only* reason to select
> C++ over C is the desire or need to learn and do object oriented
> programming.
C++ was designed to support several different styles of programming,
of which object-oriented programming is only one. (The other main
ones that I can think of are procedural programming as in C, abstract
data typing, and generic programming.)
There is no reason for every C++ program to be object-oriented.
Lord Shaman
> William Christensen wrote:
> >
> > You can use C as an "object
> > oriented" language and C++ as a "structured" language but you are giving up on
> > the strengths that each language gives to its "camp".
>
> C++, and gain the advantages of its "better C" capabilities?
You can. 8) Stuff like operator overloading, typesafe new, variable
declarations anywhere, and the like are very useful and don't have any runtime speed
hit.
Tero Pulkkinen
> >not be hard to find. For better efficiency, non-trivial objects are
> >almost always passed in by reference anyway, so the "remembering" is
> >rather minimal.
fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
> The main problem is not in writing the function but in calling the
> function - having to keep track of all the parameters of all the functions
> that a piece of code calls.
1) Reference parameters of a function that does not change the given arguments
should be *const*. Note that you'll need to make it const once and compiler
will catch all misuses of it in million calls from your code.
2) If you do change the arguments, pass it as pointers, and the caller will
certainly know you're going to change it.
With these two rules you'll never have that problem. Of course nonconst
references are useful as a handle of an object in function local scope.
> One of the frist languages I learnt was Pascal.
> It was a pleasant language with only a couple of warts. It quickly
> became apparent that perhaps the largest of these was VAR parameters.
Yes, var-parameters are bad because from the call you cannot see if it
changes the arguments. So is nonconst reference parameters in C++ too.
But this does not change the fact that references are very useful.
> When browseing through code you simply can't tell whether an argument
> being passed to a function could be changed or not. The situation in C
> is *far* better because you know that function arguments can never be
> changed.
You know that in C++ too, because you have interfaces with enough
consts in them. (If I see a header file with reference parameter without
const, I'll go change it to const or ask the one who made that piece
of code to change it:) In practise, when we have tools available to
prevent misuses, they are of no problem. I would be more concerned
about misuses of pointers than minor misuses of references.
> The unfortunate thing as far as C is concerned is that
> macro instances can look the same as function calls. That's one of the
> reasons many people adopt naming conventions to make macros (or at least
> "unsafe" macros) easily identifiable in the source code. Adding references
> to C would seriously degrade the language. They presumably exit in C++
> to allow classes that modify objects, even Stroustrup recommends against
> their use in normal functions.
In C++ references exists (originally) to make operator overloading possible.
(if I remember it correctly from Design and Evolution of C++).
> The problem with C++ is tht it has references, classes and all that other
> baggage.
Those are there to make it safer. They enable global program wide checks that
programmer can specify. (this is not possible with lint and other tools, which
try to provide same functionality without having language support for it).
Every of those things enable programming technigues that leads to safer
programs. Consider:
{
Monitor m;
... // critical section here
}
and compare to the C's sollution to the same:
{
Monitor *m;
... /* use of m here? a problem? */
m=alloc_new_monitor(); /* forgot to alloc it? */
... /* critical section here. */
free_monitor(m); /* forgot to free it? */
}
Which do you think is easier to break? I would be more conserned about the
fact that all variables must be declared at start of the scope in C - this
disables many useful programming techniques that make your programs
safer and easier to understand.
No amount of language restrictions will make newbies create safer
working applications, but restrictions will prevent people knowing their
language to create safer abstractions. Not having references or classes
will not help people do better programs.
> You have to be aware that a function might be doing unpleasant
> things behind your back. With C you don't have to keep looking over your
> shoulder when maintaining code.
In C you'll need to watch for huge amount of runtime type information
people must introduce to the programs to get proper abstractions
done. Lack of proper tools to make good interfaces is much worse
problem in C than what possibility to use nonconst references in
function parameters are in C++.
The normal example at this point is container types, which in C will
catch errors on insertion only at runtime, while in C++ errors are
catched at compile time. Learning C++ will make you do horrible code
first, but eventually will teach you advantages of static type
checking and teach you think in terms of how to prevent people
from using your interface badly.
All this reduces need of testing. And testing can only detect errors from
the code, never prove there isnt errors.
(sorry about participating in a language war, but lets hope this helps
someone :)
--
-- Tero Pulkkinen -- te...@modeemi.cs.tut.fi --
Lord Shaman
> C and C++ are DIFFERENT. There are some things you can (and sometimes might)
> do in C that you CANNOT do in C++, and vice-versa [syntactically]. If you've
> got a team of C programmers and a problem that is best attacked in a
> procedural manner it would be the height of idiocy to insist on using a C++
> compiler.
Now you're just being silly. C++ is a SUPERSET of C, and thus requires at
few extra keywords, of COURSE you're going to get errors if you use those
keywords as variable names! But fixing this is just a matter of "search and
replace", not rewriting code.
> Example:
> legal C / illegal C++ - (two C++ errors, zero C errors)
> int *newnode()
> {
> int *new;
> new = malloc(sizeof(int));
> return new;
> }
Yes, but if you would calle the variable "newint" or "New", you wouldn't have
any problems.
> Reverse example:
> legal C++ / illegal C -
> for (int i = 0; i <limit; i++)
> {
> stuff( i );
> }
Of course the reverse doesn't work! C++ has MORE features than C. Why would
this be a problem? OO aside, C++ has a whole bunch of nifty things for
procedural programmers, including as you've shown above, the ability to define
variable anywhere. (Also: type safe new, function overloading, operator
overloading, streams, Strings, etc..)
Jack Klein
Russ Paielli <pai...@etna.arc.nasa.gov> wrote in article
<3432E5...@etna.arc.nasa.gov>...
[humungous snip]
> C was originally intended for systems-level programming and it
shows.
> C++ is intended for both systems programming and more general
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!
> programming and should be preferred to C by anyone who isn't
unlucky
> enough to be stuck with legacy code. Even then, it may often
be
> preferable to write new code in C++ and link with C code.
Hi Russ,
I don't doubt that there might be experimental systems out there
but...
UNIX (all flavors) is written in C.
OS/2 is written in C.
Windows (all flavors) is written in C.
Mac-OS is (I don't know, they dropped MPW years ago) is PROBABLY
written in C.
Even MS-DOS is partly written in C (mostly assembly language).
Since this covers about 99.8% of all the operating systems
installed on desktops these days, what leads you to conclude
that C++ is, or is intended to be, a systems programming
language?
Jack
(Just had to get into the sure winner for longest thread of the
week!)
Chris Engebretson
|> 1) He said you *could* write structured procedural code in C++ (I know
|> he said structured but he meant procedural).
|> 2) C++ is NOT, nor will it ever be a *better* C. C is a general purpose
|> procedural programming language. C++ is a general purpose object
|> oriented programming language.
|>
|> C and C++ are two entirely different langauge. Any comparison has the
|> same validity as comparing apples and oranges. I read another poster
|> who said, "Choose C or C++ based on whether you want to be doing
|> procedural coding or object oriented coding." Any other reason is
|> foolish and will get you bit.
You seem to be trying to say that one cannot write object-oriented
code in C, which is false. You can write OO code in C++. You can
write OO code in C. You can write OO code in assembly. You can
write OO code from the toggle switches on the machine's front panel.
The distinction is that some languages provide language-level
support for the requirements of an OO language; others provide more
indirect support. Lack of language-level OO support does not
preclude the use of an objected-oriented design paradigm.
Another poster to this thread, apparently while under the influence
of large quantities of mind-altering drugs, stated that "anybody
who would choose C over C++ for any new development is confused."
To state that one language is universally the best language for any
generic, arbitrary project is completely ridiculous, and is also
the reason why asinine threads such as this accomplish nothing but
the waste of an enormous amount of bandwidth and storage space (to
which this post is admittedly contributing, apologies in advance.)
The *best* language for a project is the one that best fits in
with your requirements and design, and any other set of project-
specific criteria that may be present. Blanket statements such as
"C++ is the only language that you should use" or "C reigns king;
use it universally" are ridiculous at best, and demonstrate a
clear lack of real-world experience in software development.
Mark Wilden
Tero Pulkkinen wrote:
>
> 1) Reference parameters of a function that does not change the given arguments
> should be *const*. Note that you'll need to make it const once and compiler
> will catch all misuses of it in million calls from your code.
I believe this holds for builtin types, but not necessarily for objects.
Let's say I pass an object to a function and inside that function call
the object's CalcResult() method. Originally, CalcResult() was const, so
I could make the function parameter const. Now, I change CalcResult(),
so that it caches, and the method is no longer const. I'd have to change
the parameter to non-const wherever I used it.
I'm leaning towards making object parameters non-const, because that way
the function doesn't have to know or care whether the object modifies
itself.
Jon Bell
[I doubt that comp.os.linux.development.apps is really interested in this,
so I've removed that group from the Newsgroups line.]
Alicia Carla Longstreet <carla...@ici.net> wrote:
> C is a general purpose
>procedural programming language. C++ is a general purpose object
>oriented programming language.
C++ supports object oriented programming but does not force you to design
your programs that way. I don't consider things like using iostreams for
basic input and output to be particularly "object-oriented" in terms of
overall program design.
From Bjarne Stroustrup's home page:
"C++ is a multi-paradigm language that supports object-oriented and other
useful styles of programming. If what you are looking for is something
that forces you to do things in exactly one way, C++ isn't it."
In a general procedural sense, what can you do in C that you can't do in
C++? I'm not asking about differences in particular idioms or syntax
details, but rather about the overall procedural design of a program.
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Albert D. Cahalan
jb...@synopsys.com (Joe Buck) writes:
>> C and C++ are two entirely different langauge.
>
> No, they aren't. They are different, but far from entirely different.
> One of C++'s primary advantages is its strong connection to C, and the
> ease of making systems that are partly in C and partly in C++ work. One
> of C++'s primary disadvantages is that carrying along all the C baggage
> (e.g. the broken handling of arrays) is painful.
What? The array handling in C is excellent, at least compared to the
broken array handling in Pascal and Java. Not that it matters though,
because you ought to just use pointers directly.
This is the right way to code:
things = malloc(sizeof(thing)*things_x*things_y);
...
*(things+x+y_by_x) = 42; /* by x,y */
*(things+n) = 666; /* ignoring x,y */
Arrays are a very artificial concept. Arrays must die.
Another problem with C++ is that a call foo(bar) does not
ensure the caller that bar won't be modified. The reference
operator is responsible for this terrible uncertainty.
C++ broke void. Perhaps that is the worst sin. Pointers to void
exist so that programmers can avoid casts. Since casts disable
type checking anyway, breaking void is no advantage.
C++ creates confusion over the meaning of this:
foo(){ /* whatever */ }
The compiler ought to enforce the use of void:
void foo(void){ /* whatever */ }
Tero Pulkkinen
> Tero Pulkkinen wrote:
> > 1) Reference parameters of a function that does not change the given arguments
> > should be *const*. Note that you'll need to make it const once and compiler
> > will catch all misuses of it in million calls from your code.
Mark Wilden <Ma...@mWilden.com> writes:
> I believe this holds for builtin types, but not necessarily for objects.
No, It applies to all objects, including objects of builtin types.
> Let's say I pass an object to a function and inside that function call
> the object's CalcResult() method.
> Originally, CalcResult() was const, so
> I could make the function parameter const.
If this function is not supposed to change the state (observable by
outside user) of the object, then it must be const member function.
If you remove the const, you'll lose the static type checking and
you'll probably get into troubles in the future when maintaining the
code.
> Now, I change CalcResult(),
> so that it caches, and the method is no longer const. I'd have to change
> the parameter to non-const wherever I used it.
No. Never remove consts. Better use mutable data members for
information that does not affect the state observable by outside user
(caching, or reorganizing data structure for faster access should be
inside const member functions modifying mutable data members)
> I'm leaning towards making object parameters non-const, because that way
> the function doesn't have to know or care whether the object modifies
> itself.
Const is a property of the interface! If you want a member function to
modify the object, you'll put the member function nonconst, otherwise
it *must* be const member function. Using const_cast is much better
alternative than to remove consts from your member functions! (using
mutable is better than const_cast of course :)
(this situation is similar to the use of friends vs public data members -
using friends always wins, even tho old textbooks advice to avoid friends,
which is completely wrong advice. Friends are also used to make compiler
catch the misuses of an interface, as it allows you to still keep certain
data private, even tho grant access for another object.)
Ron Natalie
Albert D. Cahalan wrote:
> What? The array handling in C is excellent, at least compared to the
> broken array handling in Pascal and Java. Not that it matters though,
> because you ought to just use pointers directly.
>
> This is the right way to code:
> things = malloc(sizeof(thing)*things_x*things_y);
> ...
> *(things+x+y_by_x) = 42; /* by x,y */
> *(things+n) = 666; /* ignoring x,y */
>
You're loopy. Do you think that the programmer really wants
to multiply out his own array subscripts. Arrays are second
class concepts in both C and C++.
> Arrays are a very artificial concept. Arrays must die.
Or be implemented properly.
> Another problem with C++ is that a call foo(bar) does not
> ensure the caller that bar won't be modified. The reference
> operator is responsible for this terrible uncertainty.
That's what prototypes are for.
> C++ broke void. Perhaps that is the worst sin. Pointers to void
> exist so that programmers can avoid casts. Since casts disable
> type checking anyway, breaking void is no advantage.
I don't think C++ did anything to "void" itself. It doesn't
allow arbitrary assignment of void pointers. This is because
it ins't safe in C++ to do this. In C, it was merely a
matter of size and alignment, in C++ it's a necessary evil.
> C++ creates confusion over the meaning of this:
> foo(){ /* whatever */ }
> The compiler ought to enforce the use of void:
> void foo(void){ /* whatever */ }
Obviously it creates confusion for you, the meaning of
the first line is "int foo(void)" The only thing C++
changed here is that since it you can't omit args in
declarations there's no need to force the user to type
void to distinguish it from a function with no arguments.
Dann Corbit
Here is why I use C instead of C++ for development of structured code type
projects:
1. It has an international standard and many compilers that nearly comply.
2. C++ does not.
As an experiment, find an implementation of the STL anywhere on the net.
Compile it on ten different C++ compilers. If it compiles on more than two, I
will be shocked. On the two that you can get it to compile on, you will have
to do all kinds of tweaking [except for the compiler it was designed for --
you will find that the STL implementations are named]. Keep in mind that the
"S" in STL stands for STANDARD. No two C++ compilers work alike. It is not
the fault of the C++ compiler manufacturers. They have no standard to use as
a baseline. And the ARM is a moving target. It is ludicrous to do C
development in C++, unless, for some strange reason, you have to. [IMO --
YMMV].
I do C++ development in C++, and C development in C.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software? Algorithms? Pubs? http://www.infoseek.com
[snip of R S Haig's excellent points about why he develops C using C compilers
rather than C++]
R S Haigh
In article <EHHH5...@presby.edu>, jtb...@presby.edu (Jon Bell) writes:
> C++ supports object oriented programming but does not force you to design
> your programs that way. I don't consider things like using iostreams for
> basic input and output to be particularly "object-oriented" in terms of
> overall program design.
But << and >> are classic examples of virtual functions, performing the
same conceptual action on many different types of object.
(Pity they're also overloaded to do a different job entirely :-)
--
Christopher Browne
On 2 Oct 1997 22:38:02 GMT, jb...@synopsys.com (Joe Buck) wrote:
>carla...@ici.net writes:
>>2) C++ is NOT, nor will it ever be a *better* C. C is a general purpose
>>procedural programming language. C++ is a general purpose object
>>oriented programming language.
>
>Sorry, that's too simplistic. C++ contains all of C as a subset, and code
>that uses only the C features pays no penalty. C++ supports multiple
>paradigms. Some powerful paradigms, such as generic programming (as
>in the Standard Template Library), have nothing to do with object-oriented
>programming and have more to do with languages such as ML than with,
>say, Smalltalk.
Fair enough.
>People who want a pure object-oriented-programming approach are advised
>to choose some other language than C++. C++ is a hybrid language.
>
>>C and C++ are two entirely different langauge.
>
>No, they aren't. They are different, but far from entirely different.
>One of C++'s primary advantages is its strong connection to C, and the
>ease of making systems that are partly in C and partly in C++ work. One
>of C++'s primary disadvantages is that carrying along all the C baggage
>(e.g. the broken handling of arrays) is painful.
I would suggest that one of C++'s primary disadvantages is that it
looks enough like C that you can mistake semantics in one language for
the semantics in the other. Java is very similar; it looks enough
like C and C++ that you can make the serious mistake of assuming that
you can write the same code and have it work.
If C++ had been a completely different language from C, we might all
be better off, just due to the removal of confusion...
>> Any comparison has the
>>same validity as comparing apples and oranges. I read another poster
>>who said, "Choose C or C++ based on whether you want to be doing
>>procedural coding or object oriented coding." Any other reason is
>>foolish and will get you bit.
>
>Well, it would seem foolish to use C++ and ignore object-oriented
>programming. But object-oriented programming in C is quite feasible and
>often done, e.g. in the Xt library and in the Linux kernel (the VFS, or
>virtual file system, is object-oriented programming: there's an abstract
>base type representing a generic filesystem and each specific type is a
>derived type). Languages that support function pointers (such as C)
>permit object-oriented programming without too much trouble.
Indeed.
If one examines Bjarne Stroustrup's own web pages, one will find that
*he* does not make the claim that C++ is an "OO" language. He claims
in comparison with C something more like "it adds OO and other useful
features...
--
cbbr...@hex.net, <http://www.hex.net/~cbbrowne> Q: Where would Microsoft
take you today? A: Confutatis maledictis, flammis acribus addictis...
Spam bait: dom...@cyberpromo.com postm...@netvigator.com postm...@onlinebiz.net
pmdat...@aol.com ad...@submitking.com c...@llv.com wa...@pwrnet.com
Alicia Carla Longstreet
R S Haigh wrote:
> Chris Engebretson writes:
> > Another poster to this thread, apparently while under the influence
> > of large quantities of mind-altering drugs, stated that "anybody
> > who would choose C over C++ for any new development is confused."
> I think he had a point. Anything you can do in C, you can do (rather
> similarly) in a small subset of C++, and a subset that should be stable
> and portable by now. If both are available, I can't see how C might be
> more appropriate linguistically for a particular problem.
Most problems can be solved in a linear manner, e.g. procedurally. For
many problems this is still the best way to approach them. Other
problems are best approached in an object oriented manner. Your choice
of langauge should be based on the nature of the problem you are
solving.
If the problem is best handled in a procedural manner use C, it is the
height of folly to limit yourself by using C++. C and C++ are two
different but *equal* languages, they each have their place in the
scheme of things. C++ is *not* going to replace C.
> Why do I still use C then? Not for any reasons that have anything to
> do with the languages themselves. One is that I might be doing something
> else next year, and I don't want to have to maintain old code that I've
> put behind me. This is less likely if I use the more well-known
> language.
> The other is that I know the gotchas in C, whereas I don't know how much
> I don't know about C++. I suspect there may be non-orthogonalities
> glossed over in the introductory books (wouldn't sit well with the
> evangelism) and the justification isn't there for me to learn it all
> the hard way.
I can't disagree with your assesment, since I do not know C++ well
enough myself and therefore do use C to solve problems where C++ might
be more effective. On the other hand, I have no intention of dropping C
in favor of C++. I will learn C++ and subsequently use if to solve the
appropriate problems, but I will still resort to C when that language is
more suited to solving the problem than C++.
Kaz
In article <6117oa$6...@hermes.synopsys.com>,
Joe Buck <jb...@synopsys.com> wrote:
>carla...@ici.net writes:
>>2) C++ is NOT, nor will it ever be a *better* C. C is a general purpose
>>procedural programming language. C++ is a general purpose object
>>oriented programming language.
>
>Sorry, that's too simplistic. C++ contains all of C as a subset, and code
This is false. If you had been following this thread from the start you would
know that neither language is a ``superset'' of the other. A language is
defined by the sentences in that language, which can be correct on various
levels: lexical, syntactic, semantic and logical. Even programs that
are lexically and syntactically valid C _and_ C++ sentences may have
different semantics. To me, one language can be a superset of the other
if each of the other's sentences is well formed in that language, and has the
same semantics. C++ was originally based on the C language described
by the original K&R textbook, and even then it did not build a strict
superset of that.
On another note, I should point out that C++ is only in the draft stages.
To make any fair comparison between C and C++, you have to compare the C++
draft language against the ongoing C9X.
C++ does not provide an integral type which can be depended upon by a
maximally portable program to have more than 32 bits. The draft C language
has support for 64+ bit integers.
There is no proposal for restricted pointers for C++, as far as I know. The
use of restricted pointers will enable compilers to produce much more
efficient code, and will likely challenge Fortran's performance dominance in
the numerical/scientific arena. :)
Standardization wise, C++ is at the stage where C was in 1987 or 1988. It's
probably far too late in the game for C++ to catch up to the new features in
C9X. In some ways, C is leaving C++ in the dust. We may even one day see an
object-oriented C language that is much more reasonable than C++. (Fortran
programmers never thought they would get data structures, pointers,
and operator overloading!).
>that uses only the C features pays no penalty. C++ supports multiple
That is debatable. One possible penalty is portability.
>paradigms. Some powerful paradigms, such as generic programming (as
That's part of the problem. You see, what you leave _out_ of a language
matters as much as what you put into it.
Part of that split personality means that I can ``write Fortran'' in C++
and claim that I'm using C++. The implication is that if you have a team
of C++ programmers working for you, they aren't necessarily working
with the paradigms of object oriented design. OO purists tend attack C++ from
this angle, and I think they have a point.
>Well, it would seem foolish to use C++ and ignore object-oriented
>programming. But object-oriented programming in C is quite feasible and
>often done, e.g. in the Xt library and in the Linux kernel (the VFS, or
>virtual file system, is object-oriented programming: there's an abstract
>base type representing a generic filesystem and each specific type is a
>derived type). Languages that support function pointers (such as C)
>permit object-oriented programming without too much trouble.
True; good examples!
It's not just the VFS, but the devices themselves. For example, a socket
is conceptually a derived type of file (descriptor). Most operations that are
normally done on a file descriptor are permitted on a socket. But a socket has
type-specific constructors (accept(), socket()) as well as a properties and
operations that are specific to it (getpeername(), bind(), etc). You can
give a socket to subsystems that previously only worked with non-socket
files, and expect them to work. When UNIX users talk about playing sound
files with the good old 'cat' or 'cp' commands, that's OO at work. :)
This is actually perhaps even a better example than the VFS, since file
systems rarely extend the functionality by very much, hence they don't
demonstrate much inhertance (but some: you may see features in some FS's
that aren't available in others, but this is actually more of a nuisance
because the user would like to see total uniformity, whereas I don't find
it a nuisance that I cannot do a getpeername() or listen() on a tape drive).
Using function pointers is intuitive, and puts you in touch with the
mechanisms for implementing object oriented systems. Also, since you manage
the mechanisms yourself, you have a great deal of flexibility.
Where C is not helpful is in forcing you to build your program for
unanticipated future requirements of flexibility. But neither is C++.
--
Kaz
In article <vc7iuve...@jupiter.cs.uml.edu>,
Albert D. Cahalan <acah...@jupiter.cs.uml.edu> wrote:
>jb...@synopsys.com (Joe Buck) writes:
>
>>> C and C++ are two entirely different langauge.
>>
>> No, they aren't. They are different, but far from entirely different.
>> One of C++'s primary advantages is its strong connection to C, and the
>> ease of making systems that are partly in C and partly in C++ work. One
>> of C++'s primary disadvantages is that carrying along all the C baggage
>> (e.g. the broken handling of arrays) is painful.
>
>broken array handling in Pascal and Java. Not that it matters though,
>because you ought to just use pointers directly.
In Java, arrays are a fundamental feature of the virtual machine. I would
agree that they are very restricted in Java; you can't just treat any object
as an array of bytes they way you do in C. It's annoying, but not a basis for
calling arrays broken. The real problem is the lack of pointer types for
manipulating and interpreting memory.
>This is the right way to code:
> things = malloc(sizeof(thing)*things_x*things_y);
> ...
> *(things+x+y_by_x) = 42; /* by x,y */
> *(things+n) = 666; /* ignoring x,y */
>
>Arrays are a very artificial concept. Arrays must die.
I suppose. Real computer architectures, unlike the Java VM, don't have
a concept of an array, just an addressable memory arena.
>Another problem with C++ is that a call foo(bar) does not
>ensure the caller that bar won't be modified. The reference
>operator is responsible for this terrible uncertainty.
I see what you are getting at. The programmer has to inspect the declaration
of foo to ensure that bar is not a reference type. That's actually a good
point. In this sense, having to write an explicit & operator is safer,
because it's a form of acknowledgement: ``yes I know I'm passing this
object as an address, and yes I know it may be modified''.
>C++ broke void. Perhaps that is the worst sin. Pointers to void
>exist so that programmers can avoid casts. Since casts disable
>type checking anyway, breaking void is no advantage.
I agree with you. And the funniest thing is that C++ introduced void in the
first place! C acquired the void type from C++. Pointers to void are useless
in C++ except for some obscure exception handling situations and such.
>C++ creates confusion over the meaning of this:
> foo(){ /* whatever */ }
>The compiler ought to enforce the use of void:
> void foo(void){ /* whatever */ }
Here, I must strongly disagree. foo(void) is an inconsistency that is only
tolerated in C for the support of old-style programs. Ideally, a function that
takes no arguments should be declared like foo(). Void is abused for this
purpose, because syntactically it *suggests* that the function has a single
argument of type void. This is one of the widely noted quirks in C that
detract from its elegance, but is, unfortunately, necessary.
--
Mark Wilden
Tero Pulkkinen wrote:
>
> Mark Wilden <Ma...@mWilden.com> writes:
> > There is a problem, however. If the object itself is const and you cast
> > it away, the behavior is undefined.
>
> Oh yeah. But that does not matter - Better have interface safe and then
> just use more time for testing :) After that, all code that uses the
> interface is in safe ground.
I don't think it matters much if source code is on safe ground if the
program itself can result in undefined behavior!
> I'll rather take undefined, but otherwise ok behavior
Isn't that equivalent to saying "I'd rather take code that randomly
formats my hard disk, but is otherwise OK..."? :)
And I'm not altogether convinced that const creates "safety." What are
your feelings on this? I always looked upon it as a type of
encapsulation, handy when tracking down bugs. You see a
pointer-to-const, and you know that whatever else might be screwing up
that object, it ain't through that pointer! const_cast and mutable
prevent this assurance. Since you've obviously thought about this, could
you give some practical examples of the usefulness of const?
Be that as it may, it seems to me that I don't use const objects very
often (if I ever have). Trying to think of a time... Nope. And of
course, it's not at all undefined to cast away const from a
pointer/reference-to-const that actually points/references a nonconst
object.
So I think I'll give it a try, then later take out the const_casts when
my compiler supports mutable. Thanks for the food for thought, Tero!
Kaz
In article <1997Oct3.2...@leeds.ac.uk>,
Except that virtual functions are not part of OO jargon. In object oriented
terms, you have objects that have methods which can be overriden in a way that
gives rise to polymorphism.
Operator overloading is not an example of this, although >> and << could
be overloaded with virtual functions. So that the meaning of *object << x
would depend on the specific derived class of the object. But this is
then due to a property of the virtual function than of the overloading
(which is just syntactic sugar, after all).
--
o r c e l l . p o r t l a n d . o r . u s
In article <vc7iuve...@jupiter.cs.uml.edu>,
Albert D. Cahalan <acah...@jupiter.cs.uml.edu> wrote:
>jb...@synopsys.com (Joe Buck) writes:
>
>>> C and C++ are two entirely different langauge.
>>
>> No, they aren't. They are different, but far from entirely different.
>> One of C++'s primary advantages is its strong connection to C, and the
>> ease of making systems that are partly in C and partly in C++ work. One
>> of C++'s primary disadvantages is that carrying along all the C baggage
>> (e.g. the broken handling of arrays) is painful.
>
>What? The array handling in C is excellent, at least compared to the
>broken array handling in Pascal and Java. Not that it matters though,
>because you ought to just use pointers directly.
>
> things = malloc(sizeof(thing)*things_x*things_y);
> ...
> *(things+x+y_by_x) = 42; /* by x,y */
> *(things+n) = 666; /* ignoring x,y */
Well, this is certainly enlightening.
Why bother to clutter up your coding with ANY high-level language
constructs, then? After all, everything above toggling in the
program at the console is breaking the essential elegance of the
hardware.
____
david parsons \bi/ I LIKE a[x][y].
\/
Kaz
In article <34350A...@skidmore.edu>,
Pierre A. von Kaenel <pv...@skidmore.edu> wrote:
>I think Stroustrup has even said C++ is a better C and, yes, it can be
Mind you, Stroustrup invented C++.
One's endorsement of something carries a weight that is inversely proportional
to one's degree of involvement in its origin, or in the amount of some other
vested interests in that thing, wouldn't you say?
--
Jason Shankel
Alicia Carla Longstreet wrote:
> If the problem is best handled in a procedural manner use C, it is the
> height of folly to limit yourself by using C++.
In what way, precisely does C++ 'limit' you compared to C?
More specifically, what procedural problem solving elements exist in C
which are absent or deficient in C++?
The incompatibilities between C and C++ are limited mainly to type
checking, prototyping requirements, keywords, etc.
So 'char *c = malloc(len);' is valid C, but not valid C++.
However, 'char *c = (char *)malloc(len);' is valid C++.
C++ requires you to declare or define a function before using it, C does
not.
C++ requires you to use the keyword 'extern' to declare an externally
defined variable, C does not.
Most of the differences between the two langauges are of this nature and
while they are significant, they should not greatly impact the
implementation of a procedural program.
Short of examples such as this, please provide an example of a valid
procedural approach in C which cannot be implemented directly (no
reworking, perhaps some syntactic juggling) in C++.
> I can't disagree with your assesment, since I do not know C++ well
> enough myself and therefore do use C to solve problems where C++ might
> be more effective. On the other hand, I have no intention of dropping C
> in favor of C++. I will learn C++ and subsequently use if to solve the
> appropriate problems, but I will still resort to C when that language is
> more suited to solving the problem than C++.
How well, in your own assessment, do you know C++? Forgive me, but it
seems that you have made the logical fallacy of believing that the
differences between C++ and C define C++. C is not a pure subset of
C++, this is true. But there is a C-compatible subset of C++ (that is,
a group of C++ constructs which are legal C). While this subset does
not allow you to do things like use functions before prototyping or name
varaibles 'public' and 'virtual', it is enough to implement almost any
procedural solution you care to. Said another way, there is no
significant feature of C missing from the C-compatible C++ subset.
I would be interested to see you take some of you C code and recompile
it with a C++ compiler. Almost certainly, you will get compile errors.
However, you might ask yourself whether the syntactic changes required
to compile your C code cleanly under C++ would really compromise your
ability to implement procedural solutions.
Jason Shankel
Maxis, Inc.
Kaz
In article <34342322...@nlc.net.au>,
Lord Shaman <sha...@nlc.net.au> wrote:
>> C and C++ are DIFFERENT. There are some things you can (and sometimes might)
>> do in C that you CANNOT do in C++, and vice-versa [syntactically]. If you've
>> got a team of C programmers and a problem that is best attacked in a
>> procedural manner it would be the height of idiocy to insist on using a C++
>> compiler.
>
> Now you're just being silly. C++ is a SUPERSET of C, and thus requires at
>few extra keywords, of COURSE you're going to get errors if you use those
Those few extra keywords could be used by a C program as valid C
identifiers. Such C programs are not valid C++ programs.
In the past, I have used the words "delete" and "new" in my C programs
liberally. I still do---but now I avoid them in header files that are intended
for inclusion into both C and C++ programs.
Perhaps you should reexamine the notion of superset, and what it means for
one language to contain another. Hint: look at the _sentences_ of both
languages. For one language to contain another, its set of sentences must
contain the other language's set of sentences; additionally if semantics are
important rather than just syntax, the sentences common to both languages
should have the same interpretation. If each valid program of language X
can be interpreted as a valid program in language Y, and additionally it
performs the same thing, then language Y can be called a ``superlanguage''
of X and the set of Y programs is a superset of the set of X programs.
I would expect programmers to have such trivial ideas in the back pocket. One
has to wonder what the colleges are actually teaching these days in computer
science programs.
--
Kaz
In article <EHFFB...@igsrsparc2.er.usgs.gov>,
Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>Of the four C compilers that I use on a regular basis, none allow
>C++-style comments by default. I would classify at least two of
>these as truly outstanding compilers, and none of them are older
>than 1995. Tragically, "THINK C" and "CodeWarrior" do not define
>the C language, in which "//" is a syntax error (at least for the
>time being, until we start seeing C9X compilers in the future.)
And even that is not written in stone! The C9X folk could change their minds
at the last minute. I imagine that dropping // would be as easy as dropping a
wet kleenex if the slightest reason for it became apparent. :)
--
Kaz
In article <613t8f$6...@hermes.synopsys.com>,
Joe Buck <jb...@synopsys.com> wrote:
>
>
>
>Albert D. Cahalan <acah...@jupiter.cs.uml.edu> wrote:
>>>What? The array handling in C is excellent, at least compared to the
>>>broken array handling in Pascal and Java. Not that it matters though,
>>>because you ought to just use pointers directly.
>
>The primary reason that modern C compilers produce code that is a factor
>of 1.5 to 2 worse than modern Fortran compilers is *precisely* because
>of C's blurring of the distinction between pointers and arrays, with
>the resulting aliasing problems, together with folk who code like
>the following example:
[ snip ]
The proposed ``restrict'' type qualifier for pointers will hopefully solve
that problem (though admittedly, reams of existing C code will not benefit
from it without some maintainer judiciously inserting the qualifier, with
the possible risk of inserting it where it doesn't belong and thus blowing
up the program. And, of course, you need a compiler that takes
advantage of the new qualifier.)
Roughly speaking, the restrict qualifier indicates that the so-qualified
pointer has exclusive access to the object that it points to. Violating this
assumption leads to undefined behavior. In other words, the implementation
is free to assume that the program shall not violate the assumptions that
underlie the correct use of restricted pointers.
See http://www.lysator.liu.se/c/restrict.html
--
R. J. Dunnill
Alicia Carla Longstreet wrote:
> If you are not writing OOP code, it is plain foolishness to use an OOP
> language.
> A procedural langauge is *always* going to be better and easier to use
> when writting procedural code.
It's possible to use C++ as a "better C". C++ has stronger type
checking,
reference variables, and inline functions, amongst other things. Bruce
Eck? claims that bugs that remain hidden for years in straight C code
can
be caught by a C++ compiler.
Kaz
In article <610tbq$3...@halley.pi.net>, Jan Panteltje <pa...@pi.net> wrote:
>#define THREE 5
>#define FIVE 6
>
>fprintf(stdout, "THREE divided by FIVE = %f\n", THREE.0 / FIVE);
>
>ahum
What are you trying to say here? Your message could be interpreted on
many levels. The first would be that calling something THREE doesn't make
it three.
But to a hard-core C, guru, what is much more funny is your use of THREE.0.
Is that an intentional joke?
This is grossly invalid. In C, a numeric constant must be the result of a
single preprocessor token (known as a pp-number) which must be successfully
converted to a either an integer or a floating point constant token after
the preprocessing stage. In your program, TREE.0 expands to *two* adjacent
pp-number tokens, a "5" and a ".0", hence what you have is a syntax error.
That's because the results of preprocessor macro expansions are not
pre-processor tokenized all over again. The only exception to this is the token
pasting operator ##, which produces a single pp token out of two in macro
replacement lists:
#include <stdio.h> /* absolute must for printf functions */
#define THREE 5
#define paste_together(x, y) x ## y
/*...*/
printf("%f\n", paste_together(THREE,.0));
To implement the pasting operator, the preprocessing part of a C compiler
suite must recover the original lexeme corresponding to each pp token,
juxtapose them, and interpret the result as a token.
--
Kaz
In article <eTZHast...@nih2naab.prod2.compuserve.com>,
Stephen Kay <70714...@CompuServe.COM> wrote:
>>Why should I bother "simulating" it when I can just use C++? C
>>style
>>comments are ugly, inconvenient, and error prone (you can't
>>comment out
>>a block of code that already has comments). And you can use C++
>>perfectly well for procedural code, a combination of procedural and
>>object-oriented code, or straight object-oriented code.
>
>I agree. C style /* comments */ are ugly and difficult to comment
>out. What I want to know is what kind of bizarre, ancient compilers
>are you using to write C that doesn't allow C++ style //comments,
>such as I have used for years with THINK C and now CodeWarrior?
A C compiler's support of // comments renders it non-conforming to the bloody
standard! Why do you think GCC fails to recognize these comments when given
the -ansi option? I know several compilers which have no such support.
Nor should they; not only is it not a requirement, but it's also implicitly
forbidden. A C compiler must see // as a pair of operator tokens, unless
that sequence appears in a comment or string literal. Outside of these
contexts, it is a pair of operators, a combination of tokens that cannot
appear in any well-formed sentence of the C language.
Comments are for documentation, not for ``commenting out'', as mature C (and
C++) programmers know, hint hint! Other languages also provide a separate
configuration and commenting facility. For excluding sections of a source file
from participating in the translation unit, it is advisable to use the
pre-processor #if or #ifdef directives, perhaps in conjunction with
configuration macros. For excluding logical sections of code, you may want to
consider using selection statements, whose controlling expressions are
constants defined somewhere at the beginning of the translation unit or in a
header file.
Be kind to your maintainers: whatever language you use, use its proper
constructs for documenting and for configuring if it provides them!
>And in regards to the discussion, I would venture to suggest that
>learning C is probably easier than C++, and a better choice for a
>first jump into programming languages.
Yes, it is easier! C is a much smaller language, that gives you fewer ways
of doing the same thing. This much should be obvious!
--
Mark Wilden
Kaz wrote:
>
> Mind you, Stroustrup invented C++.
>
> One's endorsement of something carries a weight that is inversely proportional
> to one's degree of involvement in its origin, or in the amount of some other
> vested interests in that thing, wouldn't you say?
Only if you totally ignore the effort the man put into making C++ as
compatible as possible with C, to the detriment of the language.
Mark Wilden
Alicia Carla Longstreet wrote:
>
> If the problem is best handled in a procedural manner use C, it is the
> height of folly to limit yourself by using C++.
How would writing C code and compiling it with a C++ compiler "limit"
you?
It seems more reasonable to say it's the height of folly to use a
compiler than only supported the C language, instead of one that
supports both C and C++.
Pierre A. von Kaenel
I think Stroustrup has even said C++ is a better C and, yes, it can be
didn't have compilers - it went through a precompiler which then went
through a C compiler.
--
<<<========================================================>>>
Pierre A. von Kaenel Math & CS Dept.
"Simplify, simplify, simplify" Skidmore College
Vlad `Borg` Ptersen
Michael Orr wrote:
..........
> so with POC (Plain Ol' C). Let the ints be demoted to chars when
> needed, let the return type of a function be undefined, etc. When I
> have worked with C-only programmers, that seems to be their biggest
> problem, and it seems to be the biggest source of bugs in a C program;
> pass the wrong type of argument by accident, and it will merrily truck
> right along, probably into a wall. C++ will catch those types of errors
> at compile time.
Hmm... I met older badly implemented C++ compilers that let that
kind of errors pass through which, on the other hand, could be
easily detected by gcc with `-Wall -ansi -pedantic'.
I would say I see more programs written in good C rather than bad
C.
There are things in C++ that suck. Useless iostreams, often
practically uncomprehensible code (written by others), other
complexities. Rather than solving C problems, it actually
often emphasizes them... and that's the language that was
supposed to be a "better C"?!
There are good things in C++ that I like to use, e.g. classes
with methods and inheritance as opposed to C structures with
ugly looking pointers to functions.
Both languages have their advantages and drawbacks. Which one
do I prefer? Whatever is better for projects I have to do,
putting all stupid religious sentiments aside.
--
My real email address is: <vladimip at uniserve dot com>
#include <disclaimer.h> | *Good pings come in small packets*
Vancouver, BC | Windows: for IQs smaller than 95
SIGSIG -- signature too long (core dumped)
Mark Wilden
Tero Pulkkinen wrote:
>
> No. Never remove consts. Better use mutable data members for
> information that does not affect the state observable by outside user
> (caching, or reorganizing data structure for faster access should be
> inside const member functions modifying mutable data members)
You make good points, but I'm still not sure. I just don't like using
casts, and my compiler doesn't yet support mutable. Somehow, using
either seems like a kludge. const seems to me to mean that the object
doesn't change state--internal or external.
But I guess if the public interface still returns the same output from
the same input, it doesn't really matter what changed within the object.
Taken to its logical conclusion, that would mean that any function that
changes only the internal state, as long as that's invisible to clients,
should be const.
Hmm...I'm going to think about that. Thanks for your comments!
Mark Wilden
Tero Pulkkinen wrote:
>
> Kludge by definition is unsafe.
Nah. It just means "unclean." :)
> Mutable and const_cast preserves the
> interface safe and thus are safer to use than to remove const from the
> function declaration.
There is a problem, however. If the object itself is const and you cast
it away, the behavior is undefined.
Therefore, casting away const (if necessary because of the absence of
mutable) is cleaner but more dangerous. :)
R S Haigh
In article <34350A...@skidmore.edu>, "Pierre A. von Kaenel" <pv...@skidmore.edu> writes:
> I think Stroustrup has even said C++ is a better C and, yes, it can be
> used as a procedural language w/o the OOP stuff. In the early days C++
> didn't have compilers - it went through a precompiler which then went
> through a C compiler.
I would take that to mean that cfront had a less then complete
knowledge of the language and did a less than complete analysis of
the source -- which I don't believe.
Truer I think to say that cfront was a compiler that emitted C code as
output.
--
Tero Pulkkinen
> Tero Pulkkinen wrote:
> > Mutable and const_cast preserves the
> > interface safe and thus are safer to use than to remove const from the
> > function declaration.
Mark Wilden <Ma...@mWilden.com> writes:
> There is a problem, however. If the object itself is const and you cast
> it away, the behavior is undefined.
Oh yeah. But that does not matter - Better have interface safe and then
just use more time for testing :) After that, all code that uses the
interface is in safe ground.
> Therefore, casting away const (if necessary because of the absence of
> mutable) is cleaner but more dangerous. :)
I'll rather take undefined, but otherwise ok behavior at
implementation than dangerous interface. Implementation deficiencies
need to be fixed once, while deficiencies at interface will haunt
you for the rest of your life :)
--
-- Tero Pulkkinen -- te...@modeemi.cs.tut.fi --
Tero Pulkkinen
> Tero Pulkkinen wrote:
> > No. Never remove consts. Better use mutable data members for
> > information that does not affect the state observable by outside user
> > (caching, or reorganizing data structure for faster access should be
> > inside const member functions modifying mutable data members)
Mark Wilden <Ma...@mWilden.com> writes:
> You make good points, but I'm still not sure. I just don't like using
> casts, and my compiler doesn't yet support mutable.
> Somehow, using
> either seems like a kludge.
Kludge by definition is unsafe. Mutable and const_cast preserves the
interface safe and thus are safer to use than to remove const from the
function declaration. => Removing const from declaration is more
kludge than mutable or const-cast in implementation. Mutable or the
cast is needed only in the implementation, and implementation is never
really an issue.
>const seems to me to mean that the object
> doesn't change state--internal or external.
But it is not. :)
> But I guess if the public interface still returns the same output from
> the same input, it doesn't really matter what changed within the object.
Exactly.
> Taken to its logical conclusion, that would mean that any function that
> changes only the internal state, as long as that's invisible to clients,
> should be const.
Yes.