81–90 of 216 posts
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(ma…
Earlier quoted context omitted.
What is this referring to? I would imagine whatever you consider recent competition is actually not that recent.
On the time scale of c++, rust is very recent. :-)
Earlier quoted context omitted.
Yes. There are a very small handful of early adopters in the year 2025 for a feature ostensibly added in C++20. So, like I said, modules don’t exist in practice and I’d be shocked if in 2030 modules were considered normal. C++11 was pretty game changing. C++14 and C++17 only took a few years to reach widespread adoption. It’s very safe to require C++17 today. C++20 was a little slower and because of the modules fucku…
> C++20 and beyond haven’t added much that’s worth upgrading for. std::format is pretty nice (although not yet available on Ubuntu 24.04 LTS. Lambda capture of parameter packs is actually huge! And ... I think it still remains to be see what the outcome of modules will be. One hopes (against hope) that the big payoff for modules will be in tool-ability of C++. IDE support for languages like C#, Java, typescript is va…
Visual Age for C++ v4.0 had a Smalltalk like experience with a database storage for the code, and Lucid Energize C++ already had something that people now know as LSP (Cadillac on their implementation), with incremental compilation and linking (at method/function level).
They failed commercially due to high prices and hardware requirements.
We have had C++ Builder for decades for GUI RAD development, Delphi/VB style, but due to how Borland went after the enterprise and various changes of hands, very few are aware that it exists and its capabilities.
C++ Builder with VCL was Java/.NET before these were even an idea looking for an implementation.
Problem now is that C++ has become a specialized tooling for high performance code, language runtimes, drivers and GPGPU, so you write 90% of the code in Java/C#/nodejs/..... and then reach out to native libraries, for various reasons.
Still, Clion, Visual Studio, C++ Builder, are quite good as far as development experience goes.
Earlier quoted context omitted.
how would this work with internationalized strings? especially if you have to change the order of things? You'd still need a string version with object ordering I would think
I'm skeptical that people would want to do this in a single expression.
So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose… This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers. Stop using C++ already!
It doesn't. Unfortunately, C++ programmers choose not to use basic safety features for performance reasons (or aesthetics, or disagreement with the idea that a language should take into account that a programmer might make a mistake, but at least performance is a good one), but C++ actually has quite a few tricks to prevent the memory management issues that cause C/C++ bugs.
Using modern C++ safety features won't completely prevent bugs and memory issues, just like using Rust won't, but the mess that causes the worst bugs is the result of a choice, not the language itself.
So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
Hah. What's interesting about this is that since it doesn't require everything to actually be converted to a string, one can implement things other than just printing. So you could also implement interpretation, eg: pylist = python(f"[ y*{coef} for y in {pylist} if y > {threshold}]")
cursor = mydb::sql(f"UPDATE user SET password={password} WHERE user.id={userid}")I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
C++ also has std::format, which was introduced in C++20. This is just sugar on top of it, except it also returns a container type so that printing functions can have overloads that format into a file or stream directly from an f-string, instead of going through the overhead of a temporary string.
Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.
So, the f-string in Python is "spelled" that way because another leading character was the only ASCII syntax left for such a thing. It's odd that PRQL and now potentially C++ might copy it. In the PRQL case it was a new thing so they could have chosen anything, double quotes (like shell interpolation) or even backticks, that seem to make more sense. Also the f- prefix was supposed to be short for format and pronounce…