[META] Talking about talking about C.

[Guest]

Have you forgotten 6.3p2?

    Conversion of an operand value to a compatible type
    causes no change to the value or the representation.
           ^^^^^^^^^^^^^^^^^^^^^^

6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1.

If _Bool values are allowed to be any other than 0 or 1, then 6.3p2
and 6.3.1.2 are contradictory.

 

[Marcin Grzegorczyk]

Sorry, "compound statement" was the wrong phrase.

What I really meant was that I tend to pretend that selection and
iteration statements require braces. For example, I'll write
if (condition) {
statement;
}
rather than
if (condition)
statement;

OK, I suspected that was what you meant indeed.
I tend to do the same, except when the whole selection/iteration
statement fits in one line. (Of course, things are different if I have
to match some external coding convention.)

 

[Seebs]

What the **** were you *doing*?

You know, I get asked that a lot. It's hard to remember, but as I recall,
most meetings we started out with methamphetamines and expensive hookers,
and by the end of the week we were pretty much doing whatever was left
around.

Did you consider, at any point, making C any less shit?

From what you've said in your posts here, I sincerely hope we never
did anything that you would have considered "any less shit", though we
did fix up a lot of things that experienced C programmers have usually
regarded as weaknesses or flaws in the language.

-s

 

[Keith Thompson]

What the f*** were you *doing*?

Did you consider, at any point, making C any less s***?

[quotation edited for content]

Would you consider offering any kind of *constructive* suggestion?

 

[Keith Thompson]

You can start by giving typedef some teeth, or replacing/augmenting it with
something stronger.
As it stands, typedef has about as much force as Hungarian Notation.

Just how easy do you think that would be?

Giving typedef "some teeth", assuming you mean having it actually
create a new type, would break existing code, so that's not an
option.

As for adding a new feature, say "newtype" that's similar to typedef
except that it creates a new type rather than an alias, I wouldn't be
opposed to the idea, but nailing down the semantics wouldn't be easy
(perhaps you missed the recent lengthy thread). Would a "newtype"
for a numeric type be implicitly convertible to other numeric types?
If so, there's not much point (the difference would show up mainly
in the presence of pointers to the new type); if not, that's a
fairly radical change to the semantics of arithmetic expressions.
And you still couldn't use the new feature for existing types in
the standard library (size_t et al) without breaking existing code.

As for struct types, well, we already have the ability to create a
new incompatible types just by declaring a new struct type. Arrays?
Pointers? It's already not clear that typedefing them is a good
idea; a "newtype" feature wouldn't necessarily change that.

In practice, most C programmers manage to use typedefs correctly,
treating them *as if* they were distinct types. I don't claim this
is an ideal situation, but there doesn't seem to be much pressure
to add a new feature to the language.

 

[Ian Collins]

Just how easy do you think that would be?

Giving typedef "some teeth", assuming you mean having it actually
create a new type, would break existing code, so that's not an
option.

As for adding a new feature, say "newtype" that's similar to typedef
except that it creates a new type rather than an alias, I wouldn't be
opposed to the idea, but nailing down the semantics wouldn't be easy
(perhaps you missed the recent lengthy thread). Would a "newtype"
for a numeric type be implicitly convertible to other numeric types?
If so, there's not much point (the difference would show up mainly
in the presence of pointers to the new type); if not, that's a
fairly radical change to the semantics of arithmetic expressions.
And you still couldn't use the new feature for existing types in
the standard library (size_t et al) without breaking existing code.

It would turn C into C with objects. We already have that, it's another
language called C++...

 

[Rui Maciel]

You can start by giving typedef some teeth, or replacing/augmenting it
with something stronger.
As it stands, typedef has about as much force as Hungarian Notation.

There isn't a problem with typedef. There is, however, a problem with
people not understanding what it does and believing it is supposed to also
do other stuff or even something else entirely.

If that was the most severe problem regarding C then those who contributed
to the standard should be proud of their work.


Rui Maciel

 

[Seebs]

There isn't a problem with typedef. There is, however, a problem with
people not understanding what it does and believing it is supposed to also
do other stuff or even something else entirely.

I'm not sure there is, in that I've yet to see evidence that there's many
people out there who are confused by what it does. I think there's a lot
of confusion about the *terminology*, but not about the reality of what
you can expect a compiler to accept or reject.

The point of treating typedef-names *as if* they were new types is much
like the point of treating a struct pointer *as if* it were an opaque handle.

Sure, you can look inside a FILE *. (Much to my dismay, it turns out that
FILE is "an object type", so it can't be an incomplete type, so you can't
just have it be a pointer to an otherwise unspecified "struct __file" or
something similar; you actually have to complete the type.) But, unless
you're doing something pretty crazy, it's nearly always a bad idea to do
so; instead, you should write your code *as if* you couldn't look inside
it.

Same goes with most other user-created data types. Writing good code means
honoring the *intended* encapsulation and type distinctions, even though
the language, in general, doesn't provide you with the tools to enforce that.

-s

 

[Felix Palmen]

It would turn C into C with objects. We already have that, it's another
language called C++...

Uhm no, really not. This may be an unpopular thought in a C newsgroup,
but, never mind whether you actually like the ideas of the language or
not, C++ is much more than "C with objects". You can have a minimal
version of "C with objects" just by typedef'ing (jehova!) some
"reference types" (pointers to structs) and a set of functions dealing
with them without revealing their contents to the caller.

Regards,
Felix

 

[Ian Collins]

Uhm no, really not. This may be an unpopular thought in a C newsgroup,
but, never mind whether you actually like the ideas of the language or
not, C++ is much more than "C with objects". You can have a minimal
version of "C with objects" just by typedef'ing (jehova!) some
"reference types" (pointers to structs) and a set of functions dealing
with them without revealing their contents to the caller.

If you had kept the context I was replying to, you would see I was
commenting on Keith's (I assume) rhetorical suggestion of adding means
of adding new types with their own conversion rules. Doing so is
trivially easy in C++, but is not something we do in C.

 

[Felix Palmen]

If you had kept the context I was replying to, you would see I was
commenting on Keith's (I assume) rhetorical suggestion of adding means
of adding new types with their own conversion rules. Doing so is
trivially easy in C++, but is not something we do in C.

I was referring to your statement that this would be "C with objects".
Neither does a mechanism to define new types magically introduce
objects, nor is C++ "C with objects".

Regards,
Felix

 

[Ian Collins]

I was referring to your statement that this would be "C with objects".
Neither does a mechanism to define new types magically introduce
objects, nor is C++ "C with objects".

Well it introduces something that has customisable conversion and
probably logic rules which is beyond the scope of C. Whether you chose
to call it an object is up to you.

I never claimed that C++ "C with objects". It started out that way, but
those days are long gone.

 

[Keith Thompson]

http://www.google.com/codesearch?hl=en&lr=&q=\(const\+LP[A-Z]{2,}+lang:c&sbtn=Search

I think the point you're making is that some typedefs are *meant*
to be aliases, not treated as distinct types. If so, you're right,
and I should have covered that in my comments above.

The functionality provided by typedef (creating an alias for an
existing type) is clearly useful. The additional functionality of
creating a new type that's an incompatible clone of an existing
type might also be useful (but not so useful that cursing at a
member of the C committee for not adding it seems appropriate).

 

[Keith Thompson]

If you had kept the context I was replying to, you would see I was
commenting on Keith's (I assume) rhetorical suggestion of adding means
of adding new types with their own conversion rules. Doing so is
trivially easy in C++, but is not something we do in C.

The change I was, well, not proposing but musing about would not make C
much more object-oriented than it is now.

C's predefined numeric types are already incompatible with each
other, as are user-defined struct types. The suggested change
would merely add a way for the programmer to do something similar.

Just about any new feature added to C is likely to be a step in the
direction of C++. This would be a very small step.

 

[Keith Thompson]

I never claimed that C++ "C with objects". It started out that way, but
those days are long gone.

C++ started out as "C with classes". It's always had objects. }

 

[Keith Thompson]

Jacob has implemented user defined data types in his compiler maybe
someone who has used this feature can weigh in with their experience.

I didn't know that. I'd be interested in seeing some documentation
on this feature.

 

[Keith Thompson]

Look for operator overloading and jacob navia

The following (one of many links) has an overview of Jacob's ideas

http://bytes.com/topic/c/answers/212416-operator-overloading-c

That appears to be an unacknowledged copy of a discussion thread
from this newsgroup.

It is syntactically simple BUT the devil is always in the details as
we found out. Even a simple type can have complex implementation
issues that affect application reliability. As well as operators
new data types need casts and other conversion code to be complete.

As far as I can see from the discussion, the extension enables
operator overloading but I don't see anything specific about a
new mechanism for creating new types. It seems to provide a way
to treat types created by existing mechanisms *as if* they were
numeric types, e.g., by applying arithmetic operators to them.

 

[lawrence.jones]

Sure, you can look inside a FILE *. (Much to my dismay, it turns out that
FILE is "an object type", so it can't be an incomplete type

That has changed in the current draft -- it's still described as an object type,
but that no longer implies a complete type.

 

[Joshua Maurice]

I'm not sure there is, in that I've yet to see evidence that there's many
people out there who are confused by what it does.  I think there's a lot
of confusion about the *terminology*, but not about the reality of what
you can expect a compiler to accept or reject.

I do want to apologize over my behavior in the other thread. I was out
of line.

However, I do wish to say that it took me over 100 posts in that other
thread (not all mine) to even convince you that typedef does not
specify new types. At the very least, you were still playing around
with the possibility that you can have "distinct types" which are not
distinct to the type checker, whatever that means.

 

[Joshua Maurice]

Keith Thompson ha scritto:







what about this?

http://cprog.tomsweb.net/cintro.html#2.4

"The type char may be equivalent to either signed char or unsigned char
(that depends on your compiler), but it is always a separate type from
either of these."

so what does equivalent mean?

They are not the same type because the type checker says that they are
not the same type:
int main()
{
char * x;
unsigned char * y = x;
signed char * z = x;
}
Both of those simple assignments / initializations will fail. Thus
char is a distinct type from the other two.

However, otherwise the two "equivalent" char types have basically all
of the same rules. They have the same bit representation, same
arithmetic rules, and so on. Think of it as something like a "strong
typedef" which specifies a new distinct type as an exact new distinct
copy of an already specified type.