Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2178 > unrolled thread

A good subset of C

Back to article view | Back to comp.lang.misc

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#2268

Rod Pemberton wrote:
>
> It hid information no more than C hides information.  I don't exactly
> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
> explicit mechanism where there is none?  So, maybe, I'm not grasping
> where the hiding is occurring? ...

The simple example of C's file I/O is a good example of information 
hiding.  Do you know or even care what a FILE object is?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2269

On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>  
wrote:
> Rod Pemberton wrote:

>> It hid information no more than C hides information.  I don't exactly
>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>> where the hiding is occurring? ...
>
> The simple example of C's file I/O is a good example of information  
> hiding.  Do you know or even care what a FILE object is?
>

Yes and no.

No, I generally don't care.  The 'struct' based FILE works just as well
99.99% of the time.

Yes, I'd rather that it be a 'char' or 'int' like earlier C compilers
and POSIX file I/O, than as a 'struct' of newer C compilers and ANSI C
file I/O functions.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2270

Rod Pemberton wrote:
> On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>
> wrote:
>> Rod Pemberton wrote:
>
>>> It hid information no more than C hides information.  I don't exactly
>>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>>> where the hiding is occurring? ...
>>
>> The simple example of C's file I/O is a good example of information
>> hiding.  Do you know or even care what a FILE object is?
>>
>
> Yes and no.
>
> No, I generally don't care.  The 'struct' based FILE works just as well
> 99.99% of the time.

So you agree that C file I/O uses information hiding and that you grasp 
where the hiding is occurring?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2271

On Sat, 24 May 2014 20:53:33 -0400, Ian Collins <ian-news@hotmail.com>  
wrote:
> Rod Pemberton wrote:
>> On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>
>> wrote:
>>> Rod Pemberton wrote:

>>>> It hid information no more than C hides information.  I don't exactly
>>>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>>>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>>>> where the hiding is occurring? ...
>>>
>>> The simple example of C's file I/O is a good example of information
>>> hiding.  Do you know or even care what a FILE object is?
>>>
>>
>> Yes and no.
>>
>> No, I generally don't care.  The 'struct' based FILE works just as well
>> 99.99% of the time.
>
> So you agree that C file I/O uses information hiding [...]

No, I don't.  Anyone can read what elements are within a struct version of
FILE.  It's declared within stdio.h.  With a FILE pointer, anyone can  
access
those elements too.  They'll be specific to the specific implementation.

> [...] and that you grasp where the hiding is occurring?

Does non-necessity of use constitute hiding?  Nothing is hidden.
It's all accessible and useable, even if it's not that useful.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2272

Rod Pemberton wrote:
> On Sat, 24 May 2014 20:53:33 -0400, Ian Collins <ian-news@hotmail.com>
> wrote:
>> Rod Pemberton wrote:
>>> On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>>>> Rod Pemberton wrote:
>
>>>>> It hid information no more than C hides information.  I don't exactly
>>>>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>>>>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>>>>> where the hiding is occurring? ...
>>>>
>>>> The simple example of C's file I/O is a good example of information
>>>> hiding.  Do you know or even care what a FILE object is?
>>>>
>>>
>>> Yes and no.
>>>
>>> No, I generally don't care.  The 'struct' based FILE works just as well
>>> 99.99% of the time.
>>
>> So you agree that C file I/O uses information hiding [...]
>
> No, I don't.  Anyone can read what elements are within a struct version of
> FILE.  It's declared within stdio.h.  With a FILE pointer, anyone can
> access
> those elements too.  They'll be specific to the specific implementation.

Not necessarily.  The actual definition could be in a private header or 
a source file.

Many C libraries use an opaque pointers.  If you don't have access to 
the library source, you don't know the contents.

>> [...] and that you grasp where the hiding is occurring?
>
> Does non-necessity of use constitute hiding?  Nothing is hidden.
> It's all accessible and useable, even if it's not that useful.

Not if the definition is not in the available source.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2274

On 2014-05-25, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sat, 24 May 2014 20:53:33 -0400, Ian Collins <ian-news@hotmail.com>  
> wrote:
>> Rod Pemberton wrote:
>>> On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>>>> Rod Pemberton wrote:
>
>>>>> It hid information no more than C hides information.  I don't exactly
>>>>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>>>>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>>>>> where the hiding is occurring? ...
>>>>
>>>> The simple example of C's file I/O is a good example of information
>>>> hiding.  Do you know or even care what a FILE object is?
>>>>
>>>
>>> Yes and no.
>>>
>>> No, I generally don't care.  The 'struct' based FILE works just as well
>>> 99.99% of the time.
>>
>> So you agree that C file I/O uses information hiding [...]
>
> No, I don't.  Anyone can read what elements are within a struct version of
> FILE.  It's declared within stdio.h.

But that is not portable to any other stdio.h. So a recompile of your
program on several other implementations will flush out these modularity
violations.

> With a FILE pointer, anyone can  
> access
> those elements too.  They'll be specific to the specific implementation.
>
>> [...] and that you grasp where the hiding is occurring?
>
> Does non-necessity of use constitute hiding?  Nothing is hidden.

Yes. Information hiding is the situation in the overall program whereby
nothing peeks directly at data managed by an abstract module, even though
there are ways to do that.

[toc] | [prev] | [next] | [standalone]

#2273

On 2014-05-25, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sat, 24 May 2014 19:04:54 -0400, Ian Collins <ian-news@hotmail.com>  
> wrote:
>> Rod Pemberton wrote:
>
>>> It hid information no more than C hides information.  I don't exactly
>>> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
>>> explicit mechanism where there is none?  So, maybe, I'm not grasping
>>> where the hiding is occurring? ...
>>
>> The simple example of C's file I/O is a good example of information  
>> hiding.  Do you know or even care what a FILE object is?
>>
>
> Yes and no.
>
> No, I generally don't care.  The 'struct' based FILE works just as well
> 99.99% of the time.
>
> Yes, I'd rather that it be a 'char' or 'int' like earlier C compilers
> and POSIX file I/O, than as a 'struct' of newer C compilers and ANSI C
> file I/O functions.

Version 6 Unix had:

  #define FILE struct __iobuf

or something very similar.

That counts as "very earlier C compilers". :)

[toc] | [prev] | [next] | [standalone]

#2189

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:lk7flm$m95$1@dont-email.me...
> 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?

Here's an attempt at this.

* Separate compilation
* Pointers (this and the next two are good specifically in the context of C)
* Array and pointer similarities
* Zero-terminated strings, char data type
* Simple memory model
* Signed and unsigned integers (some languages only permit signed)
* Being able to choose integers of explicit sizes, e.g. uint16_t
* Enumerated integers
* Structs
* Loops (for, do)
* Sequential selection (if, else)
* Top selection (switch, case, default) but not automatic fall through
* Support for variadic functions
* Choice of where to place variables: stack, block, module
* Escape codes: \n, \t etc and \"
* Hex number entry such as 0x101
* ++ and -- operators

Any thoughts on how complete that list is?

Notably, even if all the things we have discussed are combined the result is 
not a big feature list. I don't know about you but I think of C as a 
difficult language to compile and wouldn't want to have to write a full C 
preprocessor and compiler. But a subset might be more manageable and also 
form a base for extension.

By the way, I noticed that in a list of essential parts of C no one 
mentioned bit fields. :-)

James

[toc] | [prev] | [next] | [standalone]

#2193

"James Harris" <james.harris.1@gmail.com> wrote in message
news:lk8qjv$ejd$1@dont-email.me...
> "James Harris" <james.harris.1@gmail.com> wrote in message
> news:lk7flm$m95$1@dont-email.me...

>> Put another way, if you were designing a new language based on C what
>> parts of C would you keep in?
>
> Here's an attempt at this.
>
> * Separate compilation

OK, I don't think C has a monopoly on that.

> * Pointers (this and the next two are good specifically in the context of
> C)
> * Array and pointer similarities

This I believe is a bad feature. Usually you want to know whether that int*
p parameter points to a single object, or to an array of such objects.
Because in the former case, ++p or p[i] might be inadvisable.

However if you separate the two, then you have to think about how to
represent strings which currently use char*.

> * Zero-terminated strings, char data type

I don't think a char type (distinct from integer) is that essential. A byte
type will do the job.

> * Simple memory model
> * Signed and unsigned integers (some languages only permit signed)
> * Being able to choose integers of explicit sizes, e.g. uint16_t
> * Enumerated integers
> * Structs

As used in C, structs presents some tricky problems for compilation:

(1) The idea of struct tags with their separate namespaces (and having both
struct A and typedef B (or even struct A and typedef A) represent the same
struct))

(2) C allows in-place declarations of structs, wherever a variable is
defined for example, so: int fn(struct{int a,b;} x). (I require them to be
defined separately from their use and always named as a typedef.)

(3) This extends to nested structs (and unions, which are treated the same
way). (I don't allow nested structs to be declared in-place; they must be
predefined as a typedef first. However I allow 'struct'/'union' keywords
inside a struct definition, only for the purposes of grouping members.)

> * Loops (for, do)
> * Sequential selection (if, else)
> * Top selection (switch, case, default) but not automatic fall through
> * Support for variadic functions

I've never used this feature. It might only be there to be able to implement
functions such as printf. If you have an alternative to printf (even keeping
it, but making it built-in syntax not implemented as an user-function), then
variadic might not be needed.

> * Choice of where to place variables: stack, block, module
> * Escape codes: \n, \t etc and \"

I've started avoiding "\n" recently, as I could never be exactly sure what
it would do. (Instead I tend to use \c for CR, \l for LF, and \w for an
explicit CRLF which, when sent to a file, is generally done in binary mode.
The text mode of C is something I should have put on my big list.)

> * Hex number entry such as 0x101
> * ++ and -- operators

> By the way, I noticed that in a list of essential parts of C no one
> mentioned bit fields. :-)

Does anyone use them much?

I'm not too impressed with them (and they are tricky to compile for).
Isolated bitfields, inside a struct, also don't offer much space saving (as
would, say, an array of them). I'd imagine they were designed for fields
which represented the bit-groupings of some hardware device or other, except
there doesn't seem to be any control over exactly where a compiler would
place them.

But an ordinary byte or word field, and perhaps some slightly more advanced
bitfield operations, could do the same job, with a lot more control.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2198

On Mon, 05 May 2014 17:28:51 -0400, BartC <bc@freeuk.com> wrote:
> "James Harris" <james.harris.1@gmail.com> wrote in message
> news:lk8qjv$ejd$1@dont-email.me...

>> [snip]
>
> As used in C, structs presents some tricky problems for compilation:
>
> (1) The idea of struct tags with their separate namespaces (and having  
> both struct A and typedef B (or even struct A and typedef A) represent
> the same struct))

No.  The struct represents the struct: name, addressing, space for data.
The typedef represents a typedef: name, addressing.  It doesn't allocate
any space.  I.e., it's not an object and therefore not a struct.  That
space must be allocated by some other method, e.g., malloc, alloca,
declaration of an "array" of chars or longs, etc.

> (2) C allows in-place declarations of structs, wherever a variable is
> defined for example, so: int fn(struct{int a,b;} x). (I require them to
> be defined separately from their use and always named as a typedef.)

Do you mean C++? C99? ANSI C or C89/C90 doesn't allow that.

>> * Choice of where to place variables: stack, block, module
>> * Escape codes: \n, \t etc and \"
>
> I've started avoiding "\n" recently, as I could never be exactly sure
> what it would do. (Instead I tend to use \c for CR, \l for LF, and \w
> for an explicit CRLF which, when sent to a file, is generally done in
> binary mode.  The text mode of C is something I should have put on my
> big list.)
>

For the most part, you can use binary mode only.  Rarely, text mode is
useful because it outputs the correct end-of-line for the host, but most
systems only use one char for the end-of-line, exceptions being MS-DOS,
DEC VAX, etc.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2201

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xfesqnyp6zenlw@localhost...
> On Mon, 05 May 2014 17:28:51 -0400, BartC <bc@freeuk.com> wrote:


>> (2) C allows in-place declarations of structs, wherever a variable is
>> defined for example, so: int fn(struct{int a,b;} x). (I require them to
>> be defined separately from their use and always named as a typedef.)
>
> Do you mean C++? C99? ANSI C or C89/C90 doesn't allow that.

My mistake. You can do this:

struct {
 int a,b;
 struct {
  int c,d;
  struct {
   int e,f;
  };
 };
} x;

But x can't be a parameter name (I think because you can't create a 
compatible struct from outside the function to use as an argument).

Although even the use as I've given it is more trouble than if each nested 
struct is properly defined in advance.

(The parameter problem shows the advantage of defining such a struct 
separately.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2208

On Mon, 5 May 2014 22:28:51 +0100, "BartC" <bc@freeuk.com> wrote:

>"James Harris" <james.harris.1@gmail.com> wrote in message
>news:lk8qjv$ejd$1@dont-email.me...
>> "James Harris" <james.harris.1@gmail.com> wrote in message
>> news:lk7flm$m95$1@dont-email.me...
>
>> * Separate compilation
>
>OK, I don't think C has a monopoly on that.

Technically C has "independent" compilation rather than "separate",
the difference being that interfaces between modules are not verified
by the compiler [or linker].

In C the programmer has to code module interfaces explicitly - e.g.,
in a header file - and the compiler simply trusts that the provided
information is correct.

In languages having separate compilation, compiling a module produces
matching interface information which then can be imported directly by
another module.  The programmer does not code the interface separately
so the opportunity for error is reduced.

Separate compilation alone doesn't entirely prevent mismatched
modules. E.g., in Modula2 and Ada the interface definition exists
separately from the object module, so you can make the mistake of
importing the wrong version of definitions.  However the linker will
catch this and won't allow you to produce an executable having
mismatched modules, so at least when static linking you still have
some protection.  [All bets are off with dynamic linking.]

Java, C# and others further reduce possibility for error by embedding
the interface information directly into the object module, so import
directly references the intended module and it isn't as easy to
mistakenly import the wrong version.

George

[toc] | [prev] | [next] | [standalone]

#2211

"George Neuner" <gneuner2@comcast.net> wrote in message 
news:bb6im95s5u3gfvrvi6193r98g0e0835lsg@4ax.com...

...

> Separate compilation alone doesn't entirely prevent mismatched
> modules. E.g., in Modula2 and Ada the interface definition exists
> separately from the object module, so you can make the mistake of
> importing the wrong version of definitions.  However the linker will
> catch this and won't allow you to produce an executable having
> mismatched modules, so at least when static linking you still have
> some protection.  [All bets are off with dynamic linking.]

How will the linker know that the object modules are incompatible? Name 
mangling?

> Java, C# and others further reduce possibility for error by embedding
> the interface information directly into the object module, so import
> directly references the intended module and it isn't as easy to
> mistakenly import the wrong version.

Is any special object format needed to support this?

James

[toc] | [prev] | [next] | [standalone]

#2214

On Wed, 7 May 2014 15:43:58 +0100, "James Harris"
<james.harris.1@gmail.com> wrote:

>"George Neuner" <gneuner2@comcast.net> wrote in message 
>news:bb6im95s5u3gfvrvi6193r98g0e0835lsg@4ax.com...
>
>...
>
>> Separate compilation alone doesn't entirely prevent mismatched
>> modules. E.g., in Modula2 and Ada the interface definition exists
>> separately from the object module, so you can make the mistake of
>> importing the wrong version of definitions.  However the linker will
>> catch this and won't allow you to produce an executable having
>> mismatched modules, so at least when static linking you still have
>> some protection.  [All bets are off with dynamic linking.]
>
>How will the linker know that the object modules are incompatible? Name 
>mangling?

That's one way.  However, some of the languages that do this predate
widespread use of name mangling and used various version stamping
techniques instead.

The idea is that the exported interface of the module be versioned
separately from the code that implements it.  How that is accomplished
isn't really important so long as different interfaces can be
distinguished and the interface implemented by a particular object
file can be identified.

E.g., in Modula2 each module has 2 source files: a definition file
(the interface) and an implementation file (the code).  These are
compiled and versioned separately, producing an interface digest (like
a precompiled header) and an object file. The object file contains
version stamps both for the interface and the code along with a
dependency list detailing its imported interfaces and their desired
versions.  The linker checked import lists against supplied object
files and signaled mismatches.  As long as the interface remains the
same, an importing module can be linked to any build version of the
implementing object file.

Ada behaves similarly although it has different terminology for the
files involved.

Oberon did away with separate source definition files - instead the
programmer used a markup scheme in the source to explicitly indicate
what functions or objects should be exported and how they may be
accessed.  Compiling the source file produced both an interface digest
and an object file.  The interface digest then was referenced by the
compiler when the interface was imported into another module.



>> Java, C# and others further reduce possibility for error by embedding
>> the interface information directly into the object module, so import
>> directly references the intended module and it isn't as easy to
>> mistakenly import the wrong version.
>
>Is any special object format needed to support this?

Java and C# each have a defined "class file" format which contains
reflection information about the code.  The compiler extracts the
exported interface from the embedded reflection data.

This is different from interface definitions as described above:
definitions detail *only* the exported interface of the module whereas
reflection is more like debug data in that it describes both the
interface of the class and the internal structure of its objects (if
any).

C# uses standard object file formats - COFF or ELF depending on the
version - and places reflection information in an additional data
segment.  C# executables are normal Windows PE load files or DLLs.

I don't know Java's format offhand, but Java applications normally are
delivered unlinked as a bunch of class (object) files packaged in a
ZIP file wrapper rather than as an executable ... so my suspicion is
that they are not a standard object file format.


>James
George

[toc] | [prev] | [next] | [standalone]

#2215

"George Neuner" <gneuner2@comcast.net> wrote in message
news:nlrkm9thg33of04a9h1jrkl3apc8nih6pp@4ax.com...
> On Wed, 7 May 2014 15:43:58 +0100, "James Harris"
> <james.harris.1@gmail.com> wrote:

>>How will the linker know that the object modules are incompatible? Name
>>mangling?
>
> That's one way.  However, some of the languages that do this predate
> widespread use of name mangling and used various version stamping
> techniques instead.
>
> The idea is that the exported interface of the module be versioned
> separately from the code that implements it.  How that is accomplished
> isn't really important so long as different interfaces can be
> distinguished and the interface implemented by a particular object
> file can be identified.

Seems simple enough to have a function 'checkversion(version_no)' as part
the interface. The 'version-no' is part of the interface, and that can be
checked with the internal version number. Although, the caller has to
explicitly do the check (unless there is a way of automatically invoking
some start-up code in the library).

> Oberon did away with separate source definition files - instead the
> programmer used a markup scheme in the source to explicitly indicate
> what functions or objects should be exported and how they may be
> accessed.  Compiling the source file produced both an interface digest
> and an object file.  The interface digest then was referenced by the
> compiler when the interface was imported into another module.

That's pretty much what I do now. Although it runs into problems when there
are mutual or circular references between modules. But with a library that 
is distinct from an application, that wouldn't be a problem.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2216

On 5/7/2014 9:43 AM, James Harris wrote:
> "George Neuner" <gneuner2@comcast.net> wrote in message
> news:bb6im95s5u3gfvrvi6193r98g0e0835lsg@4ax.com...
>
> ...
>
>> Separate compilation alone doesn't entirely prevent mismatched
>> modules. E.g., in Modula2 and Ada the interface definition exists
>> separately from the object module, so you can make the mistake of
>> importing the wrong version of definitions.  However the linker will
>> catch this and won't allow you to produce an executable having
>> mismatched modules, so at least when static linking you still have
>> some protection.  [All bets are off with dynamic linking.]
>
> How will the linker know that the object modules are incompatible? Name
> mangling?
>

>> Java, C# and others further reduce possibility for error by embedding
>> the interface information directly into the object module, so import
>> directly references the intended module and it isn't as easy to
>> mistakenly import the wrong version.
>
> Is any special object format needed to support this?
>

Java uses '.class'-files, which basically embed a lot of metadata 
(type-signatures, ... so, it is basically like you have function 
prototypes albeit without the variable names). likewise, the format 
contains the names and types of things like class fields, ... (the 
type-signatures are essentially ASCII strings describing the data with a 
special notation).

they are basically a somewhat different format from native object files.


.NET uses somewhat tweaked COFF objects, and the linker produces a 
special sub-image within the PE/COFF image, with this sub-image holding 
all the .NET bytecode and metadata (laid out as a big collection of 
tables with references into other tables), with the main PE/COFF image 
treated more as a stub (sort of like what NE and PE did to the DOS MZ 
EXE format), though it may be used for any code/data shared with 
native-land (it is possible to create DLLs or similar with both native 
code and MSIL/CIL).

like with Java, type-signatures are present for declarations (albeit a 
binary format is used rather than ASCII).



some of my current VM projects basically use TLV formats, which can 
structurally be loosely compared with AVI files (albeit using a 
different TLV packaging scheme, sort of like an IFF/ASN.1 hybrid).

generally, an ASCII notation vaguely similar to the JVM notation is 
used, but is basically mixed with notation derived from C++ 
name-mangling (namely the IA64 / GCC 3.x+ mangling scheme).


some of my stuff also uses COM+ like object-representations as well, 
which have a few times (for performance reasons) been considered as the 
primary/canonical VM object representation for a few considered VMs (to 
reduce overhead from calls via C APIs from native code, and try to get a 
little closer to native C-like speeds).

structurally, they can be compared with C++ classes, except more 
constrained in terms of representation and semantics. namely: single 
inheritance + interfaces, with interface vtable pointers glued on the 
end of the object's data area (casting a class to an interface returning 
a pointer to one of these pointers).


or such...

[toc] | [prev] | [next] | [standalone]

#2196

On Mon, 05 May 2014 15:59:26 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> Here's an attempt at this.
>
> * Separate compilation

?

If it can compile one file, then it can compile many ... (?)
I'd think this is, perhaps, a linking issue?

> * Pointers (this and the next two are good specifically
> in the context of C)

Yes.

> * Array and pointer similarities

Yes.

> * Zero-terminated strings, char data type

Oops, did I forget to mention nul-terminated strings?

> * Simple memory model

Allocated memory blocks, e.g., malloc, declarations of objects, etc
must be contiguous, i.e., not split.  C can't handle a disjointed
memory, i.e., implies paging might be useful to reorganize memory.

> * Signed and unsigned integers (some languages only permit signed)

(I'd disagree on the signed.)

> * Being able to choose integers of explicit sizes, e.g. uint16_t

You only need two. (8-bits char, something bigger)

> * Enumerated integers

Why?  Enums are one of the least used aspects of C, IMO.

> * Structs

Yes.

No typedefs?  They don't allocate space.  I.e., good for overlaying
data structures onto "arrays" of char, e.g., databases, records,
filesystems, struct nodes in a linked list, etc.

> * Loops (for, do)

Yes.

> * Sequential selection (if, else)

Yes.

> * Top selection (switch, case, default) but not automatic fall through

Ok.

> * Support for variadic functions

Why?  Support a maximum of six parameters to start.  If you're using
more than three per function, you're doing something wrong anyway, IMO.

> * Choice of where to place variables: stack, block, module

Why?

(That kind of defeats the purpose of C.  Use Forth for that.)

> * Escape codes: \n, \t etc and \"

Ok.

> * Hex number entry such as 0x101

Ok.

> * ++ and -- operators

What? No other operators? No assignment?

What about logical and bitwise operations?  && !!  ~ | & ^

> Any thoughts on how complete that list is?

See above for my perspective, otherwise, it's decent.

> I don't know about you but I think of C as a difficult language
> to compile and wouldn't want to have to write a full C
> preprocessor and compiler.

...

> By the way, I noticed that in a list of essential parts of C no
> one mentioned bit fields. :-)

Well, years ago, they warned that using bit-fields on some C compilers
were broken, or perhaps they had endian issues or somesuch.  So, the
"C way" became #define masks and logical-and, e.g.,

#define FLAG1 0x01
#define FLAG2 0x02
#define FLAG3 0x04
#define FLAG4 0x08

if(value&FLAG4) {
...

If bit-fields worked, that would be the perfect place to use them.

You do recognize C code like that, yes?  I sure hope so...  :-)

You might check a C style guide or perhaps Steve Summit's FAQ to
find an answer as to why bit fields are avoided in C.  I'm sure
it's out there somewhere, and it's probably what I stated above,
but I'm not looking for it today.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2202

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xfer8g1j6zenlw@localhost...
> On Mon, 05 May 2014 15:59:26 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> Here's an attempt at this.
>>
>> * Separate compilation
>
> ?
>
> If it can compile one file, then it can compile many ... (?)
> I'd think this is, perhaps, a linking issue?

C supports separate compilation by, in part, using header files to convey 
information between modules. For example,

  #include "mod.h"
  mod_func(MOD_OPER);

Here MOD_OPER is a constant defined in mod.h. Without the header the 
compiler would not know what value to substitute for MOD_OPER. Neither would 
it know the types of arguments to mod_func().

There are more-complex examples but that hopefully illustrates the kind of 
thing I mean when I say that C supports separate compilation.

...

>> * Being able to choose integers of explicit sizes, e.g. uint16_t
>
> You only need two. (8-bits char, something bigger)

Not so. Say you were writing an x86 OS - something you are familiar with. 
You would have 8-bit (many), 16-bit (e.g. port numbers), 32-bit (many) and 
64-bit (e.g. TSC, MSRs) values to deal with.

>> * Enumerated integers
>
> Why?  Enums are one of the least used aspects of C, IMO.

IYO or IYE? :-) They can be used instead of many #defines and automatically 
allocate numbers. They would also be easy to compile so ISTM they would be 
good to include.

>> * Structs
>
> Yes.
>
> No typedefs?  They don't allocate space.  I.e., good for overlaying
> data structures onto "arrays" of char, e.g., databases, records,
> filesystems, struct nodes in a linked list, etc.

Don't forget a typedef is just an alias for something that already exists.

Consider

  struct Tag { ... };

No typedef but, here, the struct needs no space allocation. It is just a 
definition and Tag is just a name.

...

>> * Support for variadic functions
>
> Why?  Support a maximum of six parameters to start.  If you're using
> more than three per function, you're doing something wrong anyway, IMO.

It is true that variadic support isn't often needed but when it is it can be 
invaluable.

>> * Choice of where to place variables: stack, block, module
>
> Why?
>
> (That kind of defeats the purpose of C.  Use Forth for that.)

Consider

  int a;
  void fn() {
    int b;
    static int c;
    for (int d;;) {
    }
    for (int e;;) {
    }
  }

Here the intention is that A has module scope and storage, B has stack 
storage, C has module storage but function scope, and D has block scope and 
probably some form of stack storage but would not have to compete with E. D 
and E could occupy the same stack space.

...

>> * ++ and -- operators
>
> What? No other operators? No assignment?
>
> What about logical and bitwise operations?  && !!  ~ | & ^

Sure, I just listed things which I thought were especially characteristic of 
C.

...

>> By the way, I noticed that in a list of essential parts of C no
>> one mentioned bit fields. :-)
>
> Well, years ago, they warned that using bit-fields on some C compilers
> were broken, or perhaps they had endian issues or somesuch.  So, the
> "C way" became #define masks and logical-and, e.g.,
>
> #define FLAG1 0x01
> #define FLAG2 0x02
> #define FLAG3 0x04
> #define FLAG4 0x08
>
> if(value&FLAG4) {
> ...
>
> If bit-fields worked, that would be the perfect place to use them.
>
> You do recognize C code like that, yes?  I sure hope so...  :-)

Yes, I once wrote up a note on this. See

  http://codewiki.wikispaces.com/bitfield_operations.c

C's bit fields are notorious for being limited - which is why I put the 
smiley!

James

[toc] | [prev] | [next] | [standalone]

#2207

On Mon, 05 May 2014 19:42:51 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xfer8g1j6zenlw@localhost...
>> On Mon, 05 May 2014 15:59:26 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:

>>> * Structs
>>
>> Yes.
>>
>> No typedefs?  They don't allocate space.  I.e., good for overlaying
>> data structures onto "arrays" of char, e.g., databases, records,
>> filesystems, struct nodes in a linked list, etc.
>
> Don't forget a typedef is just an alias for something that already  
> exists.
>

No, it's not for something that already exists.  Something must be declared
for it to "exist" as an object in C.  A typedef provides a reference to a
object type, which may be allocated or unallocated.  It acts as a language
element, a new type, an extension of C.  The typedef itself never exists as
an object.  I.e., it has no storage for data.   When used by itself, it
provides naming and addressing.  When used in a declaration, it will  
provide
naming, addressing, and allocation for the object defined in the  
declaration
according to the object used to define the typedef.


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;
};

/* Now structures structB and structC have been declared */
/* Both structB and structC have structA's layout */
/* Both structB and structC have space allocated for them */
   struct structA structB, structC;

/* This is a pointer to a struct of structA's layout */
/* The pointer hasn't been set to point to anything */
/* A struct has been allocated above to which it can be set */
   struct structA *tptr1;

2) second example

/* No structure has been declared here */
/* No structure has space allocated for it here */
/* The typedef represents the struct layout */
/* No space is allocated for the typedef */
/* tdef is the name of the typedef */
typedef struct {
   char c;
   int d;
} tdef;

/* Now structures struct1 and struct2 have been declared by typedef */
/* Both struct1 and struct2 have space allocated for them */
/* Both struct1 and struct2 have the struct layout of the typedef'd  
struct: tdef */
   tdef struct1, struct2;

/* This is a pointer to a struct of the typedef'd struct's layout */
/* The pointer hasn't been set to point to anything */
/* No struct has been allocated for which the pointer can point to */
/* The space for the pointer to point to is allocated via some other  
method */
   tdef *tptr2;


3) third example - you can combine them ...

/* structA has space allocated.  tdef1 and tdef2 do not. */
/* one struct can be defined, but multiple typedefs ... */
typedef struct structA {
   char c;
   int d;
} tdef1, tdef2;

   struct structA structB, structC; /* space is allocated for structs */
   struct structA *tptr1; /* pointer to struct with structA's layout */
   tdef1 struct1, struct2; /* space is allocated for structs*/
   tdef2 *tptr2; /* pointer to struct with structA's layout */

Isn't that lovely?  :-)

In the third example, you could say that tdef1 and tdef2 represent
the syntax 'struct structA', but you can't say that about the second
example since the struct is unnamed and C doesn't support unnamed
objects (or didn't, C99 might ...).

> Consider
>
>   struct Tag { ... };
>
> No typedef but, here, the struct needs no space allocation.
> It is just a definition and Tag is just a name.
>

Does the '...' represent C's ellipsis or stuff you didn't want
to type out?

Was this a struct prototype or an incomplete struct definition?

Once an incomplete struct definition is completed, or a full
structure is defined.  Space is allocated for that struct.

>>> * Choice of where to place variables: stack, block, module
>>
>> Why?
>>
>> (That kind of defeats the purpose of C.  Use Forth for that.)
>
> Consider
>
>   int a;
>   void fn() {
>     int b;
>     static int c;
>     for (int d;;) {
>     }
>     for (int e;;) {
>     }
>   }
>
> Here the intention is that A has module scope and storage, B has stack
> storage, C has module storage but function scope, and D has block scope  
> and
> probably some form of stack storage but would not have to compete with  
> E. D
> and E could occupy the same stack space.

Yes, but except for "A [with] module scope", nowhere do I, nor you,
need to know that.  It's convenient to know that "B has stack storage"
(typically).  In all cases, the compiler can relocate the storage from
memory, to register, to stack, vice-versa, either-or, whatever, and back,
space permitting, i.e., no structs will fit in a register.

I.e., while these have a typical way they're implemented in C, the
compiler can optimize or change that as needed.  Not dealing with this
issue directly allows the compiler to do the "best thing".  Specifically,
the fact C can generate code for a variable no matter where it's stored
or moved is one of the better ideas behind C, IMO.

Compare with Forth, where you can't do anything (almost nothing) to
their variables.  Forth doesn't have any (only one) defined operation
which works on variables.  They could easily, but don't.  To do things
the "Forth way", you must move them to the stack, manipulate the value
on the stack, perhaps with other values on the stack at the same time,
juggle them a bit, then store the decide result back into the variable.
All of that is done manually, by the programmer...


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2210

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xffpmfaf6zenlw@localhost...
> On Mon, 05 May 2014 19:42:51 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xfer8g1j6zenlw@localhost...
>>> On Mon, 05 May 2014 15:59:26 -0400, James Harris
>>> <james.harris.1@gmail.com> wrote:
>
>>>> * Structs
>>>
>>> Yes.
>>>
>>> No typedefs?  They don't allocate space.  I.e., good for overlaying
>>> data structures onto "arrays" of char, e.g., databases, records,
>>> filesystems, struct nodes in a linked list, etc.
>>
>> Don't forget a typedef is just an alias for something that already 
>> exists.
>>
>
> No, it's not for something that already exists.  Something must be 
> declared
> for it to "exist" as an object in C.

I don't mean exist as an object but as a type. The format of a typedef is 
often

  typedef <existing type> <new name>;

That defines a new name for an existing type. Some examples,

  typedef int MyInt;
  typedef unsigned char *MyCharPtr;
  typedef struct S MyStruct;

In each case the <new name> piece on the right is just made an alias of what 
precedes it. I was saying that the typedef itself doesn't introduce a type 
but only gives a name to a type such as struct S. So struct S is a type and 
MyStruct is made an alias of it.

AIUI neither MyStruct nor struct S would take up any space in the 
executable. They are just info to the compiler.

>  A typedef provides a reference to a
> object type, which may be allocated or unallocated.  It acts as a language
> element, a new type, an extension of C.  The typedef itself never exists 
> as
> an object.  I.e., it has no storage for data.   When used by itself, it
> provides naming and addressing.  When used in a declaration, it will 
> provide
> naming, addressing, and allocation for the object defined in the 
> declaration
> according to the object used to define the typedef.

Yes. The same sorts of point could be made for struct S, above.

> 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?

> /* Now structures structB and structC have been declared */
> /* Both structB and structC have structA's layout */
> /* Both structB and structC have space allocated for them */
>   struct structA structB, structC;

If the comments relate to the code that succeeds them I agree with them. IMO 
structA would occupy no space but structB and structC would. Isn't structA 
just a template?

> /* This is a pointer to a struct of structA's layout */
> /* The pointer hasn't been set to point to anything */
> /* A struct has been allocated above to which it can be set */
>   struct structA *tptr1;

Yes, all agreed with.

> 2) second example
>
> /* No structure has been declared here */
> /* No structure has space allocated for it here */
> /* The typedef represents the struct layout */
> /* No space is allocated for the typedef */
> /* tdef is the name of the typedef */
> typedef struct {
>   char c;
>   int d;
> } tdef;

OK.

> /* Now structures struct1 and struct2 have been declared by typedef */
> /* Both struct1 and struct2 have space allocated for them */
> /* Both struct1 and struct2 have the struct layout of the typedef'd 
> struct: tdef */
>   tdef struct1, struct2;

Yes.

> /* This is a pointer to a struct of the typedef'd struct's layout */
> /* The pointer hasn't been set to point to anything */
> /* No struct has been allocated for which the pointer can point to */
> /* The space for the pointer to point to is allocated via some other 
> method */
>   tdef *tptr2;

OK.

> 3) third example - you can combine them ...
>
> /* structA has space allocated.  tdef1 and tdef2 do not. */
> /* one struct can be defined, but multiple typedefs ... */
> typedef struct structA {
>   char c;
>   int d;
> } tdef1, tdef2;
>
>   struct structA structB, structC; /* space is allocated for structs */

How many structs do you believe get space allocated by that line?

>   struct structA *tptr1; /* pointer to struct with structA's layout */

Yes.

>   tdef1 struct1, struct2; /* space is allocated for structs*/

Yes.

>   tdef2 *tptr2; /* pointer to struct with structA's layout */

Yes, also.

> Isn't that lovely?  :-)
>
> In the third example, you could say that tdef1 and tdef2 represent
> the syntax 'struct structA', but you can't say that about the second
> example since the struct is unnamed and C doesn't support unnamed
> objects (or didn't, C99 might ...).
>
>> Consider
>>
>>   struct Tag { ... };
>>
>> No typedef but, here, the struct needs no space allocation.
>> It is just a definition and Tag is just a name.
>>
>
> Does the '...' represent C's ellipsis or stuff you didn't want
> to type out?

It was meant to take the place of the details of the struct definition as 
those details are irrelevant to the point being made.

> Was this a struct prototype or an incomplete struct definition?
>
> Once an incomplete struct definition is completed, or a full
> structure is defined.  Space is allocated for that struct.

Sorry, I don't understand what those two paragraphs mean.

James

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.misc

csiph-web