It is a featureful formatting library, not simply a library for slow printing of ints and strings without any modifiers. You can't create a library which is full of features, fast, and small simultaneously.

You'd hope the unused stuff gets stripped out but I don't know much about this topic so not going to argue.

Ffunction-sections and fdata-sections would need at a minimum to be used to strip dead code. But even with LTO it’s highly unlikely this could be trimmed unless all format strings are parsed at compile time because the compiler wouldn’t know that the code wouldn’t be asked to format a floating point number at some point. There could be other subtle things that hide it from the compiler as dead code.

The surest bet would be a compile time feature flag to disable floating point formatting support which it does have.

Still, that’s 8kib of string formatting library code without floating point and a bunch of other optimizations which is really heavy in a microcontroller context

I think this is one scenario where C++ type-templated string formatters could shine.

Especially if you extended them to indicate assumptions about the values at compile time. E.g., possible ranges for integers, whether or not a floating point value can have certain special values, etc.

You’d be surprised. I’m pretty sure std::format is templated. That doesn’t mean that it’s still easy to convince the compiler to delete that code.

> it’s highly unlikely this could be trimmed unless all format strings are parsed at compile time

They probably should be passed at compile time, like how zig does it. It seems so weird to me that in C & C++ something as simple as format strings are handled dynamically.

Clang even parses format strings anyway, to look for mismatched arguments. It just - I suppose - doesn’t do anything with that.

That’s passed at compile time via template arguments and/or constexpr/consteval. Even still, there can be all sorts of reasons a compiler isn’t able to omit something as deeply integrated as floating point formatting from a generic floating point library. Rust handles this more elegantly with cargo features so that you could explicitly guarantee you’ve disabled floating point altogether in a generically reusable and intentional way (and whatever other features might take up space).

It’s also important to note that the floating point code only contributed ~44kib out of 75kib but they stopped once the library got down to ~23kib and then removed the c++ runtime completely to shave off another ~10kib.

However, it’s also equally important to remember that these shavings are interesting and completely useless:

1. In a typical codebase this would contribute 0% of overall size and not be important at all

2. A codebase where this would be important and you care about it (ie embedded) is not served well by this library eating up at least 10kib even after significant optimization as that 10kib that is intractible is still too large for this space when you’re working with a max ~128-256kib binary size (or even less sometimes).

fmt support full compile-time processing of strings with FMT_COMPILE though: https://fmt.dev/latest/api/#format-string-compilation

The usual case is that libc is linked dynamically so it's not a problem spending a few KB for the library.

And run time format strings are a concise encoding for calling this functionality. I would assume that compile time alternatives take more space.

It is indeed possible to remove unused code with techniques like format string compilation but that's a topic for another post.

The design of any library for a microcontroller and an "equivalent" for general end user application is going to be different in pretty much every major design point. I'm not sure how this is any more relevant to fmt than it is just general complaining out in the open.

The code for an algorithm like Dragonbox or Dragon4 alone is already blowing your size budget, so the "optional" stuff doesn't really matter. And that's 1 of like 20 features people want.

>I can assure you that when writing code for microcontrollers with 2 kilobytes of code space, we don't include a 14 kilobyte string formatting library...

then the thing to do is publish the libraries you do use, right, then document what formatting features they support? then other people might discover more and clever ways to pack more features in than you thought of

otherwise, I don't get your point.

I don't think the requirements for your specific programming niche should influence the language like that. Your requirements are valid, but they should be served by a bottom of the barrel microcontroller compiler rather than the language spec.

It’s relevant because the author mentions microcontrollers as the reason for focusing on binary size.

There are many orders of magnitude difference between smallest and higher end microcontrollers. You can have an 8bit micro with <1k of ram and <8k of flash memory, and you can have something with >8MB of flash memory or more running a RTOS possibly even capable of running Linux with moderate effort. In the later case 14k of formatting library is probably fine.

Pretty much anything in the Arm M0+ will be in the 4kb / 8kb / 16kb flash range and anything in the M3 class will typically be in the 64kb / 128kb flash range. These are small microcontrollers, yes, but they the typical microcontroller I would reach for when doing something that is not algorithmically intensive. Microcontrollers such as this are more than capable of responding to user input, running an LCD screen, or interfacing with peripherals. With 128kb maybe I could burn 14kb (~11%) on a string formatting library, but that seems pretty excessive to me.

It isn't designed to be small; it's designed to be a fully featured string formatting library with size as an important secondary goal.

If you want something that has to be microscopic at the cost of not supporting basic features there are definitely better options.

> I can assure you that when writing code for microcontrollers with 2 kilobytes of code space, we don't include a 14 kilobyte string formatting library...

No shit. If you only have 2kB (unlikely these days) don't use this. Fortunately the vast majority of modern microcontrollers have way more than that. E.g. esp32 starts at 1MB. Perfectly reasonable to use a 14kB formatting library there.

When you're designing something that sells for a dollar to retailers, eg. a birthday card that sings, your boss won't let you spend more than about 5 cents on the microcontroller, and probably wants you to spend 1-2 cents if you can.

Perhaps a singing birthday card doesn't need to format strings.

How else would you get nice looking logs for debugging it?

I kind of get where you're coming from but at what point do we admit that such use cases are the fringe and not the main?

> When you're designing something that sells for a dollar to retailers

Then you shouldn't prioritize compatibility with 1980s Unix code, which is what C++ is for.

Sure, but such extreme use cases are rare and don't need to be constantly brought up.

Even on larger microcontrollers you often have to write a bootloader...

Ok but most of these use cases don't link to the standard libs anyway, even if you're writing a C program.

Very occasionally I guess. They're almost always bare metal.

You still want a bootloader to support firmware updates, typically in the first 8 kB of flash or something like that.

Good point. I guess don't use `fmt` for that...

> esp32 starts at 1MB

Which models? The most I've ever seen on an ESP32 is 512KB of SRAM.

I think they are talking about the flash. The code is by default run from flash (a mechanism called XIP execute in place). But you can annotate functions (with a macro called IRAM_ATTR) that you want to have in ram if you need performance (you have to also be careful about the data types you use inside as they are not guaranteed to be put in RAM).

Sure, but there are also microcontrollers with a lot more space. This probably won’t ever usefully target the small ones, but that doesn’t mean it isn’t useful in the space at all.

As someone coming into this programming space, is it common to be running a debugger that can read the float, as opposed to someone brand new to the space printing out a value for debugging. Not specifically comments like yours, but in general the assumption that others should know their tools as strongly as those profess in limited environment spaces, makes it seem that this is a space only for those with a high level of knowledge. That is absolutely not a knock on your knowledge or ability if that is just how things are, I'm sure there are specific areas of computing that require a vast knowledge of how things work without having a library to debug your issues into the way a simple print statement works. I have worked in limited environments, so I am curious specifically about a microcontroller environment like londons_explore specified.

I learned to program in Atari 8-bit systems, and know there are limitations on what you can output. londons_explore had a completely valid comment. I was just looking for a perspective for developers getting involved in microcontroller environments, and how they could best debug their code. We all know that a debugger is better than a "print" statement, but not always the fastest, especially with logic. If my answer is just "debugging", and there isn't another, that satisfies me. I am always looking for unique ways developers solve problems in ANY environment, because I would enjoy being able to work in any environment that's best for the solution being provided. I guess I have been blessed with environments where the client is willing to pay for something higher-level than what is actually required.

I enjoy all aspects of development across devices, so I hope nobody took my comment as a challenge, it absolutely was not.

> I can assure you that when writing code for microcontrollers with 2 kilobytes of code space, we don't include a 14 kilobyte string formatting library...

I'm pretty sure you wouldn't use C++ in that situation anyway, so I don't really see your point.

If you get rid of the runtime, which most compilers allow you to do, C++ is just as suitable for this task as C. Not as good as hand-rolled assembly, but usable

Okay, vtables in 2kb code space?

Where are the vtables coming from if you use no inheritance and no memory allocation?

Why program in C++ if you don't use any of its features? You're just writing C in disguise.

A C in disguise with better strong typing, compile time programming that beats hands down the preprocessor, while having the preprocessor available if one insists in using it, being able to design abstractions with bounds checking, namespaces instead of 1960's prefixes,....

Template specialization means more generated code, which, again, must fit in 2kb.

On very old archs (16bits, 8bits), there was no OO, because the code could not be complex enough to warrant it. It could not be complex because there wasn't room enough.

That being said, there are templated libraries (like fmt...) which may result in zero overhead in code size, so if the thread OP is using C++, then surely he could also use that library...

> Template specialization means more generated code, which, again, must fit in 2kb.

modern compilers are way better about de-duplicating "different types but same instruction" template specializations so it's less of an issue than you may expect , especially if you're coming with template specialization generation from the mid/late 2000's.

No different from copy-paste hard to debug preprocessor code.

This is not my claim.

It actually is, as it is voiced in a way as if preprocessor was better than using templates.

You'll have to quote me, I don't see where I am implying that.

But anyway, the point that I am refuting is the use of C++ to write programs for such an extremely constrained runtime environnement, and at the same time refuse to use this library (which is template based afaik).

"Template specialization means more generated code, which, again, must fit in 2kb."

Have fun,

"Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17"

https://youtu.be/zBkNBP00wJE?si=im0ga3rW08mR8g8f

That quote does not imply anything about C macro being better in any way, but I am nevertheless delighted that you could prove me wrong somehow. Thank you for this!

I don't write anything new and use inheritance anyway.

Even in an embedded context you have classes and destructors, operator overloading and templates. You can still make data structures that exist in flat constrained memory.

Sure, but 2kb code space? What sort of class hierarchy can you possibly use in so little space?

C++ has namespaces, C does not. That one singular feature makes C++ worthy of being used over C.

What class hierarchy?

Even demo scene people use C++ and windows binaries can start at 1KB. Classes, operator overloading and destructors are all still useful. There is no reason there has to be more overhead than C.

Right, they also tend to use special tools to crunch their binaries down to acceptable size, afaik.

That said, that's a very good point. Maybe they'd even use that fmt library?

What point are you even trying to make now? Every time you've been wrong about something and corrected you don't acknowledge it and just move on to something barely related.

https://en.wikipedia.org/wiki/Gish_gallop

You said this:

I'm pretty sure you wouldn't use C++ in that situation anyway, so I don't really see your point.

People have pointed out to you why you both can and would use C++, especially in place of C.

Thank you for bringing this to my attention. I will try to remember that

Let me coin a new term to help me in that task: the "swarm gallop", which would be that technique applied by a group of people, instead of just one person (somewhat like a DDOS).

Thank you.

You can use c++ yes and a lot of people do. You just keep the exceptions, stdlib and runtime in general at the door.

avrlibc's small variant of printf (which still has a ton of features) is like 600 bytes.

What do you use instead?

Iostream is… far bigger than this, for example.

most platforms come with their own libraries for this, which are usually a mix of hand coded assembly and C. You #include the whole library/sdk, but the linker strips out all bits you don't use.

Even then, if you read the disassembled code, you can usually find within a few minutes looking some stupid/unused/inefficient code - so you could totally do a better job if you wrote the assembly by hand, but it would take much more time (especially since most of these architectures tend to have very irregular instruction sets)

If you’re just going to use the platform built in, then the size of a third party library doesn’t matter to you.

If you only have 2 kB of code space, you would likely be doing custom routines in assembly that do exactly what you need and nothing more.

Right - so no matter how small libfmt gets Op isn’t going to use it

I presume the sort of custom routines that GP described?

Curious what space space you work in? What kind of devices, what are they used for?

Not me but a friend. Things like making electronics for singing birthday cards and toys that make noise.

But there are plenty of other similar things - like making the code that determines the flashing pattern of a bicycle light or flashlight. Or the code that does the countdown timer on a microwave. Or the code that makes the 'ding' sound on a non-smart doorbell. Or the code that makes a hotel safe open when the right combination is entered. Or the code that measures the battery voltage on a USB battery bank and puts 1-4 indicator LED's on so you know how full it is.

You don't tend to hear about it because the design of most of this stuff doesn't happen in the USA anymore - the software devs are now in China for all except high-end stuff.

Do any of those need a string formatting library?

Hotel safe might, if it logs somewhere (serial port?).

The others may have a serial port setup during development, too. If you have a truly small formatter, you can just disable it for final builds (or leave it on, asssuming output is non blocking, if someone finds the serial pins, great for them), rather than having larger rom for development and smaller for production.

mostly used for debugging with "printf debugging" - either on the developers desk, or in the field ("we've got a dead one. Can you hook up this pin to a USB-serial converter and tell me what it's saying?")

> strings are ~4 instructions (test for null terminator, output character, branch back two).

that's C strings. You also need to handle (size, data) strings like std::string_view

For the record, here's what fmt allows (from the docs):

    fmt::print(fmt::emphasis::bold | fg(fmt::color::red)
             , "Elapsed time: {0:.2f} seconds", 1.23);
    fmt::print("Elapsed time: {0:.2f} seconds"
             , fmt::styled(1.23, fmt::fg(fmt::color::green)  fmt::bg(fmt::color::blue)));
 
    fmt::print("{}", fmt::join(std::vector<int>{1, 2, 3}, ", "));

    fmt::print("strftime-like format: {:%H:%M:%S}\n", 3h + 15min + 30s);

you really think you can replicate that in 50 bytes?

Would someone writing code for a 2Kb microcontroller even be using full-fledged C++, or just C With Classes?

It's still full fledged C++, you just don't use many of the features, and the compiler leaves out all of the associated code.

Pretty easy to accidentally use some iostream and accidentally pull in loads of code you didn't want though.

To me the only reason to use C++ over C in that case is a the slightly stronger type-checking and maybe some extra syntactic sugar.

What? I mean, you realize that fmtlib is much more complicated than that, right? What you are describing is something very basic, primitive by comparison. I’m also puzzled why you think floats are not used by many programs, that’s kind of mind-boggling. I get that you wouldn’t load it on a microcontroller but you wouldn’t do that with the standard library either.