[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Macro Code-Generation Too Ugly?

Shao Miller

5/8/2011 3:03:00 AM

Good day to all.

In another C-devoted forum, there appeared to be consensus that using
macros to automatically expand as code for serializing and deserializing
and defining structures was not worth the trade-off between redundancy
and legibility.

This is a quick poll of opinion here, if you please.

Some advantages:
- All source remains within the scope of C
- Less typing

Some disadvantages:
- More challenging for humans to interpret
- Partial C parsers such as IDEs won't likely be able to determine
structure definitions and definition locations

As quick example:

#define M_TEST(B_, U_, T_, N_, D_, E_) \
\
B_(test) \
U_(T_(M_SER_TD_BE_U16), N_(alpha), D_("The alpha member")) \
U_(T_(M_SER_TD_BE_U8), N_(beta), D_("The beta member")) \
U_(T_(M_SER_TD_BE_U32), N_(gamma), D_("The gamma member")) \
E_

which could be expanded by various macros into various declarations,
definitions, and statements. Is that just way too ugly?

A suggestion was that a specification file could be easier to read and
another tool could auto-generate C source code. An enhancement of that
suggestion was that the spec. file could even resemble C! If so, what
might be a pleasant way to mark up a struct definition with meta-data?
Would something like:

struct foo {
SERIALIZE_WITH_MEMCPY char some_array[20];
SERIALIZE_AS_BEUINT32 uint32_t some_uint;
};

be pleasant? Or what about:

struct foo {
char __XXX(SERIALIZE_WITH_MEMCPY) some_array[20];
uint32_t __XXX(SERIALIZE_WITH_MEMCPY) some_uint;
};

? What do you think? Thanks! :)
8 Answers

Ian Collins

5/9/2011 2:23:00 AM

0

On 05/ 8/11 03:02 PM, Shao Miller wrote:
> Good day to all.
>
> In another C-devoted forum, there appeared to be consensus that using
> macros to automatically expand as code for serializing and deserializing
> and defining structures was not worth the trade-off between redundancy
> and legibility.
>
> This is a quick poll of opinion here, if you please.
>
> Some advantages:
> - All source remains within the scope of C
> - Less typing
>
> Some disadvantages:
> - More challenging for humans to interpret
> - Partial C parsers such as IDEs won't likely be able to determine
> structure definitions and definition locations

It must have been a sensible forum. Code generation is the way to go.

With code generation both the specification and the resulting code
(should you have to debug it) are human readable.

--
Ian Collins

Francois Grieu

5/9/2011 8:28:00 AM

0

On 08/05/2011 05:02, Shao Miller wrote:
>
> In another C-devoted forum, there appeared to be consensus that using macros to automatically expand as code for serializing and deserializing and defining
> structures was not worth the trade-off between redundancy and legibility.

I recently tried to raise interest on that here with
"Serialisation/deserialisation of argument/results",
with little success.


> This is a quick poll of opinion here, if you please.
>
> Some advantages:
> - All source remains within the scope of C
> - Less typing

- Easiest to port.
- not so frontally yet-another-language

> Some disadvantages:
> - More challenging for humans to interpret
> - Partial C parsers such as IDEs won't likely be able to determine structure definitions and definition locations

- When things get more complex than fixed-size fields,
(e.g. the size of a field depends on the value of
another field), it gets ugly.


I think both methods are preferable to the one I currently wrestle
with: hand-generated serialization/de-serialization code.

Francois Grieu

Ben Bacarisse

5/9/2011 1:25:00 PM

0

Francois Grieu <fgrieu@gmail.com> writes:

> On 08/05/2011 05:02, Shao Miller wrote:
>>
>> In another C-devoted forum, there appeared to be consensus that using macros to automatically expand as code for serializing and deserializing and defining
>> structures was not worth the trade-off between redundancy and legibility.
>
> I recently tried to raise interest on that here with
> "Serialisation/deserialisation of argument/results",
> with little success.

It depends how you interpret the mixture of response and silence that
you got! My reading would be that there is an almost universal view
that some sort of extended type description plus automatic code
generation is the way to go. The fact that no one suggested a way to do
this using the C pre-processor suggests that it is not considered to
viable in the general case.

You posed a very general question, and that gave rise to very general
answers, so it is possible that you are dealing with some limited case
that makes PP driven code generation look viable, but that did not come
out of your original posting.

>> This is a quick poll of opinion here, if you please.
>>
>> Some advantages:
>> - All source remains within the scope of C
>> - Less typing
>
> - Easiest to port.
> - not so frontally yet-another-language

Other methods can be quite easy to port. For example, an interface
processor written in standard C is not likely to be any less portable
than the code it generates.

>> Some disadvantages:
>> - More challenging for humans to interpret

I think this is a very strong objection. C macro code does not scale
well in my experience. It can be very hard to maintain above a certain
degree of complexity.

>> - Partial C parsers such as IDEs won't likely be able to determine structure definitions and definition locations
>
> - When things get more complex than fixed-size fields,
> (e.g. the size of a field depends on the value of
> another field), it gets ugly.

<snip>
--
Ben.

Shao Miller

5/9/2011 4:34:00 PM

0

On 5/9/2011 3:27 AM, Francois Grieu wrote:
> On 08/05/2011 05:02, Shao Miller wrote:
>>
>> In another C-devoted forum, there appeared to be consensus that using
>> macros to automatically expand as code for serializing and
>> deserializing and defining
>> structures was not worth the trade-off between redundancy and legibility.
>
> I recently tried to raise interest on that here with
> "Serialisation/deserialisation of argument/results",
> with little success.

I'll try to find your thread; thanks.

Well I think that some of that macro stuff can look pretty ugly, indeed!
Perhaps not _too_ ugly, but that's why I appreciate the opinions.

>
>
>> This is a quick poll of opinion here, if you please.
>>
>> Some advantages:
>> - All source remains within the scope of C
>> - Less typing
>
> - Easiest to port.
> - not so frontally yet-another-language
>

Aha. :)

>> Some disadvantages:
>> - More challenging for humans to interpret
>> - Partial C parsers such as IDEs won't likely be able to determine
>> structure definitions and definition locations
>
> - When things get more complex than fixed-size fields,
> (e.g. the size of a field depends on the value of
> another field), it gets ugly.
>

Yes, the fixed-size thing seem relatively easy.

>
> I think both methods are preferable to the one I currently wrestle
> with: hand-generated serialization/de-serialization code.

For what it's worth, here's the toy that prompted me to ask,
essentially, if it was a worth-while direction to pursue... Assuming
you have git, bash, gcc, you could try:

git clone http://git.zytor.com/users/sha0/seri... cd
serialize; bash ./build.sh; ./sdeftest

With any luck, there isn't much UB so it shouldn't hurt your files or
pets. :)

But still, I'm curious as to what might be a pleasant way to "mark up" C
struct definitions which could be used by another tool to auto-generate
code. I think that such a strategy would be less "frontally
yet-another-language," too.

Shao Miller

5/9/2011 4:38:00 PM

0

On 5/8/2011 9:23 PM, Ian Collins wrote:
> On 05/ 8/11 03:02 PM, Shao Miller wrote:
>> Good day to all.
>>
>> In another C-devoted forum, there appeared to be consensus that using
>> macros to automatically expand as code for serializing and deserializing
>> and defining structures was not worth the trade-off between redundancy
>> and legibility.
>>
>> This is a quick poll of opinion here, if you please.
>>
>> Some advantages:
>> - All source remains within the scope of C
>> - Less typing
>>
>> Some disadvantages:
>> - More challenging for humans to interpret
>> - Partial C parsers such as IDEs won't likely be able to determine
>> structure definitions and definition locations
>
> It must have been a sensible forum. Code generation is the way to go.
>

Thanks for the opinion. :)

Speaking of which, if using macro expansion and GCC, one can -save-temps
and then the .i files are essentially the generated code. Heheh.
Regardless of that, a spec. file for use with a code generating tool
could certainly be easier to read than wild macros.

> With code generation both the specification and the resulting code
> (should you have to debug it) are human readable.
>

Agreed!

luserXtrog

5/10/2011 7:15:00 AM

0

On May 9, 8:24 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Francois Grieu <fgr...@gmail.com> writes:
> > On 08/05/2011 05:02, Shao Miller wrote:
>

> >> Some disadvantages:
> >> - More challenging for humans to interpret
>
> I think this is a very strong objection.  C macro code does not scale
> well in my experience.  It can be very hard to maintain above a certain
> degree of complexity.

Is this a specific fault of cpp or is it intrinsic to macro-processing
in general?
At what point do you need to make a little language?

Ben Bacarisse

5/10/2011 11:20:00 AM

0

luser- -droog <mijoryx@yahoo.com> writes:

> On May 9, 8:24 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Francois Grieu <fgr...@gmail.com> writes:
>> > On 08/05/2011 05:02, Shao Miller wrote:
>>
>
>> >> Some disadvantages:
>> >> - More challenging for humans to interpret
>>
>> I think this is a very strong objection.  C macro code does not scale
>> well in my experience.  It can be very hard to maintain above a certain
>> degree of complexity.
>
> Is this a specific fault of cpp or is it intrinsic to macro-processing
> in general?

A part of it is intrinsic to macro processing in general -- especially
in those where expansion can yield text that is re-parsed (rather than
just re-expanded). Token-based macro processors (like C's) are a little
better but then C's PP lacks a general syntax to quote and group items
so complex cpp code often ends up using all sorts of tricks. They are
not (at least to me) very readable.

> At what point do you need to make a little language?

Ah, that's a tough call. When Perl 6 is finished the balance will
change.

--
Ben.

Mark Bluemel

5/10/2011 11:32:00 AM

0

On 05/10/2011 12:20 PM, Ben Bacarisse wrote:
> luser- -droog<mijoryx@yahoo.com> writes:

>> At what point do you need to make a little language?
>
> Ah, that's a tough call. When Perl 6 is finished the balance will
> change.

Is that due before or after I receive my flying car and nuclear fusion
makes electricity too cheap to meter?