Unused Warnings

I don’t know if we want to go Qt style or just removed names from
parameters but there is a Qt4 macro Q_UNUSED(x) that makes it so you
don’t get warnings about x being unused. shrug just throwing that out
there, i don’t care either way.


Donald

On Tuesday 22 May 2007 03:16:27 Donald Ephraim Curtis wrote:

I don’t know if we want to go Qt style or just removed names from
parameters but there is a Qt4 macro Q_UNUSED(x) that makes it so you
don’t get warnings about x being unused. shrug just throwing that out
there, i don’t care either way.

I hadn’t thought to check for alternate solutions. I have always liked the
signature with no variable name - it declares the intention not to use the
variable and you must consciously add it in if you begin using it. That said
I would happily go with whatever the policy was.

I couldn’t sleep and thought it would be nice to fix some fairly simple
compiler warnings… Sorry if it has been counterproductive. I have been
doing some other clean ups. I did want to ask about a few things I
encountered that seem like they should be cleaned but I am not sure if you
have plans for them.

In the engines there are public functions for rendering atoms, bonds and
molecules. In most engines they aren’t used. Can they be removed? If not
shouldn’t they be private functions? The bsdyengine and the stick engine also
implement the add/modify/remove primitive functions. Is that required and
does the m_update variable do anything?

As all engines are effectively dynamic engines now I didn’t know if the
bsdyengine description should also be updated. Benoit and I have also been
discussing some issues with custom engine settings and kalzium porting over
on the kalzium list - not sure what the ideal solution is just yet and I
would welcome any opinions. I seem to have wandered away from the original
subject a little though :wink:

Thanks,

Marcus

(Tue, May 22, 2007 at 02:50:36AM +0100) “Marcus D. Hanwell” marcus@cryos.org:

On Tuesday 22 May 2007 03:16:27 Donald Ephraim Curtis wrote:

I don’t know if we want to go Qt style or just removed names from
parameters but there is a Qt4 macro Q_UNUSED(x) that makes it so you
don’t get warnings about x being unused. shrug just throwing that out
there, i don’t care either way.

I hadn’t thought to check for alternate solutions. I have always liked the
signature with no variable name - it declares the intention not to use the
variable and you must consciously add it in if you begin using it. That said
I would happily go with whatever the policy was.

Actually, i think removing the name from the .cpp file is a good choice.
Can we still leave the arguments in the .h file but remove them from the
.cpp? Then it’s great, just so the doxygen stuff doesn’t get screwed
up.

I couldn’t sleep and thought it would be nice to fix some fairly simple
compiler warnings… Sorry if it has been counterproductive. I have been
doing some other clean ups. I did want to ask about a few things I
encountered that seem like they should be cleaned but I am not sure if you
have plans for them.

Blah, seriously, don’t worry about it. Nothing is couterproductive, i
didn’t mean to imply anything of the kind. Also, like Geoff says, if
code is commented you can remove it, it’s in SVN and if we ever need it
we can find it again.

In the engines there are public functions for rendering atoms, bonds and
molecules. In most engines they aren’t used. Can they be removed? If not
shouldn’t they be private functions? The bsdyengine and the stick engine also
implement the add/modify/remove primitive functions. Is that required and
does the m_update variable do anything?

No, they can be removed. I put them in there once so that the engine
could control display list stuff internally (ie. making a display list
for the opaque stuff, but this is going to be un-needed soon. I think
i’m going to leave the functions virtual though, i could easily see that
in the future this could be valuable for optimization but i’m not sure i
see a purpose atm. Also, some engines may want to manage their own
lists or something.

As all engines are effectively dynamic engines now I didn’t know if the
bsdyengine description should also be updated. Benoit and I have also been
discussing some issues with custom engine settings and kalzium porting over
on the kalzium list - not sure what the ideal solution is just yet and I
would welcome any opinions. I seem to have wandered away from the original
subject a little though :wink:

Thanks,

Marcus


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


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