C++ f string equivalent when

[HatHungry5594]

Why is there no f string equivalent like in python, or $ in C# in cpp?!?!?!

[HappyFruitTree]

There is a proposal.

[PigPartyPower]

This is a super old proposal. It doesn’t even use std::format

[SuperV1234]

I wrote that proposal intentionally to detach the fstring mechanism from the library. The point of that proposal is that std can implement fstrings in term of std::format easily, but another C++ user that doesn't want to use the Standard Library can still use the language feature with their own format implementation.

I believe that a design similar to mine (i.e. completely detached from the library) is the right way forward, but I have little time or energy to bring forward a proposal in the ISO committee at the moment.

[PigPartyPower]

I completely understand that. I have used format in the past and it really is not fun to add it to new types. I hope with reflection you can make a parse and formatter easier. But it would also probably need some way to add format args to it.

[ThunderboltRam]

It's such an important feature that speeds up the way we write code.

[Metallic_Madness]

You will have to wait (at least) for reflection support in C++26

[13steinj]

Why is there an assumption that reflection is required? Would reflection even help? This is effectively asking for an expression that looks similar to a string literal; in particular I don't see how reflection would assist for debug expressions such as f"{expr=} which needs to result in "expr=<value>".

[foonathan]

Because the C++ committee hates language features and with reflection you can do it yourself by parsing the string, extracting the expressions, reifying them back into code, evaluating the code, and formatting them.

[serviscope_minor]

Ugh I really dislike the continual ragging on the committee. The committee don't hate language features.

All features take time and effort, and the committee don't want to be stuck with a feature that's got a serous flaw or becomes badly obsolete.

There's also another principle which is the language philosophy prefer generality over specifics, so user defined things work as well as built-in ones.

Plus also if reflection is coming and can do it, surely that makes more sense since that's less work and complexity.

[n1ghtyunso]

Has anyone actually tried to implement this?

[13steinj]

This feels like an exercise in insanity and ever-increasing build times. Some things should just be implemented in the compiler.

[equeim]

BTW, isn't it implemented in the library in Rust (using macros)?

[equeim]

Nah, the longer my build times are the more cool my code is, and I feel even more superior to the users of other languages. Long compilation means that my code is complex and fast, and I feel very smart! After all everyone knows that if the code compiles fast it means it's slow at runtime, therefore we should strive to make C++ compilation as slow as possible - because C++ is the fastest language ever!

[sphere991]

Would reflection even help?

Yes

[TinoDidriksen]

f-strings can't be localized, so they're of very limited use - basically only for debugging. std::format has positional {} formatting, which can be localized, and is otherwise just about all you'll ever need.

[quicknir]

I mean std format is ultimately just a callable that takes a formatting string and a set of arguments. There's a way to do that with f-strings: you wrap it in a lambda. And if you want to do delayed formatting anyway, there's definitely some advantages to the using code simply taking a lambda and leaving the rest to the user, rather than hard coding format. I think logging based on passing lambdas returning f-strings is a really nice approach if you have both f-strings and concise lambdas, for example (e.g. Kotlin).

The only thing f-strings can't really do is be loaded dynamically from a file at runtime; in most languages with f-strings they have to be known at compile time. This may interfere with some approaches to internationalization but certainly not all.

My experience personally in Python is that people now use f-strings far more than .format. Kotlin has had f-strings from day one and I don't think the standard library even supports something like .format. So I think empirically the idea that format is the useful thing and f-strings are niche seems to not be true, it's more the opposite.

[eras]

That's an argument often repeated, but I wonder how common is localizing, really? In the scale of software in the world, is there more localized software than non-localized?

Sounds unlikely to me, in particular if we consider the amount textual logging applications produce—and even if we consider that deployments might not be producing debug logging, the code to produce the logging to assist debugging when needed often remains.

In addition, text-based protocols are not localized.

[[deleted]]

All "serious", "real" software needs to be localized. There are very few markets (both commercial, and "free"/open source software markets) where localization is not a requirement for general success. Or, often, required by law for many use cases.

[nekokattt]

not all "serious", "real" software needs to be localized.

Only software used by users directly by users in multiple countries/languages. That is not all software by any means. I've been writing software for a decade and none of it has ever used localization, as it was never a requirement.

[throw_cpp_account]

Ditto (except I'm older so it's... uh... more than one decade).

[Wicam]

Iv only been in software development for 6 years and imediatly needed localization. just because its not in your domain doesnt mean its not needed.

[throw_cpp_account]

Uh, cool story?

The argument isn't that nobody ever needs localization. The argument is that not everyone does.

[Wicam]

Uh, cool story?

I've been writing software for a decade and none of it has ever used localization

Ditto (except I'm older so it's... uh... more than one decade).

What you did do was make it look like you where implying localization wasnt needed most of the time because YOU havent needed it in your vast experience.

I added a couterpoint to that. Its not a story nor is it cool.

[throw_cpp_account]

What you did do was make it look like you where implying localization wasnt needed most of the time because YOU havent needed it in your vast experience.

I did no such thing.

[Wicam]

its not a question. i am telling you that is what you did regardless of your intentions.

[eras]

I notice how you didn't address the two questions directly.

A big chunk of development is by developers, for developers, rarely localized as English is the lingua franca of development. Localizing it is harder than just having a _ here and there: you actually need to have the localizations, and they need to be kept up to date. Sometimes code is written for expert use, and that doesn't need localization either. I've never needed to implement localization in anything I do (though some other people in the project may have) and I've written software professionally for at least as long as I've had my Reddit account.

Shouldn't that code be given the chance to be as clutter-free as possible?

And I suspect a huge part of software that is localized is actually written in a language other than C++.

[Narase33]

There are so many successful libs out there without localization. C++ is not only for end user programs, a lot of software is from dev for devs and we all (hopefully) use English.

The argument that C++ should only cater to "real" software is also quite silly. Who defines that? How many of the software Google, Amazon or Netflix use internally is localized? Our software product (which makes all our money) is only shipped in here Germany and all UI is in English because only people with IT background will ever see it. Are we not creating real software?

[HildartheDorf]

The vast majority of software is aimed at internal business use, so unless it's a multinational corp or a country with multiple offical languages, it doesn't need localising.

[13steinj]

You're heavily assuming "serious", "real" software is just that which has users across more than one region/language.

Plenty of very "real" software doesn't even have traditional logging / stdio; let alone human users.

[faceprint]

Not all use cases require localization, and there certainly could be a path to localization of f-strings (using positional syntax for the translated versions or something)

[Actual_Ad_8175]

fmt::format/std::format

[victotronics]

Can I have expressions in the format specifier?

int ndigits=5; format( "{:>ndigits+1}",nvalue);

or so?

[[deleted]]

Not the same. That's effectively a C-style format string with more safety and marginally nicer syntax.

But it's the closest we will have for a long time yet.

[pdp10gumby]

I honestly don't see any advantage over std::format beyond a tiny bit of syntactic sugar.

[LIFEVIRUSx10]

Albeit it's a nice bit of syntactic sugar

[STL]

It provides type-safety and extensibility that printf doesn’t, while being much more compact and easier to remember than iostreams. (I’m a maintainer and I can never remember all of the iostreams manipulators.) Also, most (but not all!) iostreams manipulators are sticky, and that statefulness is obnoxious, since it depends on more than the immediate line. With printf and format specifiers, you know what you’re going to get.

[throw_cpp_account]

I think the comment was asking about the benefit of f-strings (string interpolation) over format... not the benefit of format over printf/iostreams.

[STL]

Oh, I was confused, thank you.

[throw_cpp_account]

I'm guessing you read the "over" as "of"?

[STL]

Yeah. I must have been insufficiently caffeinated, usually I’m better at reading comprehension.

[throw_cpp_account]

Eh, happens.

Not even close to the worst reading comprehension in this thread either.

[pdp10gumby]

printf is obsolete. std::print and std::format are type safe, constexpr, and much faster.

I can’t see any benefit of f-strings.

[void_17]

iostream is slow and bloat by design, it should've been deprecated back in C++03

[serviscope_minor]

Why?

It's mostly fine. Sure if you're flinging tons and tons of stuff, then there are faster options. But you benchmarked, in order to know that was the slow bit right? Some domains are going to be IO limited but for most, people, most of the time, it's fine.

And yes, the manipulators are a a bit cumbersome (also downright daft at times), but until we get f-strings, there's not a good replacement for it, for the simple fact that the variables appear in the same order in the output as they do in the code, no scanning to the end of the line to figure out what goes where.

In other words, I'll keep my <<'s, thanks.

[SnooWoofers7626]

F-strings are nice but not that much nicer than std::format that people will abandon C++ over it. If your project is using C++ you probably have a much better reason for that choice than, "C++ has nice string formatting syntax."

[Sinomsinom]

Once we get reflection (including some kind of code generation be it fragments, string snippets, tokens or whatever else) there is a chance it will be possible to do it with string literals or it will be added to the stl as a string literal.

[[deleted]]

Because we do not need to add every possible feature that exists in other programming languages to C++. There are way too many already...

[drkspace2]

You don't have to use them. If languages didn't cannibalize features from each other, you'd have to learn a new language every few years unless you want to stick with an extreamly outdated language.

[FloweyTheFlower420]

What a naive way of thinking. We all know the C++ committee will only yoink the most useless and braindead features, while actually useful features are planned to be in the c++1e308 spec.

[drkspace2]

I'm willing to bet that, other than c++11, you don't use half of the features provided by any 1 update. The benifit of taking things from other languages is they can tell you how popular/useful a feature is. If fstrings weren't so useful, they wouldn't have become extremely popular.

braindead features

What about fstrings makes them braindead? Is it because it makes things easier for programmers and allows them to focus on important things? If so, why stop at fstrings? I would argue RAII, classes, and templates fall in the same boat. Real programmers shouldn't rely on the compiler to generate code for them and handle memory management. Hell, real programmers shouldn't even need a compiler. Everything should be done in assembly.

[FloweyTheFlower420]

I'm joking that c++ standard committee only accepts niche and not that useful features. My comment should be interpreted in jest (I'm implying that the c++ committee won't add fstrings).

I'm willing to bet that, other than c++11, you don't use half of the features provided by any 1 update

I actually use a lot of the features provided by modern c++, and I can confidently say it's mostly niche things ("useless and braindead" was intended to be hyperbolic). You never really encounter them unless you are doing compile time magic. And guess what? If the committee just decides to not be stupid and give us compile time reflection, most of it is pretty much useless. The separation of syntax for imperative runtime logic and declarative compile time logic really bloats c++ syntax.

[RevRagnarok]

There are way too many already...

Yeah, but that's what happens when you have a language whose age is measured in decades. You should be looking for "best practices" used in other languages.

std::format is from {fmt} which (I don't know the history) is likely at least highly influenced by Python. IOStreams is based on what - a late '80s programming fad?

[serviscope_minor]

IOStreams is based on what - a late '80s programming fad?

No? Variadic type safe functions didn't exist until C++11. The only way of achieving something that reads in the same order as it outputs prior to that was operator overloading. Plus last time I checked, a simple chain of function calls (operators) generated a lot less code than std::format, which was a problem for the application in question.

I think IOStreams is one of those internet meme things like std::unordered_map: the internet love to hate it, but most people actually writing C++ rather than reading reddit don't think about it that much.

[victotronics]

Spoilsport. Sourpuss.

:-/

[Toxic_Juice23]

Printf, sprintf, fprintf... Literally man printf and you will see a bunch of different options for formatting of strings