No, because they have some extra tokens in the syntax (mostly to deal with strong typing). But they're semantically identical, which I think was the author's point. You declare the data instead of assembling it, and you do it in the same order and in the same manner. There's more typing but the idiom is the same.

This is something that I think a lot of people miss about modern C++. They make the mistake of assuming you still program it using C idioms, when often you don't have to. They assume you have to "manually manage memory" when obvious and simple RAII techniques have basically obsoleted that for probably 90% of cases.

It's just not like that. If you have a problem that is "easy to express" in Python/Perl/Ruby/Javascript it is expressable in essentially the same way in C++.

The gotcha to my mind is more that the C++ environment is unforgiving -- a novice python programmer making a syntax error generally bangs around and gets it to work, maybe with some odd thought errors someone else will have to clean up. A novice C++ programmer is lost until they find an expert to explain the problem. So I don't think web engineers need to worry about losing their jobs to C++ hackers quite yet.

But at the same time, the intuition that C++ is "hard" is mostly wrong. A true expert can solve the same problems the scripting languages do, arriving at essentially equivalent code, in very similar time and with very similar (potentially higher due to typesafety) quality.

I agree, it is much uglier. Part of it is that Python thinks a character is unsigned, whereas C++ thinks it is signed. This arbitrarily works in Python's favor here. Part of it is that Python just handles this better.

I suppose he wanted to showcase boost::format. You can do it simpler with std::to_string:

    return to_string(static_cast<unsigned char>(s[0]));