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

Groups > comp.std.c++ > #625

Re: A preprocessor feature we should have had 40 years ago

Show all headers | View raw

> On 5/25/2013 2:24 AM, Keith Thompson wrote:
>
>
> No, that's not the *only* way to do that.  You could write another
> program that generates C source code from an input file in some well
> defined format.  That format could even be standard C source with the
> addition of a "#repeat" directive recognized by the program.  Make it
> part of your build process, and voila, you have a #repeat directive.


Sure, but that's not doing it IN C/C++. And that requires a learning
curve if you want to figure out how to integrate it into Eclipse, or
Visual Studio, or Codewarrior, since normally one uses an IDE without
learning the ugly details about how its configured. And to give the
project to someone else, you have to provide the executable for that
extra tool, not just a project file and a bunch of source code.

> In my opinion, the need to have simply repeated lines of code like
> that is rare enough that it doesn't justify adding a new feature
> to the preprocessor and to the language standard.


I found I needed it recently, in order to build the descriptor tables
for a USB driver that I wanted to parameterize by the number of
endpoints. Since they had to be in flash, they had to be written as
constant tables. Then, in perusing the Atmel library, I discovered
that they, too, had come up against the same sort of thing, and had
used a big tree of #if blocks too.

> I wouldn't have *opposed* adding such a feature to the preprocessor
> from the beginning, but I think adding it now would cause more
> trouble than it's really worth, as new code that depends on it would
> fail to compile on pre-C20XY compilers.  (Which is admittedly an
> argument against adding *anything* to the language.)


It seems like the C++ community is generally open to useful additions
to the language, more so than the C community. Look at all the arcana
added since C++98. Furthermore, it seems like the GNU community is
even more open to extensions that go beyond what the standards
provide. Yet no one seems interested in the lowly preprocessor, even
though it hasn't been touched in decades. Besides, no new feature
"causes trouble" unless it introduces an incompatibility, which it
never should. If you don't use it, you don't notice it's there. I was
just hoping someone else would find this useful.

By the way, this particular extension could also be extended to
iterate through the characters of a string constant, something I've
needed to do a couple of times. Another trivial example:

    #define NAME "foobar" // e.g., in an include file

    const char name[] = NAME;
    const char ucase_name[] = {
        #repeat c NAME
        c < 'a' ? c : c <= 'z' ? c - 0x20 : c,
        #endrepeat
        0 };

In desktop environments, these issues don't generally come up, because
they all run entirely out of RAM, and expect to use extensive init
code anyway, so variable-sized tables can be built at runtime in
containers. In embedded environments, though, you often need to put
stuff in ROM, which these constructs would make a lot easier.

--

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


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

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

A preprocessor feature we should have had 40 years ago "Paul D. DeRocco" <pderocco@ix.netcom.com> - 2013-05-23 19:18 -0600
  Re: A preprocessor feature we should have had 40 years ago Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-05-24 15:19 -0700
  Re: A preprocessor feature we should have had 40 years ago jacob navia <jacob@spamsink.net> - 2013-05-25 02:23 -0700
  Re: A preprocessor feature we should have had 40 years ago Keith Thompson <kst-u@mib.org> - 2013-05-25 02:24 -0700
    Re: A preprocessor feature we should have had 40 years ago "Kenneth \"Bessarion\" Boyd" <zaimoni@zaimoni.com> - 2013-05-25 23:43 -0700
    Re: A preprocessor feature we should have had 40 years ago "Paul D. DeRocco" <pderocco@ix.netcom.com> - 2013-05-25 23:44 -0700
      Re: A preprocessor feature we should have had 40 years ago Francis Glassborow <francis.glassborow@btinternet.com> - 2013-05-26 08:52 -0600
  Re: A preprocessor feature we should have had 40 years ago Rui Maciel <rui.maciel@googlemail.com> - 2013-05-25 23:43 -0700
  Re: A preprocessor feature we should have had 40 years ago Peter <pcurran88@googlemail.com> - 2013-05-30 19:40 -0600
    Re: A preprocessor feature we should have had 40 years ago "Paul D. DeRocco" <pderocco@ix.netcom.com> - 2013-06-01 02:04 -0600
      Re: A preprocessor feature we should have had 40 years ago ootiib@hot.ee - 2013-06-01 14:53 -0600
      Re: A preprocessor feature we should have had 40 years ago James Kuyper <jameskuyper@verizon.net> - 2013-06-04 10:41 -0600
        Re: A preprocessor feature we should have had 40 years ago espie@lain.home (Marc Espie) - 2013-06-05 23:12 -0700
          Re: A preprocessor feature we should have had 40 years ago James Kuyper <jameskuyper@verizon.net> - 2013-06-06 09:20 -0700
  Re: A preprocessor feature we should have had 40 years ago Jens Schweikhardt <usenet@schweikhardt.net> - 2013-06-09 02:21 -0700

csiph-web