Od C ++ 11, kontenery biblioteki standardowej istd::string mają konstruktorów pobierających listę inicjatorów. Ten konstruktor ma pierwszeństwo przed innymi konstruktorami (nawet, jak zauważył @ JohannesSchaub-litb w komentarzach, nawet ignorując inne kryteria „najlepszego dopasowania”). Prowadzi to do kilku znanych pułapek podczas konwersji wszystkich nawiasów() formy konstruktorów do ich wzmocnionych wersji{}

#include <algorithm>
#include <iostream>
#include <iterator>
#include <vector>
#include <string>

void print(std::vector<int> const& v)
{
    std::copy(begin(v), end(v), std::ostream_iterator<int>(std::cout, ","));
    std::cout << "\n";
}

void print(std::string const& s)
{
    std::cout << s << "\n";
}

int main()
{
    // well-known 
    print(std::vector<int>{ 11, 22 });  // 11, 22, not 11 copies of 22
    print(std::vector<int>{ 11 });      // 11,     not 11 copies of 0

    // more surprising
    print(std::string{ 65, 'C' });      // AC,     not 65 copies of 'C'
}

Nie mogłem znaleźć trzeciego przykładu na tej stronie, a rzecz pojawiła się w czacie Lounge <C ++> (w dyskusji z @rightfold, @Abyx i @JerryCoffin), nieco zaskakujące jest to, że konwersjastd::string konstruktor używający licznika i postaci do użycia{} zamiast(), zmienia swoje znaczenie zn kopie postaci don-ty znak (zwykle z tabeli ASCII), po którym następuje drugi znak.

Nie jest to złapane przez zwykły zakaz zawężania konwersji, ponieważ 65 jest stałym wyrażeniem, które może być reprezentowane jako char i zachowa swoją oryginalną wartość po konwersji z powrotem na int (§ 8.5.4 / 7, punktor 4) (dzięki do @JerryCoffin).

Pytanie: czy jest więcej przykładów czających się w Bibliotece Standardowej, gdzie konwertujemy() konstruktor stylu do{} styl, jest łapczywie dopasowany przez konstruktora listy inicjalizującej?