Macros

Discussion in 'C Programming' started by BartC, Dec 2, 2012.

  1. BartC

    BartC Guest

    I'm trying out these macros to save on typing and errors** :

    #define else } el##se {

    That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    the new 'else' from being recursively processed.

    But:

    #define elsif } el##se if

    if converted to '} } else { if'. That new 'else' is this time processed one
    extra time.

    What's the way to make it do what I want? (I don't like using capitals; I
    reserve those for debug code.)


    (** A month or so of using C, and I'm starting to suffer from RSI pain
    again! Partly from all the extra typing needed, partly from sorting out
    problems from mismatching/missing braces, case labels and everything else.
    For a supposedly terse language, there's a lot of typing involved!)


    --
    Bartc
     
    BartC, Dec 2, 2012
    #1
    1. Advertising

  2. BartC

    Öö Tiib Guest

    On Sunday, 2 December 2012 19:53:27 UTC+2, Bart wrote:
    > I'm trying out these macros to save on typing and errors** :


    If C syntax is too hard to type for you then better choose
    a language with more laconic syntax like Python. Do not mutate
    language or else others can not read your code.

    > #define else } el##se {
    >
    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.


    You are violating standards here.
    You may not use language keywords as macro names.
    You may do something like:

    #define BartcElse } else {

    That will work. Also if someone wants to undo your effort
    (for obvious reasons) then it will be easier for him.
     
    Öö Tiib, Dec 2, 2012
    #2
    1. Advertising

  3. BartC

    Ian Collins Guest

    BartC wrote:
    > I'm trying out these macros to save on typing and errors** :
    >
    > #define else } el##se {


    Have you taken a Bill pill?

    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.
    >
    > But:
    >
    > #define elsif } el##se if
    >
    > if converted to '} } else { if'. That new 'else' is this time processed one
    > extra time.
    >
    > What's the way to make it do what I want? (I don't like using capitals; I
    > reserve those for debug code.)
    >
    >
    > (** A month or so of using C, and I'm starting to suffer from RSI pain
    > again! Partly from all the extra typing needed, partly from sorting out
    > problems from mismatching/missing braces, case labels and everything else.
    > For a supposedly terse language, there's a lot of typing involved!)


    Use a decent editor, or a not so good one that does auto indent and
    bracket/brace matching.

    --
    Ian Collins
     
    Ian Collins, Dec 2, 2012
    #3
  4. On Dec 3, 12:53 am, "BartC" <> wrote:
    > I'm trying out these macros to save on typing and errors** :


    :)


    > #define else } el##se {
    > ... problems from mismatching/missing braces ...


    :) :)
     
    James Dow Allen, Dec 2, 2012
    #4
  5. BartC

    James Kuyper Guest

    On 12/02/2012 01:11 PM, � wrote:
    > On Sunday, 2 December 2012 19:53:27 UTC+2, Bart wrote:
    >> I'm trying out these macros to save on typing and errors** :

    >
    > If C syntax is too hard to type for you then better choose
    > a language with more laconic syntax like Python. Do not mutate
    > language or else others can not read your code.


    I agree with the sentiment. I'd hate to do maintenance work on code
    written by someone who finds the following concept attractive:

    >> #define else } el##se {
    >>
    >> That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    >> the new 'else' from being recursively processed.

    >
    > You are violating standards here.
    > You may not use language keywords as macro names.


    Citation, please? The grammar for #define requires only that a macro
    parse as an identifier. The C standard distinguishes between plain
    tokens and preprocessing tokens (6.4p1). During translation phase 3, the
    source text is decomposed into preprocessing tokens (5.1.1.2p3) - It's
    only during translation phase 7 that preprocessing tokens get converted
    into tokens. Keywords are parsed tokens during translation phase 7, but
    parse as identifiers during translation phase 3.
    --
    James Kuyper
     
    James Kuyper, Dec 2, 2012
    #5
  6. BartC

    BartC Guest

    "Öö Tiib" <> wrote in message
    news:...
    > On Sunday, 2 December 2012 19:53:27 UTC+2, Bart wrote:
    >> I'm trying out these macros to save on typing and errors** :

    >
    > If C syntax is too hard to type for you then better choose
    > a language with more laconic syntax like Python. Do not mutate
    > language or else others can not read your code.


    Python is no good to me. While I no longer care that no-one else can read my
    code. (Since I've been mostly using my own languages since about 1980, that
    is hardly new for me!)

    >> #define else } el##se {
    >>
    >> That seems to work: 'else' is converted to '} else {'. Somehow the ##
    >> stops
    >> the new 'else' from being recursively processed.


    Now it seems to work without using ##. Strange.

    > You are violating standards here.
    > You may not use language keywords as macro names.
    > You may do something like:
    >
    > #define BartcElse } else {
    >
    > That will work. Also if someone wants to undo your effort
    > (for obvious reasons) then it will be easier for him.


    I think (since no-one is taking me seriously, also that no-one has given me
    a solution...) that I will look instead at creating a preprocessor for the
    source code. This will just take care of the keywords for some statements,
    and help look after the braces.

    The input file needs to have an extension other than ".c", so it will be
    a'language' distinct from C, and the output will be pure C to keep the
    people here happy.

    --
    Bartc
     
    BartC, Dec 2, 2012
    #6
  7. BartC

    Ian Collins Guest

    BartC wrote:
    >
    > I think (since no-one is taking me seriously, also that no-one has given me
    > a solution...) that I will look instead at creating a preprocessor for the
    > source code. This will just take care of the keywords for some statements,
    > and help look after the braces.


    Did you expect to be taken seriously?

    The "solution" is simple - get your editor to do the work for you.

    --
    Ian Collins
     
    Ian Collins, Dec 2, 2012
    #7
  8. BartC

    Greg Martin Guest

    On 12-12-02 12:14 PM, Ian Collins wrote:
    > BartC wrote:
    >>
    >> I think (since no-one is taking me seriously, also that no-one has
    >> given me
    >> a solution...) that I will look instead at creating a preprocessor for
    >> the
    >> source code. This will just take care of the keywords for some
    >> statements,
    >> and help look after the braces.

    >
    > Did you expect to be taken seriously?
    >
    > The "solution" is simple - get your editor to do the work for you.
    >


    +1 ... or if the repetition is significant enough write a code
    generator. Alternatively, run the macro processor in a separate phase to
    leave the final sources readable and free of obfuscation.

    Famous last words ... I'm the only one who'll ever read this anyway.
     
    Greg Martin, Dec 2, 2012
    #8
  9. On 12/2/12 12:53 PM, BartC wrote:
    > I'm trying out these macros to save on typing and errors** :
    >
    > #define else } el##se {
    >
    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.
    >

    No, what is stopping the define from running recursively is the rules
    for expanding defines. The rule approximately states that a macro will
    not reprocess the replacement it creates.

    > But:
    >
    > #define elsif } el##se if
    >
    > if converted to '} } else { if'. That new 'else' is this time processed one
    > extra time.
    >

    Since elsif and else are different macros, so the recursive clause
    doesn't apply.

    > What's the way to make it do what I want? (I don't like using capitals; I
    > reserve those for debug code.)
    >
    >
    > (** A month or so of using C, and I'm starting to suffer from RSI pain
    > again! Partly from all the extra typing needed, partly from sorting out
    > problems from mismatching/missing braces, case labels and everything else.
    > For a supposedly terse language, there's a lot of typing involved!)
    >
    >


    I wouldn't do this sort of redefinitions. For one thing I believe your
    programs have technically invoked undefined behavior to the compiler so
    nothing is promised anymore about your program.

    You are also making your code unreadable to anyone else.

    IF I was to try and do something similar to this, I would use capitals,
    in C these are generally indicative of a macro, so it warns the reader
    to look for the definition. Thus you would have

    #define IF(x) if(x) {
    #define ELSE } else {
    #define ELSIF(x) } else if(x) {
    #define FI }

    note that the last is needed to avoid giving smart editors that match
    the braces from having fits over your code.
     
    Richard Damon, Dec 2, 2012
    #9
  10. BartC

    BartC Guest

    "Ian Collins" <> wrote in message
    news:...
    > BartC wrote:
    >>
    >> I think (since no-one is taking me seriously, also that no-one has given
    >> me
    >> a solution...) that I will look instead at creating a preprocessor for
    >> the
    >> source code. This will just take care of the keywords for some
    >> statements,
    >> and help look after the braces.

    >
    > Did you expect to be taken seriously?


    I thought someone might rise to the technical challenge... But it doesn't
    matter now.

    > The "solution" is simple - get your editor to do the work for you.


    So one answer is to use some external software to help out. Which is what
    I'm now attempting. (And I'll probably fix a few other things while I'm
    about it.)

    --
    Bartc
     
    BartC, Dec 2, 2012
    #10
  11. BartC

    Öö Tiib Guest

    On Sunday, 2 December 2012 20:58:16 UTC+2, James Kuyper wrote:
    > On 12/02/2012 01:11 PM, Öö Tiib wrote:
    > > On Sunday, 2 December 2012 19:53:27 UTC+2, Bart wrote:
    > >> #define else } el##se {
    > >>
    > >> That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > >> the new 'else' from being recursively processed.

    > >
    > > You are violating standards here.
    > > You may not use language keywords as macro names.

    >
    > Citation, please? The grammar for #define requires only that a macro
    > parse as an identifier. The C standard distinguishes between plain
    > tokens and preprocessing tokens (6.4p1). During translation phase 3, the
    > source text is decomposed into preprocessing tokens (5.1.1.2p3) - It's
    > only during translation phase 7 that preprocessing tokens get converted
    > into tokens. Keywords are parsed tokens during translation phase 7, but
    > parse as identifiers during translation phase 3.


    You might be correct, I had memory that the tokens like else are reserved
    for keywords and shall not be used otherwise. But now I looked 6.4.1 again
    and there is some sort of "reserved (in translation phases 7 and 8) for useas
    keywords, and shall not be used otherwise." So that can be indeed read as
    "shall not be used otherwise in translation phases 7 and 8".
     
    Öö Tiib, Dec 2, 2012
    #11
  12. BartC

    BartC Guest

    "BartC" <> wrote in message
    news:bmOus.898237$4...

    > "Öö Tiib" <> wrote in message


    >> You may do something like:
    >>
    >> #define BartcElse } else {


    > I think
    > ... that I will look instead at creating a preprocessor for the
    > source code.


    > The input file needs to have an extension other than ".c", so it will be
    > a'language' distinct from C, and the output will be pure C to keep the
    > people here happy.


    This preprocessor now 'works', and is transparent to the compilation
    process.

    (So long as the input is line-oriented and follows certain guidelines.)

    But one small snag I hadn't thought of: modifying thousands of lines of
    existing code to conform to this new format. I don't think it will help my
    RSI much.)

    --
    Bartc
     
    BartC, Dec 2, 2012
    #12
  13. BartC

    Rui Maciel Guest

    pete wrote:

    > Also,
    > if a good coding style is not being used consistently,
    > then looking at one's own code for the first time in six months,
    > is a lot like reading someone else's code.


    Hear, hear.

    In addition, there are always bugs lingering around, which eventually
    require a fix, and cryptic code only makes them that much harder to spot.


    Rui Maciel
     
    Rui Maciel, Dec 2, 2012
    #13
  14. BartC

    Joe Pfeiffer Guest

    "BartC" <> writes:

    > I'm trying out these macros to save on typing and errors** :
    >
    > #define else } el##se {
    >
    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.
    >
    > But:
    >
    > #define elsif } el##se if
    >
    > if converted to '} } else { if'. That new 'else' is this time processed one
    > extra time.
    >
    > What's the way to make it do what I want? (I don't like using capitals; I
    > reserve those for debug code.)
    >
    >
    > (** A month or so of using C, and I'm starting to suffer from RSI pain
    > again! Partly from all the extra typing needed, partly from sorting out
    > problems from mismatching/missing braces, case labels and everything else.
    > For a supposedly terse language, there's a lot of typing involved!)


    No, no, no.

    Many new C programmers have made this mistake -- I was one of them.

    C has a syntax. It may or may not be a good syntax, but it is C's
    syntax. Using macros to try to create a new syntax for C leads to
    madness. Just... don't.
     
    Joe Pfeiffer, Dec 3, 2012
    #14
  15. BartC

    Joe Pfeiffer Guest

    "BartC" <> writes:

    > I'm trying out these macros to save on typing and errors** :
    >
    > #define else } el##se {
    >
    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.
    >
    > But:
    >
    > #define elsif } el##se if
    >
    > if converted to '} } else { if'. That new 'else' is this time processed one
    > extra time.
    >
    > What's the way to make it do what I want? (I don't like using capitals; I
    > reserve those for debug code.)
    >
    >
    > (** A month or so of using C, and I'm starting to suffer from RSI pain
    > again! Partly from all the extra typing needed, partly from sorting out
    > problems from mismatching/missing braces, case labels and everything else.
    > For a supposedly terse language, there's a lot of typing involved!)


    No, no, no.

    Many new C programmers have made this mistake -- I was one of them.

    C has a syntax. It may or may not be a good syntax, but it is C's
    syntax. Using macros to try to create a new syntax for C leads to
    madness. Just... don't.
     
    Joe Pfeiffer, Dec 3, 2012
    #15
  16. BartC

    Joe Pfeiffer Guest

    "BartC" <> writes:

    > I'm trying out these macros to save on typing and errors** :
    >
    > #define else } el##se {
    >
    > That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
    > the new 'else' from being recursively processed.
    >
    > But:
    >
    > #define elsif } el##se if
    >
    > if converted to '} } else { if'. That new 'else' is this time processed one
    > extra time.
    >
    > What's the way to make it do what I want? (I don't like using capitals; I
    > reserve those for debug code.)
    >
    >
    > (** A month or so of using C, and I'm starting to suffer from RSI pain
    > again! Partly from all the extra typing needed, partly from sorting out
    > problems from mismatching/missing braces, case labels and everything else.
    > For a supposedly terse language, there's a lot of typing involved!)


    No, no, no.

    Many new C programmers have made this mistake -- I was one of them.

    C has a syntax. It may or may not be a good syntax, but it is C's
    syntax. Using macros to try to create a new syntax for C leads to
    madness. Just... don't.
     
    Joe Pfeiffer, Dec 3, 2012
    #16
  17. There exist some tools that reformat the code to a structured indentation
    and to systematic braces. After reformatting the code you may be able to
    find problems with misplaced braces and misleading indentation.

    For many years I used Diamond X-Tools as such a tool. Furthermore it makes
    the code visible as Nassi-Schneidermann diagram and offers editing in that
    diagram. Unfortunately the deafult setting is to add many special
    controlling comments to the source code. But you can switch many of these
    off.
     
    Heinrich Wolf, Dec 3, 2012
    #17
  18. BartC

    BartC Guest

    "Joe Pfeiffer" <> wrote in message
    news:...
    > "BartC" <> writes:
    >
    >> I'm trying out these macros to save on typing and errors** :
    >>
    >> #define else } el##se {


    > No, no, no.
    >
    > Many new C programmers have made this mistake -- I was one of them.


    Possibly that tells you something about the language...

    > C has a syntax. It may or may not be a good syntax, but it is C's
    > syntax.


    Maybe. A 'good' syntax that requires external tools to encode/decipher type
    declarations, or to count braces, or (in my case) to create lists of local
    and global function prototypes that would otherwise take half my time to
    maintain.

    > Using macros to try to create a new syntax for C leads to
    > madness. Just... don't.


    Well, I've given up on that, because it's not up to the job. As I've said,
    I'm using an external tool to convert source code in a kind of hybrid
    language to what is considered normal C code.

    It's a crude tool that converts source a line at a time (so that line
    numbers correspond), but it seems to work.

    Braces have been almost entirely eliminated. Endings for if, switch, while
    etc are distinct (rather than be all "}"). Function prototypes are taken
    care of (they are placed in two include files, one for locals, one for
    exports).

    There were a few other things which weren't that important, but in this
    language implementation project, they were changed to match the target
    language (for example, using := and =, instead of = and ==).

    And, the output is perfectly readable, ordinary C. Where the braces always
    match up.

    --
    Bartc
     
    BartC, Dec 3, 2012
    #18
  19. BartC

    ImpalerCore Guest

    On Dec 2, 5:55 pm, "BartC" <> wrote:
    > "BartC" <> wrote in message
    >
    > news:bmOus.898237$4...
    >
    > > "Öö Tiib" <> wrote in message
    > >> You may do something like:

    >
    > >> #define BartcElse } else {

    > > I think
    > > ... that I will look instead at creating a preprocessor for the
    > > source code.
    > > The input file needs to have an extension other than ".c", so it will be
    > > a'language' distinct from C, and the output will be pure C to keep the
    > > people here happy.

    >
    > This preprocessor now 'works', and is transparent to the compilation
    > process.
    >
    > (So long as the input is line-oriented and follows certain guidelines.)
    >
    > But one small snag I hadn't thought of: modifying thousands of lines of
    > existing code to conform to this new format. I don't think it will help my
    > RSI much.)


    If you use 'vi', it has a macro mechanism to record a series of steps
    and apply it on command.

    If you have code that features the same style, you should be able to
    change it through a careful selection of movement and edit commands,
    and apply it to any number of sequential lines.

    For example, let's say that you have a set of integer declarations.

    int a;
    int b;
    int c;
    ....
    int z;

    You want to create a set of printf statements from that block. The
    '^' represents a cursor position in the text.
    vi command
    int a;
    ^ ma
    int b;
    int c;
    ....
    int z;
    ^ y'a

    Paste it in a new location.

    vi
    int a; p
    int b;
    int c;
    ....
    int z;

    Go to beginning of first line of copied block.

    int a;
    ^ qa
    int b;
    int c;
    ....
    int z;

    Hitting 'q' starts recording a macro in slot 'a'.

    Perform your edit and place the cursor at the beginning of the next
    line. Use 'yw' to copy the character 'a' to store relative text and
    paste to duplicate that text. At the end of your edit, move to the
    beginning of the next line ('j', '0') that's used to anchor your next
    line edit.

    vi
    printf( "a = %d", a );
    int b;
    ^ q
    int c;
    ....
    int z;

    Hit 'q' to end the macro. Now you have a macro to change 'int a;'
    into ' printf( "a = %d", a );' and moves down to the beginning of the
    next line.

    printf( "a = %d", a );
    int b;
    ^ 25@a
    int c;
    ....
    int z;

    Type 25@a to apply your macro 'a' 25 times.

    printf( "a = %d", a );
    printf( "b = %d", b );
    printf( "c = %d", c );
    ....
    printf( "z = %d", z );
    ^

    You can also do it with regular expressions. If you have this much
    editing to do, it's worth looking into an editor that can help you out
    with repetitive code changes.

    Best regards,
    John D.
     
    ImpalerCore, Dec 3, 2012
    #19
  20. BartC

    Öö Tiib Guest

    On Monday, 3 December 2012 10:48:35 UTC+2, Heinrich Wolf wrote:
    > There exist some tools that reformat the code to a structured indentation
    > and to systematic braces. After reformatting the code you may be able to
    > find problems with misplaced braces and misleading indentation.


    +1

    > For many years I used Diamond X-Tools as such a tool. Furthermore it makes
    > the code visible as Nassi-Schneidermann diagram and offers editing in that
    > diagram. Unfortunately the deafult setting is to add many special
    > controlling comments to the source code. But you can switch many of these
    > off.


    I have used "Artistic Style". It does not do any editing only formats.
    However it formats quite well. It formats C and Java and C# and even
    C++ code for very wide variety of bracing and white-spacing tastes.
    It is open source C++ and not too large code-base so when I don't like
    something that it does then I can just modify it.
     
    Öö Tiib, Dec 3, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    80
    Views:
    2,524
    Stephen J. Bevan
    Nov 7, 2003
  2. Replies:
    1
    Views:
    492
    Marco Antoniotti
    Oct 7, 2003
  3. Replies:
    5
    Views:
    514
  4. Michael T. Babcock

    Re: Explanation of macros; Haskell macros

    Michael T. Babcock, Nov 3, 2003, in forum: Python
    Replies:
    0
    Views:
    543
    Michael T. Babcock
    Nov 3, 2003
  5. Andrew Arro

    macros-loop? calling macros X times?

    Andrew Arro, Jul 23, 2004, in forum: C Programming
    Replies:
    2
    Views:
    519
    S.Tobias
    Jul 24, 2004
Loading...

Share This Page