Re: [boost] Re: compile-time binary constants

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-19 14:10:22

At 10:59 AM 1/19/2003, Gennaro Prota wrote:
>On Sat, 18 Jan 2003 20:16:36 -0700, Greg Colvin
><Gregory.Colvin_at_[hidden]> wrote:
>
>>At a meeting years ago I proposed to make string literals more
>>useful as constant expressions, but we decided against that.
>>As I recall part of the problem is that linkers are free to map
>>the same literal string to different addresses in different
>>compilation units. 
>
>I'm not sure what you are referring to by "using string-literals as
>constant expressions". If you are alluding to making the array
>referred to by a string-literal usable as a template argument, like in
>
>   template <const char c[]>
>   struct X {};
>
>   X <"hello"> x;

Yes, that is part of what I wanted.

>then I'd like to make a comment. Currently C++ doesn't allow this.
>Briefly, the problem is that a string-literal (which is not an object
>per se, but an expression which *refers* to an object implicitly
>created by the compiler) refers to an unnamed object and such an
>object is not usable as a template argument. However it would be
>perfectly possible to give it a compiler-generated name. Now, as you
>say, it's not specified whether array objects corresponding to
>identical string literals are collapsed together or not and thus you
>don't know whether e.g. x and y below have the same type or not
>
>   X <"hello"> x;   // (*)
>   X <"hello"> y;
>
>
>But this is IMHO a problem only when it is a problem! :-)

Right.  But it was enough of a problem, and different enough
from integral constants, that the committee wasn't comfortable
with this extension.

> It's no
>problem at all e.g. when I instantiate X<> just to make some sort of
>processing on the string-literal itself (see below). And if I want to
>be sure that different strings are instantiated I can explicitly use
>arrays:
>
>extern const char arr1[] = "hello";
>extern const char arr2[] = "hello";
>
>X<arr1> x;
>X<arr2> y;

But again, due to aliasing, I think it is not in general
possible to distinguish arr1 and arr2 at compile time.  If
I'm wrong then this might be a workable approach.

>However processing on string-literals (example: counting the number of
>occurrences of a given character) is anyhow impossible for other
>reasons, mainly because you cannot cycle through the single characters
>and obtain character constants. Thus, doesn't C++ lack a support for
>true string rvalues?

Yes, C++ lacks such support.