Hi,
I guess we might end up happier with `operator()` instead of `run()` for
several reasons:
* There are lots of places where the stdlib uses `operator()` and
implements algorithms that way; my personal impression is that
following stdlib-conventions often ended way nicer with newer
standards than inventing your own. (See Qt's map-iterators and how
badly they interact with range-for)
* It would be how C++-lambdas do it. (again implying that this is what
the ISO-committee likes)
* This API would be compatible with simple functions, making trivial
things trivial, without compromising on more advanced techniques.
* Instead of a base-class we could just alias std::function which would
give us structural typing here (the python-fans of you may like
that, especially since this wouldn't compromise on type-safety)
I suspect however that this ship has already sailed. If not I would
however strongly recommend to use that approach.
Concerning the returnvalues: Could you elaborate on that, since I don't
really see the problem that this solves, especially since returning more
than one value is nowadays of acceptable complexity in c++? ¹
Returning a value directly is usually the by far fastest way that also
doesn't have the problem of wasting space in the class, the BIG problem
of returning a non default-constructable type (you need some kind of
optional-type for that, which can certainly be done, but further
increases complexity), and dealing with early calls to `getResult()`
(before the algorithm has executed, it is not obvious how to handle that
case, while for returnvalues that problem just doesn't exist).
Concerning the function-arguments: You are certainly right with the
approach to pass several of them in the ctor, I would however recommend
to leave some room there, since sometimes the benefits of being able to
call the same functor twice with slightly different arguments might be
significant: Just think of Dijkstra: If we need to get the distances of
different places to the same starting-point on the same graph, we would
profit enormously from being able to pass end-note as argument and
reusing the structures build so far. OTOH we wouldn't profit in any way
from reseting the starting-node or the graph, so those should be ctor-args.
Best regards,
Florian
[1] std::tuple<int, float, std::string> my_fun();
auto i = int{};
auto d = double{}; //sic
std::tie(i, d, std::ignore) = my_fun();
Since this appears to be a quite regular demand, the future-direction of
the standard even seems to be to somehow allow creating a new variable
in the call to `std::tie`.
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigr??e : 819 bytes
Beschreibung: OpenPGP digital signature
URL : <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20141029/13460da3/attachment.sig>