The "loop and a half"
bartc
bc at freeuk.com
Fri Oct 6 20:47:49 EDT 2017
On 07/10/2017 01:14, Ben Bacarisse wrote:
> bartc <bc at freeuk.com> writes:
>
>> On 06/10/2017 14:35, Paul Moore wrote:
>>> On 6 October 2017 at 13:56, bartc <bc at freeuk.com> wrote:
>>>> If you don't like the word 'crude', try 'lazy'. Take this example of the gcc
>>>> C compiler:
>>>>
>>>> > gcc -E program.c
>>>>
>>>> This preprocesses the code and shows the result. Typical programs will have
>>>> many thousands of lines of output, but it just dumps it to the console. You
>>>> /have/ to use '>' to use it practically (Windows doesn't really have a
>>>> working '|' system.)
>
> Does the Windows version of gcc not support the -o file option?
I never thought of trying it. But OK, you have to use -o or > to stop
the output from swamping the console. (| might work if I could find a
program that captured the piped output for the purpose of browsing.)
(In my IDE, if a particular C file is highlighted, then typing 'cpp'
will invoke the currently selected C compiler's -E equivalent, then
instantly show the result in the editor.
Looking at the script for that, that does make use of the -o option, for
gcc, so I must have known about it.)
> And a good system lets you alter that. How many labels are generated
> for some code? Let's see:
>
> gcc -S -o /dev/stdout t.c | grep -c '^\.L'
>
> Now gcc also permits -o - (it's a common Unix convention) but you can
> almost always get round less helpful programs using /dev/sdout.
I'm not really arguing against this. I'm disputing the suggestion that
because these utilities, which are rarely given data actually typed from
the keyboard, work by reading from stdin using an eof-checking loop,
that the same method must always be used in programs that really are
reading data from the keyboard.
I think they are different kinds of applications.
(As for the ability to chain these programs together, I have the same
opinion of that as doing the same in program code when you use the
result of one function/method call to feed in as the argument to the next.
They can both end up as long horizontal hard-to-follow (or to intercept)
sequences.
I'd prefer to break them up using intermediate variables in the language
and intermediate files in the shell.
And as you can see from my IDE's 'cpp' command, which works with 4
different C compilers (a fifth doesn't properly support -E), there are
other approaches developers can use.)
--
bartc
More information about the Python-list
mailing list