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! 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.
-------------------------------------------------------------------------*
Types
A machine has no concept of type, everything is just a sequence of bits,
and any operation with those sequences can be done, even if it is not
meaningful at all, for example adding two addresses, or multiplying two
character strings.
A high level programming language however, enforces the concept of types
of data. Operations are allowed between compatible types and not between
any data whatsoever. It is possible to add two integers, or an integer
and a floating point number, and even an integer and a complex number.
It is not possible to add an integer to a function or to a character
string, the operation has no meaning for those types.
An operation implies always compatible types netween the operands.
In C, all data must be associated with a specific type before it can be
used. All variables must be declared to be of a known type before any
operation with them is attempted since to be able to generate code the
compiler must know the type of each operand.
C allows the programmer to define new types based on the previously
dfined ones. This means that the type system in C is static, i.e. known
at compile time, but extensible since you can add new types.
This is in contrast to dynamic typing, where no declarations are needed
since the language associates types and data during the run time.
Dynamic typing is much more flexible, but this flexibility has a price:
the run time system must constantly check the types of the operands for
each operation to see if they are compatible, what slows down the
program considerably.
In C there is absolutely no run time checking in most operations, since
the compiler is able to check everything during the compilation, what
accelerates execution of the program, and allows the compiler to
discover a lot of errors during the compilation instead of crashing at
run time when an operation with incompatible types is attempted.
What is a type?
A first tentative, definition for what a type is, could be “a type is a
definition of an algorithm for understanding a sequence of storage
bits”. It gives the meaning of the data stored in memory. If we say that
the object a is an int, it means that the bits stored at that location
are to be understood as a natural number that is built by consecutive
additions of powers of two. If we say that the type of a is a double, it
means that the bits are to be understood as the IEEE 754 standard
sequences of bits representing a double precision floating point value.
Functions have a type too. The type of a function is determined by the
type of its return value, and all its arguments. The type of a function
is its interface with the outside world: its inputs (arguments) and its
outputs (return value).
Types in C can be incomplete, i.e. they can exist as types but nothing
is known about them, neither their size nor their bit-layout. They are
useful for encapsulating data into entities that are known only to
certain parts of the program.
Each type can have an associated pointer type: for int we have int
pointer, for double we have double pointer, etc. We can have also
pointers that point to an unspecified object. They are written as void
*, i.e. pointers to void. Some types exist only as pointers: the
function pointer type has no object counterpart since a function object
doesn’t exist in C, only pointers to functions exist.
Types classification
This type classification is based on the classification published by
Plauger and Brody, slightly modified.
Types
1. Function types
1.1 Fully qualified function types. (Functions whose full prototype is
visible)
1.2 Assumed function types (Functions whose prototype is partly or not
visible)
1.2.1 Functions whose return value is visible but not their arguments
1.2.2 Functions where the return value and their arguments are unknown.
2. Incomplete types (Types not completely specified)
2.1 void
2.2 Incomplete struct types
2.3 Incomplete array types
2.4 Incomplete union types
3. Object types
3.1 Scalar types
3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 char (signed/unsigned)
3.1.1.1.1.2 short (signed unsigned)
3.1.1.1.1.3 int (signed/unsigned)
3.1.1.1.1.4 long (signed/unsigned)
3.1.1.1.1.5 long long (signed/unsigned)
3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 float
3.1.1.2.2 double
3.1.1.2.3 long double
3.1.2 Pointer types
3.1.2.1 Pointer to function
3.1.2.2 Pointer to object types
3.1.2.3 Pointer to incomplete types
3.2 Non -scalar types
3.2.1 Struct types
3.2.2 Union types
3.2.3 Array types
Integer types
The language doesn’t specify exactly how big each integer type must be,
but it has some requirements as to the minimum size of the integer
types. The char type must be at least 8 bits, the int type must be at
least 16 bits, and the long type must be at least 32 bits. How big each
integer type actually is, is defined in the standard header limits.h.
Floating types
Floating types are discussed in more detail later. Here we will just
retain that they can represent integer and non integer quantities, and
in general, their dynamic range is bigger that integers of the same
size. They have two parts: a mantissa and an exponent.
As a result, there are some values that can’t be expressed in floating
point, for instance 1/3 or 1/10. This comes as a surprise for many
people, so it is better to underscore this fact here. More explanations
for this later on.
Floating point arithmetic is approximative, and many mathematical laws
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.
Compatible types
There are types that share the same underlying representation. For
instance, in lcc-win32 for the Intel platform, in 32 bits, long and int
are the same. They are compatible types for that version of lcc. In the
version of lcc-linux for 64 bits however, long is 64 bits and int is 32
bits, they are no longer compatible types, but long is now compatible
with the long long type.
Plauger and Brody give the following definition for when two types are
compatible types:
Both types are the same.
Both are pointer types, with the same type qualifiers, that point to
compatible types.
Both are array types whose elements have compatible types. If both
specify repetition counts, the repetition counts are equal.
Both are function types whose return types are compatible. If both
specify types for their parameters, both declare the same number of
parameters (including ellipses) and the types of corresponding
parameters are compatible. Otherwise, at least one does not specify
types for its parameters. If the other specifies types for its
parameters, it specifies only a fixed number of parameters and does not
specify parameters of type float or of any integer types that change
when promoted.
Both are structure, union, or enumeration types that are declared in
different translation units with the same member names. Structure
members are declared in the same order. Structure and union members
whose names match are declared with compatible types. Enumeration
constants whose names match have the same values.
Incomplete types
An incomplete type is missing some part of the declaration. For instance
struct SomeType;
We know now that “SomeType” is a struct, but since the contents aren’t
specified, we can’t use directly that type. The use of this is precisely
to avoid using the type: encapsulation. Many times you want to publish
some interface but you do not want people using the structure,
allocating a structure, or doing anything else but pass those structure
to your functions. In those situations, an opaque type is a good thing
to have.
Casting
The programmer can at any time change the type associated with a piece
of data by making a “cast” operation. For instance if you have:
float f = 67.8f;
you can do
double d = (double)f;
The “(double)” means that the type of data in f should be converted into
an equvalent data using the double representation. We will come back to
types when we speak again about casts later.
58  3240 
P.S. The difference between the classification of types as proposed by
Plauger and Brody and the classification there is that I think it is
important to differenciate function types, between functions with full
prototype
int fn(int,double);
"half prototype"
char *fn();
and no prototype at all.
jacob navia said:
P.S. The difference between the classification of types as proposed by
Plauger and Brody and the classification there is that I think it is
important to differenciate function types, between functions with full
prototype
int fn(int,double);
"half prototype"
char *fn();
That isn't a half-prototype. It's a function declaration, and that's all it
is.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield a écrit :
jacob navia said:
>>P.S. The difference between the classification of types as proposed by
Plauger and Brody and the classification there is that I think it is
important to differenciate function types, between functions with full
prototype
int fn(int,double);
"half prototype"
char *fn();
That isn't a half-prototype. It's a function declaration, and that's all it
is.
No, it is missing the number and types of the arguments.
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.
jacob navia wrote:
>
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! 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.
-----------------------------------------------------------------*
Types
A machine has no concept of type, everything is just a sequence of
bits, and any operation with those sequences can be done, even if
it is not meaningful at all, for example adding two addresses, or
multiplying two character strings.
Meet the Burroughs machines.
.... snip ...
>
In C there is absolutely no run time checking in most operations,
since the compiler is able to check everything during the
compilation, what accelerates execution of the program, and allows
the compiler to discover a lot of errors during the compilation
instead of crashing at run time when an operation with incompatible
types is attempted.
Not necessarily. Signed integer overflow always results in
undefined behaviour, for example.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer a écrit :
jacob navia wrote:
>>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! 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.
-----------------------------------------------------------------*
Types
A machine has no concept of type, everything is just a sequence of
bits, and any operation with those sequences can be done, even if
it is not meaningful at all, for example adding two addresses, or
multiplying two character strings.
Meet the Burroughs machines.
... snip ...
>>In C there is absolutely no run time checking in most operations,
since the compiler is able to check everything during the
compilation, what accelerates execution of the program, and allows
the compiler to discover a lot of errors during the compilation
instead of crashing at run time when an operation with incompatible
types is attempted.
Not necessarily. Signed integer overflow always results in
undefined behaviour, for example.
Yes, you are right, and lcc-win32 provides a way to check this at run
time. I will add a few sentences concerning this possibility, and the
runtime errors that can appear in C during the runtime in the primitive
types.
This means, as you notice, signed int overflow but also floating
point errors, bad pointer values, and other types of errors.
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>... Keep in mind that this is a tutorial, and I donot want to
overwhelm the reader with little details.
It is OK to gloss over details, but if you are going to do so, I
think you should note where this has occurred. (Maybe mark parts
with footnotes, marginal notes, some of those typographic "dingbats"
as they are called, or some other technique.)
>-------------------------------------------------------------------------*
Types
A machine has no concept of type,
This is a huge overstatement. Not only is it not strictly true
(there are machines with "typed RAM", although they are no longer
in common use and they can make C compilers difficult or even
impossible), it is also highly misleading: a typical modern machine
still applies a type to every operation, it is just that you get
to choose the type each time you do the operation. For instance:
mulf rResult, rInput1, rInput2
could treat the two inputs as 32-bit floating-point numbers, while:
mull rResult, rInput1, rInput2
would treat the two inputs as 32-bit integer values. And of course,
on many machines including the x86, "floating-point" numbers are
handled very differently from "integer" numbers: you cannot quite
stick a full FP number into an integer register (since there are
no 80-bit integer registers), although using SSE/MMX extensions,
you can sometimes do vice versa.
A lot of machines also have "semi-typed" registers: address vs
data, for instance (see the 680x0; and even the x86 does this, to
a lesser extent: computational results commonly go in %eax,
occasionally in %edx, rarely in %esi, etc.).
On the other hand, this part is generally true:
>everything is just a sequence of bits,
and any operation with those sequences can be done, even if it is not
meaningful at all, for example adding two addresses, or multiplying two
character strings.
I think it is worth re-phrasing this paragraph. Maybe even just make
the opening sentence something like "Machines don't enforce consistency
of types. Everything is just a sequence of bits, ..."
>A high level programming language however, enforces the concept of types
of data. Operations are allowed between compatible types and not between
any data whatsoever. It is possible to add two integers, or an integer
and a floating point number, and even an integer and a complex number.
It is not possible to add an integer to a function or to a character
string, the operation has no meaning for those types.
(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
>A first tentative, definition for what a type is, could be 0x93a type is a
definition of an algorithm for understanding a sequence of storage
bits0x94.
(These 0x93/0x94 characters are rather annoying Microsoft-isms. They
are not just non-ASCII, they are even non-ISO-8851. This definition
seems good though. There are other Microsoft characters that snuck
into the posting, too, I just noticed these first. I have no comments
on the rest of this)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
jacob navia wrote:
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.
First suggestion: correct spelling errors before asking for criticisms.
A high level programming language however, enforces the concept of types
of data.
I would say that high-level programming languages implement the concept
of types of data. "Enforcing a concept" doesn't make sense.
An operation implies always compatible types netween the operands.
An operation requires compatible operand types.
C allows the programmer to define new types based on the previously
dfined ones. This means that the type system in C is static, i.e. known
at compile time, but extensible since you can add new types.
This means that although the type system in C is static (known at
compile time), it is also extensible, since you can add new types.
This is in contrast to dynamic typing, where no declarations are needed
since the language associates types and data during the run time.
Dynamic typing is much more flexible, but this flexibility has a price:
the run time system must constantly check the types of the operands for
each operation to see if they are compatible, what slows down the
program considerably.
.... each operation to see if they are compatible, and perform
conversions if needed, which significantly slows execution.
A first tentative, definition for what a type is, could be “a type is a
definition of an algorithm for understanding a sequence of storage
bits”.
I disagree that a type is a "definition of an algorithm". To me, it is
a specification of the meaning of the bits of a variable. I don't
associate such specifications directly with algorithms.
If we say that the type of a is a double, it
means that the bits are to be understood as the IEEE 754 standard
sequences of bits representing a double precision floating point value.
This is not universally true. How about
If a variable type is double, it means that the variable contains a
sign, mantissa, and exponent used to approximate a real number. The
IEEE 754 standard specifies floating point formats that are used by a
majority of current computers.
Floating point arithmetic is approximative, and many mathematical laws
approximate
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.
That is a poor example. There may be some arithmetic units for which
addition is not commutative, but I am not aware of any (excluding result
carry-over with additional precision). Consider "(a+b)+c is equal to
a+(b+c)".
There are types that share the same underlying representation. For
That's fine.
instance, in lcc-win32 for the Intel platform, in 32 bits, long and int
are the same. They are compatible types for that version of lcc.
The precision of the wording should be improved. Are the types "the
same" or "compatible"? These are different concepts.
I can't speak for lcc-win32, but in Standard C, I think, different
integer types, even if the same size, are not compatible. Conversions
apply, even if they result in no code being generated.
--
Thad
>jacob navia wrote:
>A first tentative, definition for what a type is, could be 0x93a type is a
definition of an algorithm for understanding a sequence of storage
bits0x94.
In article <45***********************@auth.newsreader.octanew s.com>
Thad Smith <Th*******@acm.orgwrote:
>I disagree that a type is a "definition of an algorithm". To me, it is
a specification of the meaning of the bits of a variable. I don't
associate such specifications directly with algorithms.
That might be a better "first, tentative definition" for a type,
as it is the actual definition of a concrete type. But given a
specification, one can derive an algorithm ... and it depends
on whether one wants to start with the concrete or the abstract.
(An abstract type is sort of "more algorithm, less specification",
as it were. With a concrete type, you not only have the raw bits,
but also everything you need to know to find the value given the
bits. With an abstract type, you have at least some, but not
necessarily all, the bits -- some set of bits that provide a sort
of handle to the underlying value, at least[%] -- and only as much
information as the type-provider chooses to provide to find values,
along with a separate set of operations upon bit-sets to produce
new bit-sets.)
[% Consider an abstract type where the value is simply a pointer to
the "real" value, e.g., "struct incomplete *p".]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
jacob navia wrote:
Richard Heathfield a écrit :
jacob navia said:
>P.S. The difference between the classification of types as proposed by
Plauger and Brody and the classification there is that I think it is
important to differenciate function types, between functions with full
prototype
int fn(int,double);
"half prototype"
char *fn();
That isn't a half-prototype. It's a function declaration, and that's all it
is.
No, it is missing the number and types of the arguments.
Right. So it's just a function declaration that is not a prototype.
There's no such thing as a "half-prototype".
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.
Thad Smith wrote:
jacob navia wrote:
Floating point arithmetic is approximative, and many mathematical laws
approximate
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.
That is a poor example. There may be some arithmetic units for which
addition is not commutative, but I am not aware of any (excluding result
carry-over with additional precision).
Isn't that enough?
Consider "(a+b)+c is equal to
a+(b+c)".
That does not apply to integer or pointer arithmetic either.
"Harald van Dijk" <tr*****@gmail.comwrites:
Thad Smith wrote:
>jacob navia wrote:
Floating point arithmetic is approximative, and many mathematical laws
approximate
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.
That is a poor example. There may be some arithmetic units for which
addition is not commutative, but I am not aware of any (excluding result
carry-over with additional precision).
Isn't that enough?
>Consider "(a+b)+c is equal to
a+(b+c)".
That does not apply to integer or pointer arithmetic either.
It's different, though. Integer and pointer arithmetic are
associative *unless* an intermediate result is undefined, I think. In
floating-point arithmetic, it's possible that (a+b)+c and a+(b+c) have
different values without overflow.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia <ja***@jacob.remcomp.frwrote:
Types
A machine has no concept of type, everything is just a sequence of bits,
and any operation with those sequences can be done, even if it is not
meaningful at all, for example adding two addresses, or multiplying two
character strings.
Great way to start... never heard of address register, floating point
registers, and integer registers?
A high level programming language however, enforces the concept of types
of data. Operations are allowed between compatible types and not between
any data whatsoever. It is possible to add two integers, or an integer
and a floating point number, and even an integer and a complex number.
It is not possible to add an integer to a function or to a character
string, the operation has no meaning for those types.
This is a run on sentence, run on sentences are just as wrong in French
as in English so you should have known better, you are unfortunately not
the only person to make such mistakes so don't feel too bad, replace the
last comma with a full stop.
An operation implies always compatible types netween the operands.
Not necessarily. See casts. And for some operations, the compatibility
needs to run only one way.
This is in contrast to dynamic typing, where no declarations are needed
since the language associates types and data during the run time.
Dynamic typing is much more flexible, but this flexibility has a price:
the run time system must constantly check the types of the operands for
each operation to see if they are compatible, what slows down the
program considerably.
_Which_ slows down the program. And that's not the only problem; it also
leads to more run-time errors and fewer compile-time errors.
In C there is absolutely no run time checking in most operations, since
the compiler is able to check everything during the compilation, what
accelerates execution of the program,
_Which_.
What is a type?
A first tentative, definition for what a type is, could be “a type is a
A first, tentative, definition. And don't use that kind of quote mark on
Usenet - it's OK (indeed, better) if it goes into a web page.
definition of an algorithm for understanding a sequence of storage
bits”.
An unusual, but not a bad definition of type.
Each type can have an associated pointer type:
s/can have/has/.
for int we have int
pointer, for double we have double pointer, etc. We can have also
pointers that point to an unspecified object. They are written as void
*, i.e. pointers to void.
Bad line break. Break this before "void *".
Some types exist only as pointers: the function pointer type has no
object counterpart since a function object doesn’t exist in C, only
pointers to functions exist.
A function object doesn't exist (because it's a contradiction in terms),
but that doesn't mean that a function type doesn't. See 6.2.5.
Types classification
This type classification is based on the classification published by
Plauger and Brody, slightly modified.
Types
1. Function types
1.1 Fully qualified function types. (Functions whose full prototype is
visible)
1.2 Assumed function types (Functions whose prototype is partly or not
visible)
1.2.1 Functions whose return value is visible but not their arguments
1.2.2 Functions where the return value and their arguments are unknown.
You're missing variadic functions, which fall in between 1.1 and 1.2.1.
2. Incomplete types (Types not completely specified)
2.1 void
2.2 Incomplete struct types
2.3 Incomplete array types
2.4 Incomplete union types
Better keep struct and union together - not necessarily under the same
item, but not separated by array.
3. Object types
3.1 Scalar types
3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 char (signed/unsigned)
3.1.1.1.1.2 short (signed unsigned)
3.1.1.1.1.3 int (signed/unsigned)
3.1.1.1.1.4 long (signed/unsigned)
3.1.1.1.1.5 long long (signed/unsigned)
Don't use 8-space tabs. This indentation is ridiculous.
If you mention long long, you need to mention intN_t, intmax_t, and so
forth...
3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 float
3.1.1.2.2 double
3.1.1.2.3 long double
....and complex types.
You also need to mention that these, including long long, are C99 only.
3.1.2 Pointer types
3.1.2.1 Pointer to function
3.1.2.2 Pointer to object types
3.1.2.3 Pointer to incomplete types
3.2 Non -scalar types
3.2.1 Struct types
3.2.2 Union types
3.2.3 Array types
This is better than 2.2-2.4 above, but at the very least be consistent.
Integer types
The language doesn’t specify exactly how big each integer type must be,
but it has some requirements as to the minimum size of the integer
types.
Wrong. It has requirements as to the minimum _values_ it can hold. This
necessarily does translate to a minimum bit size, but it pays to be
precise.
The char type must be at least 8 bits, the int type must be at
least 16 bits, and the long type must be at least 32 bits. How big each
integer type actually is, is defined in the standard header limits.h.
Floating types
Floating types are discussed in more detail later. Here we will just
retain that they can represent integer and non integer quantities, and
in general, their dynamic range is bigger that integers of the same
size.
This is highly misleading unless you define "dynamic range" and mention
that it means that a 4-byte float can't represent all values that a
4-byte int can, as much as the opposite.
They have two parts: a mantissa and an exponent.
And this is just subtly wrong. You missed one bit.
Floating point arithmetic is approximative,
Usually, but...
and many mathematical laws that we take for granted like a+b is
equal to b+a do not apply in many cases to floating point math.
....this shouldn't be true. Floating point addition _is_ commutative; it
isn't associative.
Plauger and Brody give the following definition for when two types are
compatible types:
Use the Standard instead. I _think_ what you have here is equivalent,
but check.
Incomplete types
An incomplete type is missing some part of the declaration.
No. Check the Standard: an incomplete type is an object type which does
not have the necessary information to determine its size. This does not
mean that anything need be missing; the information may simply not
exist. In particular, void is an incomplete type which cannot be
completed.
Casting
The programmer can at any time change the type associated with a piece
of data by making a “cast” operation.
s/making/using/, and see below.
For instance if you have:
float f = 67.8f;
you can do
double d = (double)f;
The “(double)” means that the type of data in f should be converted into
an equvalent data using the double representation.
Wrong, wrong, wrongity-wrong. The data in f should be left alone. The
_expression_ evaluates to the _value_ of f converted to that type. Not
the data, i.e. the bytes; purely the value.
(Oh, and: "equivalent". Use a spill chucker.)
Do we get credit in the final document?
Richard
Keith Thompson wrote:
"Harald van Dijk" <tr*****@gmail.comwrites:
Thad Smith wrote:
jacob navia wrote:
Floating point arithmetic is approximative, and many mathematical laws
approximate
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.
That is a poor example. There may be some arithmetic units for which
addition is not commutative, but I am not aware of any (excluding result
carry-over with additional precision).
Isn't that enough?
Consider "(a+b)+c is equal to
a+(b+c)".
That does not apply to integer or pointer arithmetic either.
It's different, though. Integer and pointer arithmetic are
associative *unless* an intermediate result is undefined, I think.
unsigned a = UINT_MAX;
unsigned b = UINT_MAX;
unsigned long c = 1;
Now, there is no undefined behaviour in either (a + b) + c or a + (b +
c), but it's still possible for those to give different results.
In
floating-point arithmetic, it's possible that (a+b)+c and a+(b+c) have
different values without overflow.
Technically, there is no overflow in my example, but I get your point.
Chris Torek wrote:
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>... Keep in mind that this is a tutorial, and I donot want to
overwhelm the reader with little details.
It is OK to gloss over details, but if you are going to do so, I
think you should note where this has occurred. (Maybe mark parts
with footnotes, marginal notes, some of those typographic "dingbats"
as they are called, or some other technique.)
>>-------------------------------------------------------------------------*
Types
A machine has no concept of type,
This is a huge overstatement. Not only is it not strictly true
(there are machines with "typed RAM", although they are no longer
in common use and they can make C compilers difficult or even
impossible), it is also highly misleading: a typical modern machine
still applies a type to every operation, it is just that you get
to choose the type each time you do the operation. For instance:
mulf rResult, rInput1, rInput2
could treat the two inputs as 32-bit floating-point numbers, while:
mull rResult, rInput1, rInput2
would treat the two inputs as 32-bit integer values. And of course,
on many machines including the x86, "floating-point" numbers are
handled very differently from "integer" numbers: you cannot quite
stick a full FP number into an integer register (since there are
no 80-bit integer registers), although using SSE/MMX extensions,
you can sometimes do vice versa.
A lot of machines also have "semi-typed" registers: address vs
data, for instance (see the 680x0; and even the x86 does this, to
a lesser extent: computational results commonly go in %eax,
occasionally in %edx, rarely in %esi, etc.).
On the other hand, this part is generally true:
>>everything is just a sequence of bits,
and any operation with those sequences can be done, even if it is not
meaningful at all, for example adding two addresses, or multiplying two
character strings.
I think it is worth re-phrasing this paragraph. Maybe even just make
the opening sentence something like "Machines don't enforce consistency
of types. Everything is just a sequence of bits, ..."
Yes, thanks. My intent was to say exactly that (there are no enforced
types) but I did not say it explicitely. Obviously a floating point add
assumes some structure in the bits at the input addresses, as an integer
add, etc.
>
>>A high level programming language however, enforces the concept of types
of data. Operations are allowed between compatible types and not between
any data whatsoever. It is possible to add two integers, or an integer
and a floating point number, and even an integer and a complex number.
It is not possible to add an integer to a function or to a character
string, the operation has no meaning for those types.
(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
Adding an integer to a character string? What would be the result of THAT?
Or maybe you mean
"9" + "1" --"91"
jacob navia wrote:
Chris Torek wrote:
>(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
Adding an integer to a character string? What would be the result of THAT?
Or maybe you mean
"9" + "1" --"91"
More likely "string"+1, which is legal in several languages.
--
Ian Collins.
Ian Collins wrote:
jacob navia wrote:
Chris Torek wrote:
(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
Adding an integer to a character string? What would be the result of THAT?
Or maybe you mean
"9" + "1" --"91"
More likely "string"+1, which is legal in several languages.
The meaning of "string"+1 is inconsistent between languages, though. In
Perl, its result is 1. In JavaScript, the result is "string1". It's
also legal C, and equivalent to "tring".
Harald van Dijk wrote:
jacob navia wrote:
>>Richard Heathfield a écrit :
>>>jacob navia said:
P.S. The difference between the classification of types as proposed by
Plauger and Brody and the classification there is that I think it is
important to differenciate function types, between functions with full
prototype
int fn(int,double);
"half prototype"
char *fn();
That isn't a half-prototype. It's a function declaration, and that's all it
is.
No, it is missing the number and types of the arguments.
Right. So it's just a function declaration that is not a prototype.
There's no such thing as a "half-prototype".
>>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();
Harald van Dijk wrote:
Ian Collins wrote:
>>jacob navia wrote:
>>>Chris Torek wrote:
(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
Adding an integer to a character string? What would be the result of THAT?
Or maybe you mean
"9" + "1" --"91"
More likely "string"+1, which is legal in several languages.
The meaning of "string"+1 is inconsistent between languages, though. In
Perl, its result is 1. In JavaScript, the result is "string1". It's
also legal C, and equivalent to "tring".
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!
jacob navia said:
Harald van D?k wrote:
>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,
That's not what "incomplete types" means in C, though. In C, there are three
kinds of types - object types, function types, and incomplete types. If
it's a function type, it simply can't be an incomplete type. See 3.1.2.5 of
C89 or 6.2.5 of C99.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
jacob navia <ja***@jacob.remcomp.frwrites:
Harald van Dijk wrote:
>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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia wrote:
Harald van Dijk wrote:
Ian Collins wrote:
>jacob navia wrote:
Chris Torek wrote:
(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
Adding an integer to a character string? What would be the result of THAT?
Or maybe you mean
"9" + "1" --"91"
More likely "string"+1, which is legal in several languages.
The meaning of "string"+1 is inconsistent between languages, though. In
Perl, its result is 1. In JavaScript, the result is "string1". It's
also legal C, and equivalent to "tring".
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.
jacob navia wrote:
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.
--
Eric Sosman es*****@acm-dot-org.invalid
On Mon, 11 Dec 2006 10:03:45 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Chris Torek wrote:
>(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
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
On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>
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
Mark McIntyre a écrit :
On Mon, 11 Dec 2006 10:03:45 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Chris Torek wrote:
>>>(This glosses over some stuff, e.g., many "high level" languages *do*
allow you to add an integer to a character string.)
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"
Ahhh how CLEVER!!!
Gosh, I hope I do not come across it sometime
:-)
Mark McIntyre <ma**********@spamcop.netwrites:
On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>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.
It would? What is the lifetime for the object that "a" + "b"
would yield?
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
Ben Pfaff a écrit :
Mark McIntyre <ma**********@spamcop.netwrites:
>>On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>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.
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"
:-(
Ben Pfaff <bl*@cs.stanford.eduwrites:
Mark McIntyre <ma**********@spamcop.netwrites:
>On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>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.
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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson <ks***@mib.orgwrites:
Ben Pfaff <bl*@cs.stanford.eduwrites:
>Mark McIntyre <ma**********@spamcop.netwrites:
>>On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>>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.
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.
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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
On Mon, 11 Dec 2006 09:24:48 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>On Mon, 11 Dec 2006 10:48:13 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>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.
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
On Mon, 11 Dec 2006 10:08:13 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:
>
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
On Mon, 11 Dec 2006 17:28:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre a écrit :
>"foo" + 31 = "foo31"
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
Mark McIntyre wrote:
On Mon, 11 Dec 2006 10:08:13 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:
>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?
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:)
--
Eric Sosman es*****@acm-dot-org.invalid
Mark McIntyre <ma**********@spamcop.netwrote:
On Mon, 11 Dec 2006 17:28:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
Mark McIntyre a écrit :
"foo" + 31 = "foo31"
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...
Sinclair QL Basic, I think.
Richard
Mark McIntyre wrote:
On Mon, 11 Dec 2006 17:28:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Mark McIntyre a écrit :
>>>"foo" + 31 = "foo31"
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...
It's fairly idiomatic JavaScript.
--
Ian Collins.
On Tue, 12 Dec 2006 20:39:51 +1300, Ian Collins wrote:
>Mark McIntyre wrote:
>On Mon, 11 Dec 2006 17:28:48 +0100, jacob navia wrote:
>>>>"foo" + 31 = "foo31"
Ahhh how CLEVER!!!
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
Roland Pibinger wrote:
On Tue, 12 Dec 2006 20:39:51 +1300, Ian Collins wrote:
Mark McIntyre wrote:
On Mon, 11 Dec 2006 17:28:48 +0100, jacob navia wrote:
"foo" + 31 = "foo31"
Ahhh how CLEVER!!!
It's fairly idiomatic JavaScript.
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.
On Mon, 11 Dec 2006 17:35:55 -0500, in comp.lang.c , Eric Sosman
<es*****@acm-dot-org.invalidwrote:
>Mark McIntyre wrote:
>On Mon, 11 Dec 2006 10:08:13 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:
>>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?
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
On Tue, 12 Dec 2006 20:39:51 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Mark McIntyre wrote:
>On Mon, 11 Dec 2006 17:28:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>Mark McIntyre a écrit :
>>>>"foo" + 31 = "foo31"
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...
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
Mark McIntyre wrote:
On Mon, 11 Dec 2006 17:35:55 -0500, in comp.lang.c , Eric Sosman
<es*****@acm-dot-org.invalidwrote:
>Mark McIntyre wrote:
>>On Mon, 11 Dec 2006 10:08:13 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:
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?
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?
Ah, Grasshopper, you are so quick to take offense. Learn
patience like your cousin the locust, and you, too, may move
to the Wild West and demonstrate inner peace by kicking people's
heads off.
The message that launched all this, um, meditation was
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.
.... in which there is no mention of "Standard C." As a card-
carrying August Master, I naturally made certain allowances for
your preoccupation with matters temporal, and divined that you
believed that adding "string addition" to C would be a "fairly
trivial" extension to the language that the Transcendent Dennis
bestowed upon us. My response was in the nature of a Zen koan --
or maybe a Cen Coan -- intended to bring about that state called
"satori" in which you would suddenly and mystically come to know
that the data type "string" is more wrenching to C than grasshoppers
might suppose.
Of course, it might also bring about the state called "abhorri"
in which you suddenly and mystically bless your Revered Teacher
with the pleasant effluent of an AK-47. In that case, your R.T.
will demonstrate his unparalleled control over and indifference to
matters physical by swatting away the bullets like so many pesky
(but holy and precious in their own way) mosquitoes -- yet on the
whole, the R.T. would prefer not to put the matter to the test.
--
Eric Sosman es*****@acm-dot-org.invalid
Eric Sosman said:
<snip>
Learn patience like your cousin the locust, and you, too, may move
to the Wild West and demonstrate inner peace by kicking people's
heads off.
When you can walk the callstack and leave no backtrace, then you will have
learned.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Tue, 12 Dec 2006 22:09:44 -0500, in comp.lang.c , Eric Sosman
<es*****@acm-dot-org.invalidwrote:
Ah, Grasshopper, you are so quick to take offense.
Actually, I didn't take offense at all.
The message that launched all this, um, meditation was
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.
... in which there is no mention of "Standard C."
Eggs act a mun doe.
>As a card-
carrying August Master, I naturally made certain allowances for
your preoccupation with matters temporal, and divined that you
believed that adding "string addition" to C would be a "fairly
trivial" extension to the language
.... unfortunately your divining rod was in this case, broke... :-)
--
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
On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>--
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
this signature is OT, false and it irritate me: can you please change
it?
av said:
On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>>--
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
this signature is OT,
It's a *sig block*. Since when did sig blocks have to be topical?
false
Really? Looks about right to me. But if you have a problem with it, take it
up with bwk, not Mark.
and it irritate me: can you please change it?
That's a reasonable request (although of course it's one that Mark is under
no obligation to meet). Here's another reasonable request, which you are
under no obligation to meet: can you please use a capital letter at the
beginning of each sentence, and use the appropriate verb ending that
matches the subject?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Wed, 13 Dec 2006 18:11:19 +0100, in comp.lang.c , av <av@ala.a>
wrote:
>On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>>--
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
this signature is OT,
Hardly.
>false
The only person who can say that is bwk.
>and it irritate me: can you please change
it?
--
[It's] a sig block, anyone who takes it seriously is a dork - MMcI,
ucsm
On Fri, 15 Dec 2006 00:05:50 +0000, Mark McIntyre wrote:
>On Wed, 13 Dec 2006 18:11:19 +0100, in comp.lang.c , av <av@ala.a>
wrote:
>>On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>>>--
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
this signature is OT,
Hardly.
it not speak on "C language standard", it is about how difficult
should be to debug, an ot subject
>>false
The only person who can say that is bwk.
who is bwk? is bwk==Brian Kernighan?
the quote above is not valid at last for Who create the Universe
and possibly for many others
>>and it irritate me: can you please change
it?
On Wed, 13 Dec 2006 18:37:42 +0000, Richard Heathfield wrote:
>av said:
>On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>>>--
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
this signature is OT,
It's a *sig block*. Since when did sig blocks have to be topical?
for me no. but seeing all people says we have to be not ot and seeing
that the above quote is false too
>false
Really? Looks about right to me. But if you have a problem with it, take it
up with bwk, not Mark.
bwk?
>and it irritate me: can you please change it?
That's a reasonable request (although of course it's one that Mark is under
no obligation to meet). Here's another reasonable request, which you are
under no obligation to meet: can you please use a capital letter at the
beginning of each sentence, and use the appropriate verb ending that
matches the subject?
he is free to write what he wants but i say i not agree on that,
because my little experience shows that with some run time (for to
make to show these errors) and some debugging, is possible to correct
all showed errors; it is not matter the complexity of under code
the above quote could be right only for code not written by me or in
other not low languages i don't know
or if error doesn't show itself
or if the programmer write in an high language and not know assembly
av wrote:
On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
>>--
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
this signature is OT, false and it irritate me: can you please change
it?
(a) It's a /signature/. It's topicality isn't at issue. Feel free to
complain about my signature(s) if you like.
(b) I certainly find debugging code harder than writing it. So it's
certainly not obviously false.
(c) It's a /signature/, not a peer-reviewed essay. It's pithy and
makes a point.
(d) If it irritates you, ignore it. Or introspect to find out why.
(e) It's a /signature/. It's not insulting, it's not offensive,
and it's relevant to programming and tells us something about
the mindset of one of the people most involved with C. I
think it's rather good, myself.
--
Chris "Perikles triumphant" Dollin
"Our future looks secure, but it's all out of our hands"
- Magenta, /Man and Machine/
av said:
On Wed, 13 Dec 2006 18:37:42 +0000, Richard Heathfield wrote:
>>av said:
>>On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:
--
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
this signature is OT,
It's a *sig block*. Since when did sig blocks have to be topical?
for me no. but seeing all people says we have to be not ot
It's a sig block, for heaven's sake!
and seeing that the above quote is false too
Your claim that it is false is not self-evidently true.
>>false
Really? Looks about right to me. But if you have a problem with it, take
it up with bwk, not Mark.
bwk?
Brian W Kernighan, the author of the quote.
>
>>and it irritate me: can you please change it?
That's a reasonable request (although of course it's one that Mark is
under no obligation to meet). Here's another reasonable request, which you
are under no obligation to meet: can you please use a capital letter at
the beginning of each sentence, and use the appropriate verb ending that
matches the subject?
he is free to write what he wants but i say i not agree on that,
because my little experience shows that with some run time (for to
make to show these errors) and some debugging, is possible to correct
all showed errors; it is not matter the complexity of under code
Yeah, right.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
3 posts
views
Thread by John Dibling |
last post: by
|
5 posts
views
Thread by Andy Skypeck |
last post: by
|
8 posts
views
Thread by Shailesh |
last post: by
|
188 posts
views
Thread by infobahn |
last post: by
|
5 posts
views
Thread by Zach |
last post: by
|
14 posts
views
Thread by Lane Straatman |
last post: by
|
159 posts
views
Thread by Bob Timpkinson |
last post: by
|
3 posts
views
Thread by sophia.agnes |
last post: by
|
55 posts
views
Thread by tonytech08 |
last post: by
| | | | | | | | | | | | | | | | | | | |
