As a programmer of both languages...

[Ian Collins]

Yes Sir!

struct A {
int age;
char *Name;
};

int main(void)
{
A jacob;
}

This is valid C++ but invalid C. In C++ each "structure" definition
is just a CLASS where all members are PUBLIC by default. I see this
explanation in all C++ books I read but in my ignorance I believe
them. Stupid isn't it?

What's your point? The fact that struct is close to a synonym for class
is irrelevant. Your example struct is equally valid in both languages,
C++ treats it exactly the same as C. Saying you can't write anything
useful in C++ without classes is like saying you can't write anything
useful in C without using structs. In both languages we represent
collections of data in structures.

You are just playing word games, a favorite sport in this group.
Of course you can write programs in C and compile them with C++,
modulo some differences it is possible.

That's not what I said. Are function templates OO? Is function
overloading OO? Are exceptions OO?

Does your beloved operator overloading make sense without structs?

I would be surprised that you
can use the STL without using implicitly a class!!!

Many of the C++ standard library algorithms work equally well with
pointers. Very little of the STL is OO, which ironically is a common
criticism of it from OO purists.

All of the extensions to C you keep pushing are available in standard
C++, today.

 

[Richard Heathfield]

jacob navia said:

Yes Sir!

struct A {
int age;
char *Name;
};

int main(void)
{
A jacob;
}

This is valid C++ but invalid C.

Yes, for reasons which have nothing to do with classes.

In C++ each "structure" definition
is just a CLASS where all members are PUBLIC by default.

Stroustrup says much the same thing, albeit more quietly. But it can be
said just as correctly (or incorrectly) that, in C++, each "class"
definition is just a struct where all members are private by default. So
if the claim is that C++ is "all about classes" (which I don't accept),
then it can just as logically be said that C++ is "all about structs".
And, just as it is possible in C to write programs - *useful* programs -
that don't use structs, so it is possible in C++ to write useful programs
that don't use classes.

I see this
explanation in all C++ books I read but in my ignorance I believe
them. Stupid isn't it?

Yes - if you really want to know what a C++ struct is, the place to look is
ISO/IEC 14882.

If you write

int main(void) { printf("hello\n");}

you do not need classes but is it C++?

The behaviour of that program, either in C or in C++, is undefined. (I
believe that C++ even requires a diagnostic message to be produced during
translation of that program.) If you want people to treat your views about
C seriously, you might want to start off by learning enough about C that
you can write a simple "hello" program properly.


<snip>

 

[Ian Collins]

struct A {
int age;
char *Name;
};

int main(void)
{
A jacob;
}

This is valid C++ but invalid C. In C++ each "structure" definition
is just a CLASS where all members are PUBLIC by default. I see this
explanation in all C++ books I read but in my ignorance I believe
them. Stupid isn't it?

I think I see your conceptual problem, do you claim that

class A {
public:
int age;
char *Name;
};

Is OO while

struct A {
int age;
char *Name;
};

isn't?

You appear to be confusing the use of structures with object orientation.

One can choose to write OO code in C or in C++. The choice depends of
the nature of the problem. One of the cleanest OO designs I have seen
is the old OpenView GUI toolkit, a textbook example of OO C.

 

[jacob navia]

The behaviour of that program, either in C or in C++, is undefined. (I
believe that C++ even requires a diagnostic message to be produced during
translation of that program.) If you want people to treat your views about
C seriously, you might want to start off by learning enough about C that
you can write a simple "hello" program properly.

All this crap because there wasn't an

#include <stdio.h>

I am not compiling heathfield. I am writing to people, and
people can understand (contrary to compilers that can't)

 

[jacob navia]

What's your point? The fact that struct is close to a synonym for class
is irrelevant. Your example struct is equally valid in both languages,
C++ treats it exactly the same as C. Saying you can't write anything
useful in C++ without classes is like saying you can't write anything
useful in C without using structs.

I have never written anything serious in C without using data types and
structures. Even a "hello world" program needs stdio.h that has (at
least) the definition of FILE.

Structures are central to C, as classes are to C++.

In both languages we represent
collections of data in structures.

C++ uses inheritance. Didn't know that you can inherit from a C
structure.

That's not what I said. Are function templates OO? Is function
overloading OO? Are exceptions OO?

Exceptions are objects in C++. The exceptions I am proposing for C
aren't objects but just integer error codes, what is quite different.

All of the extensions to C you keep pushing are available in standard
C++, today.

Yes, and so what?

Why wouldn't those extensions be acceptable then?

Why must C be frozen for the benefit of C++?

This attitude:

"The better C is C++, improving C has no sense" has destroyed any
development of the language and left us with bugs that are fixed
forever in some distant past.

It is time to stop this situation.

 

[Richard Heathfield]

jacob navia said:

All this crap because there wasn't an

#include <stdio.h>

The "crap", as you put it, is in the code you posted. You asked whether it
was a C++ program, and I answered your question. If you don't want
answers, don't ask questions.

I am not compiling heathfield. I am writing to people, and
people can understand (contrary to compilers that can't)

People understand better than you realise.

 

[Richard Heathfield]

jacob navia said:

I have never written anything serious in C without using data types and
structures.

A C program that did not use any data types would be astoundingly empty.
But if you have *never* written anything serious in C that didn't use a
structure, this says less about C than it does about the limits of your
programming experience. Are you really sure that you meant to say that?

Structures are central to C, as classes are to C++.

Structures are important, but I wouldn't say they were central.

C++ uses inheritance. Didn't know that you can inherit from a C
structure.

He didn't claim otherwise.

Yes, and so what?

So if people want them, they'll use C++. If people want their *absence*,
for reasons of simplicity or portability or whatever, they'll use C. You
do C no favours by trying to move it closer to C++.

<snip>

 

[jacob navia]

jacob navia said:

A C program that did not use any data types would be astoundingly empty.
But if you have *never* written anything serious in C that didn't use a
structure, this says less about C than it does about the limits of your
programming experience. Are you really sure that you meant to say that?

If I #include <stdio.h> I include the definition of FILE, that is
a structure... If I include time.h I include several structures in
there, as in stdlib.h that defines div_t and others...

Really, I can't imagine a program not using a structure definition!

Of course, you can find a contrived example but... let's be realistic.

 

[Richard Heathfield]

jacob navia said:

If I #include <stdio.h> I include the definition of FILE, that is
a structure...

FILE isn't actually required to be a structure. It is "an object type
capable of recording all the information needed to control a stream,
including its file position indicator, a pointer to its associated buffer,
an error indicator that records whether a read/write error has occurred,
and an end-of-file indicator that records whether the end of the file has
been reached", which does seem to suggest that a structure is a sensible
implementation, but it's *not* actually required by the Standard. So a
program that uses streams may or may not be using structures - you can't
actually tell. Certainly the visible code (for who in their right mind
pokes about in standard headers?) bears no evidence of the use of structs
where FILEs are concerned.

But anyway, it is now clear that you regard including a header that
contains a structure type definition as somehow "using" that structure,
regardless of whether the structure type is referred to within the C
source itself, in which case your statement is pretty meaningless really.

 

[Nick Keighley]

There seems to be constant vacuous debate about which is better or
preferable, C or C++, and it looks like one of these discussions is on-
going right now in this newsgroup.

I'm a programmer who started out in C++, and who's currently doing
an embedded systems project in C. The relationship and comparison
between the two languages is very simple in my opinion.

The objective of C++ was to build upon C; to take everything that C
can do, and then add a few more features, such as classes, operator
overloading, and exceptions.

"a few"! You missed templates (and consequently the STL).

- inline
- references

Overlooking the small differences between the common subset of the
two languages (e.g. converting from void*, the type of character
literals), it's quite accurate to say that C++ is C with some more added
features.

C with a large pile of new features...

So at the most basic, you can say that C++ is better than C in that
it can do everything C can does, and that it has a few more extra
features.

that's not the way I use "better". I'm not knocking C++. I like C++.
But X isn't "better" than Y because it does more. Would you carve
your dinner with a Swiss Army Knife?

I can claim to pretty well know C.

Admittedly I've never used signal.h, locale.h, float.h, wctype.h,
longjmp.h or volatile. I've used goto once and seen register and
continue in other people's programs. I know auto is a keyword.

Ok so I don't *really* know C.

C++ is a a tougher nut. I've just about grasped what to put in
my thrown objects but I would not dare claim to have reached the
dizzy heights of "Exception Safe". algorithm slightly scares me.
STL error messages almost don't frighten me anymore. I've barely
touched templates and the only namespace I've used is std.
Then there's Template Metaprogramming...

Should all my virtual functions be protected?

That's great and all, but the price to pay for these extra
features is the increased complexity of the compiler.

riight. So C++ *isn't* an unqualified "better"?

I'm currently
writing a program for the PIC 16F684 microcontroller (which is less than
the size of a postage stamp),

I'm amazed it's so large. Isn't that the size of a pentium? Or do
you have very small stamps where you come from?

and there wouldn't be a snowball's chance
in hell of me finding a C++ compiler for it. Why? Because nobody's
bothered writing one. I mean *have* *you* *seen* the size of the C++
Standard? :-O

yup. I even have access to a hardcopy. And you then need a book on
STL and Myers books and...

Not only that, but when programming for embedded systems,
the nature of the programs doesn't tend to give rise to a desire for
object-orientated programming. The current program I'm writing is a
Connect4 game, and there hasn't be one instance yet in which I've
yearned for object orientation (even though I use classes extensively
when writing PC applications).

I suppose it depends how embedded, embedded is. Designing OO still
makes sense. Protocols often look like inheritance trees.

So my own point of view is that while C++ is the programming
language to be used today for PC's, game consoles and the like, C is
still the king when it comes to embedded systems, and that doesn't seem
like changing any time soon. And for the less-than-proficient among us,
there's Java for PC's, and Basic for micrcontrollers.

Basic? Basic for microcontrollers? ug.



--
Nick Keighley

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.

 

[Tomás Ó hÉilidhe]

Basic? Basic for microcontrollers? ug.

I'm doing an embedded systems project in college at the moment for
my degree. There was a finite number of projects to choose from, and
each had a description. In the description for the embedded systems
project, it mentioned using the Basic Stamp microcontroller and
programming it in Basic.

Before I chose which project I wanted to do, I approached the
embedded systems lecturer and asked him if I could code it in C and
use a proper microcontroller; thankfully he was more than happy to
accomodate me!

Another project choice was to write a webserver. The description
mentioned doing it in Java. I put my hand up and asked if I could do
it in C++... and I got a paragraph of non-information back. So then
I asked again "Just to clarify, can I do it in C++?". I got an
answer something to the effect of "we'll see" and so I went with the
embedded systems project. I'm actually quite glad I did because it's
quite interesting and exciting, plus I got to design my own printed
circuit board and have it sent off to be made. I get the circuit
board back after Christmas and then I can populate it with
components and finally try out my program on it :-D

Plus I get to do the embedded systems project on my own, whereas the
webserver project was a group effort. I also asked the
aforementioned lecturer if I could write a webserver on my own but
the answer to that was No... which was a definite deal-breaker
considering I was the only person in the room who had more than
trivial understanding of any programming language. Electronic
Engineering for you.

 

[Tomás Ó hÉilidhe]

I also asked the
aforementioned lecturer if I could write a webserver on my own but
the answer to that was No... which was a definite deal-breaker
considering I was the only person in the room who had more than
trivial understanding of any programming language.

Of course, "only person" doesn't encompass the lecturers

 

[James Kuyper]

Yes Sir!

struct A {
int age;
char *Name;
};

int main(void)
{
A jacob;
}

This is valid C++ but invalid C. In C++ each "structure" definition
is just a CLASS where all members are PUBLIC by default. I see this
explanation in all C++ books I read but in my ignorance I believe
them. Stupid isn't it?

The ability to name a type using 'A' instead of 'struct A' is just
syntactic sugar, not object orientation. Note that this is also a valid
C++ program:

struct A {
int age;
char *Name;
};

int main(void)
{
struct A jacob;
}

Calling structs classes isn't what makes C++ more object oriented than
C. It's what you do with those structs that matters. C++'s object
orientation comes primarily from the fact that it supports member
functions; many other features of C++ help make object orientated code
easier to write, but it's the member functions that make it an object
oriented language.

When you define a struct with no member functions, whether it's called a
struct or a class, you're defining something that is no more object
oriented in C++ than the same code would be in C if you replace 'class'
with 'struct'.

C++ does implicitly define certain special member functions even for
classes with no explicitly declared or defined member functions. These
include things like the default constructor, destructor, copy
constructor, and copy assignment operator. However, C++'s special rules
for POD (Plain Old Data) types mean that the semantics of using the
special member functions for POD structs (such as A above) are identical
to the semantics of the corresponding code in C. They therefore do
nothing to make POD structs in C++ any more object-oriented than they
are in C.

Both languages are still compatible at many levels. But I am not getting
crazy, the concept of CLASS is CENTRAL to the C++ language.

No, it's not. C++ classes and structs can support object orientation
more completely than C structs, and that's an important part of the
language, but it's built on top of C. You still have a language fully as
powerful as C even if you never use the object-oriented features of C++
classes that are not supported in C. And object orientation is just one
among several ways that C++ extends C. Generic programming is arguably
becoming far more important in modern C++ than object orientation.

Of course. But then you are not using C++.

If you write

int main(void) { printf("hello\n");}

you do not need classes but is it C++?

Of course it is. You can also any of the many C++ features that have
nothing to do with object orientation, such as templates and exceptions.
If that isn't C++, what is it?

 

[James Kuyper]

I have never written anything serious in C without using data types and
structures. Even a "hello world" program needs stdio.h that has (at
least) the definition of FILE.

Structures are central to C, as classes are to C++.


C++ uses inheritance. Didn't know that you can inherit from a C
structure.

The fact that you can do more things with a C++ struct than you can do
with a C struct doesn't mean that you're forced to do them. Contrary to
your original objection, you can use C++ structs without writing a
single line of C++ code that is any more object oriented than
corresponding C code, and you can do that without giving up any valuable
feature of C.

....

Exceptions are objects in C++. The exceptions I am proposing for C
aren't objects but just integer error codes, what is quite different.

Integers are also stored in objects, both in C and in C++. C++
exceptions can be integers. The existence of objects isn't what makes
code object oriented, otherwise C would be an object-oriented language too.

 

[Erik Trulsson]

I would like to have some more inputs on the above point mentioned by
you. You are indicating that "One's language choice depends partly on
the program and partly on
the programmer"
Actually my doubt is how it can depend on program? Because we write
program to solve one particular problem .Now before writing code we
think about the algorithm which is independent of programming
language.

Algorithms may be independent of programming languages in that any
algorithm *can* be implemented in any (Turing-complete) programming
language. Some algorithms can, however, be *much* easier to implement
in one programming language than in another.

Could you give one small example where program decides the programming
language?

Pick for example some algorithm that involves using a single-linked list.
You could implement this algorithm in FORTRAN 77, or older versions of BASIC,
but it would be quite painful since these languages lack several features
that are usually used when implementing linked lists (e.g. user-defined datatypes,
pointers and dynamic memory allocation.)

If you were to implement the same algorithm in, say, Standard ML it would
most likely be much easier since that language has single-linked lists as
one of the basic datatypes.


If on the other hand you were writing a program to do lots of calculations
involving matrices and vectors, the FORTRAN would seem a much better choice
than SML.


C++ (and to a somewhat lesser extent C) is somewhat unusual (but not unique)
among programming languages in that even if they seldom are the best tool
for any given job, they are also almost never a really bad choice.

 

[Nick Keighley]

I'm doing an embedded systems project in college at the moment for
my degree. There was a finite number of projects to choose from, and
each had a description. In the description for the embedded systems
project, it mentioned using the Basic Stamp microcontroller and
programming it in Basic.

Before I chose which project I wanted to do, I approached the
embedded systems lecturer and asked him if I could code it in C and
use a proper microcontroller; thankfully he was more than happy to
accomodate me!

Another project choice was to write a webserver. The description
mentioned doing it in Java. I put my hand up and asked if I could do
it in C++... and I got a paragraph of non-information back. So then
I asked again "Just to clarify, can I do it in C++?". I got an
answer something to the effect of "we'll see" and so I went with the
embedded systems project. I'm actually quite glad I did because it's
quite interesting and exciting, plus I got to design my own printed
circuit board and have it sent off to be made. I get the circuit
board back after Christmas and then I can populate it with
components and finally try out my program on it :-D

Plus I get to do the embedded systems project on my own, whereas the
webserver project was a group effort. I also asked the
aforementioned lecturer if I could write a webserver on my own but
the answer to that was No... which was a definite deal-breaker
considering I was the only person in the room who had more than
trivial understanding of any programming language. Electronic
Engineering for you.

sounds fun!

 

[Keith Thompson]

jacob navia wrote: [...]

Exceptions are objects in C++. The exceptions I am proposing for C
aren't objects but just integer error codes, what is quite different.

Integers are also stored in objects, both in C and in C++. C++
exceptions can be integers. The existence of objects isn't what makes
code object oriented, otherwise C would be an object-oriented language
too.

We're getting into yet more confusion caused by multiple meanings of a
word, similar to the problems we've had with "byte" and "stack".

Both the C and C++ standards define the word "object". In C, an
object is a "region of data storage in the execution environment, the
contents of which can represent values". The C++ definition is quite
similar.

This meaning has little or nothing to do with the concept of
"object-oriented" programming.

Another meaning of "object" is, more or less, an instance of a class
type; this is the sense that's consistent with the idea of
"object-oriented" programming. (But the C++ standard does *not* use
the word *object* in this sense.)

C++ exceptions, as I understand it, are *typically* objects in the
latter sense (or perhaps they're values rather than objects?), but
they needn't be. For example, ``throw 42;'' is a legal C++ statement.

Note that the C++ standard also defines the concept of "POD" (which
stands for "Plain Old Data", I think). A POD class, for example, is a
class (a struct or union) that doesn't have any of the C++-specific
stuff (static members, destructor, etc.). C++ code that uses only POD
types is not object-oriented in the usual sense of the term.

 

[dj3vande]

C++ (and to a somewhat lesser extent C) is somewhat unusual (but not unique)
among programming languages in that even if they seldom are the best tool
for any given job, they are also almost never a really bad choice.

And where they ARE a bad choice, you can probably at least use them to
implement a better one.


dave
(the world runs on languages whose implementations are written in C)

 

[CBFalconer]

jacob navia said:

I have.

A C program that did not use any data types would be astoundingly
empty. But if you have *never* written anything serious in C that
didn't use a structure, this says less about C than it does about
the limits of your programming experience. Are you really sure
that you meant to say that?


Structures are important, but I wouldn't say they were central.

You can write fairly elegant programs using only stdin and stdout,
with getc and putc. The fact that those are normally implemented
using such complicated items as FILEs and structures has nothing
essential to do with it. A suitable library can be written (for
that program) without those complications.

 

[Ian Collins]

C++ uses inheritance. Didn't know that you can inherit from a C
structure.

C++ offers the option of using inheritance to extend C structs, it
doesn't force one to use it.

Exceptions are objects in C++. The exceptions I am proposing for C
aren't objects but just integer error codes, what is quite different.

C++ exceptions can be integers as well as objects.

Yes, and so what?

If I want them, I use C++, if I don't I use C. Same as if I want
reflection I use PHP. I don't push for reflection in C or C++ even
though it is a very useful addition, I use a language that supports it.

A programmer should build up a toolkit of languages and libraries and
know which one best fits the problems he or she encounters.

Why wouldn't those extensions be acceptable then?

Why must C be frozen for the benefit of C++?

I never said it should, the languages have lives of their own. They may
occasionally cross-pollinate (bits of C++ in C99, bits of C99 in C++
next) but one does not drive the other.