A preprocessor feature we should have had 40 years ago

[Paul D. DeRocco]

This is going to the C and C++ lists because it is equally applicable to
both.

I've occasionally needed to use the preprocessor to repeat a piece of
code some variable number of times. What would be so hard about
implementing this?

#repeat <identifier> <const-expression>
...
#endrepeat

The expression would be evaluated, and the contents of the block would
be repeated that number of times, with the preprocessor identifier
taking values 0 through n-1. Even with a fixed count, this can be useful:

const int squares[] = {
#repeat I 101
I * I,
#endrepeat
};

Less trivial usages would of course involve counts that are themselves
preprocessor symbols or expressions. The only way to do this now is to
nest a lot of #if statements, up to some maximum size one might need,
and explicitly write the contents of each iteration.

--

Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com


[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Francis Glassborow]

On 26/05/2013 07:43, Rui Maciel wrote:

> Paul D. DeRocco wrote:
>
>> This is going to the C and C++ lists because it is equally applicable to
>> both.
>>
>> I've occasionally needed to use the preprocessor to repeat a piece of
>> code some variable number of times. What would be so hard about
>> implementing this?
>>
>> #repeat <identifier> <const-expression>
>> ...
>> #endrepeat
>>
>> The expression would be evaluated, and the contents of the block would
>> be repeated that number of times, with the preprocessor identifier
>> taking values 0 through n-1. Even with a fixed count, this can be useful:
>>
>> const int squares[] = {
>> #repeat I 101
>> I * I,
>> #endrepeat
>> };
>>
>> Less trivial usages would of course involve counts that are themselves
>> preprocessor symbols or expressions. The only way to do this now is to
>> nest a lot of #if statements, up to some maximum size one might need,
>> and explicitly write the contents of each iteration.
>

> What's wrong with using for() loops? Compilers are able to unroll loops for
> some time now.
>
>


Indeed the proposal looks very much like trying to deal with a circa
1980s' problem with a solution from the same era.

In addition the C++11 constexpr could address some problems and I seem
to remember that C++14 will extend the range of constructs permitted
within a constexpr.

Francis

[Peter]

On May 23, 8:20 pm, "Paul D. DeRocco" <pdero...@ix.netcom.com> wrote:
> This is going to the C and C++ lists because it is equally applicable to
> both.
>
> I've occasionally needed to use the preprocessor to repeat a piece of
> code some variable number of times. What would be so hard about
> implementing this?
>
> #repeat <identifier> <const-expression>
> ...
> #endrepeat
>
> The expression would be evaluated, and the contents of the block would
> be repeated that number of times, with the preprocessor identifier
> taking values 0 through n-1. Even with a fixed count, this can be useful:

<snip>

Over many years, I have heard two main arguments against this kind of
feature.

The first is the "slippery slope" argument. Where do you stop? What
about a preprocessor-while statement? A preprocessor-for statement?
Arithmetic statements? A library of string functions? A library of
arithmetic functions? User-written preprocessor functions? Etc, etc.
Over the years I have had occasions where all of these would have been
useful. It would be very hard to draw a line, but all the imaginable
and useful features could result in a mess.

The second argument is, if you want that, you can create it. In many,
if not most, programming environments, it would be simple to insert a
customized preprocessor into the compilation sequence. You just have
to write it, and use it. There are in fact a few extended
preprocessors out there. I have had occasion to use tools like 'sed'
as a preprocessor.

The fact that such tools aren't widely used could be taken as a sign
that they aren't wanted, or as a sign that a non-standardized tool is
not going to catch on. If you believe the latter, you can get involved
with The Committee and try to make it happen.


--

[Paul D. DeRocco]

> On 5/30/2013 6:40 PM, Peter wrote:
>
>
> Over many years, I have heard two main arguments against this kind of
> feature.
>
> The first is the "slippery slope" argument. Where do you stop? What
> about a preprocessor-while statement? A preprocessor-for statement?
> Arithmetic statements? A library of string functions? A library of
> arithmetic functions? User-written preprocessor functions? Etc, etc.
> Over the years I have had occasions where all of these would have been
> useful. It would be very hard to draw a line, but all the imaginable
> and useful features could result in a mess.

A simple 0 to n-1 count seems like a likely stopping point. (My more
fanciful string-to-char iterator is perhaps a bridge too far.) A
"while" construct doesn't make much sense, since there is nothing that
can change value in an unpredictable manner in the preprocessor, and
that therefore can't be boiled down to a simple count.

> The second argument is, if you want that, you can create it. In many,
> if not most, programming environments, it would be simple to insert a
> customized preprocessor into the compilation sequence. You just have
> to write it, and use it. There are in fact a few extended
> preprocessors out there. I have had occasion to use tools like 'sed'
> as a preprocessor.

That creates a barrier to distribution, because you can no longer just
ship some .cpp and .h files; you also have to ship either an
executable tool for whatever platform someone might wish to compile
the program with, or source for the executable tool; and then you have
to provide a customized makefile for the program that includes the
appropriate rule, which presumes the use of a particular make utility
since they're not standardized the way the language is.

Oh, well.

--

Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com

[James Kuyper]

On 06/01/2013 04:04 AM, Paul D. DeRocco wrote:
...

> the program with, or source for the executable tool; and then you have
> to provide a customized makefile for the program that includes the
> appropriate rule, which presumes the use of a particular make utility
> since they're not standardized the way the language is.

Some make utilities are standardized; POSIX make, for instance. Of
course, that won't do you much good if your target platform doesn't
conform to POSIX, but it's not the absence of a standard that's the
problem; it's the fact that many systems haven't adopted it.


--