great. then any plan to add maxCoeff overload for lvalue reference to carry out the coord? thanks.
On Mon, Mar 25, 2019 at 12:50 AM Michael Hofmann <[email protected]> wrote: > I agree. Using pointers as output parameters (as opposed to > references) seems a bit inspired by the Google coding guidelines, but > these have always seemed, uhm, sub-optimal to me. > > I find the following much more consistent and obvious: > - const references (or values) designate input parameters, > - const pointers designate purely optional input parameters, > - non-const references designate output parameters, and > - non-const pointers designate purely optional output parameters. > > In this scheme, there is no confusion possible; a non-const reference > should never serve as input parameter. > But in most cases, non-optional output parameters should go into the > return type in the first place, and non-const references should be > avoided. > > Some may argue that it's harder to see at the call site what a > parameter is, i.e. without looking at the function declaration. In my > opinion this is negligible, but the cost for using pointers as output > variables is incredibly high: the function gets harder to use (have to > add that extra '*', which *should* mean optional!), and much easier to > mis-use (can simply pass nullptr -> boom!). > > Best, > Michael > > On Mon, Mar 25, 2019 at 5:56 AM Meng Zhu <[email protected]> wrote: > > > > trying to understand the justification here. wouldn't pointers as out > parameters easily lead to bugs, such as null pointers, or wild pointers? as > I read today's [eigen source here]( > https://github.com/eigenteam/eigen-git-mirror/blob/667b550a1f161ac85bc8f2013939a0adc10af12c/Eigen/src/Core/Visitor.h#L278), > `*rowPtr = maxVisitor.row;` looks like a real bug. with references you > > don't get this kind of bugs, so why not? > > > > as for maxCoeff to return coord, does it make sense to use tags to > express programmer intention, e.g., > > auto [value, row, col] = A.maxCoeff(Eigen::return_coord); > > > > basically a form of tag dispatching, but only for overload purpose to > live with the original version to cover all usage. > > > > On Fri, Mar 22, 2019 at 9:20 AM David Tellenbach < > [email protected]> wrote: > >> > >> Hello, > >> > >> > We must make sure that this does not introduce overhead if the > index(es) is not used. Perhaps with some template magic it is possible to > distinguish calling > >> > > >> > auto [value, row,col] = A.maxCoeff(); > >> > vs > >> > auto value = A.maxCoeff(); > >> > >> I guess it is not possible to realise something like this without > (unnecessarily) calculating the indices in the case > >> > >> auto value = A.maxCoeff(); > >> > >> If we allow the unnecessary index calculation this is easy to > implement. Distinguishing function calls based on return types is usually > really hard because return types are not used for template deduction. > >> > >> > If that is not possible, we could of course just give one method a > different name. > >> > >> Another alternative would be a static function maxCoeff(A) that returns > a struct (or a tuple) but this might introduce more confusion. > >> > >> Cheers, > >> David > >> > >> > On 22. Mar 2019, at 11:54, Christoph Hertzberg < > [email protected]> wrote: > >> > > >> > We must make sure that this does not introduce overhead if the > index(es) is not used. Perhaps with some template magic it is possible to > distinguish calling > >> > > >> > auto [value, row,col] = A.maxCoeff(); > >> > vs > >> > auto value = A.maxCoeff(); > >> > > >> > This would actually be very close to how Matlab "overloads" many > functions. If that is not possible, we could of course just give one method > a different name. > >> > > >> > Btw: I agree on not overloading for references, as it should be > obvious that these are out-parameters. O.t.o.h., with pointers there is > always the ambiguity if null-pointers are allowed or not. > >> > > >> > Christoph > >> > > >> > On 22/03/2019 09.45, Gael Guennebaud wrote: > >> >> We chose pointers to emphasise they are out parameters. I would not > add > >> >> overloads taking references but maybe a version returning everything > within > >> >> a struct to be used with C++17 structure bindings? > >> >> On Thu, Mar 21, 2019 at 3:27 AM Meng Zhu <[email protected]> wrote: > >> >>> hi, I noticed eigen maxCoeff function ( > >> >>> > https://eigen.tuxfamily.org/dox/classEigen_1_1DenseBase.html#a784e23ccbb39e7c57b70af386f94f8b5 > ) > >> >>> takes pointers to return the max entry coord, and there is no > overload to > >> >>> take reference type. is there a reason to not provide reference > access? > >> >>> thanks. > >> >>> > >> >>> Meng > >> >>> > >> >>> > >> >>> > >> > > >> > -- > >> > Dr.-Ing. Christoph Hertzberg > >> > > >> > Besuchsadresse der Nebengeschäftsstelle: > >> > DFKI GmbH > >> > Robotics Innovation Center > >> > Robert-Hooke-Straße 5 > >> > 28359 Bremen, Germany > >> > > >> > Postadresse der Hauptgeschäftsstelle Standort Bremen: > >> > DFKI GmbH > >> > Robotics Innovation Center > >> > Robert-Hooke-Straße 1 > >> > 28359 Bremen, Germany > >> > > >> > Tel.: +49 421 178 45-4021 > >> > Zentrale: +49 421 178 45-0 > >> > E-Mail: [email protected] > >> > > >> > Weitere Informationen: http://www.dfki.de/robotik > >> > ------------------------------------------------------------- > >> > Deutsches Forschungszentrum für Künstliche Intelligenz GmbH > >> > Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany > >> > > >> > Geschäftsführung: > >> > Prof. Dr. Jana Koehler (Vorsitzende) > >> > Dr. Walter Olthoff > >> > > >> > Vorsitzender des Aufsichtsrats: > >> > Prof. Dr. h.c. Hans A. Aukes > >> > Amtsgericht Kaiserslautern, HRB 2313 > >> > ------------------------------------------------------------- > >> > > >> > > >> > > >> > >> > >> > > >
