Types

[Keith Thompson]

jacob navia wrote: [...]

I do not know if this classification in function types is correct, or it
would be better to add this to the "incomplete types" section.

A function type cannot ever be an incomplete type.

Incomplete in the sense that the number and types of the function
arguments are unknown, as in an incomplete declaration the number and
types of the structure/union members are unknown.

There are two kinds:

1) Function declarations that are not prototypes, to use your terminology.
2) Completely implicit declaration where the compiler assumes:

int fn();

But it's unwise to use the term "incomplete type" to mean something
other than what the standard defines it to be.

 

[Guest]

But this is not adding 1 to a character string!

It means (in C) adding 1 to the ADDRESS of the start of the string,
what is completely another matter!

Yes, the comment about C was just a side note. In the other two
languages, it /is/ adding 1 to a character string.

 

[Eric Sosman]

Hi people
I have been working again in my tutorial, and I have finished the
"types" chapter. If you feel like "jacob bashing" this is the
occasion!

Jacob, your attitude verges on paranoia. And if there's
one thing I hate above all else, it's the way you paranoids
are always going out of your way to irritate ME!

I am asking for criticisms, or for things I may have said
wrong. Keep in mind that this is a tutorial, and I donot want to
overwhelm the reader with little details.
[... thoughtful essay ...]

There are a lot of minor nit-picks, but I'll ignore them
and try to look at a couple larger issues.

First, I think the notion of "type" in the essay is at odds
with C's use of the term. The essay promotes the idea that type
is a creature of the compiler, something imposed by the language
upon an undifferentiated mass of bits. While I agree that the
bits themselves may not carry type information (they do on some
systems but not on all), I'd dispute the notion that "type" is
absent from the machine language. For example, most machines
will have two (or more) ADD instructions that operate differently
on bit-for-bit identical operands: One will interpret the operands
as integers and generate an integer sum, the other will interpret
them as floating-point values and generate a different sum. This
seems to me a perfect example of "type."

Second, there seems to be a rather narrow focus on "type" as
a property of data. That's only part of the story, because in C
the expressions have types. True, those types do in some cases
derive from the declared types of variables that appear in them,
but it could be argued that the only reason for assigning a type
to a variable is to allow the compiler to do the bookkeeping to
derive the type of the expression. (This point of view leads to
a fairly straightforward explanation of why one can view a data
object in different ways by accessing it with expressions of
different types: it's not that the object itself somehow morphs
between `double' and `unsigned char[sizeof(double)]', but that the
object just sits there while expressions of different types work
on it. This approach also handles the question of the "type" of a
freshly-mallocated memory area: the memory has no "type" of its
own, but the expressions that operate on it do.) You might not wish
to take the notion quite as far as I'm suggesting, but I think it
is a mistake to limit "type" to the data objects and ignore the
expressions.

Third and finally, you write that you do not want to "overwhelm
the reader with little details," and that's fine. What, then, is
the purpose of the long list of C's types? If you are trying to
make the point that there are many types built in to C, I think it
could be made more clearly and more briefly than by exhibiting a
sterile (and incomplete!) catalog.

Looking forward to version two-dot-oh.

 

[Mark McIntyre]

Adding an integer to a character string? What would be the result of THAT?

Or maybe you mean
"9" + "1" --> "91"

Precisely.
"foo" + 31 = "foo31"


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

But this is not adding 1 to a character string!

It is, but just not according to the definition you're thinking of.

Bear in mind that several languages define string addition and most
provide default conversion operators. It'd be fairly trivial to
implement such an "addition" operator.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[jacob navia]

Mark McIntyre a écrit :

Precisely.
"foo" + 31 = "foo31"

Ahhh how CLEVER!!!


Gosh, I hope I do not come across it sometime

 

[Ben Pfaff]

On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia


It is, but just not according to the definition you're thinking of.

Bear in mind that several languages define string addition and most
provide default conversion operators. It'd be fairly trivial to
implement such an "addition" operator.

It would? What is the lifetime for the object that "a" + "b"
would yield?

 

[jacob navia]

Ben Pfaff a écrit :

It would? What is the lifetime for the object that "a" + "b"
would yield?

Even if lcc-win32 implements operator overloading, I have warned
in the docs and in the tutorial against such "applications".

"a"+"b" != "b"+"a"

Addition is no longer commutative, and there is always the
horrible
"1"+"1" --> "11"

:-(

 

[Keith Thompson]

It would? What is the lifetime for the object that "a" + "b"
would yield?

It depends on how the language in question deals with the concept of
"lifetime". In some languages, it will simply live until the
implementation can prove that there are no more references to it. And
you're assuming it's an object rather than just a value; there are
plenty of languages in which strings are treated almost like simple
scalar values.

 

[Ben Pfaff]

It depends on how the language in question deals with the concept of
"lifetime". In some languages, it will simply live until the
implementation can prove that there are no more references to it. And
you're assuming it's an object rather than just a value; there are
plenty of languages in which strings are treated almost like simple
scalar values.

Let me expand on my comment.

It is my impression that Mark McIntyre was saying that it'd be
fairly trivial to implement a string addition operator in C. In
that case, you need to pick one of the existing C forms of
lifetime, or define a new one. I don't think any of the existing
forms are suitable. I also think it'd be nontrivial to define a
new kind of lifetime. Therefore, I don't think it'd be trivial
to implement a string addition operator in C.

 

[Mark McIntyre]

It would? What is the lifetime for the object that "a" + "b"
would yield?

Whatever the semantics of the language you're using allow it to be.

Lets take some hypothetical c-like language:

string f;

void dosomething()
{
f = "a" + "b";
}

I belive that 'f' is likely to have a lifetime equal to that of your
application.





--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Let me expand on my comment.

It is my impression that Mark McIntyre was saying that it'd be
fairly trivial to implement a string addition operator in C.

In fact, not the case. Sorry if you misunderstood.

In that case, you need to pick one of the existing C forms of
lifetime, or define a new one. I don't think any of the existing
forms are suitable.

Well, assigning the result of the addition to a file-scope object
would cause the lifetime to be perfectly acceptable surely?

Therefore, I don't think it'd be trivial
to implement a string addition operator in C.

Obviously one can't do it in standard C, since one can't override
operators.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Mark McIntyre a écrit :

Ahhh how CLEVER!!!

Gosh, I hope I do not come across it sometime

At least one language I've seen implements this already, though
thankfully I've already managed to forget which one...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Eric Sosman]

In fact, not the case. Sorry if you misunderstood.


Well, assigning the result of the addition to a file-scope object
would cause the lifetime to be perfectly acceptable surely?

What is this "result" of which you speak, Grasshopper?

Assigning a char* value to a file-scope object -- to anything
at all -- doesn't influence the lifetime of the pointed-to object
and hence doesn't, er, address the issue.

Assigning a string means extending C to support array
assignment, an exercise I personally would not call "trivial."
(You might be able to escape the chore of full-scale array
assignment by making "string" a first-class data type in its
own right, but I still don't think "trivial" is the mot juste.)

Finally, if all you want is the "addition" of string literals,
C already does that. (Using an "operator" whose notation is
about as concise as can be imagined; you'll find it written
between the final two punctuation marks here

 

[Richard Bos]

At least one language I've seen implements this already, though
thankfully I've already managed to forget which one...

Sinclair QL Basic, I think.

Richard

 

[Ian Collins]

At least one language I've seen implements this already, though
thankfully I've already managed to forget which one...

It's fairly idiomatic JavaScript.

 

[Roland Pibinger]

It's fairly idiomatic JavaScript.

If that means that the left type of the operator determines the result
type it's fairly reasonable, IMHO.

Best wishes,
Roland Pibinger

 

[Guest]

If that means that the left type of the operator determines the result
type it's fairly reasonable, IMHO.

It doesn't. The type of the result is a string if either operand is a
string. 31 + "1" becomes "311", not 32.

 

[Mark McIntyre]

What is this "result" of which you speak, Grasshopper?

Why master, "foo31" of course, which is assigned as the value of the
string thingy 'foo'....

Assigning a char* value to a file-scope object -- to anything
at all -- doesn't influence the lifetime of the pointed-to object
and hence doesn't, er, address the issue.

Which part of "obviously you can't do this in Standard C" was hard to
understand, Master? And also irrelevant since my example didn't
depend on a char*.

Assigning a string means extending C to support array
assignment, an exercise I personally would not call "trivial."

Newsflash: who said anything about arrays?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

It's fairly idiomatic JavaScript.

There's a 't' missing in the third word above, surely?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan