I have an abstract base class which defines an interface to a function which takes 3 arguments.  
From that ABC I define a set of derived classes which implements the base class' interface.  The 
thing is, some derived classes don't use some of the parameters, which causes the compiler to throw 
warnings.  As I'm not using those parameters intentionally, those warnings tend to be a bit 
annoying.

So, does anyone happen to know a good standard way to get the compiler to stop warning about those 
specific instances where a parameter isn't used? 


Thanks in advance,
Rui Maciel

On Sep 25, 3:08=A0pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> I have an abstract base class which defines an interface to a function wh=
ich takes 3 arguments. =A0
> From that ABC I define a set of derived classes which implements the base=
 class' interface. =A0The
> thing is, some derived classes don't use some of the parameters, which ca=
uses the compiler to throw
> warnings. =A0As I'm not using those parameters intentionally, those warni=
ngs tend to be a bit
> annoying.
>
> So, does anyone happen to know a good standard way to get the compiler to=
 stop warning about those
> specific instances where a parameter isn't used?

One way is not to name the parameters, give only type:

 int foo( int )
 {
   return 0;
 }

For me it is fine. The downside that some claim it not documenting the
intention well enough. They may use some macro or template that does
not generate instructions:

 template<typename T>
 inline void UnusedParameter( T const& )
 {
 }

 #define UNUSED_PARAMETER(X) sizeof(X)

 int foo( int a, int b )
 {
     UNUSED_PARAMETER(a);
     UnusedParameter(b);
     return 0;
 }

That perhaps documents everything well enough.

* Rui Maciel, on 25.09.2010 14:08:
> I have an abstract base class which defines an interface to a function
> which takes 3 arguments. From that ABC I define a set of derived classes
> which implements the base class' interface.  The thing is, some derived
> classes don't use some of the parameters, which causes the compiler to
> throw warnings.  As I'm not using those parameters intentionally, those
> warnings tend to be a bit annoying.
>
> So, does anyone happen to know a good standard way to get the compiler to
> stop warning about those specific instances where a parameter isn't used?

In addition to ��'s answer else-thread you might consider this an opportunity 
for redesign. For example, perhaps a parameter that is unused in one 
implementation but used in another, is really a piece of knowledge that should 
reside with the object that hosts the function implementation that uses the 
parameter? Or perhaps there should be two different functions, not just one?

Cheers,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

Öö Tiib wrote:

> One way is not to name the parameters, give only type:
> 
> int foo( int )
> {
> return 0;
> }
> 
> For me it is fine.
<snip/>

Thanks for the help, Öö. That does the trick quite nicely, at least on g++.  Is this trick 
guaranteed to work on all platforms or is it one of those things specific to GCC?


Once again thanks for the help.  Kudos!
Rui Maciel

Alf P. Steinbach /Usenet wrote:

> In addition to Öö's answer else-thread you might consider this an
> opportunity for redesign. For example, perhaps a parameter that is unused
> in one implementation but used in another, is really a piece of knowledge
> that should reside with the object that hosts the function implementation
> that uses the parameter? Or perhaps there should be two different
> functions, not just one?

I see what you mean and you do have a point.  Nonetheless, in this case I believe that this design 
works well.  The abstract base class is used to specify, among other things, the interfaces to a 
specific family of interpolation functions in 3D space and their partial derivatives.  The 
interpolation functions are defined in the subsequent derived classes.  As some functions happen to 
be linear polynomials, that means that deriving them results in eliminating a parameter from the 
expression, which causes the compiler to warn about unused parameters. 


Rui Maciel

Rui Maciel wrote:

> �� Tiib wrote:
> 
>> One way is not to name the parameters, give only type:
>> 
>> int foo( int )
>> {
>> return 0;
>> }
>> 
>> For me it is fine.
> <snip/>
> 
> Thanks for the help, ��. That does the trick quite nicely, at least on
> g++.  Is this trick guaranteed to work on all platforms or is it one of
> those things specific to GCC?

As with all warnings, they are compiler specific. There is nothing in the 
standard that requires the warnings in the first place, and there is also no 
language that prevents a compiler from issuing gratuitous warnings of any 
kind. 

That said, what would be a good wording for this warning in case of an 
unnamed parameter? Something like:

  unnamed parameter not used (not that you
  could use it, but I just felt like telling you)


Best

Kai-Uwe Bux

�� Tiib wrote:

> On Sep 25, 3:08 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
>> I have an abstract base class which defines an interface to a function
>> which takes 3 arguments. From that ABC I define a set of derived classes
>> which implements the base class' interface.  The thing is, some derived
>> classes don't use some of the parameters, which causes the compiler to
>> throw warnings.  As I'm not using those parameters intentionally, those
>> warnings tend to be a bit annoying.
>>
>> So, does anyone happen to know a good standard way to get the compiler to
>> stop warning about those specific instances where a parameter isn't used?
> 
> One way is not to name the parameters, give only type:
> 
>  int foo( int )
>  {
>    return 0;
>  }
> 
> For me it is fine. 

For me too.

> The downside that some claim it not documenting the
> intention well enough. They may use some macro or template that does
> not generate instructions:
> 
>  template<typename T>
>  inline void UnusedParameter( T const& )
>  {
>  }
> 
>  #define UNUSED_PARAMETER(X) sizeof(X)
> 
>  int foo( int a, int b )
>  {
>      UNUSED_PARAMETER(a);
>      UnusedParameter(b);
>      return 0;
>  }
> 
> That perhaps documents everything well enough.

I think, this is worse. By giving names to the parameters, you actually make 
it possible in the first place to use them. Those macros amount to nothing 
more than comments and, given enough time, they _will_ turn false. The 
compiler has no change anymore of catching things like:

  int foo ( int a, int b )
  {
    UNUSED_PARAMETER(a);
    return ( a*b );
  }


Best

Kai-Uwe Bux

On Sep 25, 4:28=A0pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> =D6=F6 Tiib wrote:
> > One way is not to name the parameters, give only type:
>
> > int foo( int )
> > {
> > return 0;
> > }
>
> > For me it is fine.
>
> <snip/>
>
> Thanks for the help, =D6=F6. That does the trick quite nicely, at least o=
n g++. =A0Is this trick
> guaranteed to work on all platforms or is it one of those things specific=
 to GCC?

I don't know a C++ compiler that does not compile it.

Rui Maciel ha scritto:

> So, does anyone happen to know a good standard way to get the compiler to stop warning about those 
> specific instances where a parameter isn't used? 

What's wrong with disabling the warning using appropriate compiler flags 
for those compilation units in which the warning annoys you?


-- 
Christian Hackl
hacki@sbox.tugraz.at

Milano 2008/2009 -- L'Italia chiam�, s�!

On 2010-09-25 10:58:56 -0400, �� Tiib said:

> On Sep 25, 4:28�pm, Rui Maciel <rui.mac...@gmail.com> wrote:
>> �� Tiib wrote:
>>> One way is not to name the parameters, give only type:
>> 
>>> int foo( int )
>>> {
>>> return 0;
>>> }
>> 
>>> For me it is fine.
>> 
>> <snip/>
>> 
>> Thanks for the help, ��. That does the trick quite nicely, at least on 
>> g++. �Is this trick
>> guaranteed to work on all platforms or is it one of those things 
>> specific to GCC?
> 
> I don't know a C++ compiler that does not compile it.

Well, yes, it's guaranteed to work on all platforms in the sense that 
it's valid C++, so conforming compilers must accept it. But the 
question was whether it will suppress that warning on all platforms, 
and that, as others have said, is not required.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

Christian Hackl wrote:

> What's wrong with disabling the warning using appropriate compiler flags
> for those compilation units in which the warning annoys you?

I only want to eliminate that particular type of warning when it refers to the set of functions 
which I intentionally wrote so that they don't use a given parameter.


Rui Maciel

�� Tiib <ootiib@hot.ee> wrote:
>> Thanks for the help, ��. That does the trick quite nicely, at least on g++. �Is this trick
>> guaranteed to work on all platforms or is it one of those things specific to GCC?
> 
> I don't know a C++ compiler that does not compile it.

  I think that's the wrong answer to the question. The correct answer is:
"Well, the C++ standard defines that syntax. If a compiler wouldn't support
it, throw it away because it's broken."

On 26 sept, 10:11, Juha Nieminen <nos...@thanks.invalid> wrote:
> =D6=F6 Tiib <oot...@hot.ee> wrote:
> >> Thanks for the help, =D6=F6. That does the trick quite nicely, at leas=
t on g++. =A0Is this trick
> >> guaranteed to work on all platforms or is it one of those things speci=
fic to GCC?
>
> > I don't know a C++ compiler that does not compile it.
>
> =A0 I think that's the wrong answer to the question. The correct answer i=
s:
> "Well, the C++ standard defines that syntax. If a compiler wouldn't suppo=
rt
> it, throw it away because it's broken."

Maybe your answer is better, but it does not say what i wanted to
tell.  I wanted only to say that

 int foo( int )
 {
     return 0;
 }

compiles well and without warnings on all C++ compilers that i know of
and so that is not g++ specific. Not everything may be anonymous by
standard. Code like:

typedef struct {int x; int y} Point;

It is ill-formed (but does still compile on several compilers).

�� Tiib <ootiib@hot.ee> wrote:
> typedef struct {int x; int y} Point;
> 
> It is ill-formed (but does still compile on several compilers).

  Hmm, why is it ill-formed? (Or are you talking about the missing
semi-colon?)

On 9/25/2010 1:12 PM, Rui Maciel wrote:
> Christian Hackl wrote:
>
>> What's wrong with disabling the warning using appropriate compiler flags
>> for those compilation units in which the warning annoys you?
>
> I only want to eliminate that particular type of warning when it refers to the set of functions
> which I intentionally wrote so that they don't use a given parameter.

Why do you give the function a parameter when you know that you're not 
going to use it?  Just curious.

V
-- 
I do not respond to top-posted replies, please don't ask

Victor Bazarov wrote:

> Why do you give the function a parameter when you know that you're not
> going to use it?  Just curious.

In this case we are dealing with an abstract base class which defines a specific interface.  Then, 
when implementing this interface, some implementations may not use every parameter which was defined 
in the interface.  In my case, I was dealing with an interface to a set of interpolation functions, 
along with a set of partial derivatives.  As some interpolation functions happen to be linear 
polynomials, their derived functions will not contain some parameters, hence the need to get rid of 
those warnings.


Rui Maciel

On Sep 25, 5:08=A0pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> I have an abstract base class which defines an interface to a function wh=
ich takes 3 arguments. =A0
> From that ABC I define a set of derived classes which implements the base=
 class' interface. =A0The
> thing is, some derived classes don't use some of the parameters, which ca=
uses the compiler to throw
> warnings. =A0As I'm not using those parameters intentionally, those warni=
ngs tend to be a bit
> annoying.
>
> So, does anyone happen to know a good standard way to get the compiler to=
 stop warning about those
> specific instances where a parameter isn't used?
>
> Thanks in advance,
> Rui Maciel

Thank you so much for sharing information.