Beman Dawes wrote:
> Unfortunate? Is that one of those understatement jokes Canadians are known
> for? I'd say it is way worse that "unfortunate" - it is ugly and error
> prone.
I didn't want to prejudice the group with judgemental language like "ugly and
error prone." :-)
I certainly recognize that the syntax is terrible, but the syntax isn't the
essence of this proposal. I'm really proposing a general direction toward a
solution to a problem that, as you have mentioned, has already been discussed by
the performance subgroup of the C++ committee. The details can be changed.
One thing that I'm really interested in discussing is whether the problem that
this library addresses is one that's worth solving. Is there sufficient interest
in solving the problem (and others like it) that a change to the language is
justified?
> * Can you come up with a small, workable language extension that eases
> those problems?
Here's a list of possibilities, with some discussion. Please note that I'm not
arguing that any of these ideas is especially desirable. They're just ideas to be
explored.
idea #1: string literals as template arguments
The extensions subgroup of the committee has discussed this one briefly.
Interestingly, this extension is not, by itself, sufficient for the implementation
of a static_string. The reason for this is that the expression "str[index]" is
not currently a compile-time constant expression. Since individual characters
cannot be selected from a string literal at compile-time, it would be impossible
to implement compile-time versions of most of the basic_string (and static_string)
member functions. To be useful for creating a static_string library, then, this
idea really involves more than one change to the core language. If these changes
were in fact made to the language, would we still need a static_string library? I
suppose that the answer to this question depends on the number and nature of those
changes.
idea #2: a magic operator
This idea is simple, but it might not be of sufficiently general utility to
justify its addition to the language. The magic operator would instruct the C++
compiler to rewrite a string literal by replacing it with a comma-separated list
of character literals. Then the initialization syntax for a static_string would
look like this:
boost::static_string<magic_string_unglue("my text")> str;
// becomes: boost::static_string<'m', 'y', ' ', 't', 'e', 'x', 't'> str;
Please note that I chose to name the operator "magic_string_unglue" for the
purpose of this example only. I'm not seriously suggesting that this is a great
name for a C++ keyword. :-)
idea #3: preprocessor tricks
I don't believe that a preprocessor trick can help, actually, though I'd be happy
to be proven wrong. The basic lexical unit that can be manipulated by the
preprocessor is the token. The individual characters that compose a token aren't
really available for manipulation. The preprocessor has a token-pasting macro,
but no token-unpasting macro, for example.
> Lack of internationalization support is also a serious concern.
I'm not sure whether this addresses that concern, but I had thought that I would
wait until more of the issues surrounding static_string were resolved before I
began to implement a static_wstring.
Trying-not-to-appear-crazy,
Robert Klarer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
