compile-time-constant

I want to write a function magic_get , which can extract a value from a parameter pack by index, for example: int n = 0; n = magic_get<0>(1, 3, 5, 7); assert(1 == n); n = magic_get<1>(1, 3, 5, 7); assert(3 == n); n = magic_get<2>(1, 3, 5, 7); assert(5 == n); n = magic_get<3>(1, 3, 5, 7); assert(7 == n); How to implement magic_get ? template <size_t N, typename... Args> decltype(auto) magic_get(Args&&... as) noexcept { return std::get<N>(std::forward_as_tuple(std::forward<Args>(as)...)); } Change decltype(auto) to auto and add a trailing return type of decltype(/* the whole returned expression

I was exploring how far I could take the constexpr char const* concatenation from this answer: constexpr to concatenate two or more char strings I have the following user code that shows exactly what I'm trying to do. It seems that the compiler can't see that the function parameters (a and b) are being passed in as constexpr. Can anyone see a way to make the two I indicate don't work below, actually work? It would be extremely convenient to be able to combine character arrays through functions like this. template<typename A, typename B> constexpr auto test1(A a, B b) { return concat(a, b); }

EDIT 1: I know there are alternatives such as telescoping, this was a purely educational question. I know that this is true, but why must it be? It seems like with something like this: public class Foo{ private int bar; public void SetBar(int baz = ThatOtherClass.GetBaz(3)){ this.bar = baz; } } The compiler could change the method to something like this: public void SetBar(int baz){ //if baz wasn't passed: baz = ThatOtherClass.GetBaz(3); this.bar = baz; } Why wouldn't that work, or would it, and it's just a design decision? Because the spec says so: A fixed-parameter with a default-argument is

Is there any way to ensure, that an expression like the following would be evaluated at compile time? myList :: [Int] myList = sort [3,2,0,1] If what you're evaluating is an instance of Lift , you can evaluate it at compile time using TemplateHaskell : {-# LANGUAGE TemplateHaskell #-} module Sort where import Data.List import Language.Haskell.TH.Syntax myList :: [Int] myList = $(lift (sort [3,2,0,1] :: [Int])) If you want, you can check what it has compiled to with -ddump-splices : $ ghc -ddump-splices sort [1 of 1] Compiling Sort ( sort.hs, sort.o ) sort.hs:9:12-41: Splicing expression lift

Is it possible to declare a new type (an empty struct , or a struct without an implementation) on the fly? E.g. constexpr auto make_new_type() -> ???; using A = decltype(make_new_type()); using B = decltype(make_new_type()); using C = decltype(make_new_type()); static_assert(!std::is_same<A, B>::value, ""); static_assert(!std::is_same<B, C>::value, ""); static_assert(!std::is_same<A, C>::value, ""); A "manual" solution is template <class> struct Tag; using A = Tag<struct TagA>; using B = Tag<struct TagB>; using C = Tag<struct TagC>; or even struct A; struct B; struct C; but for templating /

I am working on an annotation processor. This code compiles: package sand; import java.util.Set; import javax.annotation.processing.AbstractProcessor; import javax.annotation.processing.RoundEnvironment; import javax.annotation.processing.SupportedAnnotationTypes; import javax.lang.model.element.TypeElement; @SupportedAnnotationTypes("sand.Foo") public class FooProcessor extends AbstractProcessor { @Override public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) { return false; // TODO } } However, I am displeased by the string constant "sand.Foo" (not too

std::string provides a max_size() method to determine the maximum number of elements it can contain. However, to work out the maximum length of a string in general, the programmer has to create a (possibly empty) string object. If this class doesn't need any information from the programmer, why isn't max_size() available as a compile-time constant ? Is there some kind of runtime information necessary for a string to work out its maximum size ? One reason is that the max_size function isn't very useful at all, and the committee doesn't think it is worth the trouble to try to fix it. So it is