Constructing short C strings in limited or constrained situations

[SiliconWizard]

(I absolutely detest cout << "Hello, " << "World" << "!")

The ugliest thing that ever accompanied a programming language.

Well, I'm not a C++ user, so I'm biased. But I don't find this particularly awful per se? That is, if you consider streams as a useful construct. What tickles me with this is that it only works with streams, so that yields to different ways of building strings throughout a program, instead of using a unified way. That's really what I find disturbing.

[brucehoult]

(I absolutely detest cout << "Hello, " << "World" << "!")

The ugliest thing that ever accompanied a programming language.

Well, I'm not a C++ user, so I'm biased. But I don't find this particularly awful per se? That is, if you consider streams as a useful construct. What tickles me with this is that it only works with streams, so that yields to different ways of building strings throughout a program, instead of using a unified way. That's really what I find disturbing.

http://www.cplusplus.com/reference/sstream/ostringstream/

?

[SiliconWizard]

(I absolutely detest cout << "Hello, " << "World" << "!")

The ugliest thing that ever accompanied a programming language.

Well, I'm not a C++ user, so I'm biased. But I don't find this particularly awful per se? That is, if you consider streams as a useful construct. What tickles me with this is that it only works with streams, so that yields to different ways of building strings throughout a program, instead of using a unified way. That's really what I find disturbing.

http://www.cplusplus.com/reference/sstream/ostringstream/

?

As I said, I'm not a C++ user, so there are certainly a lot of things I'm missing.
And here, whereas you can indeed use string streams to get a consistent way of dealing with strings, I've seen a lot of C++ code mixing approaches for dealing with strings, including using both streams and string formatting functions/methods. Very annoying.

[brucehoult]

C++20 adds a std:format() stream function :-)

Code: [Select]

cout << millis() << ": " << format("The answer is {}.", 42) << endl;

I also don't like this overloading of << for streams. Would it be that much worse to write instead of the above?

Code: [Select]

cout.put(millis()).put(": ").format("The answer is {}.", 42).endl();

Either way comes down to the exact same thing at the compiled code level.

The advantages of the C++ way are extensibility, type safety, and not dragging in the formatters and libraries for floating point  (for example) if you don't use them.

But it's SO MUCH more cumbersome to write than printf()-style formatting. And defeats localisation that wants to change not only the words or formats for dates etc but also wants to change the order of the elements.

A *proper* objected-oriented language can separate the conversion of values into strings from the interpolation of those strings into the format string e.g. by using a toString() method, possibly with arguments for field width, decimal places, padding character etc.

But in C++ characters and strings and numbers are not instances of a class :-(

[Nominal Animal]

C++20 fell into the same {{-escapes-{ trap that Python did, I see.  I do claim "Use \(\) to yield {}" is at least as easy to perceive/maintain as "Use {{}} to yield {}" is (and that "\// escapes a backslash, \/" is much easier to verify for correctness than "\\\\ escapes a backslash, \\"), but the former is much easier to implement in a robust efficient form. With just one lookaside character, you can parse my escape forms either right-to-left or left-to-right, too.

Hmm. Perhaps it is time to put up an implementation in runtime-library form (no help needed from the compiler, using currently available features), and let the devusers decide for themselves.
As a potato disguised as a human, I utterly detest popularity contests, though.