Xeo c9xeo Sanity is just a mask

Niner since 2012


  • Stephan T. Lavavej - Core C++, 6 of n

    @jbandela: This particular case is a bug. The direct-list-initialization form ( T v{ ... }; ) should consider explicit constructors. Note that the copy-list-initialization form

    T v = { ... };
    foo({ ... })
    return { ... };

    does not.

  • Stephan T. Lavavej - Core C++, 6 of n

    Great video and great features, thanks a bunch!

    (Direct-initialization can invoke explicit constructors, while "T x = a;" copy-initialization can't.)

    I find it kinda sad that

    return {some_args};

    aswell as


    don't count as direct-initialization and as such can't invoke explicit constructors. Especially annoying for unique_ptr and tuple.

    @Benjamin Lindley: A good example here would be the following gotcha with list-initialization:

    std::vector<int> v{5};
    assert(v.size() == 1 && v.front() == 5);

    The standard explicitly demands that this happens in §

    When objects of non-aggregate class type T are list-initialized (8.5.4), overload resolution selects the constructor in two phases:

    •  Initially, the candidate functions are the initializer-list constructors (8.5.4) of the class T and the argument list consists of the initializer list as a single argument.
    • If no viable initializer-list constructor is found, overload resolution is performed again, where the candidate functions are all the constructors of the class T and the argument list consists of the elements of the initializer list.

    And a little note in §8.5.4/2:

    [ Note: Initializer-list constructors are favored over other constructors in list-initialization (—end note ]

  • Stephan T. Lavavej: Core C++, 3 of n

    I think you can just use std::is_pointer() as the tag "value" for dispatching, as all UnaryTypeTraits are required to derive from either true_type or false_type (which is incidentially where the nested type typedef comes from).

    Other than that, another great video, thanks.

  • STL11: Magic && Secrets

    > I am definitely thinking I'll do a "Core C++" series

    Yes, please!

    > iostreams fills me with dread and loathing. Maintaining the stuff is just about all I can handle.

    Then make it a "Bash the IOstreams" session? Smiley Tell us what's so horrible about them!

  • STL11: Magic && Secrets

    > Me too. You can think of this as "Advanced STL, Part Infinity" for the time being. :->

    Heh, topic suggestion: Template meta programming! With things like Expression SFINAE, writing ones own type traits (like how to find out if a class has a certain member function), like you did in part 5 of Advanced STL.

    Maybe also about constexpr? But that isn't implemented in VS, right? Sad

    Hmm, what else... I'll think about it some more and report back. Smiley

    Edit: Oooh, another idea! I know this doesn't really count as STL, since they don't belong in that subpart of the library, but what about IOstreams? Especially the streambufs, locales, facets, codecvt stuff. As far as I know, there's only one real book on IOstreams, and it's from 2000 (IIRC). And personally, I think IOstreams are one of the more advanced topics, if you go beyond simple streaming to existing streams. Smiley

  • Variadic Templates are Funadic

    @Andrei: But then it's still missing a "class" after the "template< >" around the Policies, or am I missing something?

  • Variadic Templates are Funadic

    At 00:19:48, I'm pretty sure there's a mistake on the slide.

    template <
        typename T,
        template <
            template<class...> class... Policies
    class ICantBelieveItsNotButter;

    Either a missing "class Name" or the "template< >" around the policies is too much. So much for "My code has no mistakes". Wink

    Other than that, great talk. Enjoyed it very much. Though one thing I'd certainly like to see from the standard side is better (read: smarter) pack expansion, so we don't need to resort to recursion all that often if the expansion is actually really trivial (say, + instead of a comma):

    template<class T, class Head, class... Operands>
    struct var_add{
      static T const value = Head::value + Operands::value...
      //                     pattern -- (                 )

    Whereas the recursive (and current) way would look something like this:

    template<class T, class Head, class... Tail>
    struct var_add{
      static T const value = Head::value + var_add<Tail...>::value;
    template<class T, class Head>
    struct var_add<T, Head>{
      static T const value = Head::value;

    (I hope the formatting works...)

  • STL11: Magic && Secrets

    Great talk, it's always a joy to hear you talking! I hope you'll have a little bit more time for your Advanced STL series once VS11 is out.

    Then, any particular reason that nearly every slide was titled with a TVTrope? Smiley

    (Also, can we get access to these slides?)