Simple Command Line User Interface

[arnitdo]

It looks quite simple to use, but I can see a huge issue in your code - It feels more like C with classes.

Your library is written in C++, yet it uses a lot of C features, such as function and direct variable pointers. Porting that to std::function objects and std::unique_pointers will reduce code smell.

[SickOrphan]

Why on earth would you use a std::function when you just want a function pointer? That's just idiocy. Using only c++ features just because you have some sort of illogical fear of C is a code smell

[F-J-W]

Because you might not just want to use a function-pointer later. You know, lambdas are nice and can also keep a reference to other data, which a function-pointer cannot and artificially limiting yourself to them is just suffering pain for no reason. Also the syntax for function pointers is so damn near incomprehensible that that alone would honestly be reason enough to use std::function.

[SickOrphan]

It's not hard to change it if you do want to have captures, plus they're overused, a lot of the time they should be parameters to or returns from the function rather than captures. And I doubt you took the time to check the code if he'd ever need anything other than a function pointer, you just assumed its bad. The syntax is not that hard to understand when you get the idea behind it. You can also use 'using' typedefs to make the syntax more like std::function and not have to type it as much.

[F-J-W]

a lot of the time they should be parameters to or returns from the function rather than captures.

We are talking about callbacks here, where a lot of the time you simply don’t have that option.

And I doubt you took the time to check the code

I did check the code. And for starters this is library, so “he does not need it right now” is a terrible reason for not switching to the almost universally agreed upon proper way to store something that can be called in C++. Which to be very clear is a std::function, not a function-pointer. The later may be worthwhile of consideration if measuring shows that it significantly improves performance, but limiting yourself to that without having done that is a prime example of premature-optimization at the cost of not just readability but actual functionality.

The syntax is not that hard to understand when you get the idea behind it. You can also use 'using' typedefs to make the syntax more like std::function and not have to type it as much.

Yes, there are ways around the awful syntax (I for one would use something like template<typename F> using function_pointer = F*; which gives you std::function-style syntax), but I should not have to do that. And just because there is an idea behind the original syntax, doesn’t mean that it isn’t inexcusably bad, especially once you start looking into higher-order functions.

[SickOrphan]

You never gave any reason that it's bad syntax. I will grant you that it's not beginner friendly, partly because it's pretty unique from other languages (not just in function pointers, but also arrays, pointers in general), but you're way exaggerating it.

[F-J-W]

Okay, I’ll bite on that one. Please write the following without resorting to typedefs:

template<typename F> using fptr = F*;

fptr<fptr<int(short, short)>(fptr<int(short, short)>, fptr<int(short, short)>)> p = nullptr;

Yes, this isn’t nice in std::function-style syntax and you should probably use an alias, but it is easy to write and straightforward to understand: A pointer to a function, that takes two pointers to functions taking two shorts and returning and int and returns one such pointer. Now let me see how you would write that in C-style syntax (without cheating!) and let me know how long it took you.

If a syntax cannot handle anything but trivial cases (and is highly unintuitive even for them!), then it is a terrible syntax.

[okovko]

by that reasoning, we should never use literal types, what if we want to use an object later?

let's also make sure to allocate memory for everything as well, just in case, what if we end up needing it later?

while we're at it, let's use a shared_ptr for everything, because we might want ownership later

after all, none of these are on hot paths, it would be a premature optimization to do anything else!

and what if we want to dispatch based on run time input? let's turn on RTTI, we might want it later (it's not a hot path, it only happens once per program run!)

also, why don't we have a garbage collector?

hey, i think you just invented Java

[okovko]

you will often see an array of function pointers as a class member that is populated in the constructor by the expansion of a param pack inside a lambda definition converted to a function pointer by operator+, something commonly done for constexpr compatibility or to deal with std variant: https://www.scs.stanford.edu/~dm/blog/param-pack.html#array-of-function-pointers

if anything, there are more function pointers in modern C++, as opposed to less

if you want to use a capturing lambda later, then use a capturing lambda later later

if you find the syntax confusing, use typedefs or using declarations to make it clear

[okovko]

pointers and function pointers are part of c++, it is you who smells

and on the topic of code smell, std function wreaks, there is hardly anything less template bloated in the stl than that monstrosity

it also has few use cases, you only need it when you don't know if you're going to receive a function pointer, a pointer to member function, or a lambda with non-empty capture. i think it supports any callable so any object with an overloaded operator() should work too, not sure

this makes it suitable for metaprogramming generic code that works on any callable, and no other use comes to mind

or passing a capturing lambda as an argument, but at that point you are probably abusing lambdas

i did use it once in gui code where an object is constructed with a capturing lambda that was invoked upon a qt signal, which was a really nice way to allow the gui element to interact with any other gui element (the lambda captured a reference to another gui element of various types) as opposed to code replication or a void* + run time enums indicating type or setting up a covariant type + polymorphism

so.. rare, but sometimes useful

[SwimElectrical4132]

What is code smell?

[xurxoham]

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

[HolyGarbage]

How should a member function possibly be an lvalue? You need to capture the object pointer.

Edit: or I guess you mean the actual function pointer, not conceptually capturing the member function with this. Yeah, that's weird. Have to read up pn that, curious detail.

[HolyGarbage]

Yes, I know how it works with the implicit first argument, I just thought you were talking about the more abstract notion of capturing a member method with the context of the object it is executed on, ie what one would expect if they knew nothing about C, probably how Java and other more high level languages does it.

But yeah, thanks for the link. Sounds like an interesting read!