«

I was working on a routine that requires me to parse out a list of
attributes of an object in a text line. An attribute could be empty,
causing it to revert to it's current value, or the list of attributes
could terminate without completing and all unlisted attributes revert.
The structure of the program at this point looks like a string along
these lines....


set pointers
copy attribute
check for termination
if terminated, break
set pointers
copy attribute
check for termination
if terminated, break
set pointers
copy attribute
check for termination
if terminated, break
...

Unfortunately the only means I could find of skipping over the
remaining code without using a goto was to enclose it thusly....

do {
set pointers
copy attribute
check for termination
if terminated, break
set pointers
copy attribute
check for termination
if terminated, break
set pointers
copy attribute
check for termination
if terminated, break
...
} while (false);

Is this klugie? Is there a better way? I could make the whole piece
of code a function and escape out with a return but that seems just as
extraneous. I could make it a for loop and use the termination as the
exit condition but that would mean setting up a table of pointers to
read from in each loop, just as convoluted.

So, is there a better way?

--
TIA,
Lilith

Lilith wrote:
> I was working on a routine that requires me to parse out a list of
> attributes of an object in a text line. An attribute could be empty,
> causing it to revert to it's current value, or the list of attributes
> could terminate without completing and all unlisted attributes revert.
> The structure of the program at this point looks like a string along
> these lines....
>
>
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> ...
>
> Unfortunately the only means I could find of skipping over the
> remaining code without using a goto was to enclose it thusly....
>
> do {
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> ...
> } while (false);
>
> Is this klugie? Is there a better way? I could make the whole piece
> of code a function and escape out with a return but that seems just as
> extraneous. I could make it a for loop and use the termination as the
> exit condition but that would mean setting up a table of pointers to
> read from in each loop, just as convoluted.
>
> So, is there a better way?

Since you say nothing what "set pointers", "copy attribute", "check for
termination" mean, how can we suggest anything of value? GIGO.

If you can put the "set-copy-check" into a function with arguments and
make it return the state, you can write it

revert_all_attributes();
while (termintated != set_copy_check(stream))
;


V

In article <>,
Lilith <> wrote:

> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> ...
>
> Unfortunately the only means I could find of skipping over the
> remaining code without using a goto was to enclose it thusly....

I just can't leave this one alone...

I don't have enough information to truly guide you well. Your own
suggestion later sounds promising to me:

> I could make the whole piece
> of code a function and escape out with a return

That being said, I've seen code before that was especially convoluted
just for the purpose of avoiding the goto keyword. This is a Bad Thing
(tm).

goto is your friend. Use it wisely. Use it sparingly. Use it when it
is the best tool for the job. Do not abuse it. And most importantly of
all in today's climate: Don't gratuitously complicate your code just to
avoid typing those overly maligned 4 letters g-o-t-o.

But be prepared: Middle level programmers will snicker at you for being
so backwards as to use a goto in your code. After all, everyone who's
anyone knows that goto is evil and should never be used. "Modern"
languages don't even bother with it. Listen to their advice. If they
can show you a way to code without using goto that is more readable, not
larger code size, and not more expensive at run time, then they are
right. If they can't, then snickering alone is not enough reason to
remove a goto. As your programming skill advances (and it will if you
keep considering the advice of your peers), you'll find that you are
hardly ever tempted to use goto. But when you are, it is the perfect
tool for the job - and you'll be able to defend its use to anyone who
may snicker.

-Howard
(who has been snickered at more than once for using goto)

On Tue, 30 Aug 2005 22:48:44 -0400, "Victor Bazarov"
<> wrote:

>Lilith wrote:
>> I was working on a routine that requires me to parse out a list of
>> attributes of an object in a text line. An attribute could be empty,
>> causing it to revert to it's current value, or the list of attributes
>> could terminate without completing and all unlisted attributes revert.
>> The structure of the program at this point looks like a string along
>> these lines....
>>
>>
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> ...
>>
>> Unfortunately the only means I could find of skipping over the
>> remaining code without using a goto was to enclose it thusly....
>>
>> do {
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> ...
>> } while (false);
>>
>> Is this klugie? Is there a better way? I could make the whole piece
>> of code a function and escape out with a return but that seems just as
>> extraneous. I could make it a for loop and use the termination as the
>> exit condition but that would mean setting up a table of pointers to
>> read from in each loop, just as convoluted.
>>
>> So, is there a better way?
>
>Since you say nothing what "set pointers", "copy attribute", "check for
>termination" mean, how can we suggest anything of value? GIGO.

I was trying to be concise. Sorry. The pointers were essentially
source and destination pointers along with a pointer to a string of
potential parsing tokens (commas, braces, parenz, etc.) that needed to
be passed to the CopyTil() function. The return value is a pointer to
the character in the source string where the token (or end of string)
was found. The character pointed to by that pointer was what I was
testing. i.e., if the character wasn't a separator then it was a
termintor and there was no sense in checking for more parameters in
the list.

>If you can put the "set-copy-check" into a function with arguments and
>make it return the state, you can write it

> revert_all_attributes();
> while (termintated != set_copy_check(stream))
> ;

>V

--
Lilith

On Wed, 31 Aug 2005 14:21:05 GMT, Howard Hinnant
<> wrote:

>In article <>,
> Lilith <> wrote:
>
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers

[snip]

>I just can't leave this one alone...

>I don't have enough information to truly guide you well. Your own
>suggestion later sounds promising to me:

>> I could make the whole piece
>> of code a function and escape out with a return

>That being said, I've seen code before that was especially convoluted
>just for the purpose of avoiding the goto keyword. This is a Bad Thing
>(tm).

>goto is your friend. Use it wisely. Use it sparingly. Use it when it
>is the best tool for the job. Do not abuse it. And most importantly of
>all in today's climate: Don't gratuitously complicate your code just to
>avoid typing those overly maligned 4 letters g-o-t-o.

>But be prepared: Middle level programmers will snicker at you for being
>so backwards as to use a goto in your code. After all, everyone who's
>anyone knows that goto is evil and should never be used. "Modern"
>languages don't even bother with it. Listen to their advice. If they
>can show you a way to code without using goto that is more readable, not
>larger code size, and not more expensive at run time, then they are
>right. If they can't, then snickering alone is not enough reason to
>remove a goto. As your programming skill advances (and it will if you
>keep considering the advice of your peers), you'll find that you are
>hardly ever tempted to use goto. But when you are, it is the perfect
>tool for the job - and you'll be able to defend its use to anyone who
>may snicker.

When I started programming (a personal pleasure, not a career) I
expected to program mostly in BASIC but found more enjoyment in
assembler for the 8080/Z80 CPU. Not lots of choices WRT goto there.
My hobby led to being put in charge of the new computer department of
the small tooling distributor I was working for at the time. I
modified program in a language called CPL 5 (I think there's another,
more common, language called CPL) that could only do gotos and gosubs
on conditions. There wasn't any kind of basic looping available so my
only option was spaghetti code.

With CPL 6 they added some rudimentary FOR and WHILE statements and I,
for the first time, began to use them extensively. In my opinion they
greatly helped me keep my code neat and it also helped with
development. I've avoided the goto since that day. At that time I
read lots of articles on programming technique and tried to adjust my
methods based on any number of "authoritative" pronouncements. Some
of them I agree with others I had problems with.

AAR, if I'd had any input in the design of C/C++ I would have liked to
have seen a break statement that would essentially escape the local
set of enclosing parentheses, regardless if it was in a loop or a set
of code to be skipped over.

>-Howard
>(who has been snickered at more than once for using goto)

--
Lilith (who won't snidker at her betters)

Lilith wrote:
> I was working on a routine that requires me to parse out a list of
> attributes of an object in a text line. An attribute could be empty,
> causing it to revert to it's current value, or the list of attributes
> could terminate without completing and all unlisted attributes revert.
> The structure of the program at this point looks like a string along
> these lines....
>
>
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> ...
>
> Unfortunately the only means I could find of skipping over the
> remaining code without using a goto was to enclose it thusly....
>
> do {
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> set pointers
> copy attribute
> check for termination
> if terminated, break
> ...
> } while (false);
>
> Is this klugie? Is there a better way? I could make the whole piece
> of code a function and escape out with a return but that seems just as
> extraneous. I could make it a for loop and use the termination as the
> exit condition but that would mean setting up a table of pointers to
> read from in each loop, just as convoluted.
>
> So, is there a better way?

To me it seems like your pseudo code above is equivalent to

do {
set pointers
copy attribute
check for termination
} while (not terminated);

Am I wrong?


August

On Wed, 31 Aug 2005 16:27:58 GMT, akarl <> wrote:

>Lilith wrote:
>> I was working on a routine that requires me to parse out a list of
>> attributes of an object in a text line. An attribute could be empty,
>> causing it to revert to it's current value, or the list of attributes
>> could terminate without completing and all unlisted attributes revert.
>> The structure of the program at this point looks like a string along
>> these lines....
>>
>>
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> ...
>>
>> Unfortunately the only means I could find of skipping over the
>> remaining code without using a goto was to enclose it thusly....
>>
>> do {
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> set pointers
>> copy attribute
>> check for termination
>> if terminated, break
>> ...
>> } while (false);
>>
>> Is this klugie? Is there a better way? I could make the whole piece
>> of code a function and escape out with a return but that seems just as
>> extraneous. I could make it a for loop and use the termination as the
>> exit condition but that would mean setting up a table of pointers to
>> read from in each loop, just as convoluted.
>>
>> So, is there a better way?
>
>To me it seems like your pseudo code above is equivalent to
>
> do {
> set pointers
> copy attribute
> check for termination
> } while (not terminated);

>Am I wrong?

'Fraid so. Each of the repeating segments above involve a different
set of pointers, or at least one is set, another is manipulated and
the third is constant. So as I finish up with one segment and check
to see if the result is a termination there's no way to
programatically calculate the destination pointer for the next segment
without resorting to a some other resource, like a table, so as to
make it a brief loop. Also, making it a loop dependent on a
termination character would complicate the setting of the source
pointer, which is returned by the copy function and manipulated, for
the next round.

>August

--
Lilith

Lilith wrote:
> On Wed, 31 Aug 2005 16:27:58 GMT, akarl <> wrote:
>>Lilith wrote:
>>>Unfortunately the only means I could find of skipping over the
>>>remaining code without using a goto was to enclose it thusly....
>>>
>>>do {
>>> set pointers
>>> copy attribute
>>> check for termination
>>> if terminated, break
>>> set pointers
>>> copy attribute
>>> check for termination
>>> if terminated, break
>>> set pointers
>>> copy attribute
>>> check for termination
>>> if terminated, break
>>> ...
>>>} while (false);
....
>>
>>To me it seems like your pseudo code above is equivalent to
>>
>> do {
>> set pointers
>> copy attribute
>> check for termination
>> } while (not terminated);
>
>
>>Am I wrong?
>
>
> 'Fraid so.

Then I think it needs more detail to be of any use.

> Each of the repeating segments above involve a different
> set of pointers, or at least one is set, another is manipulated and
> the third is constant. So as I finish up with one segment and check
> to see if the result is a termination there's no way to
> programatically calculate the destination pointer for the next segment
> without resorting to a some other resource, like a table, so as to
> make it a brief loop. Also, making it a loop dependent on a
> termination character would complicate the setting of the source
> pointer, which is returned by the copy function and manipulated, for
> the next round.

On Wed, 31 Aug 2005 14:21:05 GMT, Howard Hinnant <>
wrote:

>But be prepared: Middle level programmers will snicker at you for being
>so backwards as to use a goto in your code. After all, everyone who's
>anyone knows that goto is evil and should never be used. "Modern"
>languages don't even bother with it. Listen to their advice. If they
>can show you a way to code without using goto that is more readable, not
>larger code size, and not more expensive at run time, then they are
>right. If they can't, then snickering alone is not enough reason to
>remove a goto. As your programming skill advances (and it will if you
>keep considering the advice of your peers), you'll find that you are
>hardly ever tempted to use goto. But when you are, it is the perfect
>tool for the job - and you'll be able to defend its use to anyone who
>may snicker.
>
>-Howard
>(who has been snickered at more than once for using goto)

The situations you must get into where goto is the only answer do exist.
However, they are extremely rare in my experience. So if you do want to use
goto, you're likely wrong. Very likely.

I've found that code that wants to use goto often needs to be a state machine.

-dr