Hacker News Reader

Comment by Calavar | Hacker News Reader

> When performing string concatenation operations, it is more advantageous in terms of performance to use std::ostringstream rather than std::string. This approach is also used elsewhere, such as debug_utils and node_errors.

(From the Node.js GitHub issue.) Sounds like this guy is mixing up his Java knowledge with C++ knowledge.

C++ streams are frankly insane: Loads of implicit state, needing to set about a half dozen flags to do any nontrivial formatting, running the risk of accidentally "poisoning" all downstream operations if you forget to reset any of that state, the useless callbacks API [1], obfuscated function names (xsgetn, epptr, egptr), a ridiculously convoluted inheritance hierarchy that includes virtual/diamond inheritance [2], and use of virtual functions for simple buffer manipulation. These were all bad decisions even at the time.

[1] https://en.cppreference.com/w/cpp/io/ios_base/register_callb...

[2] https://i.stack.imgur.com/dXhXP.png

View on HN

C++ dev for 20+ years. I refused to use them, they encapsulated everything with C++ I hated. A ton of implicit actions and gotchas. It's a gun in hand, foot in target.

streams is the best evidence that C++ was an experiment. It was a sandbox to try a bunch of different language ideas.

Overloading the shift operators for this purpose is prima facie insane, and anyone who has single-stepped through a C++ "hello world" program can figure out it isn't remotely efficient, but it was certainly creative.

The shift operators are literally the nicest and most innocuous design decision of C++ streams.

What's broken with them has nothing to do with bikeshedding about operator choice.

But still not without problems, because you can't naturally write `cout << x & 0x1f << endl;`...

Just put some brackets like you should for any operator chaining. Explicit over implicit etc.

But here `<<` doesn't really feel like an actual operator here, just an ordinary separator like `,`. (Of course, `,` is actually an operator in C++. But anyway.) It is just completely alien to other existing C++ conventions before and after that.

C++20 ranges went a bitwise operator overload (OR this time).

That is more justifiable, as each delimited range is unlikely to be more complex than a call expression. Operator overload is okay, as long as you understand how would operators will be used.

This is mimicking the bash syntax.

> The shift operators are literally the nicest and most innocuous design decision of C++ streams

Which just shows how bad streams are. Overloading the shift operators was a terrible decision on multiple levels, but you're right -- that's not the worst streams sin.

Using C++ since 1993, I love them.

> (From the Node.js GitHub issue.) Sounds like this guy is mixing up his Java knowledge with C++ knowledge.

That is exactly it. C++ string streams have had atrocious performance since forever. Good abstraction, not very useful in practice.

In Java, if I remember correctly, strings are immutable, so the StringBuilder or whatever ridiculous name it had was the faster way to build a string.

> "I recently learned that some Node.js engineers prefer stream classes when building strings, for performance reasons."

Pretty much tells you everything you need to know about node js, I guess.

For what it's worth, even in Java the compiler is often smart enough to replace naive string concatenation with equivalent StringBuilder usage (although I don't know if it is smart enough to do that in a for loop like this)

To less informed readers, "smart enough" hear means:

Imagine you have two Java Strings: a and b

If you write the Java code:

    String c = a + b;

The Java compiler will roughly replace this code with:

    String c = new StringBuilder(a).append(b).toString();

I'm not sure I would say this is "smart". Rather, it is just a hack to allow Strings to override the plus (+) operator. Normally, Java does not allow operator overidding, like C++.

Two things:

First, it has nothing to do with overriding the + operator, the operation is statically decidable so the compiler is perfectly aware that this is a string concatenation (not a numerical addition) and string is a special builtin, the compiler can generate anything it wants. Which is exactly what it does, they just originally decided to implement string concatenation as stringbuffer/stringbuilder ops. Meanwhile the addition of integers, longs, floats, and doubles are (or were anyway) different bytecode ops. This does not require general purpose operator overloading support. Builtins are not limited to the language’s user level semantics.

And second OpenJDK has not done that since Java 9 (JEP 280), the compiler now emits generic “string concatenation” bytecode for the runtime / jit to deal with.

It’s not, and they basically gave up on it. Historically the OpenJDK would compile direct concatenation to StringBuilder so e.g.

    a += b + c;

Would become something like

    StringBuilder sb = new StringBuilder();
    sb.append(a);
    sb.append(b);
    sb.append(c);
    a = sb.toString();

However it was never capable of doing such an optimisation across loops.

In Java 9, they gave up on such static optimisations, instead the compiler now emits dedicated string concatenation bytecode (see JEP 280), which the runtime (and JIT) can then hook into.

Does that handle loops? Unclear. Benchmarks / testimonies from back then (java9/java10 days) hint that no, direct concatenation remains much slower than StringBuilder. But I didn’t find anything super recent so maybe they improved the behaviour in the meantime.

> "I recently learned that some Node.js engineers prefer stream classes when building strings, for performance reasons." Pretty much tells you everything you need to know about node js, I guess.

Google Closure Library includes a StringBuffer class. [1]

I recall it having explanatory notes, but I don't see them in the code now. JavaScript engines can optimize a string concatenating to in-place edit, if there is only one reference to the first string. The StringBuffer class keeps the reference count at one, guaranteeing this optimization is available, even if the StringBuffer itself is ever shared.

[1] https://github.com/google/closure-library/blob/master/closur...

The github issue:

https://github.com/nodejs/node/pull/50253

Note that the person mixing java knowledge and C++ isn't Daniel Lemire.

A bigger problem is that iostream is still the only C++ way to read and write files. Yeah, you can still use `std::fopen` and so on, but the modern C++ strives to minimize type-ignorant C functions right? The introduction of `std::format` made the formatting aspect of iostream obsolete, but iostream still has no standard alternative for other aspects.

std::print is coming with C++23. In the meantime, there's std::format_to. You still have to dump the output into an std::ostream, but at least you don't have to use the disgusting ostream interface directly.

std::filebuf can be used directly without std::fstream if you just want to read and write bytes without doing formatted operations.

That's fair, but `std::filebuf` still carries an `imbue` baggage...

iostreams are such a messy design, for all the reasons you mention and more. They are rightly avoided in all code that cares about performance.

Really

C++ the base language has issues, for sure

But iostream is like taking someone that's crazy to use every single language feature and who think there's some ulterior motive to create these crazy inheritance levels etc

Maybe we need C+=2 to make things less crazy

Careful, the committee may decide to deprecate compound assignment again.

What's the alternative to string streams for building strings pieces by pieces in C++? Plain old string concatenation? Asking for a friend... I should run benchmarks I guess.

Are you doing something in a hot loop or not? The answer is likely that it doesn't really matter.

If you really need speed, then estimate how large string you need in advance and preallocate it (either with new char[], or string::reserve ig).

Huh. I don't know much at all about C++ streams, but this sounds only marginally worse than C#'s streams

Maybe not. The problem is that C++ (before C++20) has no normal print and format function. You supposed to do everything with streams. To switch to two decimal places you would first output some magic value that sets an internal flag in the stream. Then you need to remember to restore it again.

Of course you could just use good old C printf to get some work done. But if you did that the "real" C++ programmers would sneer at you.

printf is fast, but has safety problems. Also frankly I don't like the fact that the formatting and the variable the data comes from are separated and you have to count out the argument orders to figure which one is which. Python's fstring gets this right.

edit: nvm, looks like I just described fmtlib. I really should keep up..

> Of course you could just use good old C printf

The fun thing with printf is that variadic functions cannot handle C++ classes. In the past was doubly fun because compilers proactively compiled an error into the binary instead of raising an error at compile time. So any forgotten c_str() became a crash waiting to happen.

C Printf never was, never could be and never will be a suitable way to output data from C++. Now excuse me while I go through the list of thousands of predefined format macros to find out which I need to use to output a uint_fast16_t without making the compiler vomit nonsense.

> C Printf never was, never could be and never will be a suitable way to output data from C++. Now excuse me while I go through the list of thousands of predefined format macros to find out which I need to use to output a uint_fast16_t without making the compiler vomit nonsense.

   printf("%d\n", (int) myfast16_t);

Not that terrible for a type that I've never used, nor seen used.

uint_fast16_t is the fastest type (for some undefined meanings of fast) that holds at least 16 bits, I don't think the standard guarantees that it even has to fit into an int, so we are already silently discarding data. Worse if it uses an unsigned int then you are casting from unsigned to signed with a potential undefined singed overflow involved.

I would have assumed that you don't want to use uint_fast16_t to store anything that doesn't fit in 16 bits.

If you cast to signed that can't represent the complete range that still wouldn't be called "overflow" AFAIK, and no matter what you call it it is not "undefined". And assuming 32-bit ints there is no loss of information given a 16-bit ints.

You can also just cast to unsigned or whatever type you think is enough (you should know). The point is, use a conversion, cast to a simple type, make your code compatible.

> I would have assumed that you don't want to use uint_fast16_t to store anything that doesn't fit in 16 bits.

I could have a 16 bit wide bitmask in it, lets flip them ~myMaskFast16, that leaves the higher order bits set to 0xFF... whether I care about them or not.

> The point is, use a conversion, cast to a simple type, make your code compatible.

Casting to a type that depending on platform may or may not hold enough space to represent the value is not "making it compatible" it makes it non portable.

> assuming 32 bit ints

That's really not a valid assumption. There are 16 bit int platforms, I've worked on them. It's not even that uncommon.

Casting in this scenario is simply incorrect. The correct thing to do is to use the formatting macros e.g. PRIuFAST16. Which noone ever does because it's gross and most developers don't actually care about portability.

> Of course you could just use good old C printf to get some work done. But if you did that the "real" C++ programmers would sneer at you.

As someone who has been programming in C++ since before there were C++ compilers (back in the day, you had to run it through a translator to make it into C code, then use a C compiler), I think I'm as real of a C++ programmer as anybody.

C++ programmers who sneer at you for this are fully worthy of being ignored.

Of course, printf() has its own set of issues as well.

Reply on news.ycombinator.com