Eh? You want to concatenate literals at compile-time and have the result behave like a std::string? You won't be able to avoid a run-time std::string ctor call as far as I can figure, anyway. Why not just do the usual things for concatenation and wrap the whole thing in the ctor call? I.e. const char * bar = "bar"; std::string("foo" bar "baz");

Quote:Original post by Extrarius
I also want to specialize the definition of Output such that if Apply's Param1 is a BuildString<NestedChar>::Apply<Anything>::Result, instead of being a single character, Output will be std::string(1, Character) + BuildString<NestedChar>::Apply<Anything>::OutputString so I can nest them to build up a string into the Output of the outermost BuildString.

Don't use class-static const strings here, since the order of construction between them is not fully defined. Prefer static const objects in member functions or just locals returned by value. Even better, logically concatenate them at compile-time and put them into a char array of appropriate length, initialized with an initializer list.

As well, watch out for nested template instantiation depth. The standard recommends that compilers have at least a depth of 17, though most compilers do go much deeper than that. Still, keeping it low can have a noticeable impact on compile-times.

Really though, you're much better off using preprocessor metaprogramming to generate a variadic-style template parameter list and then pass all of your characters to that (i.e. instantiated like string< 'a', 'b', 'c', 'd' >). Then define metafunctions for concatenating two strings, etc. However, why build that from scratch when you can use a Boost.MPL vector_c of characters inside the implementation of your compile-time string type? Even if you are just doing it for the sake of learning, I really wouldn't recommend just working entirely from scratch as it's all pretty simple stuff, just tedious to implement, becoming more of a project in preprocessor metaprogramming if you want to do it correctly rather than template metaprogramming.

In case you're wondering what I'm trying to do, I'm trying to implement a turing complete language entirely via templates (which shouldn't be possible since the template language is supposedly not turing complete). The language I'm trying to implement is a minimalist version of Unlamda[1], leaving out the D and C functions since I'm not sure how to implement them via templates (or if it's possible). I do, however, have the SKI combinator trio implemented, and for the most part they work - I can construct an expression and get a (usually correct) result by using typeid().name() to output the final value. This is an unsatisfactory output method, though, because it is very difficult to read (end up with things like "struct S::Apply(struct I)::Result::Apply(struct I)::Result" for (S I I) because of currying) and also because it's entirely compiler-dependant (and might just return an empty string iirc) so it can't actually be used to calculate something at compile time that is later used at run time (the recursion limit eliminates the possibility of walking the answer like a tree/list to convert types into simple strings - I thought it didn't apply to the nested approach but I'm not sure now since Polymorphic OOP hasn't replied to my question).

If, however, I could get a build-string-char-by-char function working, then I could use it to build usable output in the same way that Unlambda[1]s dot-char function works (in fact, I could then translate many unlambda program straight to template metacode).

[1] http://en.wikipedia.org/wiki/Unlambda

-Extrarius

Quote:Original post by Extrarius
By this, do you mean that with a class like so:

It means that the standard recommends that compilers allow you to recursively instantiate a metafunction at least 17 times (only a recommendation, most go much beyond that, but still something to consider). Anyway, the main point is, don't rely on instantiating a template 50 times recursively just to make a 50 character long string, regardless of what your compiler can handle. You're just going to end up with an extremely complex instantiated type and, depending on how you further work with the type, you're probably going to have high complexity for many operations. If you just use preprocessor metaprogramming to generate a template parameter list of a fairly large size and use that, then make other intrinsic metafunctions for dealing with the string instantiations you'll get a much easier template to work with and one which will most-likely compile much faster.

But really, if you went that route, you might as well just use Boost.MPL.

Quote:Original post by Extrarius
In case you're wondering what I'm trying to do, I'm trying to implement a turing complete language entirely via templates (which shouldn't be possible since the template language is supposedly not turing complete).

Actually, templates are turing complete.

Quote:Original post by Extrarius
The language I'm trying to implement is a minimalist version of Unlamda

In that case have fun, and continue on with whatever choices are appropriate to reach the paradigm you want. Just keep in mind that template facilities aren't best suited for this style of programming so you'll probably encounter long compile-times and possibly reach compiler limits along the way.

Quote:Original post by Extrarius
I can construct an expression and get a (usually correct) result by using typeid().name() to output the final value.

Yeah, definately don't do that. Perform everything logically at compile-time and then instantiate one type to represent the results of arbitrarily complex operations performed at compile-time when requested. Don't use, for instance, runtime string concatenation facilities as you described in your previous post, just build one single runtime string when requested, initialized strictly with data already concatenated at compile-time, as the information is all known at compile-time anyway.

As a side note, if you are just using the string at runtime and are using runtime string concatenation facilities anyway, then there is no reason for you to be using template metaprogramming to begin with, as expression templates would generally provide a superior alternative. Use template metaprogramming if the result is needed at compile-time, such as to calculate a value needed to instantiate another template or to create a complex type from data which needs to be known at compile-time. Here it just sounds like you want all of the results at runtime.

Quote:Original post by Extrarius
If, however, I could get a build-string-char-by-char function working, then I could use it to build usable output in the same way that Unlambda[1]s dot-char function works (in fact, I could then translate many unlambda program straight to template metacode).

You can do that, an by all means, don't let the recommended compiler limit stop you (again, most compilers go well beyond it). I wouldn't wory about the limit much as I doubt you'll be using it much for extremely complex data, but its still something to consider and shows that templates generalyl aren't best-suited for this particular type of metaprogramming. Anyway, it's more compile-times and ease of use that I'd worry about since the syntax is going to start looking hairy pretty quickly. It's not exactly a style of programming that I'd want to use with templates.

Quote:Original post by Extrarius
Since a recursion limit is allowed, templates CAN be turing complete (if your specific compiler has no recursion limit), but they don't HAVE to be. Thus, by the standard, you can't count on templates being turing complete.

Not at all. By standard you can consider the turing complete. There are always going to be limits for tons of features in any language implementation, not just templates in C++; that doesn't make them any less turing complete, acknowledging them is just being realistic. The C++ standard, for instance, has dozens of recommendations for minimum compiler limits in other areas of the language -- that doesn't mean that going beyond them is nonstandard code, they are just recommendations and don't imply compliance on any level.

Templates are turing complete, it's just that a compiler is generally going to have limits, just like there are often limits for many other features of any language. They can still theoretically be recursively instantiated forever, whether your compiler can handle it or not is another story. The standard merely acknowledges that fact and provides reasonable guidelines for an implementor to follow as recommendations.

A compiler for any functional language may have a limit to how deep recursion goes, that doesn't make the language any less turing complete, again, it's just being realistic.

Quote:Original post by Extrarius
I'm not sure how to do it this way any more than any other way. I would greatly appreciate a more detailed explanation. Realize, though, that whatever method I use must be embeddable within a chain of combinators (and it should act like the Identity Combinator 'I' that I posted above, as far as how it defines it's Result type).

The most easily optimized way, but having limitation based on a size you would personally decide, would be to create a static const char array large enough to hold the entire string, and then just use an initializer list in the initialization of the char array, with each element being a compile-time constant taken from the template instantiations, thereby making the array initialized prior to any constructors for any types, therefore avoiding problems with construction order.

Short of that, I'd recommend using a static const char array reference inside of a function which is initialized to a static const char array created inside of another function. Inside of the function which directly has the static char array, use template metaprogramming to unravel a simple loop which just copies the elements of the compile-time string into the static char array. Since the local array reference in the other function is also static, the function doing the initialization is only called once, and since the initialization is based off of all compile-time constants and since you are just interfacing with it through a reference, there's going to be minimal overhead. As well, since you are using static arrays inside of functions, you also avoid any construction order problems.

If you want the result to be a ::std::string, just initialize the string with the char array in the above examples. Still, you shouldn't ever be resorting to fully runtime concatenations considering its based around template metaprogramming.

Quote:Original post by Extrarius
I thought that when the limit was reached, the compiler would emit an error of some kind.

It will emit an error if it's reached. I didn't look through your logic, but if you are having problems it's most-likely do to a mistake in code.