danpla

Sony Xperia phones traditionally have a 3.5 jack and a normal screen (without holes and other nonsense for the camera).

These are some pretty bold statements.

* "They wouldn't exist in the first place" implies that ImGui was the primary reason and foundation for creating these programs. As if using the traditional retained mode GUI is so unbearable that without ImGui the authors would have abandoned the idea of creating these tools in the first place.

* "Or wouldn't be as full-featured" implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.

> I'm surprised this is so hard to comprehend?

Well, I'm surprised that some people keep presenting the immediate mode GUI as the silver-bullet alternative to the traditional GUI. Don't get me wrong: I understand that IMGUI is a great tool if you need to quickly add a throway GUI to a game, but otherwise there is a price to pay, both by the developer and the end user.

Well, if you have a traditional immediate mode API like:

    if (button("Start"))
        start();

The author talks about the code bloat, beacause of "an API that encourages custom formatter specification to live in a template". But at the end he mentions the standard solution to this problem:

> A preferable interface (I use, but also others AFAIK) is to check the type in a template (no choice there), and dispatch the formatting routine to somewhere that lives in a single translation unit.

So what prevents you from doing this with <format>? As I understand, the implementations of parse() and format() of std::formatter don't depend on the template parameters and can delegate to non-template functions residing in one CPP file. You can also provide additional wformat_parse_context/wformat_context overloads if you need wchar_t support.

Well, that's not always true; it's better to use a profiler.

In many cases, it's trivial for the compiler to inline objects (e.g., used as predicates for <algorithm> routines), resulting in better performance compared to the equivalent procedural code.

> running constructors and destructors is expensive

If the object is not polymorphic (and sometimes even if it is), the compiler can inline both the constructor and destructor, resulting in exactly the same assembly output as the procedural code.

That's why exceptions are called exceptions, not errors. If a routine called openFile() can't open a file, that's a pretty exceptional situation, and it's up to the caller to decide whether the exact reason is an error in their case.

The exception object is already a value that can have not only a message text, but also any data members, so why reinvent the wheel with sentinel objects, tuples, etc.?

> The examples in post, where you catch exception and re-raise Exception back are terrible - what's the point of them? There is no extra clarity, just verbosity. I would defect them in any code review.

Typically, you re-raise an exception after adding some content to it. This may be less important in Python, which gives you a great stack trace, but in a language like C++, the lack of context information makes the exception basically useless.

Indeed, but it's not an option if you have more than one email account on the same service.