swestrup: (Default)
[personal profile] swestrup
Coming from a background of doing large amounts of C programming for embedded systems, I've often been crucially aware of the value of using structured constant data that can be burned to ROM. If one has particularly complex data that needs a constant structure, its normal in C to have elaborate series of macros to construct the needed declarations, sometimes going as far as to re-include the same definition file multiple times, but with different definitions for the macros that process it.

This can, indeed, be a royal pain and I heartily sympathize with Stroustrup when he says that he very much wants to deprecate the preprocessor in C++. That said, he has given us little to replace it with with respect to constructing structured data. (This was, after all, the major way that C, IMNSHO, was superior to Pascal.)

When I was first introduced to C++ in 1989, when it was already 10 years old, I was startled and dismayed to see that it had no support for literal user class initializers, and no way to initialize a const array member. Even today, when C++ is now 27 years old, if one wants to define complex const data structures in C++ (ie, ones that require no code to initialize), one writes C-compatible PODs and uses complex preprocessor macros.

There is a light at the end of the tunnel though. There is talk about adding features to support const initialized user data in the next revision of the C++ standard. The current suggestion is to add a constexpr keyword and a new standard initializer_list<> template that will, together, finally provide a way to write something that does compile-time computation of constant structured objects. Thus, one could finally write (as a simple example):
template <typename T>
constexpr initializer_list<T> &interleave
  (T *beg, T * end)
  { ... }

template <typename T>
class InterleavedArr
  {
  public:
    constexpr T const dat[];
    constexpr InterleavedArr
      ( initializer_list<T[]> a
      ) : dat(interleave(a.begin(), a.end())
      { }
  };

const InterleavedArr<char> str1 = {"abc","def"};
const char str2[] = "adbecf";
And have the above generate assembly code similar to:
.globl str1
.string "abdecf"
.globl str2
.string "abdecf"

Although the actual definition of the template function interleave above can get somewhat complex since its not allowed a loop. Depending on if the final standard allows constexpr functions to be recursive or not, one may be foreced to do the recursion through templates, which is a bit of a mess. Still, I have no doubt an entire Boost library would shortly appear to help support this kind of construct not long after a standard mandating them appeared.

If that standard comes out by 2009, we might even be able to code this stuff by 2014, only 35 years after C++ was invented...

Date: 2006-06-13 01:43 pm (UTC)
From: [identity profile] sps.livejournal.com
It would be more humourous to use the keyword 'const' and distinguish const T from T const. (Const started life as a storage class with something like [a restricted version of] this semantics, anyway!)

(C++ lies about its C compatibility, so what the hell....)

January 2017

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 13th, 2026 01:18 pm
Powered by Dreamwidth Studios