Jun. 13th, 2006

swestrup: (Default)
I crashed around 6:00 pm, and woke up at midnight. 6 hours sleep after a day with only 4 is no where near sufficient, but I've been unable to get back to sleep. I've finally given up and will go through my normal getting up routines now. With any luck I can catch a couple hours nap in the afternoon.
swestrup: (Default)
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...
swestrup: (Default)
My plans for today and yesterday had involved intensively cramming documentation into my head. Considering my zombie state today and yesterday, this isn't going to have happened by tomorrow. (And what the heck do you call THAT tense???)

Anyway, I did manage some productive labour yesterday, and may do the same today, so long as the novelty and conentration-required factors are both low.

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 May. 14th, 2026 10:17 am
Powered by Dreamwidth Studios