unreferenced formal parameter warnings in QuickFast

124 views
Skip to first unread message

Nikola Smiljanić

unread,
Dec 6, 2011, 6:16:32 AM12/6/11
to quickfa...@googlegroups.com
I would like to get rid of these warnings:

QuickFAST\src\Communication/Receiver.h(131): warning C4100: 'used' : unreferenced formal parameter
QuickFAST\src\Communication/Receiver.h(129): warning C4100: 'buffer' : unreferenced formal parameter
QuickFAST\src\Communication/SynchReceiver.h(128): warning C4100: 'threadCount' : unreferenced formal parameter

I'm not sure if there is a portable way to do this, MSVC offers the UNREFERENCED_PARAMETER macro.

Dale Wilson

unread,
Dec 6, 2011, 9:06:59 AM12/6/11
to quickfa...@googlegroups.com
What warning level are you using when you build quickfast?
I use the default level (/W3) and the only warnings I get are the
intentional warnings about "todo" variables. If you run with /W4 you are
probably not going to get rid of warnings in any non-trivial programs
unless you explicitly suppress them.

If you are building /W3 and still getting the warnings, options include:
1) Don't name the parameter, simply use the type in the parameter list
like this:
MyClass::MyMethod(int /*unused integer*/, double thisOneIsUsed)
{....}
Unfortunately this confuses Doxygen so I don't use it often.
2) For MSVC:
#ifdef _MSC_VER
#pragma warning(disable:4100)
#endif
3) Use the UNREFERENCED_PARAMETER macro or an equivalent portable
version of this macro (There is one in ACE)
Unfortunately in my opinion this clutters the code with distracting
information. When you are looking at a method trying to figure out
what it does, the fact that it doesn't use one of the parameters is
rarely of interest.

I'll consider adding #2 to the QuickFAST precompiled headers.

Dale

> --
> You received this message because you are subscribed to the Google
> Groups "quickfast_users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/quickfast_users/-/xOzoyNdtsu8J.
> To post to this group, send email to quickfa...@googlegroups.com.
> To unsubscribe from this group, send email to
> quickfast_use...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/quickfast_users?hl=en.


--
Dale Wilson
Principal Software Engineer
Object Computing, Inc.

Nikola Smiljanić

unread,
Dec 6, 2011, 5:53:21 PM12/6/11
to quickfa...@googlegroups.com
I am using Warning level 4. The application is far from trivial and the only warning I get right now is from QuickFast headers that I've included. It's not a big deal, but I would like to get rid of them if possible. One more solution would be to move these methods to .cpp file, unless it's important that they are in the header but I don't see how can this be the case since the only thing the first on does is throw an exception?

Dale Wilson

unread,
Dec 7, 2011, 11:46:51 AM12/7/11
to quickfa...@googlegroups.com
On 12/6/2011 4:53 PM, Nikola Smiljanić wrote:
> I am using Warning level 4. The application is far from trivial and
> the only warning I get right now is from QuickFast headers that I've
> included. It's not a big deal, but I would like to get rid of them if
> possible.
I took that a a challenge (grin) and upped the warning level on my
QuickFAST build to 4. It surprised me by producing very few warnings.
Maybe the compiler has improved since I formed my impression that level
4 warnings were mostly the compiler complaining about things that
couldn't possibly matter (or maybe my coding style has improved since then.)

I'll be checking in the few changes it took to eliminate the level 4
warnings.

However, my solution to the problem you are seeing was to add this line
to QuickFAST_pch.h
#pragma warning(disable:4100) // Disable: unreferenced formal parameter
(/W4 warning)

In my opinion, unused formal parameters are quite common and perfectly
acceptable in virtual methods, and any effort to eliminate them in-place
tends to introduce confusing distractions.

Dale

Nikola Smiljanić

unread,
Dec 7, 2011, 3:28:14 PM12/7/11
to quickfa...@googlegroups.com
This #pragma fixes warnings in QuickFAST but not in my application? That's another thing I wanted to talk to you about. Your header files are not self-sufficient, or am I wrong? Just including a QuickFAST header gives errors that are resolved by including appropriate boost libraries, but I'm very surprised by all this. I've never seen a library that expects users to add some other third party headers that are used by the library itself. Why is this the way it is?

Dale Wilson

unread,
Dec 7, 2011, 3:56:01 PM12/7/11
to quickfa...@googlegroups.com
An application that uses QuickFAST should use a single include:

#include <Application/QuickFAST.h>

This picks up all of the prerequisites needed by QuickFAST code
including the #pragmas, the boost includes, etc. then loads the
QuickFAST header files commonly needed by applications.

This would be a good thing to put in a precompiled header file for your
application.

If you attempt to include QuickFAST header files piecemeal you will run
into the problem you are describing. I have recently added compile-time
checking in the header files to warn about this, but I need to add
additional documentation to make it more obvious.

To answer your "Why?" question:

Having each header include boost, etc. and specify any appropriate
#pragma tends to defeat the purpose of precompiled headers (not to
mention cluttering the files and being a maintenance nightmare.)
Microsoft has the #pragma once which solves the problem for MSVC builds,
but with other compilers even if the included file has an include guard
symbol (which most do) the compiler has to open and parse the files to
find the matching #if/#endif pairs -- noticeably increasing compile time.

Dale

> are used by the library itself. Why is this the way it is? --


> You received this message because you are subscribed to the Google
> Groups "quickfast_users" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/quickfast_users/-/d5ePly3lojAJ.


> To post to this group, send email to quickfa...@googlegroups.com.
> To unsubscribe from this group, send email to
> quickfast_use...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/quickfast_users?hl=en.

Nikola Smiljanić

unread,
Dec 7, 2011, 4:14:44 PM12/7/11
to quickfa...@googlegroups.com
Good thing I asked, didn't know about QuickFAST.h. Thanks :)

Jason Aubrey

unread,
Dec 7, 2011, 4:36:09 PM12/7/11
to quickfa...@googlegroups.com
Hi Dale,

Maybe it's already the case, but please use pragma push/pop when changing warning levels in the headers.

Not doing so can impact users of the header, for example:

// Visual Studio
#pragma warning(push)
#pragma warning(disable : 4303) // old-style-cast
int floor(const double value) { return (int)value; }
#pragma warning(pop)

// GCC 4.5 - must disable for remainder of compilation unit or manually re-enable it
#pragma GCC diagnostic ignored "-Wold-style-cast"
int floor(const double value) { return (int)value; }
#pragma GCC diagnostic warning "-Wold-style-cast"

// GCC >= 4.6
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wold-style-cast"
int floor(const double value) { return (int)value; }
#pragma GCC diagnostic pop

I'm not suggesting to allow old-style-cast above, it's simply an easy example.

Thanks,
Jason Aubrey

________________________________________
From: quickfa...@googlegroups.com [quickfa...@googlegroups.com] On Behalf Of Dale Wilson [wil...@ociweb.com]
Sent: Wednesday, December 07, 2011 10:46 AM
To: quickfa...@googlegroups.com
Subject: Re: [quickfast_users] unreferenced formal parameter warnings in QuickFast

Dale

--


You received this message because you are subscribed to the Google Groups "quickfast_users" group.

Dale Wilson

unread,
Dec 8, 2011, 11:57:23 AM12/8/11
to quickfa...@googlegroups.com

On 12/7/2011 3:36 PM, Jason Aubrey wrote:
> Hi Dale,
>
> Maybe it's already the case, but please use pragma push/pop when changing warning levels in the headers.
Good point, Jason,

I already used push & pop which changing the warning levels for special
case code, but I had not considered doing so for the warnings that
QuickFAST disables "globally"

I have added the appropriate warning push & pop to Application/QuickFAST.h

Reply all
Reply to author
Forward
0 new messages