Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #70860 > unrolled thread

Multi-line #defines

Back to article view | Back to comp.lang.c

Contents

  Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-17 17:50 -0700
    Re: Multi-line #defines wssimms@gmail.com - 2015-09-17 21:13 -0700
      Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-17 23:20 -0700
        Re: Multi-line #defines David Brown <david.brown@hesbynett.no> - 2015-09-18 14:13 +0200
          Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-18 05:28 -0700
            Re: Multi-line #defines mark.bluemel@gmail.com - 2015-09-18 05:43 -0700
              Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-18 05:46 -0700
              Re: Multi-line #defines Keith Thompson <kst-u@mib.org> - 2015-09-18 08:39 -0700
                Re: Multi-line #defines Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:42 -0700
            Re: Multi-line #defines Philip Lantz <prl@canterey.us> - 2015-09-19 00:32 -0700
              Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-19 11:54 -0700
                Re: Multi-line #defines Philip Lantz <prl@canterey.us> - 2015-09-19 12:50 -0700
                  Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-19 12:58 -0700
            Re: Multi-line #defines gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-19 09:16 +0000
        Re: Multi-line #defines Richard Damon <Richard@Damon-Family.org> - 2015-09-18 08:38 -0400
          Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-18 05:45 -0700
      Re: Multi-line #defines gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-18 10:43 +0000
    Re: Multi-line #defines Bartc <bc@freeuk.com> - 2015-09-18 14:32 +0100
      Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-18 06:43 -0700
        Re: Multi-line #defines wssimms@gmail.com - 2015-09-18 09:31 -0700
          Re: Multi-line #defines supercat@casperkitty.com - 2015-09-18 10:24 -0700
    Re: Multi-line #defines Siri Cruz <chine.bleu@yahoo.com> - 2015-09-18 10:12 -0700
    Re: Multi-line #defines gordonb.vjjox@burditt.org (Gordon Burditt) - 2015-09-18 17:54 -0500
      Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-18 16:30 -0700
      Re: Multi-line #defines gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-19 09:22 +0000
      Re: Multi-line #defines Bartc <bc@freeuk.com> - 2015-09-19 11:31 +0100
        Re: Multi-line #defines Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-19 13:26 +0100
          Re: Multi-line #defines Bartc <bc@freeuk.com> - 2015-09-19 14:11 +0100
            Re: Multi-line #defines Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-19 07:01 -0700
              Re: Multi-line #defines Les Cargill <lcargill99@comcast.com> - 2015-09-19 11:23 -0500
      Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-26 20:05 -0700
        Re: Multi-line #defines Ian Collins <ian-news@hotmail.com> - 2015-10-27 16:08 +1300
          Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-26 20:16 -0700
        Re: Multi-line #defines supercat@casperkitty.com - 2015-10-27 06:30 -0700
          Re: Multi-line #defines "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-27 06:52 -0700

Page 1 of 2  [1] 2  Next page →

#70860 — Multi-line #defines

Is there a C syntax, or variant of C syntax in use, which allows multi-
line defines to be enclosed in standard braces, such that something
like this...:

     #define abc line1\
     line2\
     line3

...is translated to be the same as something like this:

     #define abc {line1
     line2
     line3}

And specifically I am considering something more human readable...:

     #define abc {
         line1
         line2
         line3
     } ignore_leading_whitespaces, ignore_leading_feeds, ignore_trailing_feeds;

...which in RDC syntax would be:

     #define abc
     | ignore_leading_whitespaces
     | ignore_leading_feeds
     | ignore_trailing_feeds
     {
         line1
         line2
         line3
     };

While it is longer in source code form, I think it's easier to read, and
it does not need to be rendered this way in a GUI editor.  It can be
rendered in whatever way conveys the same information, such as with
graphic components which signal checkboxes for enabling or disabling
supported options, rather than typing them in via their text keywords.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#70864

Am Freitag, 18. September 2015 09:50:19 UTC+9 schrieb Rick C. Hodgin:
> Is there a C syntax, or variant of C syntax in use, which allows multi-
> line defines to be enclosed in standard braces, such that something
> like this...:
> 
>      #define abc line1\
>      line2\
>      line3
> 
> ...is translated to be the same as something like this:
> 
>      #define abc {line1
>      line2
>      line3}
> 
> And specifically I am considering something more human readable...:
> 
>      #define abc {
>          line1
>          line2
>          line3
>      } ignore_leading_whitespaces, ignore_leading_feeds, ignore_trailing_feeds;
> 
> ...which in RDC syntax would be:
> 
>      #define abc
>      | ignore_leading_whitespaces
>      | ignore_leading_feeds
>      | ignore_trailing_feeds
>      {
>          line1
>          line2
>          line3
>      };
> 
> While it is longer in source code form, I think it's easier to read, and
> it does not need to be rendered this way in a GUI editor.  It can be
> rendered in whatever way conveys the same information, such as with
> graphic components which signal checkboxes for enabling or disabling
> supported options, rather than typing them in via their text keywords.

Can you explain what you are trying to do that is not done by
the usual:

#define abc do { \
line1 \
line2 \
line3 \
} while(0)

Is your question practical, or more a rhetorical question leading into
how you think things ought to work in some hypothetical not-C language?

[toc] | [prev] | [next] | [standalone]

#70866

wss...@gmail.com wrote:
> Can you explain what you are trying to do
> that is not done by the usual:

Not have the \ characters for continuation, but
still define a multi-line macro.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70878

On 18/09/15 08:20, Rick C. Hodgin wrote:
> wss...@gmail.com wrote:
>> Can you explain what you are trying to do
>> that is not done by the usual:
> 
> Not have the \ characters for continuation, but
> still define a multi-line macro.
> 
> Best regards,
> Rick C. Hodgin
> 

The trailing \ is somewhat ugly, but it's not /that/ bad.  It is
certainly much less bad than having to add annotations like
"ignore_leading_whitespaces".

The best way to avoid multi-line macros is to minimise the use of macros
at all, such as by using static inline functions where possible.

And if you really want to avoid the multi-line macros, you could always
switch to C++ where there are several alternatives (such as templates)
that greatly reduce the need for complex macros.

[toc] | [prev] | [next] | [standalone]

#70879

On Friday, September 18, 2015 at 8:13:17 AM UTC-4, David Brown wrote:
> On 18/09/15 08:20, Rick C. Hodgin wrote:
> > wss...@gmail.com wrote:
> >> Can you explain what you are trying to do
> >> that is not done by the usual:
> > 
> > Not have the \ characters for continuation, but
> > still define a multi-line macro.

I am looking for a syntax in C which is not the trailing \ character.
I do not think it exists, but the rest is just my thinking on how it
should be (will be) done for RDC.

> The trailing \ is somewhat ugly, but it's not /that/ bad.  It is
> certainly much less bad than having to add annotations like
> "ignore_leading_whitespaces".

The GUI editor would never see it.  And if someone ever did have to dip
down into raw text-based source code, it would be completely clear what
is going on there, even to someone who does not know RDC.

Such features are a natural progression of GUI abilities added onto raw
text computing as graphics cards become dominant.  I'm surprised this
hasn't already happened, FWIW.  We should be writing software like Tom
Cruise's character in Minority Report was wielding data -- drag and drop,
automatic look-ahead providing assumptions based on usage patterns, so
that we can use/re-use what the computer is providing for us.  We have
a long way to go, though I doubt very seriously we'll ever get there
before Jesus returns.

> The best way to avoid multi-line macros is to minimise the use of macros
> at all, such as by using static inline functions where possible.

I am writing a compiler.  It mandates I flush out the support fully,
regardless of how often it's used.  And RDC will still support \ forms,
but I want to provide an alternative.

> And if you really want to avoid the multi-line macros, you could always
> switch to C++ where there are several alternatives (such as templates)
> that greatly reduce the need for complex macros.

Never happen.  The day I am forced to use a C++ compiler for actual C++
code (and not just "relaxed C-like" code), I will switch to another
profession and never look back.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70881

On Friday, 18 September 2015 13:28:37 UTC+1, Rick C. Hodgin  wrote:
> On Friday, September 18, 2015 at 8:13:17 AM UTC-4, David Brown wrote:
> > On 18/09/15 08:20, Rick C. Hodgin wrote:
> > > wss...@gmail.com wrote:
> > >> Can you explain what you are trying to do
> > >> that is not done by the usual:
> > > 
> > > Not have the \ characters for continuation, but
> > > still define a multi-line macro.
> 
> I am looking for a syntax in C which is not the trailing \ character.

No - you are looking for a syntax in cpp, which is only loosely related to C 
syntax, for this. As the C preprocessor is line-based (where '\' simply allows
line continuation) I doubt you are likely to find one.

> I do not think it exists, but the rest is just my thinking on how it
> should be (will be) done for RDC.

[toc] | [prev] | [next] | [standalone]

#70883

On Friday, September 18, 2015 at 8:43:55 AM UTC-4, mark.b...@gmail.com wrote:
> On Friday, 18 September 2015 13:28:37 UTC+1, Rick C. Hodgin  wrote:
> > I am looking for a syntax in C which is not the trailing \ character.
> 
> No - you are looking for a syntax in cpp, which is only loosely related to C 
> syntax, for this. As the C preprocessor is line-based (where '\' simply allows
> line continuation) I doubt you are likely to find one.

Thank you, Mark!

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70890

mark.bluemel@gmail.com writes:
[...]
> No - you are looking for a syntax in cpp, which is only loosely
> related to C syntax, for this. As the C preprocessor is line-based
> (where '\' simply allows line continuation) I doubt you are likely to
> find one.
  
Correct, but I wouldn't quite put it that way.

The syntax of the C preprocessor is intimately related to C syntax.
In fact, it's part of it.  It's a part that's quite different
from the rest of C's syntax (for example it's line-oriented
vs. token-oriented), and it's described in its own subsection of
the standard, but it's still part of C.

A macro definition must be on one logical source line (N1570 6.10p2).
The only way to form a logical source line from multiple physical
source lines is by using the \ continuation character (5.1.1.2,
translation phase 2, line splicing).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#71249

Keith Thompson <kst-u@mib.org> writes:

> [discussing the relationship of C syntax to C preprocessor syntax]
>
> A macro definition must be on one logical source line (N1570 6.10p2).
> The only way to form a logical source line from multiple physical
> source lines is by using the \ continuation character (5.1.1.2,
> translation phase 2, line splicing).

Somewhere along here the reasoning goes astray, probably because
phase 3 is done in between phase 2 and phase 4:

    #define foo (  /*
    */   a         /*
    */   +         /*
    */   b         /*
    */)

[toc] | [prev] | [next] | [standalone]

#70917

Rick C. Hodgin wrote:
> 
> I am looking for a syntax in C which is not the trailing \ character.
> I do not think it exists, but the rest is just my thinking on how it
> should be (will be) done for RDC.
> 
> David Brown wrote:
> > The trailing \ is somewhat ugly, but it's not /that/ bad.  It is
> > certainly much less bad than having to add annotations like
> > "ignore_leading_whitespaces".

The ignore leading and trailing whitespace annotations are actually 
unnecessary, since leading and trailing whitespace are never significant 
in macro expansions anyway.

> The GUI editor would never see it.  And if someone ever did have to dip
> down into raw text-based source code, it would be completely clear what
> is going on there, even to someone who does not know RDC.

If the GUI hides the ugliness from the user, then why not just continue 
to use \ in the underlying source? Then the underlying source is 
completely clear, even to us old fogeys, in case anyone does have to 
look at it.

[toc] | [prev] | [next] | [standalone]

#70928

On Saturday, September 19, 2015 at 3:33:02 AM UTC-4, Philip Lantz wrote:
> The ignore leading and trailing whitespace annotations are actually 
> unnecessary, since leading and trailing whitespace are never significant 
> in macro expansions anyway.

They are significant in RDC.

> > The GUI editor would never see it.  And if someone ever did have to dip
> > down into raw text-based source code, it would be completely clear what
> > is going on there, even to someone who does not know RDC.
> 
> If the GUI hides the ugliness from the user, then why not just continue 
> to use \ in the underlying source? Then the underlying source is 
> completely clear, even to us old fogeys, in case anyone does have to 
> look at it.

It hides the ugliness from the user, but there are occasions where it
will be seen.  Even the GUI editors I propose will have a "RawView"
mode where the raw text file is seen, and can be edited as is, even
if incorrect syntax is introduced.

RDC is a LiveCode environment (edit-and-continue), so any errors which
exist in code result in something I call an inquiry, where the program
suspends to a point where the errant condition generating the inquiry
can be corrected, and the code resumed.  As such, all programs will
compile and run with RDC, but some of them may immediately generate
an inquiry if main() isn't defined, for example.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70931

Rick C. Hodgin wrote:
> Philip Lantz wrote:
> > The ignore leading and trailing whitespace annotations are actually 
> > unnecessary, since leading and trailing whitespace are never significant 
> > in macro expansions anyway.
> 
> They are significant in RDC.

I'm curious in what context this would arise. Can you give an example 
where leading and/or trailing whitespace in a macro expansion are 
significant?

[toc] | [prev] | [next] | [standalone]

#70933

On Saturday, September 19, 2015 at 3:50:12 PM UTC-4, Philip Lantz wrote:
> Rick C. Hodgin wrote:
> > Philip Lantz wrote:
> > > The ignore leading and trailing whitespace annotations are actually 
> > > unnecessary, since leading and trailing whitespace are never significant 
> > > in macro expansions anyway.
> > 
> > They are significant in RDC.
> 
> I'm curious in what context this would arise. Can you give an example 
> where leading and/or trailing whitespace in a macro expansion are 
> significant?

They pass thru in source code transformations which are debuggable in
RDC.  They have significance in their human-readable form only, and
in the ultimate syntax they would convey, such that the example earlier
in this thread regarding "printf" being on multiple lines, would
actually evaluate to [p][whitespace][r][whitespace]..." in RDC, which
would be visible in the transformations.

RDC records each line's source code as it was loaded, after each
macro expansion, and then through to its final generated form as by
the assembly language generation.  This allows a fully debuggable
environment, and since it's LiveCode, you can see the full expansion
of your macro as you're writing source code right before your eyes.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70919

In article <31993891-4970-43d5-9651-e4be76e7bee8@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
...
>Never happen.  The day I am forced to use a C++ compiler for actual C++
>code (and not just "relaxed C-like" code), I will switch to another
>profession and never look back.

You could try preaching, which seems to be more your forte anyway.

You'd be much happier.

-- 
Shikata ga nai...

[toc] | [prev] | [next] | [standalone]

#70880

On 9/18/15 2:20 AM, Rick C. Hodgin wrote:
> wss...@gmail.com wrote:
>> Can you explain what you are trying to do
>> that is not done by the usual:
>
> Not have the \ characters for continuation, but
> still define a multi-line macro.
>
> Best regards,
> Rick C. Hodgin
>


Rick, based on you answers to other things, I think the best solution is 
like you say you do with your cask notation, and fix the appearance in 
the editor. It is easily detectable, so an editor could easily change 
the appearance to be what you want, allowing you to not need to change 
core features of the language (which I don't think you have the 
background to understand the full impact of the changes).

[toc] | [prev] | [next] | [standalone]

#70882

On Friday, September 18, 2015 at 8:38:49 AM UTC-4, Richard Damon wrote:
> On 9/18/15 2:20 AM, Rick C. Hodgin wrote:
> > wss...@gmail.com wrote:
> >> Can you explain what you are trying to do
> >> that is not done by the usual:
> >
> > Not have the \ characters for continuation, but
> > still define a multi-line macro.
> 
> Rick, based on you answers to other things, I think the best solution is 
> like you say you do with your cask notation, and fix the appearance in 
> the editor. It is easily detectable, so an editor could easily change 
> the appearance to be what you want, allowing you to not need to change 
> core features of the language (which I don't think you have the 
> background to understand the full impact of the changes).

Perhaps not, Richard.  I will pray, however, that nothing melts down
when I switch to the RDC syntax.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70875

In article <b8ac44d9-8939-4a5d-9921-aa986687d3c6@googlegroups.com>,
 <wssimms@gmail.com> wrote:
...
>Is your question practical, or more a rhetorical question leading into
>how you think things ought to work in some hypothetical not-C language?

Seeing as it is RCH, I would assume the later.

-- 
Ted Cruz sounds like every straight man's first wife.

[toc] | [prev] | [next] | [standalone]

#70887

On 18/09/2015 01:50, Rick C. Hodgin wrote:
> Is there a C syntax, or variant of C syntax in use, which allows multi-
> line defines to be enclosed in standard braces, such that something
> like this...:
>
>       #define abc line1\
>       line2\
>       line3
>
> ...is translated to be the same as something like this:
>
>       #define abc {line1
>       line2
>       line3}
>
> And specifically I am considering something more human readable...:
>
>       #define abc {
>           line1
>           line2
>           line3
>       } ignore_leading_whitespaces, ignore_leading_feeds, ignore_trailing_feeds;

Forget C or C variants (which you don't want to be tied down to anyway). 
Invent a suitable new syntax, eg:

#mdefine name(args)
  line1
  line2
  line3
#enddefine

This is then processed with the simplest of translation tools to result 
in conventional C containing this:

#define name(args) \
line1\
line2\
line3\
         // [blank line]

(The blank line helps preserve line numbers with the original, as well 
as simplifying the logic by allowing \ on the last line.)

It's harder to end the block with "}", because that means having a 
complete C syntax analyser within the translation tool.

(Here's some rather clunky pseudo-code to do such a translation on a 
input file: http://pastebin.com/TMZa4UwR. No doubt it would be a 
one-liner in a more apt scripting language, or in 'sed'. The point is, 
it's simpler than changing the language and then changing every compiler 
on the planet.)

> ...which in RDC syntax would be:
>
>       #define abc
>       | ignore_leading_whitespaces
>       | ignore_leading_feeds
>       | ignore_trailing_feeds
>       {
>           line1
>           line2
>           line3
>       };

This won't work in general. Macro-bodies are not necessarily 
well-formed, so you don't know if that final }, or }, is part of the 
definition or not. Also, in C, it wouldn't be able to tell if this is 
defining a blank macro called "abc", or a multi-line one.

This new language might have its own rules, but anyone looking at 
'#define abc' by itself might well assume that it does what C does.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#70888

On Friday, September 18, 2015 at 9:32:56 AM UTC-4, Bart wrote:
> On 18/09/2015 01:50, Rick C. Hodgin wrote:
> > Is there a C syntax, or variant of C syntax in use, which allows multi-
> > line defines to be enclosed in standard braces, such that something
> > like this...:
> >
> >       #define abc line1\
> >       line2\
> >       line3
> >
> > ...is translated to be the same as something like this:
> >
> >       #define abc {line1
> >       line2
> >       line3}
> >
> > And specifically I am considering something more human readable...:
> >
> >       #define abc {
> >           line1
> >           line2
> >           line3
> >       } ignore_leading_whitespaces, ignore_leading_feeds, ignore_trailing_feeds;
> 
> Forget C or C variants (which you don't want to be tied down to anyway). 
> Invent a suitable new syntax, eg:
> 
> #mdefine name(args)
>   line1
>   line2
>   line3
> #enddefine
> 
> This is then processed with the simplest of translation tools to result 
> in conventional C containing this:
> 
> #define name(args) \
> line1\
> line2\
> line3\
>          // [blank line]
> 
> (The blank line helps preserve line numbers with the original, as well 
> as simplifying the logic by allowing \ on the last line.)
> 
> It's harder to end the block with "}", because that means having a 
> complete C syntax analyser within the translation tool.
> 
> (Here's some rather clunky pseudo-code to do such a translation on a 
> input file: http://pastebin.com/TMZa4UwR. No doubt it would be a 
> one-liner in a more apt scripting language, or in 'sed'. The point is, 
> it's simpler than changing the language and then changing every compiler 
> on the planet.)
> 
> > ...which in RDC syntax would be:
> >
> >       #define abc
> >       | ignore_leading_whitespaces
> >       | ignore_leading_feeds
> >       | ignore_trailing_feeds
> >       {
> >           line1
> >           line2
> >           line3
> >       };
> 
> This won't work in general. Macro-bodies are not necessarily 
> well-formed, so you don't know if that final }, or }, is part of the 
> definition or not. Also, in C, it wouldn't be able to tell if this is 
> defining a blank macro called "abc", or a multi-line one.
> 
> This new language might have its own rules, but anyone looking at 
> '#define abc' by itself might well assume that it does what C does.
> 
> -- 
> Bartc

I like the idea of an #mdefine and #endmdefine.  I will adopt it.
Thank you, Bart.

I also still plan on providing support for C's syntax on macros.
Probably not to the standard because there are things about it I
don't know, but probably sufficiently to the standard for most
programs to work, and for those that don't my design will probably
be flexible enough to allow the fix to be easily added later.  And
if not, well there are many C compilers to choose from. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#70896

Well good grief, if you are designing your own
language why not just do something like:

define macro abc
begin
        Line 1
        Line 2
        Line 3
end

What's the advantage of having it look
"kinda sorta" like C?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web