When will C have an object model?

[James Kuyper]

could one of you introduce me to one of these rich but strangely
generous
people?

How generous they are depends upon the surrounding context. The next
sentence could be, for instance, "In return, you are giving me your left
kidney."

 

[James Kuyper]

Seebs wrote:
....

I would guess that almost no module of code I've written in the last decade
would compile as C++ without changes, because I use malloc and I don't cast
the result, because casting the result is actively stupid in C.

OK - that's a perfectly reasonable reason, and probably the single most
common issue that comes up. However, it's not, in itself, an indication
of a major incompatibility between the languages, and most of the other
incompatibilities cause much less trouble than that one. It doesn't come
up much in my code, possibly because most of the data I work with has a
fixed record size, which make the use of static and automatic data
storage much easier than it would be in other contexts.

....

... C trusts
the programmer; a thing which does not trust the programmer is not a better
C.

I think that depends entirely upon how well you can trust the programmer
to know what he's doing. I like C, because I do know what I'm doing. I'm
the C guru in my office; people come to me to help figure out how to
make their C code do what they wanted it to do. As a result, I've seen a
lot of C code written by people whose competence should not be trusted
as much a C does.

I'm not sure C++ is the answer, either. It has essentially all of the
complexities of C, and a whole bunch more of it's own. I'm nowhere near
as experienced in the use of C++ as I am in the use of C, but my limited
exposure to C++ has not been positive. It could be my own inexperience,
the poor quality of the code I was modifying, or the lack of
documentation, but I've always found it difficult to determine which
class and which member it is that should be modified to produce the
desired change in the program's behavior.

 

[Seebs]

That had darn well better be a typo. Otherwise, I've been missing
something pretty major.

Or adding a reasonable inference which I never actually said. I didn't
say it was a keyword now... I think C++ just barely existed when I
learned C, and I wasn't paying any attention, so I only cared what were
keywords in C.

-s

 

[Seebs]

I'm not sure C++ is the answer, either. It has essentially all of the
complexities of C, and a whole bunch more of it's own. I'm nowhere near
as experienced in the use of C++ as I am in the use of C, but my limited
exposure to C++ has not been positive. It could be my own inexperience,
the poor quality of the code I was modifying, or the lack of
documentation, but I've always found it difficult to determine which
class and which member it is that should be modified to produce the
desired change in the program's behavior.

I am pretty sure that if C++ is the answer, it is quite probable that you've
asked the wrong question. Actually, that's not totally fair. I think it may
be a good fit for video game programming, where the combination of OO
techniques and bare-metal code could pay off. However, the language has
gotten large enough that the real answer is probably always "here is the
subset of C++ we've chosen to work with", rather than the whole language.

-s

 

[David Thompson]

Implicit void * conversions, C++ keywords used as C identifiers, VLAs
(if you have C99), K&R function declarations and implicit function
declarations (if you haven't), code that depends on the size of

To be clear, K&R func decl (= unspecified params) doesn't distinguish
C99. Implicit func decl, and also implicit int in any decl/defn, do.

<Aside> My en_US would make that "... if you have C99, ... if you
*don't*". I would use have/haven't only with a participle e.g. "... if
you have upgraded ... if you haven't". Probably related, I would say
"I don't have [any] $X" or "I have no $X", but "I haven't any $X"

character constants being int, int initialisation of enums, tentative

And other integer to enum: assignment, arg passing, return.
(The latter two are arguably covered by as-if assignment.)

definitions, initialisation of N-char arrays with
N-chars-before-the-null strings, and so on and so on.

Many of these reasons are poor (in the sense that good C code would
not contain instances of these problems) - but not all.

I concur with (i.e. have used for IMO-then good reason) all of those
except sizeof character constant and implicit func. A few more:

I have occasionally used struct (tag) defn within struct (which C++
scopes), but I would be willing to put that in the poor category.
Also enum (values, maybe tag) defn in struct, maybe less poor when
it's used only for values in that field (e.g. a variant selector).

Also sometimes identifiers with (nonleading) double-underscore.

I think I have accidentally used strchr etc. loses const, but that's
definitely in the poor category. I can't remember actually getting bit
by string literal (value) const, but I would worry about it.