std::string doesn’t have a template type for the allocator. You are stuck using the verbose basic_string type if you need a special allocator.
But, of course, nobody sane would write that by hand every time. They would use a typedef, like how std::string is just a typedef for std::basic_string<char, std::char_traits<char>, std::allocator<char>>. Regardless, the C++ standard library is insanely verbose when you start dropping down into template types and using features at an intermediate level. SFINAE in older versions of C++ was mindfuck on the best of days, for example.
Don’t get me wrong, though. I’m not saying Rust is much better. Its saving grace is its type inference in let expressions. Without it, chaining functional operations on iterators would be an unfathomable hellscape of Collect<Skip<Map<vec::Iter<Item=&'astr>>>>
std::stringdoesn’t have a template type for the allocator. You are stuck using the verbosebasic_stringtype if you need a special allocator.But, of course, nobody sane would write that by hand every time. They would use a typedef, like how
std::stringis just a typedef forstd::basic_string<char, std::char_traits<char>, std::allocator<char>>. Regardless, the C++ standard library is insanely verbose when you start dropping down into template types and using features at an intermediate level. SFINAE in older versions of C++ was mindfuck on the best of days, for example.Don’t get me wrong, though. I’m not saying Rust is much better. Its saving grace is its type inference in
letexpressions. Without it, chaining functional operations on iterators would be an unfathomable hellscape ofCollect<Skip<Map<vec::Iter<Item = &'a str>>>>Yeah, I missed the custom allocator at first. I thought I deleted my comment fast enough, but I guess you were faster. :)