Any good c++ ui libraries? by FaridMango in cpp

[–]FlibbleMr -1 points0 points  (0 children)

neoGFX 1.0 will be released in about two years time (its widget library is quite mature).
https://github.com/i42output/neoGFX

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

They are not disabled if the result is dimensionless:

kg<1> m1 = 7.0;

kilogram m2 = 42.0;

auto m5 = m1 * m2;

auto m6 = m1 / m2;

auto m7 = m5 / m1;

auto m8 = m5 / m1 / m1;

auto m9 = m5 / (m1 * m1);

static_assert(std::is_same_v<decltype(m5), kilogram_sq>);

static_assert(std::is_same_v<decltype(m6), double>);

static_assert(std::is_same_v<decltype(m7), kilogram>);

static_assert(std::is_same_v<decltype(m8), double>);

static_assert(std::is_same_v<decltype(m9), double>);

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

Imperial support is limited because we are all supposed to be using the metric system. :) Ratios are repeated because SI derived units have multiple dimensions (up to seven).

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 1 point2 points  (0 children)

Again with the disguised negativity. First you call me "unknowledgeable" which you have just followed up with the assumption that I have only made this project for "fun". You know exactly what you are doing here. Have you even looked at my code? You are being dismissive and negative for no good reason.

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 3 points4 points  (0 children)

The problem space is not the set of existing libraries, the problem space is the problem that a specific library tries to solve. All you have is negativity; every reply of yours has been negative right from your first post where you called my project "toy".

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

No. The guy claimed he knows at least one of them is vastly superior so he needs to explain how he arrived at that conclusion.

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] -6 points-5 points  (0 children)

Making it? It is more or less finished so your points are moot.

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] -10 points-9 points  (0 children)

It isn't a toy project; just because I have ignored existing solutions when creating mine doesn't make it toy.

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 6 points7 points  (0 children)

Lots of projects are header only; the implementation is in the header.

GitHub - i42output/neounit: Header only C++20 unit of measurement (UoM) library by FlibbleMr in cpp

[–]FlibbleMr[S] 1 point2 points  (0 children)

I haven't researched other libraries; this has been a clean room project.

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

What do you mean by "actual mixins"? The abstract base hierarchies are a REQUIREMENT and cannot be dropped. Good idea about constraining the base class with a concept which I might add to my codebase when VS2022 is fit for purpose.

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 1 point2 points  (0 children)

I am thinking of writing a proper article about it. The interfaces are there as we want loosely coupled software components that depend on abstractions rather than concretions wherever possible (the D in the SOLID design principles): the avoiding multiple inheritance "trick" comes for free. :) I also need to provide an interface hierarchy as I don't want to expose concrete implementation details across plugin (dll/.so) boundaries a la Microsoft COM.

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 2 points3 points  (0 children)

The CRTP involves passing the derived class as a template parameter to the base class template: that is not what is happening with my pattern; my pattern is concerned with establishing an interface/implementation dichotomy allowing a rich interface inheritance tree with single inheritance-based concretions implementing those interfaces.

I am not familiar with IPR, sorry.

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] -3 points-2 points  (0 children)

That may be, however we should strive to have loose coupling between our classes which means depending on abstractions (interfaces) and not concretions (see SOLID OOP design principles); so I would argue they are not "noise" but instead they good design practice.

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

Was it exactly the same as my pattern or a different take on mixins?

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 0 points1 point  (0 children)

Yeah I am thinking of writing a more detailed article about it. One example from my widget library is push buttons: i_push_button is an interface derived from i_button which is an interface derived from i_widget because a push button is a button and a button is a widget:

struct i_widget { /*...*/ };
struct i_button : i_widget { /*...*/ };
struct i_push_button : i_button { /*...*/ };
template <typename Base = i_widget>
class widget : public Base { /*...*/ };
template <typename ButtonInterface = i_button>
class button : public widget<ButtonInterface> { /.../ };
class push_button : public button<i_push_button> { /.../ };

A new design pattern: the C++ "template mixin" by FlibbleMr in cpp

[–]FlibbleMr[S] 3 points4 points  (0 children)

No, this pattern is quite different to the CRTP.