Error extra qualification on member

Доброго времени суток, коллеги!

Недавно перешел на fedora core 5 (FC5), в которой установлен gcc-4.1, да и сам дистр содран именно этим компилятором. Но в процессе работы выяснилось, что многие пакеты программ не собираются gcc-4.1. Хотя gcc-4.0.2 еще собирались. У меня с основном вылазят ошибки пободные этой :
fitdataset.cpp:177: error: extra qualification ‘FITRasterBand::’ on member ‘FITRasterBand’
fitdataset.cpp: In static member function ‘static GDALDataset* FITDataset::Open(GDALOpenInfo*)’:
fitdataset.cpp:1019: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[4]: *** [../o/fitdataset.o] Ошибка 1

и вот эта «extra qualification» довольно серезно достала. Возможно ли как нибудь пофиксить это? Мож есть заметный ключик к gcc-4.1, который обучит его вести себя как gcc-4.0.2? В инете предлагают фиксить каждую строчку, вызывающую аналогичную ошибку. Но, чуствую, строк таких немало. Я не программер, посему квалифицированно не могу обработать эту ситуацию.
Прошу помочь — надо край.

Спасибки!
Как я понял простого проблемы совместимости своего кода с gcc-4.1 должен решать сам разработчик. Потому как еслм всег несколько проблем, то можно решить самому. В моеи случае проект довольно большой и таких ошибок — море. Можно ли как-нибудь заставить gcc-4.1 работать в стиле gcc-4.0.2?

>Можно ли как-нибудь заставить gcc-4.1 работать в стиле gcc-4.0.2?

Нет, только следовать стандарту. Был еще портинггайд для gcc4.0 тоже рекомендую посмотреть. Вроде его гаврики из макинтошей нарисовали, по крайней мере мне гугль его там нашел.

А если хочется не мараться, то лучше компилять старым пока терпят. Ну и за компанию время протянуть, пока ошибки не исправите.

Источник

I keep getting the error extra qualification on member ‘Operator>’ and I don’t understand why. The error is with the statements below. I also tried changing it so that it just reads Employee2 operator>(Employee2& emp) but then it says it must have exactly 2 variables. Any help on this would be greatly appreciated.

bool Employee2::operator>(Employee2& emp); //in my header file

bool Employee2::operator>(Employee2& emp) //in my Employee2.cpp file
<
if(this->GetTotalEarned() > emp.GetTotalEarned())
<
cout this->GetTotalEarned())
<
cout GetTotalEarned())
<
cout Last edited on

sorry for the confusion, I’m still a little new to the forum but below is the full header code, most isn’t important to know but the
bool Employee2::operator>(Employee2& emp); that is giving me errors in in public.

#ifndef Employee2_H //Employee2_H
#define Employee2_H
#include

using namespace std;
class Employee2
<
public:
Employee2( unsigned int newID, string newLastName, string newFirstName, float newHourlyRate);
int GetID();
friend ostream& operator (Employee2& emp);
void SetID(int n);
string GetFirstName();
void SetFirstName(string str);
string GetLastName();
void SetLastName(string str);
float GetHourlyRate();
void SetHourlyRate(float n);
float Pay(float nHours);
float SalaryEarned( float nHours);
float GetTotalEarned();

private:
unsigned int ID;
string LastName;
string FirstName;
float HourlyRate;
float TotalEarned;
void increment();
>;

Источник

I am doing the example on dialogs from C++ gui programming with QT 4

I have finddialog.h
as
[code]
#ifndef FINDDIALOG_H
#define FINDDIALOG_H
#include
class QCheckBox;
class QLabel;
class QLineEdit;
class QPushButton;

class FindDialog : public QDialog
<
Q_OBJECT

public :
FindDialog(QWidget *parent = 0);

private slots:
void findClicked();
void enableFindButton(const QString &text);
private:
QLabel *label;
QLineEdit *lineEdit;
QCheckBox *caseCheckBox;
QCheckBox *backwardCheckBox;
QPushButton *findButton;
QPushButton *closeButton;
#endif
[/code]

finddialog.cpp
[code]
#include
#include «finddialog.h»
FindDialog::FindDialog(QWidget *parent) : QDialog(parent)
<
label = new QLabel(tr(«Find &what:»));
lineEdit = new QLineEdit;
label->setBuddy(lineEdit);

QVBoxLayout *leftLayout = new QVBoxLayout;
leftLayout->addLayout(topLeftLayout);
leftLayout->addWidget(findButton);
leftLayout->addWidget(backwardCheckBox);

QVBoxLayout *rightLayout = new QVBoxLayout;
rightLayout->addLayout(leftLayout);
rightLayout->addLayout(rightLayout);
rightLayout->addStretch();

QHBoxLayout *mainLayout = new QHBoxLayout;
mainLayout->addLayout(leftLayout);
mainLayout->addLayout(rightLayout);
setLayout(mainLayout);

Источник

Porting to gcc 4 (Warnings)

Overview

The transition from gcc version 3.3.4 (as used until VLT2008) to gcc 4.x caused a row of problems with inconsistencies and incompatibilities in our code, as described in TWiki page «Porting to gcc 4 (Mandatory Changes for VLT2009)». That page describes only the errors preventing from compiling successfully.

In addition, a very large number of warnings occur, often obstructing the view of the serious errors. Just to give an idea: almost 50000 warnings were generated compiling the VLT Common Software, owing to the gcc change from version 3 to 4.

Some of these warnings give hints about deprecated functionality which will no longer be supported in future compiler versions. Some of these warnings are in fact errors forced into warnings by specific compiler options just to get the code to pass the compiler. Many of these warnings are due to a lower tolerance level towards deviations from the standard.

Dangerous compiler options

gcc options -ftraditional and -ftraditional-cpp

Analysis

Description of the option -traditional taken from the gcc manual (see attachment on Porting to gcc 4 (Mandatory Changes for VLT2009)):
-traditional: Formerly, these options caused GCC to attempt to emulate a pre-standard C compiler. They are now only supported with the ‘-E’ switch. The preprocessor continues to support a pre-standard mode. See the GNU CPP manual for details.
-traditional-cpp: Try to imitate the behavior of old-fashioned C preprocessors, as opposed to ISO C preprocessors.

Solution

The option -traditional has been removed form the vltMakefile .

gcc option -fpermissive

Analysis

Description of the option -fpermissive taken from the gcc manual (see attachment on Porting to gcc 4 (Mandatory Changes for VLT2009)):
-fpermissive: Downgrade some diagnostics about nonconforming code from errors to warnings. Thus, using ‘-fpermissive’ will allow some nonconforming code to compile.

The gcc manual discourages the usage of this option:
We do not recommend using ‘-fpermissive’ to work around invalid code, and it will also only catch cases where functions in base classes are called, not where variables in base classes are used (. ).

The option -fpermissive was added to the vltMakefile to cope with certain problems caused by stricter handling of the gcc compiler.

Solution

All concerned sources have been adapted to comply with the standard and the option -fpermissive removed from the VLT2009 vltMakefile .

One example for the usage of not standard-compliant code is the usage of a so called «extra qualification» in class definitions (see Warning: extra qualification on member).

gcc option -mstrict-align

Analysis

The compiler option -mstrict-align is not supported by older compiler versions, especially not by the gcc compiler used with VxWorks 5.5.

Solution

If LCU source code is to support both VxWorks version 5.5 and 6 the settings in vltMakefile must not use the gcc option -mstrict-align by default for all LCU sources. If this option is required in the vltMakefile then it has to be used in a case differentiation depending (explicitly or implicitly) on the used VxWorks version.

The vltMakefile has been updated and the settings now depend on the WIND_BASE value. For VxWorks version 5.5 the gcc option -mstrict-align is not used.

List of warnings

Here is a collection of warnings, extracted from the VLTSW integration and filtered for identifier name etc.

warning: ‘XXX’ defined but not used

Analysis

The majority of this problem’s occurrences is owed to the change in the rcsId handling ( warning: ‘rcsId’ defined but not used ) — see also Porting to gcc 4 (Mandatory Changes for VLT2009).
The automatic conversion could add the macro ATTRIBUTE_UNUSED only to all rcsId definitions where the file vltPort.h has been already included. In all other cases the decision whether to add the (missing) include file vltPort.h or otherwise the file vltAttrib.h must be taken by the developper.
A total of 140 files in the VLT Common Software is still affected.

Solution

Add include file vltPort.h or (if vltPort.h may not be used in specific cases) vltAttrib.h to all affected source files and add ATTRIBUTE_UNUSED to the rcsId definition.

warning: deprecated conversion from string constant to ‘char*’

Analysis

Building the VLTSW this warning occured over 5121 times in 326 files.

The warnings are due to declarations like: or

And for example the definition of rcsId, which appears 187 times:

Solution

All source code has to be aligned to comply with the standards. The way to fix this is to replace by const char pointers :

Ex: case rcsId : should be replaced by

However, the large number of ocurrences in the sources require an automated solution.

For the case of rcsId, the following sed command can be used:

Analysis

First a code example demonstrating the «extra qualification»: In this example the method YYY is defined with the preceding class name XXX:: thus specifying a superfluous «extra qualification».
The second method ZZZ is defined correctly.

gcc 4 does not permit this «extra qualification» any longer (in contrast to earlier compiler versions) and the compilation fails with the error message error: extra qualification ‘XXX’ on member ‘YYY’ .
However, the compiler can be forced to accept such non-conforming code by specifying the gcc option -fpermissive. Then the error is turned into a warning and the compilation does not fail.

Solution

Removing the «extra qualification» is an essential step to make the source code standard-compliant.

warning: pointer targets . differ in signedness

Analysis

The majority of these warning are produced by the usage of vltBYTES (defined as unsigned char in vltPortGeneral.h) where a char* is expected (see SPR VLTSW20080211).

logManager.c:284: warning: pointer targets in passing argument 1 of ‘strcpy’ differ in signedness

Solution

The following has been implemented to get rid of the warning :

• type vltINT8 changed, defined now as signed char
• type vltBYTES unchanged, defined as unsigned char
• type vltSTRING, defined as char (see SPR VLTSW20090007), added

warning: there are no arguments to ‘XXX’.

warning: there are no arguments to ‘XXX’ that depend on a template parameter, so a declaration of ‘XXX’ must be available

Analysis

The problem is explained here:

In short, the C++ compiler now follows the C++ standard that prescribes that all names that are not dependent on template parameters are bound to their present definitions when parsing a template function or class.
Only names that are dependent are looked up at the point of instantiation.

Solution

In order to make it clear that you want the member of the base class, you need to defer lookup until instantiation time, at which the base class is known.

For this, you need to access i in a dependent context, by either using this->i (remember that this is of type Derived *, so is obviously dependent), or using Base ::i. Alternatively, Base ::i might be brought into scope by a using-declaration.

For example, if you get the warning on a line like:

Simply replace it with:

warning: . discards qualifiers from pointer target type

Analysis

This program attempts to modify constant data, and to discard the const property of the argument s in the return value.

warning: unused variable ‘XXX’

Analysis

In this program the variable i and the parameter p are never used.

Other warning.

The two following forms can appear :

• warning: pasting «XXX» and «»: Command received»» does not give a valid preprocessing token
• warning: pasting «XXX» and «»: Command executed»» does not give a valid preprocessing token

• warning: assignment makes integer from pointer without a cast
• warning: passing arg 2 of `XXX’ makes integer from pointer without a cast
• warning: return makes integer from pointer without a cast

• warning: assignment makes pointer from integer without a cast
• warning: passing arg 1 of `XXX’ makes pointer from integer without a cast
• warning: initialization makes pointer from integer without a cast

• warning: passing argument 1 (2, 3, . ) of ‘XXX’ from incompatible pointer type

note: obsolete option -I- used, please use -iquote instead

Analysis

This message occurs in two slightly differing forms depending on the usage of the language C or C++:

• cc1: note: obsolete option -I- used, please use -iquote instead
• cc1plus: note: obsolete option -I- used, please use -iquote instead

In the vltMakefile the option -I- was added to force the compiler to always restart the search of include files from the beginning of the search path. The -iquote option is not a complete replacement for -I-. Without -I- there is no way to inhibit the use of the directory of the current file as the first search directory for #include «file».

see SPR VLTSW20080253 for more details

Solution

It has been decided for VLT2009 to keep the option -I- until it disappears. And the output of the compiler has been filtered with a grep to suppress the warning.

Источник

I am doing the example on dialogs from C++ gui programming with QT 4

I have finddialog.h
as
[code]
#ifndef FINDDIALOG_H
#define FINDDIALOG_H
#include <QDialog>
class QCheckBox;
class QLabel;
class QLineEdit;
class QPushButton;

class FindDialog : public QDialog
{
Q_OBJECT

public :
FindDialog(QWidget *parent = 0);

signals:
void findNext(const QString &str,Qt::CaseSensitivity cs);
void findPrevious(const QString &str,Qt::CaseSensitivity cs);

private slots:
void findClicked();
void enableFindButton(const QString &text);
private:
QLabel *label;
QLineEdit *lineEdit;
QCheckBox *caseCheckBox;
QCheckBox *backwardCheckBox;
QPushButton *findButton;
QPushButton *closeButton;
#endif
[/code]

finddialog.cpp
[code]
#include <QtGui>
#include «finddialog.h»
FindDialog::FindDialog(QWidget *parent) : QDialog(parent)
{
label = new QLabel(tr(«Find &what:»));
lineEdit = new QLineEdit;
label->setBuddy(lineEdit);

 caseCheckBox = new QCheckBox(tr("Match &case"));
 backwardCheckBox = new QCheckBox(tr("Search &backward"));
 
 findButton = new QPushButton(tr("&Find"));
 findButton->setDefault(true);
 findButton->setEnabled(false);
 closeButton = new QPushButton(tr("Close"));

connect(lineEdit,SIGNAL(textChanged(const QString &)),this,SLOT(enableFindButton(const QString &)));
connect(findButton,SIGNAL(clicked()),this,SLOT(findClicked()));
connect(closeButton,SIGNAL(clicked()),this,SLOT(close()));

QHBoxLayout *topLeftLayout = new QHBoxLayout;

topLeftLayout->addWidget(label);
topLeftLayout->addWidget(lineEdit);

QVBoxLayout *leftLayout = new QVBoxLayout;
leftLayout->addLayout(topLeftLayout);
leftLayout->addWidget(findButton);
leftLayout->addWidget(backwardCheckBox);

QVBoxLayout *rightLayout = new QVBoxLayout;
rightLayout->addLayout(leftLayout);
rightLayout->addLayout(rightLayout);
rightLayout->addStretch();

QHBoxLayout *mainLayout = new QHBoxLayout;
mainLayout->addLayout(leftLayout);
mainLayout->addLayout(rightLayout);
setLayout(mainLayout);

setWindowTitle(tr(«Find»));
setFixedHeight(sizeHint().height());
}

void FindDialog :: findClicked()
{
QString text = lineEdit->text();
Qt:: CaseSensitivity cs = caseCheckBox->isChecked() ? Qt::CaseSensitive
: Qt::CaseInsensitive;
if(backwardCheckBox->isChecked()) {
emit findPrevious(text,cs);
}
else{
emit findNext(text,cs);
}
}
void FindDialog :: enableFindButton(const QString &text)
{
findButton->setEnabled(!text.isEmpty());

}
}
[/code]

main.cpp
[code]
#include <QApplication>
#include «finddialog.h>
int main(int argc,char *argv[])
{
QApplication app(argc,argv);
FindDialog *dialog = new FindDialog;
dialog->show();
return app.exec();
}
[/code]

[code]
utkarsh@utkarsh-laptop:~/programming/qt/dialog$ ls
dialog.pro finddialog.cpp finddialog.h main.cpp Makefile
utkarsh@utkarsh-laptop:~/programming/qt/dialog$ make
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o finddialog.o finddialog.cpp
finddialog.cpp:3: error: extra qualification ‘FindDialog::’ on member ‘FindDialog’
finddialog.cpp:3: error: ‘FindDialog::FindDialog(QWidget*)’ cannot be overloaded
finddialog.h:14: error: with ‘FindDialog::FindDialog(QWidget*)’
finddialog.cpp:44: error: extra qualification ‘FindDialog::’ on member ‘findClicked’
finddialog.cpp:44: error: ‘void FindDialog::findClicked()’ cannot be overloaded
finddialog.h:21: error: with ‘void FindDialog::findClicked()’
finddialog.cpp:56: error: extra qualification ‘FindDialog::’ on member ‘enableFindButton’
finddialog.cpp:56: error: ‘void FindDialog::enableFindButton(const QString&)’ cannot be overloaded
finddialog.h:22: error: with ‘void FindDialog::enableFindButton(const QString&)’
finddialog.cpp:60: error: expected unqualified-id at end of input
make: *** [finddialog.o] Error 1
utkarsh@utkarsh-laptop:~/programming/qt/dialog$ nano finddialog.cpp
utkarsh@utkarsh-laptop:~/programming/qt/dialog$
[/code]

0

0

Join Tek-Tips^® Today!

Join your peers on the Internet’s largest technical computer professional community.
It’s easy to join and it’s free.

Here’s Why Members Love Tek-Tips Forums:

• Talk To Other Members
• Notification Of Responses To Questions
• Favorite Forums One Click Access
• Keyword Search Of All Posts, And More…

Register now while it’s still free!

Already a member? Close this window and log in.

Join Us             Close

class Order{
std::string customer, product;
std::vector<std::string> itemList;

bool validName(std::string name);
bool isCustomerName(std::string name);
bool isProductName(std::string name);
bool isItemName(std::string name);

public:

Order(std::vector<std::string> line);
void print(){
void graph(std::ofstream os);
};//class Order

Order::Order(std::vector<std::string> line){

bool Order::isCustomerName(std::string name){

error: extra qualification ‘Order::’ on member ‘Order’ [-fpermissive]

#include <fstream>
#include <iostream>
#include <vector>
#include <string>
#include "order.h"

bool Order::isProductName(std::string name){
if (name.size() > 0 && isalpha(name[0]))
return true;
return false; }

#pragma once
#include <fstream>
#include <iostream>
#include <vector>
#include <string>
#include "util.h"

Решение

 void print(){

 void print();

Другие решения

Других решений пока нет …

Porting to gcc 4 (Warnings)

Overview

The transition from gcc version 3.3.4 (as used until VLT2008) to gcc 4.x caused a row of problems with inconsistencies and incompatibilities in our code, as described in TWiki page «Porting to gcc 4 (Mandatory Changes for VLT2009)». That page describes only the errors preventing from compiling successfully.

In addition, a very large number of warnings occur, often obstructing the view of the serious errors. Just to give an idea: almost 50000 warnings were generated compiling the VLT Common Software, owing to the gcc change from version 3 to 4.

Some of these warnings give hints about deprecated functionality which will no longer be supported in future compiler versions. Some of these warnings are in fact errors forced into warnings by specific compiler options just to get the code to pass the compiler. Many of these warnings are due to a lower tolerance level towards deviations from the standard.

Dangerous compiler options

gcc options -ftraditional and -ftraditional-cpp

Analysis

Description of the option -traditional taken from the gcc manual (see attachment on Porting to gcc 4 (Mandatory Changes for VLT2009)):
-traditional: Formerly, these options caused GCC to attempt to emulate a pre-standard C compiler. They are now only supported with the ‘-E’ switch. The preprocessor continues to support a pre-standard mode. See the GNU CPP manual for details.
-traditional-cpp: Try to imitate the behavior of old-fashioned C preprocessors, as opposed to ISO C preprocessors.

Solution

The option -traditional has been removed form the vltMakefile.

gcc option -fpermissive

Analysis

Description of the option -fpermissive taken from the gcc manual (see attachment on Porting to gcc 4 (Mandatory Changes for VLT2009)):
-fpermissive: Downgrade some diagnostics about nonconforming code from errors to warnings. Thus, using ‘-fpermissive’ will allow some nonconforming code to compile.

The gcc manual discourages the usage of this option:
We do not recommend using ‘-fpermissive’ to work around invalid code, and it will also only catch cases where functions in base classes are called, not where variables in base classes are used (…).

The option -fpermissive was added to the vltMakefile to cope with certain problems caused by stricter handling of the gcc compiler.

Solution

All concerned sources have been adapted to comply with the standard and the option -fpermissive removed from the VLT2009 vltMakefile.

One example for the usage of not standard-compliant code is the usage of a so called «extra qualification» in class definitions (see Warning: extra qualification on member).

gcc option -mstrict-align

Analysis

The compiler option -mstrict-align is not supported by older compiler versions, especially not by the gcc compiler used with VxWorks 5.5.

Solution

If LCU source code is to support both VxWorks version 5.5 and 6 the settings in vltMakefile must not use the gcc option -mstrict-align by default for all LCU sources. If this option is required in the vltMakefile then it has to be used in a case differentiation depending (explicitly or implicitly) on the used VxWorks version.

The vltMakefile has been updated and the settings now depend on the WIND_BASE value. For VxWorks version 5.5 the gcc option -mstrict-align is not used.

List of warnings

Here is a collection of warnings, extracted from the VLTSW integration and filtered for identifier name etc.

warning: ‘XXX’ defined but not used

Analysis

The majority of this problem’s occurrences is owed to the change in the rcsId handling ( warning: 'rcsId' defined but not used) — see also Porting to gcc 4 (Mandatory Changes for VLT2009).
The automatic conversion could add the macro ATTRIBUTE_UNUSED only to all rcsId definitions where the file vltPort.h has been already included. In all other cases the decision whether to add the (missing) include file vltPort.h or otherwise the file vltAttrib.h must be taken by the developper.
A total of 140 files in the VLT Common Software is still affected.

Solution

Add include file vltPort.h or (if vltPort.h may not be used in specific cases) vltAttrib.h to all affected source files and add ATTRIBUTE_UNUSED to the rcsId definition.

warning: deprecated conversion from string constant to ‘char*’

Analysis

Building the VLTSW this warning occured over 5121 times in 326 files.

The warnings are due to declarations like:

  char *aVar = "aString";

or

  void aFunc( char *aVar) { ... }
  aFunc( "aString" ); 

And for example the definition of rcsId, which appears 187 times:

ATTRIBUTE_UNUSED static char *rcsId="@(#) $Id: ...";

Solution

All source code has to be aligned to comply with the standards. The way to fix this is to replace by const char pointers :

const char *aVar = "aString";

or

void aFunc( const char *aVar) { ... } 
 

Ex: case rcsId :

ATTRIBUTE_UNUSED static char *rcsId="@(#) $Id: ...";

should be replaced by

ATTRIBUTE_UNUSED static const char *rcsId="@(#) $Id: ..."; 

However, the large number of ocurrences in the sources require an automated solution.

For the case of rcsId, the following sed command can be used:

find . -name "*.C"  -exec sed -i -e 's/ATTRIBUTE_UNUSED static char *rcsId/ATTRIBUTE_UNUSED static const char *rcsId/' {} ;

warning: extra qualification ‘XXX’ on member ‘YYY’

Analysis

First a code example demonstrating the «extra qualification»:

class XXX {
   int XXX::YYY(int parameter);
   int ZZZ(int parameter);
}

In this example the method YYY is defined with the preceding class name XXX:: thus specifying a superfluous «extra qualification».
The second method ZZZ is defined correctly.

gcc 4 does not permit this «extra qualification» any longer (in contrast to earlier compiler versions) and the compilation fails with the error message error: extra qualification 'XXX' on member 'YYY'.
However, the compiler can be forced to accept such non-conforming code by specifying the gcc option -fpermissive. Then the error is turned into a warning and the compilation does not fail.

Solution

Removing the «extra qualification» is an essential step to make the source code standard-compliant.

warning: pointer targets … differ in signedness

Analysis

There were 2532 warnings of this type, in different forms:

• warning: pointer targets in assignment differ in signedness
• warning: pointer targets in initialization differ in signedness
• warning: pointer targets in passing argument 1 (2, 3, 4, 5, 6, 7, of ‘XXX’ differ in signedness

The majority of these warning are produced by the usage of vltBYTES (defined as unsigned char in vltPortGeneral.h) where a char* is expected (see SPR VLTSW20080211).

For example:

logManager.c:284: warning: pointer targets in passing argument 1 of ‘strcpy’ differ in signedness

Solution

The following has been implemented to get rid of the warning :

• type vltINT8 changed, defined now as signed char
• type vltBYTES unchanged, defined as unsigned char
• type vltSTRING, defined as char (see SPR VLTSW20090007), added

warning: there are no arguments to ‘XXX’….

Complete message:

warning: there are no arguments to ‘XXX’ that depend on a template parameter, so a declaration of ‘XXX’ must be available

Analysis

The problem is explained here:

http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html

In short, the C++ compiler now follows the C++ standard that prescribes that all names that are not dependent on template parameters are bound to their present definitions when parsing a template function or class.
Only names that are dependent are looked up at the point of instantiation.

Solution

In order to make it clear that you want the member of the base class, you need to defer lookup until instantiation time, at which the base class is known.

For this, you need to access i in a dependent context, by either using this->i (remember that this is of type Derived*, so is obviously dependent), or using Base::i. Alternatively, Base::i might be brought into scope by a using-declaration.

For example, if you get the warning on a line like:

   ErrAdd(tcsMOD, tcsERR_FATAL, __FILE_LINE__,  "cannot initialize");  

Simply replace it with:

   this->ErrAdd(tcsMOD, tcsERR_FATAL, __FILE_LINE__, "cannot initialize%);  

warning: … discards qualifiers from pointer target type

Different forms:

• warning: passing arg 1 of `XXX’ discards qualifiers from pointer target type
• warning: assignment discards qualifiers from pointer target type

Analysis

These warnings occur when a pointer is used incorrectly, violating a type qualifier such as const. Data accessed through a pointer marked as const should not be modified, and the pointer itself can only be assigned to other pointers that are also marked const.

Example:

char *
f (const char *s)
{
  *s = '';  /* assigns to read-only data */
  return s;   /* discards const */
}

This program attempts to modify constant data, and to discard the const property of the argument s in the return value.

warning: unused variable ‘XXX’

Analysis

These warnings indicate that a variable has been declared as a local variable or in the parameters of a function, but has not been used anywhere. An unused variable can be the result of a programming error, such as accidentally using the name of a different variable in place of the intended one. Example:

int
foo (int k, char * p)
{
  int i, j;
  j = k;
  return j;
}

In this program the variable i and the parameter p are never used.

Other warning…

 
warning: pasting "XXX" and "YYY" does not give a valid preprocessing token 

The two following forms can appear :

• warning: pasting «XXX» and «»: Command received»» does not give a valid preprocessing token
• warning: pasting «XXX» and «»: Command executed»» does not give a valid preprocessing token

   
warning: 'XXX' may be used uninitialized in this function  

warning: 'XXX' might be used uninitialized in this function  

warning: implicit declaration of function 'XXX'  

warning: incompatible implicit declaration of built-in function 'XXX'  

warning: the `XXX' function is dangerous and should not be used.  

warning: the use of `XXX' is dangerous, better use `YYY'  

warning: ... makes integer from pointer without a cast

Different forms:

• warning: assignment makes integer from pointer without a cast
• warning: passing arg 2 of `XXX’ makes integer from pointer without a cast
• warning: return makes integer from pointer without a cast

warning: ... makes pointer from integer without a cast

Different forms:

• warning: assignment makes pointer from integer without a cast
• warning: passing arg 1 of `XXX’ makes pointer from integer without a cast
• warning: initialization makes pointer from integer without a cast

warning: dereferencing type-punned pointer will break strict-aliasing rules  

warning: cast from pointer to integer of different size  

warning: comparison between pointer and integer  

warning: comparison is always false due to limited range of data type  

warning: comparison with string literal results in unspecified behaviour  

warning: data definition has no type or storage class  

warning: "__FILE_LINE__" redefined  

warning: double format, void arg (arg 3)  

warning: extra tokens at end of #endif directive  

warning: format '%ld' expects type 'long int', but argument 3 has type 'unsigned int'  

warning: int format, void arg (arg 3)  

warning: missing braces around initializer for 'XXX'  

warning: no semicolon at end of struct or union  

warning: passing arg 1 (2, 3, ...) of `XXX' from incompatible pointer type

Other form:

• warning: passing argument 1 (2, 3, …) of ‘XXX’ from incompatible pointer type

warning: subscript has type `XXX'  

warning: this is the location of the previous definition 

warning: type defaults to `XXX' in declaration of `YYY'  

warning: use of cast expressions as lvalues is deprecated  

warning: suggest parentheses around assignment used as truth value  

warning: non-local variable 'argList [28]' uses anonymous type  

warning: ignoring old commands for target `test'  

warning: overriding commands for target `test'  

warning: return type of 'main' is not 'int'  

warning: (near initialization for `XXX[X].argument.X')  

warning: after previous specification in 'XXX'  

warning: default argument given for parameter 4 of 'XXX'  

warning: dereferencing 'void *' pointer  

warning: null character(s) ignored  

warning: overflow in implicit constant conversion  

warning: suggest explicit braces to avoid ambiguous `else' 

warning: 'return' with a value, in function returning void

note: obsolete option -I- used, please use -iquote instead

Analysis

This message occurs in two slightly differing forms depending on the usage of the language C or C++:

• cc1: note: obsolete option -I- used, please use -iquote instead
• cc1plus: note: obsolete option -I- used, please use -iquote instead

In the vltMakefile the option -I- was added to force the compiler to always restart the search of include files from the beginning of the search path. The -iquote option is not a complete replacement for -I-. Without -I- there is no way to inhibit the use of the directory of the current file as the first search directory for #include «file».

see SPR VLTSW20080253 for more details

Solution

It has been decided for VLT2009 to keep the option -I- until it disappears. And the output of the compiler has been filtered with a grep to suppress the warning.

— PeterKratzer — 23 Sep 2008