Re: Infinite Loops and Explicit Exits

From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 12/01/04 

Date: 1 Dec 2004 16:33:51 GMT

In article <e8leq0hljooe9c9ubsl2pokkf6u4u5nqi9@4ax.com>, Robert Wagner <spamblocker-robert@wagner.net> writes:
> On 25 Nov 2004 23:58:18 -0800, riplin@Azonic.co.nz (Richard) wrote:
> >Robert Wagner <spamblocker-robert@wagner.net> wrote
> >
> >> >If you want to you can in C:
> >> >
> >> > struct {
> >> > struct { char GivenName[20];
> >> > char SurName[20];
> >> > } RealName;
> >> > struct { int year, month, da;
> >> > } DateofBirth;
> >> > int Age;
> >> > } person;
> >> >
> >> >but why would you - unless you were a Cobol programmer.

If the inner structs aren't used outside the enclosing one, there's
no need to define them separately. It may still be best to define
them as structs, however, so that the fields defined using them can
be assigned with structure copy. Using your definition:

   struct person {...} personA, personB;
   ...
   personA.RealName = personB.RealName;

In this circumstance anonymous inner structures are a perfectly
reasonable C idiom.

> >> Because the input file is in that format.
> >
> >You missed the point. You wanted to contruct the whole record in one
> >piece with having to define the inner bits first. Here I just did
> >that. It can be done, but C programmers know not to do it that way.

It may be an uncommon C idiom, but there are certainly C programmers
who know when it might best be done that way.

> You're correct when you say they don't. I've never seen C written that
> way.

Your experience, as usual, is not definitive.

> My point is they should write it that way, because it follows the
> structure of the record layout in the spec.

So would defining the inner structs separately.

> If it were an output file,
> they could send the above code to the recipient, who would understand
> it.

The same would be true were the inner structs defined separately.

> How does a C programmer store a string, such as Name, in a file? His
> null-terminated memory format is unsuited to storage in a file.

Unsuited why?

> He must pad it to fixed length a'la Cobol or change the file format to
> CSV.

Ridiculous. There are as many other options as the combinatorics
of the storage space allow.

> In either case, the field in the record is not a native C type.

So what? Most fields in the record aren't native C types. That's
the whole point of an extensible type system.

> What kind of programming language doesn't natively support
> fixed-length fields in a file? A badly designed one.

Perhaps, but that criterion is not true of C. C directly supports
fixed-length fields in a file through fread (for field-at-a-time)
or fscanf (for record-at-a-time). Some people may not be capable of
constructing proper fscanf format strings, but the language certainly
supports them.

> >The only difference is that you don't like it. I don't see the dotted
> >notation as an imposition. Nor, it seems, do C like or OO
> >programmers.
>
> The imposition is not dot notation, it is the requirement for
> superfluous qualification. Some defend that, then in the next breath
> call Cobol 'too verbose'.

"Some" who?

> I'm pointing out there's a contradiction between the two.

Hardly. COBOL can still be "too verbose" by some measure even if
it offers one particular syntactic shortcut (or indeed any number
of them). Another language can in general be terse even if it
requires verbosity in one particular aspect.

> They're not content with avoiding Cobol, they throw rocks at it with
> terms like verbose and dinosaur. When I point out deficiencies in
> their language, they brush them aside, saying 'What do you expect from
> a Cobol programmer?'
>
> Then they design yet another language, hoping no one will notice they
> did it to escape flaws in the old one.
>
> [more ravings]
>
> If I said the sky was blue, people would argue that it's black half of
> the time. Real programmers are irritated by my defense of Cobol;
> mainframers are afraid they'll be exposed.

We can't fault you for a deficiency of paranoia, anyway. I
especially like the bit about the personal vendetta being carried out
against you by language designers - those poor deluded, incompetent
souls trying to hide the deficiencies of their work from the actinic
light of your wisdom. Scurry, little language designers, like the
cockroach, back into your filthy dens, or embrace the purity of COBOL
and implicit qualification and be redeemed!

Certainly there are things wrong with C; certainly there are things
wrong with every programming language. This, however, is not the
result of either foolishness on the part of language designers, or a
pervasive hatred of COBOL. 

-- 
Michael Wojcik                  michael.wojcik@microfocus.com
Even though there may be some misguided critics of what we're trying
to do, I think we're on the wrong path.  -- Reagan