SF.net SVN: avogadro: trunk

Development
1

So, this is a good point you make (renaming the functions) but at the
same time I am hesitant to give in to the naming scheme used by OB in
our code. At the same time i’m not going to wrap EVERY function from
OBMol just to make the API look good. But i think for the avogadro
code we shouldn’t mix and match just because of the API. Unfortunatly
we’ll just have to rely on the devs to distiguish between the two. If
you want to do this, what about vector3d() and setVector3d()?

(Sat, Mar 24, 2007 at 05:00:56AM -0700) benoitjacob@users.sourceforge.net:

Revision: 216
http://svn.sourceforge.net/avogadro/?rev=216&view=rev
Author: benoitjacob
Date: 2007-03-24 05:00:55 -0700 (Sat, 24 Mar 2007)

Log Message:

In class Atom: Rename position() to GetVector3d() and setPosition() to SetVector3d().
This underlines the fact that they’re just wrappers for GetVector() and SetVector() from OBAtom,
doing casts with Eigen::Vector3d.

Rewrite these functions to make sure they don’t cause copies, and inline them. Add documentation.
A “rationale for inlining” is provided in comment, to justify that inlining isn’t dangerous here.

Modified Paths:

trunk/avogadro/src/plugins/draw.cpp
trunk/libavogadro/src/camera.cpp
trunk/libavogadro/src/primitives.cpp
trunk/libavogadro/src/primitives.h

This was sent by the SourceForge.net collaborative development platform, the world’s largest Open Source development site.

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Avogadro-updates mailing list
Avogadro-updates@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-updates

2

On Sunday 25 March 2007 05:19:36 you wrote:

So, this is a good point you make (renaming the functions) but at the
same time I am hesitant to give in to the naming scheme used by OB in
our code. At the same time i’m not going to wrap EVERY function from
OBMol just to make the API look good. But i think for the avogadro
code we shouldn’t mix and match just because of the API. Unfortunatly
we’ll just have to rely on the devs to distiguish between the two. If
you want to do this, what about vector3d() and setVector3d()?

I understand your concern here. Yes, I’m OK with vector3d() and setVector3d(),
but it’s not perfect either because the type Vector3d has an uppercase V. But
yes, go ahead with that.

I think that this is only a temporary solution anyway. I’m still having plans
for a Eigen 2 that would be good enough to cover all the needs of OpenBabel 3
(and I can see some advanced needs like sparse solving). Then, both OpenBabel
and Eigen would use Eigen::Vector3d and no conversion would be needed.

Cheers,
Benoit