Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #2178 > unrolled thread
| Started by | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| First post | 2014-05-05 08:47 +0100 |
| Last post | 2014-05-05 19:08 -0500 |
| Articles | 4 on this page of 64 — 9 participants |
Back to article view | Back to comp.lang.misc
A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 08:47 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 10:56 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 19:41 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 21:08 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 21:58 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:55 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:01 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:44 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 09:45 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 07:33 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 19:14 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:12 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 11:55 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-07 19:04 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 10:14 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 07:35 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 16:22 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-09 16:45 -0400
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-10 09:04 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-10 16:30 -0400
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-11 11:59 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-11 11:06 -0400
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-12 00:26 +0000
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-12 09:54 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-12 20:01 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 17:45 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 18:11 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 23:54 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 19:43 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:00 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 16:00 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 22:17 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 19:58 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-18 07:59 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 13:10 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-19 00:54 +0100
Re: A good subset of C Andy Walker <news@cuboid.co.uk> - 2014-05-15 01:31 +0100
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-14 23:43 -0500
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:38 +0100
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 11:04 +1200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 20:36 -0400
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 12:53 +1200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 21:34 -0400
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 14:11 +1200
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:47 +0000
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:43 +0000
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:59 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:28 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:26 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-06 14:21 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:43 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-07 16:03 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-07 21:31 +0100
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-07 15:41 -0500
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:46 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:42 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-06 06:48 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:40 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 06:50 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 15:43 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-08 14:41 -0400
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-05 19:08 -0500
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-08 06:50 -0400 |
| Message-ID | <op.xfje2ptm6zenlw@localhost> |
| In reply to | #2210 |
On Wed, 07 May 2014 10:40:13 -0400, James Harris
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xffpmfaf6zenlw@localhost...
>> 1) first example
>>
>> /* The structA structure has been declared as a struct here */
>> /* The structA structure has space allocated for it here */
>> /* The layout of structA is defined here */
>> /* There is no typedef here */
>> struct structA {
>> char c;
>> int d;
>> };
>
> I'm not sure if the comments before the example are meant to
> relate to the example but if they are I don't agree. Are you
> saying that structA has space allocated for it?
Yes. I was. I did. I'm wrong. :-)
Actually, I'm a bit stunned. I was a bit confused when
GCC failed to work on that. I had to consult H&S which
didn't really clarify things.
It seems I've had this incorrect belief for a long time and
my usage of C never revealed my understanding to be un-true.
It seems my understanding of structs was in error, and I've
been conflating or confusing the struct type declaration which
doesn't allocate space by ascribing that to typedefs.
I'm not sure where this wrong belief originated, but I can
presume that since I only learned how type systems work in
the past decade, I misunderstood when first learning C.
But, I would rather blame those on comp.lang.c in 2006
when I attempted to improve my understanding of C from the
self-proclaimed experts there who were primarily incorrect.
I adopted some of the more reasoned and logical ideas they
presented. They really spread some botched up stuff ...
So, since the struct type declarations don't allocate space,
then typedefs don't have an exclusive, er... "specialty
property" of not allocating space. Then, typedefs would
just seem to be aliases for another type, as you've stated.
This may also reveal why they chose to break LALR(1) instead
of using a keyword for types: redundant. Without that "special
property", typedefs are just aliases, and there is no point
in replacing "struct structA" with "typedef mystructA".
I think we should stop here. I'll need some time to correct,
mentally, clarify further, review.
Sorry,
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Date | 2014-05-08 15:43 +0100 |
| Message-ID | <lkg55f$onk$1@dont-email.me> |
| In reply to | #2223 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
news:op.xfje2ptm6zenlw@localhost...
> On Wed, 07 May 2014 10:40:13 -0400, James Harris
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xffpmfaf6zenlw@localhost...
>
>>> 1) first example
>>>
>>> /* The structA structure has been declared as a struct here */
>>> /* The structA structure has space allocated for it here */
>>> /* The layout of structA is defined here */
>>> /* There is no typedef here */
>>> struct structA {
>>> char c;
>>> int d;
>>> };
>>
>> I'm not sure if the comments before the example are meant to
>> relate to the example but if they are I don't agree. Are you
>> saying that structA has space allocated for it?
>
> Yes. I was. I did. I'm wrong. :-)
Well, your reply certainly deserves respect.
> Actually, I'm a bit stunned. I was a bit confused when
> GCC failed to work on that. I had to consult H&S which
> didn't really clarify things.
That's interesting about H&S. I looked up K&R2 and in 6.1 it says the
following.
--- Begin quote ---
A struct declaration defines a type. The right brace that terminates the
list of members may be followed by a list of variables, just as for any
basic type. That is
struct { ... } x, y, z;
is syntactically analogous to
int x, y, z;
in the sense that each statement declares x, y and z to be variables of the
named type and causes space to be set aside for them.
A structure declaration that is not followed by a list of variables reserves
no storage; it merely describes a template of the shape of a structure. If
the declaration is tagged, however, the tag can be used later in definitions
of instances of the structure.
--- End of quote ---
Then later in 6.7 the same book says:
"It must be emphasized that a typedef declaration does not create a new type
in any sense; it merely adds a new name for some existing type."
Interestingly, and this is far beyond what I have ever used a typedef for,
it goes on to say that typedef can be used like a #define macro except that
"it can cope with textual substitutions that are beyond the capabilities of
the preprocessor." It gives the example that
typedef int (*PFI)(char *, char *);
creates the name PFI as a pointer to function (taking two char * arguments)
returning int and it can be used as in
PFI strcmp, numcmp;
That seems clever, terse, and confusing to the uninitiated. I suppose the
way to read it is that strcmp and numcmp could appear where PFI appears in
the declaration that follows the typedef keyword. Oo-er!
James
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2014-05-08 14:41 -0400 |
| Message-ID | <evinm9109pq9ujtd6e9nl0hdvltoes62op@4ax.com> |
| In reply to | #2225 |
On Thu, 8 May 2014 15:43:02 +0100, "James Harris"
<james.harris.1@gmail.com> wrote:
>
> typedef int (*PFI)(char *, char *);
>
>creates the name PFI as a pointer to function (taking two char * arguments)
>returning int ...
The typedef expression creates the name "PFI" as an alias for the
_type_ "pointer to function (taking two char * arguments) returning
int"
Nit picking, but an important distinction: "PFI" is not a pointer, it
is the type of a particular kind of pointer.
>... and it can be used as in
>
> PFI strcmp, numcmp;
>
>That seems clever, terse, and confusing to the uninitiated.
Complicated pointer types in general are confusing to the uninitiated.
But typedef in particular might have been less confusing had its
syntax been something like:
typedef { <type> } <alias>
e.g.,
typedef { int } MYINT
typedef { int (*)(char *, char *) } PFI
>I suppose the way to read it is that strcmp and numcmp could appear where
>PFI appears in the declaration that follows the typedef keyword. Oo-er!
Yes.
>James
George
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2014-05-05 19:08 -0500 |
| Message-ID | <lk9971$fcd$1@news.albasani.net> |
| In reply to | #2178 |
On 5/5/2014 2:47 AM, James Harris wrote: > In two recent threads we discussed good and bad points about C. Some good > things were mentioned but the focus was mainly on the points that we would > like to fix. I got to wondering if there could be considered a "good" subset > of C - i.e. of the whole programming approach including language, > preprocessor, standard library etc. > > The subset should be much easier to compile than full C but it does not need > to do everything that a programming language should; things could be added. > > Put another way, if you were designing a new language based on C what parts > of C would you keep in? > > James > > well, it can be split into two levels: what is needed for the backend; what is needed for the HLL. backend (fundamental): functions, arguments, locals, globals, int (*), pointers, unary and binary operators, conditional jumps (if/goto), call/return, function-pointers *: though long long, float, and double are nice. various sub-int types can be mostly emulated, and unsigned can be handled mostly via a few special-case operations. high-level features are more hit or miss, though many can basically be easily implemented essentially as "sugar" over the prior list. in a recent (starting about a week ago) attempt of mine to revive a C compiler project of mine, I have mostly ended up with a backend that looks like: functions, arguments, locals, globals, temporaries, int/longlong/float/double, pointers, structs/unions, unary and binary operators, conditional jumps (if/goto), call/return, function-pointers generally implemented with a statically-typed register-IR, ex: k=3*i+j; might become: BINOP.MUL.IC R0, L0, 3 BINOP.ADD.I L2, R0, L1 which might in-turn look in bytecode like: 81 02 20 00 03 80 04 02 01 I ended up making 3 disjoint types of register (temporaries, arguments, locals), which while making the bytecode slightly more hairy, I figured that either way the backend will need to deal with these, and the goal was mostly to try to allow a simpler and faster backend at the expense of a more complex bytecode-compiler. another sub-goal being to allow a fairly stupid JIT to produce reasonably efficient machine code. the C variant supported will likely be more-or-less feature-complete. as-above, sub-int types are mostly faked. there are a few instructions to support bitfields, but they will probably also apply to generic shift-and-mask logic as well. not sure what features could really be left out without effecting much. probably: K&R style declarations; enums; bit-fields; ... some features could be potentially changed/omitted with a "modest" impact: no more physical nesting of structures or unions; no more in-place fixed-length arrays (*2); disallowing macros which alter the lexical code structure (could allow pushing macros much later into the compilation process); moving over to C# style declaration parsing (no more context dependence or a need to rely on typedefs for parsing, but would constrain declaration parsing in some cases); ... *2: actually, the current VM will partly do this in the case of local arrays, which will likely be implemented internally essentially as heap-allocated arrays (probably using a pool allocator). or such...
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.misc
csiph-web