Re: How to work around this compiler bug
Hi,
I got another problem compiling some strange C++ code with gcc
3.5; still from opal:
std::string a(std::string(A::Class()));
results in:
error: cannot use `::' in parameter declaration
the actual code in opal looks like this:
#define OPAL_DEFINE_COMMAND(command, entity, func) \
class entity##_##command : public command \
{ \
public: virtual void Process(OpalPresentity presentity) {
dynamic_castentity (presentity).func(*this); } \
}; \
static PFactoryOpalPresentityCommand::Workerentity##_##command \
s_entity##_##command(PDefaultPFactoryKey(entity::Class())+typeid(command).name())
I have no clue what this is actually about. So I would be really
happy if someone could help me out in changing this piece of code
into something gcc 3.5 understands.
Christopher
Re: How to work around this compiler bug
On Thu, May 20, 2010 at 3:18 PM, Christopher Zimmermann madro...@zakweb.de wrote: Hi, I got another problem compiling some strange C++ code with gcc 3.5; still from opal: Again... what are you trying to achieve ? What's wrong with net/opal and x11/gnome/ekiga ports/packages ? Landry
Re: How to work around this compiler bug
On 05/20/10 15:52, Landry Breuil wrote: On Thu, May 20, 2010 at 3:18 PM, Christopher Zimmermann madro...@zakweb.de wrote: Hi, I got another problem compiling some strange C++ code with gcc 3.5; still from opal: Again... what are you trying to achieve ? What's wrong with net/opal and x11/gnome/ekiga ports/packages ? I'm doing some work on opal and would like to do it on OpenBSD. Formerly I did it on Debian. What I worked on was improving the SBC codec, adding stereo support to opal and g711 PLC. Compiling with the 4.2 g++ from ports works fine, but then even the ptlib hello world sample fails at runtime. Using gcc 3.5 at least this ptlib sample works fine. Cheers, Christopher
Re: [SOLVED] How to work around this compiler bug
Hey, I could work around this issue. Thanks for you help so far!!
If you are interested see below.
On 05/20/10 15:54, Marc Espie wrote:
On Thu, May 20, 2010 at 03:18:39PM +0200, Christopher Zimmermann wrote:
There's no gcc 3.5.
ok, that's true, its 3.3.5 of course.
std::string a(std::string(A::Class()));
results in:
error: cannot use `::' in parameter declaration
gcc 3.3.5 can't understand chains of constructors relying on temporaries,
use intermediate variables.
I think I got that.
e.g.,
A::Class tmp;
std:string a(tmp);
Class() is a method of every class in ptlib/opal, which just
returns a string as identifier for that class. (See below for the
code)
So declaring A::Class tmp does not really make sense, does it?
(the double std::string is non-sensical, btw)
As I said, I tried to strip down the offending code as much as
possible to find out what the compiler is actually complaining
about. The original snippet of code looked like this:
SNIP ===
#define OPAL_DEFINE_COMMAND(command, entity, func) \
class entity##_##command : public command \
{ \
public: virtual void Process(OpalPresentity presentity) {
dynamic_castentity (presentity).func(*this); } \
}; \
static PFactoryOpalPresentityCommand::Workerentity##_##command \
s_entity##_##command(PDefaultPFactoryKey(entity::Class())+typeid(command).name())
SNIP ===
As I understand it now, the compiler would need to create a
temporary instance of 'entity' to make the call to ::Class(), but
gcc 3.3.5 is not able to do this?
I now tried to fix it this way:
SNIP ===
#define OPAL_DEFINE_COMMAND(command, entity, func) \
class entity##_##command : public command \
{ \
public: virtual void Process(OpalPresentity presentity) {
dynamic_castentity (presentity).func(*this); } \
}; \
entity tmp; \
static PFactoryOpalPresentityCommand::Workerentity##_##command \
s_entity##_##command(PDefaultPFactoryKey(tmp.Class())+typeid(command).name())
OPAL_DEFINE_COMMAND(OpalSetLocalPresenceCommand, OpalPresentity,
Internal_SendLocalPresence);
SNIP ===
this doesn't work because:
`OpalPresentity::OpalPresentity()' is protected
within this context cannot declare variable `tmp' to be of type
`OpalPresentity' because the following virtual functions are
abstract:
virtual bool OpalPresentity::Open()
virtual bool OpalPresentity::IsOpen() const
virtual bool OpalPresentity::Close()
I'm willing to help, but can you at least double check what you type ?
Now anyway this is where the ::Class() method is defined:
SNIP ===
#define PCLASSINFO(cls, par) \
public: \
typedef cls P_thisClass; \
static inline const char * Class() \
{ return #cls; } \
SNIP ===
Since PCLASSINFO gets called with the 'OpalPresenty' as parameter
for 'cls' I could just remove the 'entity::Class()' thingy and
replace it by '#entity':
SNIP ===
#define OPAL_DEFINE_COMMAND(command, entity, func) \
class entity##_##command : public command \
{ \
public: virtual void Process(OpalPresentity presentity) {
dynamic_castentity (presentity).func(*this); } \
}; \
static PFactoryOpalPresentityCommand::Workerentity##_##command \
s_entity##_##command(PDefaultPFactoryKey(#entity)+typeid(command).name())
SNIP ===
g, that was too easy. I tried to fix this for several days
now. Sometimes you just need to know where to look.
Anyway thank you very much for your inspiration ;)
Cheers,
Christopher
Re: [SOLVED] How to work around this compiler bug
On Thu, 20 May 2010, Christopher Zimmermann wrote:
after preprocessing it looks like this:
void setUseProxy( bool v )
{
QSettings( QCoreApplication::organizationName().isEmpty() ?
Last.fm : QCoreApplication::organizationName() ).setValue(
ProxyEnabled, v ? 1 : 0 );
}
I don't know why, but just adding a return before every
SharedQSettings( stopped g++ 3.3.5 from complaining.
Does this help?
That did the trick.
Thank you!
-dav
Re: How to work around this compiler bug
On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Why do some C++ programmer still use macros where they're not needed ?
bunch of idiots, let them stay with C.
#includeerr.h
templatetypename T
inline T WarnIfNULL(T x)
{
if (!x)
warn(blub);
return x;
}
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
ok, thanks. That seems to be the solution, still I have to wrap it in a macro,
because I need __LINE__, __FILE__, __CLASS__...
Re: How to work around this compiler bug
On Sun, May 2, 2010 at 3:59 AM, Christopher Zimmermann
madro...@zakweb.de wrote:
On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Why do some C++ programmer still use macros where they're not needed ?
bunch of idiots, let them stay with C.
#includeerr.h
templatetypename T
inline T WarnIfNULL(T x)
{
if (!x)
warn(blub);
return x;
}
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
ok, thanks. That seems to be the solution, still I have to wrap it in a
macro, because I need __LINE__, __FILE__, __CLASS__...
You example obviously isn't showing the exact usage you require. I
imagine the macro is being used in assignments, not just in the blub()
method as you display.
Cheers,
--patrick
$ cat fuck.c++
#include stdlib.h
#include err.h
#include iostream
#define WarnIfNULL(x) ((!(x) ((void)warnx(blub),1)) ? (x) : (x))
class A {
protected:
int a;
};
class B : public A {
public:
voidblub(void) { WarnIfNULL(A::a); }
};
int
main(int argc, char *argv[])
{
int bs = 10;
B cxxsucks;
cxxsucks.blub();
bs = WarnIfNULL(100);
::std::cout bullshit: bs ::std::endl;
exit(0);
}
$ c++ fuck.c++
/usr/lib/libstdc++.so.49.0: warning: strcpy() is almost always
misused, please use strlcpy()
/usr/lib/libstdc++.so.49.0: warning: strcat() is almost always
misused, please use strlcat()
$ ./a.out
a.out: blub
bullshit: 100
Re: How to work around this compiler bug
On Sun, May 02, 2010 at 12:54:42PM -0700, patrick keshishian wrote:
On Sun, May 2, 2010 at 3:59 AM, Christopher Zimmermann
madro...@zakweb.de wrote:
On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Why do some C++ programmer still use macros where they're not needed ?
bunch of idiots, let them stay with C.
#includeerr.h
templatetypename T
inline T WarnIfNULL(T x)
{
if (!x)
warn(blub);
return x;
}
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
ok, thanks. That seems to be the solution, still I have to wrap it in a
macro, because I need __LINE__, __FILE__, __CLASS__...
You example obviously isn't showing the exact usage you require. I
imagine the macro is being used in assignments, not just in the blub()
method as you display.
Doesn't change a lot.
It's still a very good idea to stay away from macros for most things in C++,
and if you require __LINE__, __FILE__, __func__, *then* you write a proper
inline function (or a template if it needs to be polymorphic), and only wrap
the most external call into a macro that inserts __LINE__... where needed.
That way, you get actual parameter type checking that you can understand,
and the macros themselves.
Everyone sane does things that way, and has used similar tricks even on
C compiler (check a proper getc definition on most any reasonable library,
the macro just inlines the buffer check, and defers the actual complicated
code to an out-of-line function).
Re: [SOLVED] How to work around this compiler bug
ok, thanks everyone. Problem is solved and I even learned some things, too. Christopher
How to work around this compiler bug
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Re: How to work around this compiler bug
On Sat, May 1, 2010 at 11:39 AM, Christopher Zimmermann madro...@zakweb.de wrote: Hi, the following piece of code compiles fine using g++ 4.2.4, but fails using g++ 3.3.5 in the base system: error: operands to ?: have different types It is part of ptlib, which is the base library for opal, which in turn is needed for ekiga, which I'm trying to port. Save yourself time, pkg_add ekiga.
Re: How to work around this compiler bug
On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Why do some C++ programmer still use macros where they're not needed ?
bunch of idiots, let them stay with C.
#includeerr.h
templatetypename T
inline T WarnIfNULL(T x)
{
if (!x)
warn(blub);
return x;
}
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
Re: How to work around this compiler bug
Christopher Zimmermann madro...@zakweb.de writes:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
How about something like this...
#includeerr.h
// #define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
templateclass T
inline T WarnIfNULL(T x)
{
if (!x)
warnx(blub);
return x;
}
class A
{
protected:
A() : a(0) {}
//A() : a(1) {}
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
int
main()
{
B b;
b.blub();
return 0;
}
--
Mike Small
sma...@panix.com
Re: How to work around this compiler bug
Use a less retarded language.
On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
Hi,
the following piece of code compiles fine using g++ 4.2.4, but
fails using g++ 3.3.5 in the base system:
error: operands to ?: have different types
It is part of ptlib, which is the base library for opal, which in
turn is needed for ekiga, which I'm trying to port.
What is your suggestion? Can anyone think of a workaround for
this or should I just compile it using eg++ 4.2.4 ?
Christopher
#includeerr.h
#define WarnIfNULL(x) ((x) ? (x) : (warn(blub),(x)))
class A
{
protected:
int a;
};
class B : A
{
public:
void blub()
{
WarnIfNULL(A::a);
}
};
