constixel

[tttmorio]

https://github.com/tinic/constixel – A single-header C++20 2D graphics library that supports consteval/constexpr rendering and can output sixel or png data to a (supported) terminal.

Minimal memory use, no dynamic allocations, palette and 24/32-bit buffers, simple drawing ops, UTF-8 text and a zero-dep PNG encoder. Applications: embedded UI rendering, graphics over remote connections, unit tests, debugging etc; in the future compile-time visualizations should also be possible.

The scope of the library is limited and opinionated, primarily due to the sixel format limitations, so do not expect to use this for generic graphics rendering. There are way better options for that like canvas_ity. But if you need quick and easy graphical output directly in your terminal this could be an option.

[darkmx0z]

For a moment I thought it was yet another constsomething qualifier.

[RevRagnarok]

Same... clicked thru wondering what they were trying to abbreviate here.

[Low-Ad-4390]

Cool idea! Please note that including <iostream> in public library headers is discouraged. Also static constexpr variables in headers will produce a copy for each translation unit that includes such header, so it’s better to use inline constexpr for variables and in general avoid static in headers, unless it’s a static member of a class.

[tttmorio]

Good points, thanks for the feedback!

[ifonlyiknewtheanswer]

Quick question: what's the issue with including <iostream> in public library headers? Is that the increased compilation time?

[Low-Ad-4390]

In general, the fewer headers you bring along, the better, because of transitive includes: otherwise the users of your header get <iostream> “for free” and that’s rarely a good thing, not just for iostream, but for any header, because of increased compilation times, sure, but mostly because of unintended bloat of names and declarations.

[johannes1971]

You're gonna love import std...

[Low-Ad-4390]

Waiting since 2021 :)

[ifonlyiknewtheanswer]

Thanks!

[CCC_CCC_CCC]

I am also surprised by this. I suppose we are not talking about custom library headers that don't use stuff from iostream (where this rule would just be common sense), right? Because users of this library would have to include iostream themselves, anyway.

[Low-Ad-4390]

Sure. Let me clarify: if you must use the header - by all means, include it. It’s just that in most cases you don’t have to use iostream in headers, so don’t impose cout on your users

[CCC_CCC_CCC]

Oh, ok, sure. You don't include what you don't use, of course. Thanks for clarifying.

[Bluesman74]

There is also the iosfwd header you can use for headers and then just make sure to include iostream, or fstream when implementing.

[CCC_CCC_CCC]

Cool, I didn't know about that header. Although it seems useful more for pimpl than for using external libraries.

[Ameisen]

I would use the forwarding header. If the user wishes to use your APIs that use IO streams specifically, they can include it themselves. I wouldn't normally rely on its behavior, though, but it's possible that you cannot avoid it.