When will C have an object model?

[Seebs]

Only someone wanting to be extreme or someone who just wants to argue
apparently would say that.

I have written a fair chunk of C code that won't compile as C++.

Who cares. All that matters is what I meant.

Which I can't determine without knowing what you think the word "actuary"
means. Or without you telling me.

Don't compare IQs with me, cuz
you'll lose.

Not possible with currently-available technology. I might not win, but
it is flatly impossible for me to lose.

It doesn't matter what it means. All that matters is what I meant.

Well, that's an interesting question. It might also matter whether other
people can tell what you meant, and whether their guesses will be accurate.
When you use words in ways other than the ways most people use them, the
chances of accurate guesses go down sharply.

Yes, this was a test of your intuitive capability, of which it is determined
that you have none.

Uh, no. You think I have none. In fact, I have some; the distinction isn't
whether or not I can exercise intuition, but whether I mistake intuition and
speculation for knowledge. You apparently feel that your intuitions are
unquestionable revealed truth. I consider them speculative, and prefer not to
rely on them when I don't have to.

(Are we having fun yet?!)

I wouldn't know.

-s

 

[James Kuyper]

Seebs wrote:
....

I have written a fair chunk of C code that won't compile as C++.

What are the typical reasons why it won't compile as C++? How much of
your code could not be re-written to compile both as C code, and as C++
code, with the same behavior either way?

 

[James Kuyper]

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
character constants being int, int initialisation of enums, tentative
definitions, initialisation of N-char arrays with
N-chars-before-the-null strings, and so on and so on.

Yes, I'm well aware of the potential causes of such problems. I've
actually been working on a program part of which is compiled as C, part
of which is compiled in C++, and some of which (shared header files) is
compiled in both languages - solely for the purpose of demonstrating
those differences.

And what I've found while putting that together is that most of the
things that make for C code that won't compile as C++ code are things
that good C programmers don't do, and bad C programmers shouldn't do,
for precisely the same reasons that they are not supported in C++. The C
part of that program is awful C code; the C++ portion is merely a little
peculiar.

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

Agreed, and that's why I wanted to know which particular incompatible
features of C that Seebs uses that cause "a fair chunk" of his C code to
be incompatible with C++.

Multi-language programs have issues:

Yes, but I'm not talking about the full generality of multi-language
programs. I'm talking about C and C++, where the second language evolved
from the first, with the deliberate design goal of retaining as much
backwards compatibility with the first as possible. The committees
responsible for the standardization of both languages have a deliberate
policy of avoiding poorly motivated incompatibilities between the
languages, and maintain close contacts to promote that policy. Writing
code that can be compiled in either language involves far fewer
compromises than the more general case.

 

[Default User]

James Kuyper wrote:

Agreed, and that's why I wanted to know which particular incompatible
features of C that Seebs uses that cause "a fair chunk" of his C code
to be incompatible with C++.

That's not what he said. He said, ". . . a fair chunk of C code." Not a
fair chunk of HIS C code. The former is an absolute thing, the latter
relative.



Brian

 

[James Kuyper]

James Kuyper wrote:



That's not what he said. He said, ". . . a fair chunk of C code." Not a
fair chunk of HIS C code. The former is an absolute thing, the latter
relative.

His full statement was "I have written a fair chunk of C code that won't
compile as C++." Are you arguing that code he has written is not
necessarily HIS code?

 

[Default User]

His full statement was "I have written a fair chunk of C code that
won't compile as C++." Are you arguing that code he has written is
not necessarily HIS code?

Suppose I have a billion dollars, and I gave you $100,000. You'd
probably think that 100k was a fair chunk of money. It wouldn't be a
fair chunk of MY money.



Brian

 

[James Kuyper]

James Kuyper wrote: ....


Suppose I have a billion dollars, and I gave you $100,000. You'd
probably think that 100k was a fair chunk of money. It wouldn't be a
fair chunk of MY money.

What does that analogy have to do with it? That it was "a fair chunk of
code" was his judgement, not mine.

 

[Default User]

What does that analogy have to do with it? That it was "a fair chunk
of code" was his judgement, not mine.

What don't you understand? A "fair chunk of code" might not be "a fair
chunk of his total code".

Just as a 100k might be a fair chunk of money in absolute terms, it
might not be a fair chunk of a rich person's money.



Brian

 

[Default User]

Default User wrote:
Yes please.

I promise, when I get to a billion, I'll let you know.



Brian

 

[James Kuyper]

What don't you understand? A "fair chunk of code" might not be "a fair
chunk of his total code".

True. but how could "I have written a fair chunk of code [has this
property]" possibly be interpreted as not implying "A fair chunk of the
code I have written [has this property]"?

Just as a 100k might be a fair chunk of money in absolute terms, it
might not be a fair chunk of a rich person's money.

If a rich person says "I'm giving you a fair chunk of my money", I can
reasonably conclude that it is, indeed, a fair chunk of his money,
(unless I have reason to suspect that he is lying, or at least
exagerrating).

 

[Default User]

James Kuyper wrote:

If a rich person says "I'm giving you a fair chunk of my money",

Which is not what Seebs said.

I
can reasonably conclude that it is, indeed, a fair chunk of his
money, (unless I have reason to suspect that he is lying, or at least
exagerrating).

If a rich person says, "I am giving you a fair chunk of money", can you
conclude that he means, "I am giving you a fair chunk of my money"?




Brian

 

[James Kuyper]

James Kuyper wrote:



Which is not what Seebs said.


If a rich person says, "I am giving you a fair chunk of money", can you
conclude that he means, "I am giving you a fair chunk of my money"?

The valid distinction that you're making between those two statements
has no parallel in the actual case we're discussing.

Let me get far more precise about this than is properly justified by
such a vague phrase as "a fair chunk". His sentence " I have written a
fair chunk of C code that won't compile as C++." means that there's a
two sets of code being compared. The first set of code is that which was
written by Seebs, the second set is code written by Seebs that won't
compile as C++. By saying that "a fair chunk" of the first set is in the
second set, he's telling us that the size (according to some unspecified
measure) of the second set is a large (according to some unspecified
criteria) fraction of the size of the first set.

When I wrote "I wanted to know which particular incompatible features of
C that Seebs uses that cause "a fair chunk" of his C code to be
incompatible with C++.", I did not intend to imply comparison of any
pair of sets other than the same pair of sets that he was referring to;
I did not intend to imply the use of any measure for those sets
different from whatever unspecified measure he was using; I did not
intended to imply any criteria for comparing the size of the two sets,
except whatever unspecified criteria he himself had used. That I
intended the phrase to have precisely the same meaning when I used it,
that it had previously had when he used it, was implied by the fact that
I put that phrase in quotes, making it a cross-reference to his use of
that phrase.

I can't see any way in which I failed to achieve my intent, except of
course the fact that you seem to have somehow managed to interpret my
use of that phrase as referring to something other than precisely the
same thing it referred to when he used it. However, that you could
manage to interpret my statement in that way is a complete mystery to me.

 

[Default User]

The valid distinction that you're making between those two statements
has no parallel in the actual case we're discussing.

Obviously, I disagree.

Let me get far more precise about this than is properly justified by
such a vague phrase as "a fair chunk". His sentence " I have written
a fair chunk of C code that won't compile as C++." means that there's
a two sets of code being compared. The first set of code is that
which was written by Seebs, the second set is code written by Seebs
that won't compile as C++.

I disagree. You're adding a comparison that isn't there. Nowhere does
what he said imply that it's a fair chunk of what he's written. Only
that it's a fair chunk.

Suppose, let's say, he's written 10 million lines of code, of which
100,000 lines fall into the class "won't compile as C++". 100,000 lines
is a fair chunck of code. But it's only a small slice of what he's
written.

I obviously have no idea what the actual numbers are. Nor do you, nor
can you assume it from what he wrote.

By saying that "a fair chunk" of the first
set is in the second set, he's telling us that the size (according to
some unspecified measure) of the second set is a large (according to
some unspecified criteria) fraction of the size of the first set.

I disagree that it says that at all. A fair chunk of code is like a
fair chunk of money. It's a quantity in and of itself, and doesn't say
anything about what else he's written. It could be 100%, it could 1%.

If, to turn it around, suppse someone says, "a fair chunk of the code
I've written is incompatible." What does that tell you? Not much. It
could be 10 lines total.



Brian

 

[Seebs]

Seebs wrote:
...

What are the typical reasons why it won't compile as C++?

(void *)

How much of
your code could not be re-written to compile both as C code, and as C++
code, with the same behavior either way?

I'd guess nearly all of it could, but it would add a lot of casts where they
would increase the risk of hiding errors. (e.g., I really do want "a pointer"
and not much care what the pointer is, but if I added a cast, you could
inadvertantly pass in an int value, which is virtually guaranteed to be
wrong.)

-s

 

[Seebs]

That's not what he said. He said, ". . . a fair chunk of C code." Not a
fair chunk of HIS C code. The former is an absolute thing, the latter
relative.

Just to be clear:

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.

I probably use the name 'new' fairly often, although not all that often.

I doubt I rely on the type of character constants often enough to notice;
I'd guess it's nearly all the (void *) behavior. I believe C++ made the wrong
choice there; while it's good to use new/delete and friends in C++, and it's
good that, in C++, they provide safe and type-checked behavior, it is not
good to require casts for (void *) conversions. In good C++ code, you
should probably very rarely *SEE* a (void *), but if it's there, the compiler
should trust you. That it doesn't is one of the reasons that I do not
consider C++ a "better" C, but rather a substantially worse one. C trusts
the programmer; a thing which does not trust the programmer is not a better
C.

-s

 

[Seebs]

I wonder. Did you steal that habit from me, or did I steal it from
you, or did we steal it independently?

It wasn't a keyword in C when I learned C, and I got in the habit of
writing things like:

foo *
grow(foo *x) {
foo *new = foo_new(x->size + 5);
foo_copy(new, x);
foo_delete(x);
return new;
}

(Well, with any luck, cleaner than that.)

It is, however, a better BASIC.

I'd have to think about it.

-s

 

[Phil Carmody]

James Kuyper wrote:



That's not what he said. He said, ". . . a fair chunk of C code." Not a
fair chunk of HIS C code. The former is an absolute thing, the latter
relative.

What did you elide with the malformed ellipsis?

Phil

 

[Nick Keighley]

as usual much of what [Tech07 is] trying to say is obscured by an
odd use of the [english] language (I'm *assuming* [he] wants to be
understood).

I must admit that I thought you did. Perhaps you could explain what
you do want or what point you are trying to make.

With my OP? The subject says it all!

the subject was/is "When will C have an object model?". I still think
this sounds as if you wish C to have an object model. Are you trying
to be ironic or sarcastic? This often does not work well on usernet.
If you want to be understood then perhaps you could make a simple
statement
in plain english of what your views and wishes are.

But, I think "ya'all" might be right: C
with an OO model may be like putting lipstick on a pig. I've said it 3

times now

I known. It's colourful but unhelpful. Like much of what you write.

so surely that's what I glean from this thread.

I haven't a clue what you wanted or what you gleaned.

That is non-sequitur though.

"opinions vary" Road House

And I do [too], but in different ways. What's the difference? (Note
to self: you know).

Sorry no idea what you mean. You seem to be asking yourself questions.
Is it rude for us to listen to your internal dialogue?

I don't want to keep separate notes about USENET info, I know where it's at:
in my newsreader, with embedded notes to self.

you have re-enabled your encyptor

 

[Nick Keighley]

Which is not what Seebs said.


If a rich person says, "I am giving you a fair chunk of money", can you
conclude that he means, "I am giving you a fair chunk of my money"?

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

 

[James Kuyper]

James Kuyper wrote: ....

I disagree. You're adding a comparison that isn't there. Nowhere does
what he said imply that it's a fair chunk of what he's written. Only
that it's a fair chunk.

"fair" in this context implies comparison against something, if only his
own ideas of what is "fair". I don't really care what basis he was using
to decide whether it was "fair"; my sole intent was to mirror precisely
that basis.

Suppose, let's say, he's written 10 million lines of code, of which
100,000 lines fall into the class "won't compile as C++". 100,000 lines
is a fair chunck of code. But it's only a small slice of what he's
written.

True, "a fair chunk" is a extremely vague description; in fact,
deliberate vagueness is it's main purpose, at least by comparison with
many other ways of describing the amount. I'd certainly have no problem
with someone saying that 100,000 is a fair chunk of 10 million.

I obviously have no idea what the actual numbers are. Nor do you, nor
can you assume it from what he wrote.

Precisely, and my comment in no way relied upon making even the wildest
guess at what those numbers were. All I was trying (and in your case,
apparently failing) to convey was that I was referring to the same exact
body of code that he was, without making any judgment as to the size of
that body of code that was in any way independent of the judgment he
himself had made of it.

....

If, to turn it around, suppse someone says, "a fair chunk of the code
I've written is incompatible." What does that tell you? Not much. It
could be 10 lines total.

I think that's another wording for precisely the same statement that he
did make, and I think your conclusion about this statement is
technically accurate, just as it would have been for his actual
statement. I'd be very surprised at anyone using either phrase to refer
to a body of code as small as 10 lines, but "a fair chunk" is
sufficiently imprecise to allow for that possibility. And if he was
referring to only 10 lines of code, then all I was trying to do was
refer to those same exact 10 lines of code.

So what's it that you're making a big fuss about?