Talk:cpp/utility/integer sequence

WRT: "The behavior is undefined if N is negative."

May a negative argument actually cause UB?

In the sense the program is translated without any diagnostic but could sporadically fail at run-time?

Or does "undefined behavior" rather mean:

The program may NOT translate, but the compiler is not required to give a useful diagnostic (i.e. compilation might crash with an internal error).

Or: the program MAY translate but the compiler may silently wrap negative value to a large positive number without giving indication?

Mwe (talk) 07:05, 3 July 2015 (PDT)

perhaps it was from an earlier draft? C++14 has it as ill-formed (20.5.3[intseq.make])), page edited accordingly. The are cases of compile-time UB, but looks like this isn't one. --Cubbi (talk) 08:47, 3 July 2015 (PDT)

Thanks (for the correction and the excellent size; in the meantime I really link LOT to it from my C++ training documents).

As I'm at it and in case anybody is interested, here is a small program which I used to try the limits of compile time sequences (and a bit more - feel free to add it as another example):

http://coliru.stacked-crooked.com/a/b6d7d4fb73fd866e

It looks like clang++ bails out much earlier (around 250) while g++ still compiles a size of 900.

Mwe (talk) 09:33, 3 July 2015 (PDT)

you're not using clang's library. The options to use are -stdlib=libc++ -lsupc++. Compiles N = 1 million http://coliru.stacked-crooked.com/a/b8f7371504b32d1f --Cubbi (talk) 09:49, 3 July 2015 (PDT)

I see, it's always a good idea to post here, you (i.e. I :-)) always learns something new - thanks so much.

BTW: This is the example I finally came up with for demonstrating std::make_index_sequence_for in my C++14 training documents: http://coliru.stacked-crooked.com/a/607f5b30d0552a6e

(I'd really, REALLY! appreciate your opinion on it, especially if there is some way to avoid the "assign_multiple_helper" ... but I assume there isn't.)

It's a bit simplified compared to what I found on cppreference and doesn't use the, hmm, let's say "hack"?

Well, I don't really mean it, at least not with a negative connotion, so I hope you get the idea, but initialising an array to get a guaranteed order of evaluation ... hmm ... and achieve what is REALLY intended (printing a tuple) as side effect ... hmm ... yes, I'd say it IS a hack.

OK, considered neutrally, IMHO what is shown as example on cppreferece is a clever trick (and I very much appreciate to learn such tricks from you experts, really), but drawing from my experience in teaching C++ courses: it conveys the wrong idea to those who aren't C++-aficionados to the degree that I (and presumably you) are. Those who have a certain - say - "distance" to C++ (because they maybe rather prefer C# or Python or Go or whatever) will likely pick up the idea that you can't program (sucessfully) in C++ without adopting obscure techniques ... that's the reason why I looked for something simpler (please don't mind, just my 2 cent).

Mwe (talk) 14:50, 3 July 2015 (PDT)

relying on array init order to do things to variadic args was a very common idiom in C++11, but it's going to become obsolete with C++17's fold expressions (already supported by clang). --Cubbi (talk) 16:40, 3 July 2015 (PDT)

What is the `::value` at the end of `std::tuple<int, int, int, int>>::value`?

The ::value is the static member of the std::is_same<...> (whose second template parameter is the std::tuple<...>). --Ybab321 (talk) 04:56, 19 November 2018 (PST)