Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F-strings for C++26 proposal [pdf]

open-std.org

Post reply on HN
Print view View original

31–40 of 216 posts

Re: F-strings for C++26 proposal [pdf]

#31

Post by FpUser »

ryandrake wrote: post #27
dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

To me moving from C++11 to 17 and then 20 was just a matter of convenience. When digging on how to do this and that I've found few things that just saved my time here and there. Also couple of valuable libs I wanted to use required newer C++ versions.

Re: F-strings for C++26 proposal [pdf]

#32

Post by edflsafoiewq »

vitus wrote: post #30
ryandrake wrote: post #27

Earlier quoted context omitted.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…

17 is worth it for std::filesystem alone. It also has optional and variant.

Re: F-strings for C++26 proposal [pdf]

#33

Post by dataflow »

ryandrake wrote: post #27
dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

constexpr in 11 vs 14 was night and day difference.

Re: F-strings for C++26 proposal [pdf]

#34

Post by ggm »

I'm going to make an asinine prediction. We will be exploring F-strings in future languages in 100 years time, encountering the same problems and questions.

I still use printf semantics in Python3 despite trying to get with the program for symbolic string/template logic. I don't need to be told it's better, I need some Philip-K-Dick level brain re-wiring not to reach for

  "%d things I hate about f-strings\n" % (int(many()))
modes of thinking.

Re: F-strings for C++26 proposal [pdf]

#35

Post by unit149 »

vitus wrote: post #30
ryandrake wrote: post #27

Earlier quoted context omitted.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…

[dead]

Re: F-strings for C++26 proposal [pdf]

#36

Post by _zagj »

dataflow wrote: post #33
ryandrake wrote: post #27

Earlier quoted context omitted.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

constexpr in 11 vs 14 was night and day difference.

constexpr "if" statements (C++20) are also a game-changer.

Re: F-strings for C++26 proposal [pdf]

#37

Post by alterom »

Yeah, I really missed ubiquitous C preprocessor macros in C++, so let's bring them back, but now inside string literals. Sweet.

Seriously, I just keep being amazed that people are running with the idea of having a full-blown untyped and unchecked formatting mini language (that's what libfmt, which became C++20 format, literally calls it) inside string literals — i.e., the part of the source code that you're specifically telling the compiler to not treat as code.

Think about it for a minute.

Re: F-strings for C++26 proposal [pdf]

#38

Post by darknavi »

vitus wrote: post #30
ryandrake wrote: post #27

Earlier quoted context omitted.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…

Designated initializers are so nice. Even though they have C++-isms like required order, it adds safety and readability to code.

Re: F-strings for C++26 proposal [pdf]

#39

Post by HeliumHydride »

alterom wrote: post #37

Yeah, I really missed ubiquitous C preprocessor macros in C++, so let's bring them back, but now inside string literals. Sweet. Seriously, I just keep being amazed that people are running with the idea of having a full-blown untyped and unchecked formatting mini language (that's what libfmt, which became C++20 format, literally calls it) inside string literals — i.e., the part of the source code that you're specifica…

Format strings in C++ are checked completely at compile time. There are no hacks or compiler intrinsics involved (like what C does for printf to verify format strings).

Re: F-strings for C++26 proposal [pdf]

#40

Post by jandrewrogers »

alterom wrote: post #37

Yeah, I really missed ubiquitous C preprocessor macros in C++, so let's bring them back, but now inside string literals. Sweet. Seriously, I just keep being amazed that people are running with the idea of having a full-blown untyped and unchecked formatting mini language (that's what libfmt, which became C++20 format, literally calls it) inside string literals — i.e., the part of the source code that you're specifica…

Eh? C++20 format is checked at compile-time. This has been possible ever since string literals became constant expressions. These features are within the standard compile-time capabilities. People have done impressive compile-time parsing and codegen using it.
Post reply on HN