Thanks again very much Colin, for all of your help.
Colin Burgess <cburgess@qnx.com> wrote:
CB > Bill Caroselli <qtps@earthlink.net> wrote:
Thanks Colin. That’s exactly what I was looking for.
Where do I find this gcc html manual?
CB > http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html
I have a few other QNX4 isms I’d like to look up, like:
#pragma library ("/somedir/library_name");
CB > There isn’t a way to do this, I’m afraid.
#pragma error “Your #defines are screwed up!” ;
CB > #warning “Aye Carumba!”
CB > #error "Golly gee!
CB > should do the trick?
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > The code has to behave as if the variable was destroyed at the end of
WL > the block. The compiler is free to reorder things as long as it can
WL > prove that the reordering doesn’t change any required behaviour. In
WL > particular, if the variable didn’t have a destructor, the compiler could
WL > analyze its constructor and notice that the variable’s address can’t be
WL > known to anything that printf() could possibly call, and therefore the
WL > memory can be reused before printf() runs. But since the variable does
WL > have a destructor, and the destructor has side effects, those
WL > side-effects must happen after the side-effects of printf().
Years ago, the “bible” on the C++ language was the ARM (Annotated
Reference Manual). The language has evolved a lot since then but I
don’t think the ARM has kept up with it.
What is the current “bible” of the C++ language?
Is it available on line?
Bill Caroselli <qtps@earthlink.net> wrote:
Years ago, the “bible” on the C++ language was the ARM (Annotated
Reference Manual). The language has evolved a lot since then but I
don’t think the ARM has kept up with it.
What is the current “bible” of the C++ language?
The ISO C++ standard. ISO/IEC 14882:1998.
Is it available on line?
You can buy a PDF copy from ANSI for $18:
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+14882-1998
Make sure to read the license agreement first – some people on
comp.std.c have claimed that it allows ANSI to sue you too easily.
(That was actually about the license for the C standard, not C++, but I
suspect the agreement is either identical or very similar.)
I’m porting some QNX4 photon code. My projects with maximum warning
level set. When compiling a C++ module with maximum warnings set and
including photon/PtTree.h I get:
/usr/include/photon/PtTree.h:201: warning: cast discards qualifiers from pointer target type
The line(s) in question read:
inline int PtTreeItemIndex(
const PtWidget_t *tree, const PtTreeItem_t item
) {
return PtGenTreeItemIndex( tree, (PtGenTreeItem_t) item );
}
But they *should read:
inline int PtTreeItemIndex(
const PtWidget_t *tree,
const PtTreeItem_t item )
{
return PtGenTreeItemIndex( tree, (const PtGenTreeItem_t) item );
}
This simply maintains the ‘const’ in the typecast. The compiler is
right and QSSL should fix their header file(s).
I have also found:
/usr/include/photon/PtImageTree.h:163: warning: cast discards qualifiers from pointer target type
It is the exact same situation.
I’m sure there are other’s.
Is there some way that QSSL can compile all of their header files with maximum warning levels set to find all instances where things were insufficiently typecast?
Bill Caroselli <qtps@earthlink.net> wrote:
I’m porting some QNX4 photon code. My projects with maximum warning
level set. When compiling a C++ module with maximum warnings set and
including photon/PtTree.h I get:
/usr/include/photon/PtTree.h:201: warning: cast discards qualifiers from pointer target type
This simply maintains the ‘const’ in the typecast. The compiler is
right and QSSL should fix their header file(s).
The compiler is right, but only in the sense that the compiler is free
to warn you about anything it wishes to. What matters is that it
doesn’t refuse to compile correct code; and code that casts away the
constness of a pointer is not incorrect, even if it does it
unnecessarily.
But in this case I agree that not doing it is better. I’ll fix it. 
Is there some way that QSSL can compile all of their header files with
maximum warning levels set to find all instances where things were
insufficiently typecast?
But in this case, things are sufficiently typecast, as far as the
language is concerned; it’s just that according to GCC’s preferences,
such a typecast is suspicious enough to deserve a warning at the highest
warning level.
Personally, I don’t think it’s a good idea to make following GCC’s
preferences a policy that you have to obey at all cost. Especially if
you consider porting your code to other compilers that might have
different preferences. Of course, we shouldn’t make that decision for
our customers; I agree that it’s better if our headers don’t generate
unnecessary warnings. But I would be upset if I were told that my
code must compile without warnings from gcc at -w9.
GCC can be really annoying when you turn the warnings too high. I
really hate how it wants you to stick superfluous parentheses and braces
everywhere. Or that when you actually do need to convert a const
pointer to a non-const pointer (in C), there’s no way to do it without
getting a warning unless you do something really horrible like this:
void *p; void const cp;
p = (void) cp; // Warning!
memcpy( &p, &cp, sizeof(p) ); // Eeew! But no warning.
Having spent another day with the compiler I asm starting to agree
with you. Using -w9 is just rediculous in the things it complains
about.
-w8 seems almost usable.
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > GCC can be really annoying when you turn the warnings too high. I
WL > really hate how it wants you to stick superfluous parentheses and braces
WL > everywhere. Or that when you actually do need to convert a const
WL > pointer to a non-const pointer (in C), there’s no way to do it without
WL > getting a warning unless you do something really horrible like this:
WL > void *p; void const cp;
WL > p = (void) cp; // Warning!
WL > memcpy( &p, &cp, sizeof(p) ); // Eeew! But no warning.
I am porting a very large program with a small piece of code that boils
down to this:
extern void fn2( int );
void fn()
{
int j=8;
for( int j=0; j<10; j++ )
{
fn2( j );
}
fn2(j);
}
Of interest is the assignment of j in the for loop.
When compiling with the IDE I get warning for:
Name lookup of ‘j’ changed for new ANSI ‘for’ scoping.
Using obsolute binding at ‘j’.
I understand what these warning are telling me.
How can I get rid of them?
PS There are many instances of this kind of code and the
loops are sometimes quite large.
I have a new annoying warning from the GCC compiler. BTW, I could
have sworn I asked this once before but I could not find that post
so I’m asking again.
I have a class called Tracer. All of the work is done in the
constructor and destructor. I.E. you put it at the beginning of a
function and it log when you entered and exited the functions. It can
also log the call stack, etc.
So, in code I might write:
void my_funct ( )
{
Tracer fn( “my_funct()” );
// rest of function
}
To enable this class I have a define that I must define before the
header file.
#define TracerDebugOn
#include <tracer.hpp>
If I don’t want the class to do anything, in the header file I have this:
#ifndef TracerDebugOn
class Tracer
{
public:
Tracer ( const char * s, int = 5 , int = 5 ) { }
Tracer ( const char * s, const char *, int = 5 , int = 5 ) { }
static void SetLogSwitch ( void * ) {}
static void ClearLogSwitch ( ) {}
static void SetShowCalls ( ) {}
static void ClearShowCalls ( ) {}
static void ShowCalls ( ) {}
static void Spaces ( ) {}
};
#else
// the real tracer class goes here
#endif
HOWEVER, . . . . I can’t get rid of this warning that says:
Warning: Unused variable ‘class Tracer fn’
It IS perfectly valid to have an object that is not referenced except
for it’s constructor and destructor.
How can I get rid of this warning?
[snip]
static void ShowCalls ( ) {}
static void Spaces ( ) {}
} attribute((unused));
… should get rid of the warning.
Tracer fn( “my_funct()” ) attribute((unused));
should do it…
Bill Caroselli <qtps@earthlink.net> wrote:
I have a new annoying warning from the GCC compiler. BTW, I could
have sworn I asked this once before but I could not find that post
so I’m asking again.
I have a class called Tracer. All of the work is done in the
constructor and destructor. I.E. you put it at the beginning of a
function and it log when you entered and exited the functions. It can
also log the call stack, etc.
So, in code I might write:
void my_funct ( )
{
Tracer fn( “my_funct()” );
// rest of function
}
To enable this class I have a define that I must define before the
header file.
#define TracerDebugOn
#include <tracer.hpp
If I don’t want the class to do anything, in the header file I have this:
#ifndef TracerDebugOn
class Tracer
{
public:
Tracer ( const char * s, int = 5 , int = 5 ) { }
Tracer ( const char * s, const char *, int = 5 , int = 5 ) { }
static void SetLogSwitch ( void * ) {}
static void ClearLogSwitch ( ) {}
static void SetShowCalls ( ) {}
static void ClearShowCalls ( ) {}
static void ShowCalls ( ) {}
static void Spaces ( ) {}
};
#else
// the real tracer class goes here
#endif
HOWEVER, . . . . I can’t get rid of this warning that says:
Warning: Unused variable ‘class Tracer fn’
It IS perfectly valid to have an object that is not referenced except
for it’s constructor and destructor.
How can I get rid of this warning?
–
cburgess@qnx.com
Colin Burgess <cburgess@qnx.com> wrote:
CB > Tracer fn( “my_funct()” ) attribute((unused));
CB > should do it…
Actually I stuck it onto the end of the class in the header file. I.E.:
class Tracer
{
…
} attribute((unused));
This way I don’t have to modify all of my other code.
But thanks to both of you.