fbbdev / plot Goto Github PK

When calculating UTF-8 string length for alignment, either:

• Properly count Unicode character width (see https://sourceforge.net/p/joe-editor/mercurial/ci/default/tree/joe/unicode.c#l504)

or at least

• Count grapheme clusters (i.e. ignore non-printable and combining characters)

The first choice should be preferred.

./src/plot/plot_lib.hpp:3915:11: error: no matching function for call to 'max'
          utils::max(1l, rct.p2.y/cell_rows + (rct.p2.y%cell_rows != 0)) }
          ^~~~~~~~~~
./src/plot/plot_lib.hpp:59:24: note: candidate template ignored: deduced conflicting types for parameter 'T' ('long' vs. 'int')
    inline constexpr T max(T a, T b) {
                       ^

Identical error in a few more places.

Fixed by adding this to utils:

template<typename T, typename _T>
    inline constexpr T max(T a, _T b) {
        return (a >= b) ? a : b;
    }

Probably should do this to min() too.

clang++-3.9
-g -MMD -MP -std=c++14

Design a plotting API (so that this library starts doing what it's meant to do 😄).
It should feature various axis options, plot styles, automatic scaling, function/range/container data sources, automatic label placement.
It should also be interoperable with the animation API to be implemented per #15.

An acceptable feature set should bring the library on par with UnicodePlots

In the end, it make more sense to just have a cmake build environment for everything.

The problem is with constexpr for multi-line functions. This is only supported with gcc series 5 or greater.

https://gcc.gnu.org/projects/cxx-status.html#cxx11

http://stackoverflow.com/questions/17004648/constexpr-why-just-a-return-statement

@fbbdev

Returning a pointer to an ivar from a const function is generally considered a dangerous behavior that should be avoided.

https://github.com/fbbdev/plot/blob/master/layout.hpp#L60

At a minimum, it should be a const pointer that is returned.

It would be nice to have a simple API to define, run and display animations.

@hjmjohnson I'm seeking your advice here.

After merging #8 and a small fix in class TerminalInfo, all -Wshadow warning are gone in clang. Gcc is still complaining, though, and it's being a bit too pedantic IMHO.

Clang seems to accept member shadowing at least in struct constructors (like Color), and this makes sense to me. Moreover, gcc complains about many cases like this:

BrailleCanvas& rect(Color const& stroke, Color const& fill, Rect rect, TerminalOp op = TerminalOp::Over)

Where argument rect would shadow the method. I don't think there could be confusion here and I believe it's a pretty common case. It seems I'm not alone (see [1] and [2]). Clang 3.9 takes it without complaints.

So the question is: should I fix those errors and enable shadow warnings on continuous integration builds, or leave the code as it is and keep building without -Wshadow? Or maybe switch CI build environment to clang?

This amounts to two changes:

• Support Windows Console API in terminal.hpp functions
• Implement Unicode console output through WriteConsoleW. This means switching to wstring and wostream, or setting up cout locale to convert UTF-8 to UTF-16 (with codecvt_utf8_utf16).

See:

• wostream fails to output wstring http://stackoverflow.com/questions/11610583/wostream-fails-to-output-wstring
• std::codecvt_utf8_utf16 http://en.cppreference.com/w/cpp/locale/codecvt_utf8_utf16

The last commit is 3 years ago... :sad: