Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   C format programs (http://www.velocityreviews.com/forums/t951562-c-format-programs.html)

songbird 08-30-2012 01:07 AM

C format programs
 
I dislike the use of macros which hide
the meaning of the code, but some code I
work on does things like the following and I
don't want to stray too far from the original
version.

I tried both indent, and astyle and neither of
them understand macros enough to know what to do
with things like:


=====
# define when break; case
# define orwhen case
# define otherwise break; default

=====

so the result looks like:

=====

/* Get the options */
while (--argc > 0 && (*++argv)[0] == '-') {
while (*++(*argv)) {
switch (**argv) {
when 'a': full=2;
when 'i': init++;
when 'f': full=1;
when 'm': m = atoi(*argv+1); SKIPARG;
printf ("axe size %d.\n", m);
when 's': seed = atoi(*argv+1); SKIPARG;
printf ("Random seed %d.\n", m);
when 'v': version = atoi(*argv+1); SKIPARG;
printf ("version %d.\n", version);
otherwise: quit (1,
"Usage: axe [-if] [-msv<value>] [axed]\n");
}
}
}

=====

if there is a way to preprocess to expand the macros
without getting all the extra stuff that cpp includes
that could be done.

or if there are any other C code formatters/indenters
that do understand macros I'd be glad to hear of them.


thanks for any ideas,


songbird

Eric Sosman 08-30-2012 01:35 AM

Re: C format programs
 
On 8/29/2012 9:07 PM, songbird wrote:
> [...]
> I tried both indent, and astyle and neither of
> them understand macros enough to know what to do
> with things like:
> [... bletcherous code snipped ...]


Ugh. The most fitting punishment would be to force the
author to maintain his own code -- after a five-year hiatus
to let him forget what his "clever" macros did before someone
else "improved" them ...

There's a saying "Thou shalt not use the preprocessor to
violate the syntax," which I think is a little extreme taken
at face value but a good starting point nonetheless. The author
of the code you're facing was apparently inexperienced enough
not to have encountered that adage, or self-important enough to
imagine it didn't apply to him. Too bad.

> if there is a way to preprocess to expand the macros
> without getting all the extra stuff that cpp includes
> that could be done.
>
> or if there are any other C code formatters/indenters
> that do understand macros I'd be glad to hear of them.


Question 10.18 in the c.l.c. FAQ <http://www.c-faq.com/>
mentions a few possibilities, although I myself cannot vouch
for them. Good luck! -- you may need it ...

--
Eric Sosman
esosman@ieee-dot-org.invalid

songbird 08-30-2012 01:50 AM

Re: C format programs
 
Don't make my brown eyes China Blue wrote:
....
> If you're using unix, you can expand the macros with something
>
> sed <plugh.c >plugh.ex.c \
> 's/when/break; case/g' \
> 's/orwhen/case/g' \
> 's/otherwise/break; default/g'
>
> Similar tools like perl, tcl, ed are available on a variety of OSes and can also
> do this kind of simple string substitution.


yes, of course.

i was thinking of a more general solution for
many other macros... those three are only the
tip of the iceberg.


songbird

songbird 08-30-2012 02:43 AM

Re: C format programs
 
Eric Sosman wrote:
>songbird wrote:
>> [...]
>> I tried both indent, and astyle and neither of
>> them understand macros enough to know what to do
>> with things like:
>> [... bletcherous code snipped ...]

>
> Ugh. The most fitting punishment would be to force the
> author to maintain his own code -- after a five-year hiatus
> to let him forget what his "clever" macros did before someone
> else "improved" them ...


Code written in the early 80s (not by me :) ).
Quite a different age in terms of coding/development
than now. Part of what I'm doing with this project
is learning different tools and ways of doing things
that I didn't have back then.

> There's a saying "Thou shalt not use the preprocessor to
> violate the syntax," which I think is a little extreme taken
> at face value but a good starting point nonetheless. The author
> of the code you're facing was apparently inexperienced enough
> not to have encountered that adage, or self-important enough to
> imagine it didn't apply to him. Too bad.


:)

Well, for sure it isn't something I do. I'd
rather be able to see without having to hunt down
the definition as it may be different than what
I'd expect.

If it is code I'm working on a lot I turn the
macros into function calls as much as possible
and do the text substitutions. But that makes
it hard to do comparisons to the originals to
see what of substance has changed...


>> if there is a way to preprocess to expand the macros
>> without getting all the extra stuff that cpp includes
>> that could be done.
>>
>> or if there are any other C code formatters/indenters
>> that do understand macros I'd be glad to hear of them.

>
> Question 10.18 in the c.l.c. FAQ <http://www.c-faq.com/>
> mentions a few possibilities, although I myself cannot vouch
> for them. Good luck! -- you may need it ...


It's not looking good at the moment, but I'll keep nosing
around, thanks.


songbird

Ian Collins 08-30-2012 02:48 AM

Re: C format programs
 
On 08/30/12 02:43 PM, songbird wrote:
>
> If it is code I'm working on a lot I turn the
> macros into function calls as much as possible
> and do the text substitutions. But that makes
> it hard to do comparisons to the originals to
> see what of substance has changed...


Use your source control system.

Check in cosmetic changes on their own, never mix them with logic
changes. Then you should be able to isolate the former from the latter
quite easily.

--
Ian Collins

Keith Thompson 08-30-2012 02:50 AM

Re: C format programs
 
Don't make my brown eyes China Blue <chine.bleu@yahoo.com> writes:
> In article <nuq2h9-p77.ln1@ID-306963.user.uni-berlin.de>,
> songbird <songbird@anthive.com> wrote:
>
>> # define when break; case
>> # define orwhen case
>> # define otherwise break; default

>
>> if there is a way to preprocess to expand the macros
>> without getting all the extra stuff that cpp includes
>> that could be done.
>>
>> or if there are any other C code formatters/indenters
>> that do understand macros I'd be glad to hear of them.

>
> If you're using unix, you can expand the macros with something
>
> sed <plugh.c >plugh.ex.c \
> 's/when/break; case/g' \
> 's/orwhen/case/g' \
> 's/otherwise/break; default/g'
>
> Similar tools like perl, tcl, ed are available on a variety of OSes
> and can also do this kind of simple string substitution.


Be sure to match `when`, `orwhen`, and `otherwise` as full words. For
sed:

s/\<when\>/break; case/g

et al.

Avoiding substitutions within string literals and comments is left
as an exercise (i.e., I'm too lazy to figure out how to do it).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson 08-30-2012 02:58 AM

Re: C format programs
 
Ian Collins <ian-news@hotmail.com> writes:
> On 08/30/12 02:43 PM, songbird wrote:
>>
>> If it is code I'm working on a lot I turn the
>> macros into function calls as much as possible
>> and do the text substitutions. But that makes
>> it hard to do comparisons to the originals to
>> see what of substance has changed...

>
> Use your source control system.
>
> Check in cosmetic changes on their own, never mix them with logic
> changes. Then you should be able to isolate the former from the latter
> quite easily.


Yes, that's definitely a good idea. But comparison can still be
difficult in some cases.

For example, suppose version 5 is very old, version 10 removes the
ugly macros (so the only difference between versions 9 and 10 is
the cleanup), and version 15 is the current version. If you need
to compare versions 5 and 15, or even 8 and 11, you're still going
to see a mixture of functional changes and cleanup changes.

If you can completely automate the process of fixing the macros,
in a way that works correctly even for older versions, you can
compare a converted copy of version 5 against version 15.

On the other hand, if versions of the code prior to version 9 are
uninteresting, it's probably not worth the effort; automating the
cleanup is likely to be worthwhile anyway, but don't worry about
automating 100% of it vs. 95%.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

ImpalerCore 08-30-2012 03:32 AM

Re: C format programs
 
On Aug 29, 9:50*pm, songbird <songb...@anthive.com> wrote:
> Don't make my brown eyes China Blue wrote:
> ...
>
> > If you're using unix, you can expand the macros with something

>
> > * * sed <plugh.c >plugh.ex.c \
> > * * * * 's/when/break; case/g' \
> > * * * * 's/orwhen/case/g' \
> > * * * * 's/otherwise/break; default/g'

>
> > Similar tools like perl, tcl, ed are available on a variety of OSes andcan also
> > do this kind of simple string substitution.

>
> * yes, of course.
>
> * i was thinking of a more general solution for
> many other macros... *those three are only the
> tip of the iceberg.


There are a couple of approaches that I can think of, both of which
involve sed or some other text processing scripting language of
choice. Since I'm the most familiar with sed, here are the couple of
approaches that I would suggest.

1. sed solution - Build a lookup table in the hold space when one
runs into a single line '#define' construct. Then for each line that
doesn't contain a #define, paste the hold space contents into the
pattern space and perform a lookup table substitution regex. Not for
the faint of heart.

http://sed.sourceforge.net/grabbag/t...kup_tables.txt

2. sed + cpp solution - Create a special character sequence to
"comment out" preprocessor directives that you don't want cpp to
preprocess. For example, one can replace the '#' character in front
of every non '#define' statement with some kind of escape sequence.
For example, one can use an autoconf like quadrigraph '# --> @%:@'.

@%:@include <stdio.h> (cpp will now ignore)

@%:@ifdef HAVE_STDINT_H
@%:@ include <stdint.h>
@%:@endif

To preserve comments, one can define another "quadrigraph" sequence to
preserve comments, perhaps '@|:@ for '//' and '@<:@' for '/*' and
'@:>@' for '*/' (probably don't need to do it for '*/'). There may be
other character sequences I'm missing.

Then you pass the source through your 'cpp' preprocessor to perform
the macro substitution, and then filter the results to reestablish the
original preprocessor commands in the #define preprocessed file by
replacing your "quadrigraphs" with your original character sequences.

I recommend something along the lines of option 2, as it seems a bit
easier than the straight up 'sed' route.

Best regards,
John D.

Joe Pfeiffer 08-30-2012 04:13 AM

Re: C format programs
 
Ian Collins <ian-news@hotmail.com> writes:

> On 08/30/12 02:43 PM, songbird wrote:
>>
>> If it is code I'm working on a lot I turn the
>> macros into function calls as much as possible
>> and do the text substitutions. But that makes
>> it hard to do comparisons to the originals to
>> see what of substance has changed...

>
> Use your source control system.
>
> Check in cosmetic changes on their own, never mix them with logic
> changes. Then you should be able to isolate the former from the
> latter quite easily.


If you can cleanly separate your cosmetic changes from your logic
changes when working on code, to the point you can make a bunch of
changes that *only* fit one of those categories at a time, my hat is off
to you as a disciplined programmer.

Ian Collins 08-30-2012 04:28 AM

Re: C format programs
 
On 08/30/12 04:13 PM, Joe Pfeiffer wrote:
> Ian Collins<ian-news@hotmail.com> writes:
>
>> On 08/30/12 02:43 PM, songbird wrote:
>>>
>>> If it is code I'm working on a lot I turn the
>>> macros into function calls as much as possible
>>> and do the text substitutions. But that makes
>>> it hard to do comparisons to the originals to
>>> see what of substance has changed...

>>
>> Use your source control system.
>>
>> Check in cosmetic changes on their own, never mix them with logic
>> changes. Then you should be able to isolate the former from the
>> latter quite easily.

>
> If you can cleanly separate your cosmetic changes from your logic
> changes when working on code, to the point you can make a bunch of
> changes that *only* fit one of those categories at a time, my hat is off
> to you as a disciplined programmer.


Well that depends how often you commit. In my case it's every few
minutes. I always have a never mix the two rule for my teams.

--
Ian Collins


All times are GMT. The time now is 12:44 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.