Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Macros

Reply
Thread Tools

Macros

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      12-03-2012
"BartC" <(E-Mail Removed)> writes:

> "Joe Pfeiffer" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ...

<snip>
>> 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.


You should have given up in it for it for other reasons, as you solution
illustrates perfectly: if syntax-disrupting macros are ever used, you
can't implement a simple syntax converter without either implementing a
full C pre-processor or running the source though one first. The former
is tedious and the latter makes it hard to keep things readable.

There is a fine tradition (on Unix at least) of writing what have become
know as "little languages" -- small syntax layers over a low-level
language to produce a higher-level one (ratfor and grap spring to mind,
but I am sure there are others) so you are in good company with this
solution. Lex and YACC were supposed to make this easy but they never
quite made it trivial (I'm looking forward to Perl 6 for this purpose).

<snip>
--
Ben.
 
Reply With Quote
 
 
 
 
Edward A. Falk
Guest
Posts: n/a
 
      12-04-2012
In article <k9g8c9$4sd$(E-Mail Removed)>,
James Kuyper <(E-Mail Removed)> wrote:
>>
>> You are violating standards here.
>> You may not use language keywords as macro names.

>
>Citation, please?


Hardly matters. Unless you're entering the obfuscated C programming
contest, doing this is a double-plus ungood idea, standard or no standard.

--
-Ed Falk, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      12-05-2012
On 12/04/2012 06:59 PM, Edward A. Falk wrote:
> In article <k9g8c9$4sd$(E-Mail Removed)>,
> James Kuyper <(E-Mail Removed)> wrote:
>>>
>>> You are violating standards here.
>>> You may not use language keywords as macro names.

>>
>> Citation, please?

>
> Hardly matters. Unless you're entering the obfuscated C programming
> contest, doing this is a double-plus ungood idea, standard or no standard.


It don't like the idea of doing it, but I also don't like saying
incorrect things about what does and does not violate the requirements
of the standard. Using language keywords does not violate any
requirements imposed by the C standard. Code which does such things
might be hard to read and understand, but it has well-defined behavior
according to the C standard (unless some other feature of the program is
problematic).


 
Reply With Quote
 
Heikki Kallasjoki
Guest
Posts: n/a
 
      12-05-2012
On 2012-12-05, James Kuyper <(E-Mail Removed)> wrote:
> On 12/04/2012 06:59 PM, Edward A. Falk wrote:
>> In article <k9g8c9$4sd$(E-Mail Removed)>,
>> James Kuyper <(E-Mail Removed)> wrote:
>>>>
>>>> You are violating standards here.
>>>> You may not use language keywords as macro names.
>>>
>>> Citation, please?

>>
>> Hardly matters. Unless you're entering the obfuscated C programming
>> contest, doing this is a double-plus ungood idea, standard or no standard.

>
> It don't like the idea of doing it, but I also don't like saying
> incorrect things about what does and does not violate the requirements
> of the standard. Using language keywords does not violate any
> requirements imposed by the C standard. Code which does such things
> might be hard to read and understand, but it has well-defined behavior
> according to the C standard (unless some other feature of the program is
> problematic).


There is, however, a slightly related rule in the standard about
keywords as macro names; one that might even be the source of the
(common?) belief stated above.

The program shall not have any macros with names lexically identical
to keywords currently defined prior to the inclusion of [any standard]
header or when any macro defined in the header is expanded.
(N1570 7.1.2p4)

It's not an outright ban, but it is a limitation.

--
Heikki Kallasjoki
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-05-2012
On 12/4/2012 7:14 PM, James Kuyper wrote:
> On 12/04/2012 06:59 PM, Edward A. Falk wrote:
>> In article <k9g8c9$4sd$(E-Mail Removed)>,
>> James Kuyper <(E-Mail Removed)> wrote:
>>>>
>>>> You are violating standards here.
>>>> You may not use language keywords as macro names.
>>>
>>> Citation, please?

>>
>> Hardly matters. Unless you're entering the obfuscated C programming
>> contest, doing this is a double-plus ungood idea, standard or no standard.

>
> It don't like the idea of doing it, but I also don't like saying
> incorrect things about what does and does not violate the requirements
> of the standard. Using language keywords does not violate any
> requirements imposed by the C standard. [...]


7.1.2p4: "[...] The program shall not have any macros with
names lexically identical to keywords currently defined prior to
the inclusion of the header or when any macro defined in the header
is expanded."

So, yes: You *can* #define `if' or `void' or `case' et al., but
only in restricted circumstances:

#define int wuzzat
#include <stdio.h> // BZZZT!

#include <stdio.h>
#define int wuzzat
size_t whiffle = BUFSIZ; // BZZZT!

#include <setjmp.h>
#define int wuzzat
...
switch(setjmp(buf)) { // BZZZT!


#include <math.h>
#define int wuzzat
...
return sin(x); // BZZZT! (`(sin)(x)' would be OK)

Here's what I know: Anyone who engaged in this sort of thing,
even in formally permissible contexts, might not be fired after
the code review. He would, however, become a figure of fun and
an object of scorn, the butt of continuing jokes. (Did I mention
"companion of owls?" Probably best that I didn't.)

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-05-2012
On 12/04/2012 07:58 PM, Heikki Kallasjoki wrote:
> On 2012-12-05, James Kuyper <(E-Mail Removed)> wrote:

....
>> requirements imposed by the C standard. Code which does such things
>> might be hard to read and understand, but it has well-defined behavior
>> according to the C standard (unless some other feature of the program is
>> problematic).

>
> There is, however, a slightly related rule in the standard about
> keywords as macro names; one that might even be the source of the
> (common?) belief stated above.
>
> The program shall not have any macros with names lexically identical
> to keywords currently defined prior to the inclusion of [any standard]
> header or when any macro defined in the header is expanded.
> (N1570 7.1.2p4)
>
> It's not an outright ban, but it is a limitation.


Yes, it is a limitation, but an avoidable one. With respect to my
earlier statement, violation of that limitation counts as "some other
feature of the program" that "is problematic".


--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-05-2012
On 12/04/2012 08:03 PM, Eric Sosman wrote:
....
> Here's what I know: Anyone who engaged in this sort of thing,
> even in formally permissible contexts, might not be fired after
> the code review. He would, however, become a figure of fun and
> an object of scorn, the butt of continuing jokes. (Did I mention
> "companion of owls?" Probably best that I didn't.)


That seems reasonable. I never defended is a good idea, I only objected
to the incorrect explanation of what was wrong with it.
--
James Kuyper
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      12-05-2012
James Kuyper <(E-Mail Removed)> writes:
> On 12/04/2012 08:03 PM, Eric Sosman wrote:
> ...
> > Here's what I know: Anyone who engaged in this sort of thing,
> > even in formally permissible contexts, might not be fired after
> > the code review. He would, however, become a figure of fun and
> > an object of scorn, the butt of continuing jokes. (Did I mention
> > "companion of owls?" Probably best that I didn't.)

>
> That seems reasonable. I never defended is a good idea, I only objected
> to the incorrect explanation of what was wrong with it.


And I'm glad you did. This has been an educational sub-thread.

To be frank, it might have been simpler if the standard had just
banned it outright, but that's just bikeshedding.

Phil
--
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      12-09-2012
On Dec 2, 10:55*pm, "BartC" <(E-Mail Removed)> wrote:
> "BartC" <(E-Mail Removed)> wrote in message
>
> news:bmOus.898237$(E-Mail Removed)4...
>
> > "Öö Tiib" <(E-Mail Removed)> 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.)


Perl

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
macros-loop? calling macros X times? Andrew Arro C Programming 2 07-24-2004 09:52 AM
Explanation of macros; Haskell macros mike420@ziplip.com Python 80 11-07-2003 02:22 AM
Re: Explanation of macros; Haskell macros Michael T. Babcock Python 0 11-03-2003 01:54 PM
Re: Explanation of macros; Haskell macros mike420@ziplip.com Python 5 11-01-2003 01:09 AM
Re: Explanation of macros; Haskell macros mike420@ziplip.com Python 1 10-07-2003 04:07 PM



Advertisments