compile or not compile

compile or not compile

[Karo Szkudlarek]

Hi!

The following program:

include <iostream>
typedef int my_int;

class A
{

public:
     enum Items
     {
         item1=1000,
         item2=2000
     };

//    typedef int my_int;
     int foo(const my_int&)
         {
             std::cerr << "int\n";
             return 0;
         }
     int foo(const bool&)
         {
             std::cerr << "bool\n";
             return 0;
         }
};

int main()
{
     A a;
     a.foo(A::item1);
     return 0;
}

on my platform (Suse Linux, gcc 3.3.3) does not compile. Returns errors:
testtypedef.cpp: In function `int main()':
testtypedef.cpp:30: error: call of overloaded `foo(A::Items)' is ambiguous
testtypedef.cpp:16: error: candidates are: int A::foo(const my_int&)
testtypedef.cpp:21: error:                 int A::foo(const bool&)

I posted my problem to compl.lang.c++ and I got answer that
reason for this is compiler bug. I don't know how can I avoid it.
My program compiles fine on another linuxes with gcc 3.3.3 for
example gentoo and debian. Also I posted my problem to Suse support
but got answer that:

"So far, we are not aware about any problem in this package."

says about gcc package.

Any ideas what can I do now? Is it compiler bug or not... I am very 
confused...

Greets,
Karol Szkudlarek

Re: compile or not compile

[Eljay Love-Jensen]

Hi Karo,

Add this to your class A:

int foo(Items const&)
{
   std::cerr << "A::Items\n";
   return 0;
}

HTH,
--Eljay

Re: compile or not compile

[Purnendu/Gmail]

Is this compiler specific

i am using  gcc 3.2.2

On use c++ <filename.cpp>
the program compiles normally 

using gcc it gives errros<i have attached the error file>

Going with Ejay's solution, the problem doesn't get resolved when i
use gcc on my redhat linux 9.0 box



On Thu, 01 Jul 2004 08:59:46 -0500, Eljay Love-Jensen <eljay@adobe.com> wrote:
> Hi Karo,
> 
> Add this to your class A:
> 
> int foo(Items const&)
> {
>   std::cerr << "A::Items\n";
>   return 0;
> }
> 
> HTH,
> --Eljay
> 
>

Re: compile or not compile

[Eljay Love-Jensen]

Hi Purnendu,

Use the"gcc" command for C.

Use the "g++" command for C++.

HTH,
--Eljay

Re: compile or not compile

[Karol Szkudlarek]

Eljay Love-Jensen wrote:

> Hi Karo,
>
> Add this to your class A:
>
> int foo(Items const&)
> {
>   std::cerr << "A::Items\n";
>   return 0;
> }
>
> HTH,
> --Eljay
>
Hi!

I can't use you solution in my code because in real example I have 
little different sitiuation.
In my second test case I try to explain more precisely my real case. 
Look at the following code:

// SECOND_CASE
typedef int my_int;

class ALibraryClass
{

public:
    int foo(const my_int&)
        {
            return 0;
        }
    int foo(const bool&)
        {
            return 0;
        }
};

class BClientClass
{
    public:
    enum Items
    {
        item1=1000,
        item2=2000
    };
    void test()
    {
        ALibraryClass a;
        a.foo(BClientClass::item1);
    }
};

int main()
{
    BClientClass b;
    b.test();
    return 0;
}

In class ALibraryClass I can't define int foo(Items const&)
because I know nothing about enum Items from client class BClientClass.


Generally I would like to know why this program compiles fine (gcc 3.3.3)
under Debian but does not compile under Suse (gcc 3.3.3).  Is it possible
such a difference in compiling results with the same versions of compiler?
Is that different situation can suggest compiler bug or for example 
different
default settings/options of same compiler?

Greets,Karol Szk

Re: compile or not compile

[Eljay Love-Jensen]

Hi Karol,

Okay, then do this:

-----------------------------
// SECOND_CASE
typedef int my_int;

class ALibraryClass
{

public:
    int foo(const my_int&)
        {
            return 0;
        }
    int foo(const bool&)
        {
            return 0;
        }
};

class BClientClass
{
    public:
    enum Items
    {
        item1=1000,
        item2=2000
    };
    void test()
    {
        ALibraryClass a;
        a.foo(int(BClientClass::item1));
    }
};

int main()
{
    BClientClass b;
    b.test();
    return 0;
}
-----------------------------

And everything should work as desired.

HTH,
--Eljay

Re: compile or not compile

[Karol Szkudlarek]

Eljay Love-Jensen wrote:
> Hi Karol,
> 
> Okay, then do this:
> 
> -----------------------------
> // SECOND_CASE
> typedef int my_int;
> 
> class ALibraryClass
> {
> 
> public:
>    int foo(const my_int&)
>        {
>            return 0;
>        }
>    int foo(const bool&)
>        {
>            return 0;
>        }
> };
> 
> class BClientClass
> {
>    public:
>    enum Items
>    {
>        item1=1000,
>        item2=2000
>    };
>    void test()
>    {
>        ALibraryClass a;
>        a.foo(int(BClientClass::item1));
>    }
> };
> 
> int main()
> {
>    BClientClass b;
>    b.test();
>    return 0;
> }
> -----------------------------
> 
> And everything should work as desired.
> 
> HTH,
> --Eljay
> 

Hi!

Casting in my case is no option because in real program I have many
lines like:
               a.foo(BClientClass::item1);

Greets,Karol

Re: compile or not compile

[llewelly]

Karol Szkudlarek <karol@mikronika.com.pl> writes:

> Eljay Love-Jensen wrote:
> 
> > Hi Karo,
> >
> > Add this to your class A:
> >
> > int foo(Items const&)
> > {
> >   std::cerr << "A::Items\n";
> >   return 0;
> > }
> >
> > HTH,
> > --Eljay
> >
> Hi!
> 
> I can't use you solution in my code because in real example I have
> little different sitiuation.
> In my second test case I try to explain more precisely my real
> case. Look at the following code:
> 
> // SECOND_CASE
> typedef int my_int;
> 
> class ALibraryClass
> {
> 
> public:
>     int foo(const my_int&)
>         {
>             return 0;
>         }
>     int foo(const bool&)
>         {
>             return 0;
>         }
> };
> 
> class BClientClass
> {
>     public:
>     enum Items
>     {
>         item1=1000,
>         item2=2000
>     };
>     void test()
>     {
>         ALibraryClass a;
>         a.foo(BClientClass::item1);

This should select A::foo(const my_int&) unambigously; enum to int is
    a promotion (see 4.5) while enum to bool is a conversion (4.12)
    and a promotion is a better match than conversion, (13.3.3.2/4).

>     }
> };
> 
> int main()
> {
>     BClientClass b;
>     b.test();
>     return 0;
> }
> 
> In class ALibraryClass I can't define int foo(Items const&)
> because I know nothing about enum Items from client class BClientClass.
> 
> 
> Generally I would like to know why this program compiles fine (gcc 3.3.3)
> under Debian but does not compile under Suse (gcc 3.3.3).  Is it possible
> such a difference in compiling results with the same versions of
> compiler?

You aren't really using the same compiler versions. For reasons known
    only to those who build distros, nearly every linux distro (and
    each BSD too!) maintains its own set of patches for gcc; what
    SUSE calls GCC 3.3.3 is actually a SUSE-special derivative of FSF
    GCC 3.3.3, what debian calls GCC 3.3.3 is a debian-special
    derivative of FSF GCC 3.3.3, and they are not really the same -
    only mostly the same. Most of the time, you won't run into the
    differences, but sometimes ...

FWIW, FSF GCC 3.3.3 and 3.4 like it, FBSD GCC 2.95.3 and 3.3.3 like
    it, and slackware-9.0 GCC 3.2.2 like it. I think you should report
    a bug to SUSE.

Re: compile or not compile

[Karol Szkudlarek]

llewelly@xmission.com wrote:
> Karol Szkudlarek <karol@mikronika.com.pl> writes:
> 
> 
>>Eljay Love-Jensen wrote:
>>
>>
>>>Hi Karo,
>>>
>>>Add this to your class A:
>>>
>>>int foo(Items const&)
>>>{
>>>  std::cerr << "A::Items\n";
>>>  return 0;
>>>}
>>>
>>>HTH,
>>>--Eljay
>>>
>>
>>Hi!
>>
>>I can't use you solution in my code because in real example I have
>>little different sitiuation.
>>In my second test case I try to explain more precisely my real
>>case. Look at the following code:
>>
>>// SECOND_CASE
>>typedef int my_int;
>>
>>class ALibraryClass
>>{
>>
>>public:
>>    int foo(const my_int&)
>>        {
>>            return 0;
>>        }
>>    int foo(const bool&)
>>        {
>>            return 0;
>>        }
>>};
>>
>>class BClientClass
>>{
>>    public:
>>    enum Items
>>    {
>>        item1=1000,
>>        item2=2000
>>    };
>>    void test()
>>    {
>>        ALibraryClass a;
>>        a.foo(BClientClass::item1);
> 
> 
> This should select A::foo(const my_int&) unambigously; enum to int is
>     a promotion (see 4.5) while enum to bool is a conversion (4.12)
>     and a promotion is a better match than conversion, (13.3.3.2/4).

Those above explain me everything. Thanks. I wrote and tested on my 
"broken" suse the following program:
typedef int my_int;
void foo(const my_int& a)
{
}
void foo(const bool& b)
{
}
enum Items
{
    item1,item2
};
int main()
{
    foo(item1);
}
and something must be wrong when arguments are references because when
I remove references program compiles fine.

> 
> 
>>    }
>>};
>>
>>int main()
>>{
>>    BClientClass b;
>>    b.test();
>>    return 0;
>>}
>>
>>In class ALibraryClass I can't define int foo(Items const&)
>>because I know nothing about enum Items from client class BClientClass.
>>
>>
>>Generally I would like to know why this program compiles fine (gcc 3.3.3)
>>under Debian but does not compile under Suse (gcc 3.3.3).  Is it possible
>>such a difference in compiling results with the same versions of
>>compiler?
> 
> 
> You aren't really using the same compiler versions. For reasons known
>     only to those who build distros, nearly every linux distro (and
>     each BSD too!) maintains its own set of patches for gcc; what
>     SUSE calls GCC 3.3.3 is actually a SUSE-special derivative of FSF
>     GCC 3.3.3, what debian calls GCC 3.3.3 is a debian-special
>     derivative of FSF GCC 3.3.3, and they are not really the same -
>     only mostly the same. Most of the time, you won't run into the
>     differences, but sometimes ...
> 
> FWIW, FSF GCC 3.3.3 and 3.4 like it, FBSD GCC 2.95.3 and 3.3.3 like
>     it, and slackware-9.0 GCC 3.2.2 like it. I think you should report
>     a bug to SUSE.
> 


Once again thank you very much for help. I try once again report a bug 
to suse because when I sent bug report couple days ago I got interesting 
answer:

"Unfortunately, we cannot provide any support to fix this problem. 
Please, understand that we dont have any control on the developemnt of 
this package. But, if we made any error packaging the compiler, we need 
to know it at the form I already sent to you.

So far, we are not aware about any problem in this package."

says about gcc.

Greets, Karol

Re: compile or not compile

[Eljay Love-Jensen]

Hi Karol,

 >...and something must be wrong when arguments are references because when 
I remove references program compiles fine.

Here's my C++ rule-of-thumb I've used since I started programming in C++:
For POD, ALWAYS pass-by-value and never pass-by-constant-reference.
For UDT, ALWAYS pass-by-constant-reference and never pass-by-value.
UNLESS, you need to modify the item, then pass-by-reference.
UNLESS, the item is optional, then pass-by-pointer (and NULL represents 
"optional parm not present").

Note:  when I say "optional", I'm not necessarily referring to default 
value parameters.

Also note, pass-by-value can be pass-by-constant-value ... but I rarely do 
that.

POD is "plain old datatype", such as char, short, int, long, float, double, 
long double, bool, enum, pointer, function pointer.

UDT is "user defined types", such as classes, structs, unions.

HTH,
--Eljay

Re: compile or not compile

[llewelly]

Eljay Love-Jensen <eljay@adobe.com> writes:

> Hi Karol,
> 
>  >...and something must be wrong when arguments are references because
> when I remove references program compiles fine.
> 
> Here's my C++ rule-of-thumb I've used since I started programming in C++:
> For POD, ALWAYS pass-by-value and never pass-by-constant-reference.
> For UDT, ALWAYS pass-by-constant-reference and never pass-by-value.

hm. So if a type is both POD and UDT, what do you do?

Re: compile or not compile

[Eljay Love-Jensen]

Hi,

 >hm. So if a type is both POD and UDT, what do you do?

I didn't know that was possible, in C++.

(Keep in mind that "typedef" does not introduce a new type, it merely 
introduces an alias.)

--Eljay

Re: compile or not compile

[llewelly]

Eljay Love-Jensen <eljay@adobe.com> writes:

> Hi,
> 
>  >hm. So if a type is both POD and UDT, what do you do?
> 
> I didn't know that was possible, in C++.

struct f{};
struct f2{int i;};

template<class T>
struct cmp{bool operator()(T lhs,T rhs){return lhs < rhs;}};

f foo;
f2 foo2;
cmp<int> c;

foo, foo2, and c are all both POD and UDT. It's not just possible;
    it's quite common; any C++ project which relies on 3rd party C
    libraries uses types that are both POD and UDT. Most standard C++
    libraries (including gcc's libstdc++) contain many types that that
    are both POD and UDT. 

For reference, see the middle of 9/4:

#    [...] A POD-struct is an aggregate class that has no non-static
#    data members of type non-POD-struct, non-POD-union (or array of
#    such types) or reference, and has no user-defined copy assignment
#    operator and no user-defined destructor. [...]

and also 8.5.1/1:

#    An aggregate is an array or a class (clause 9) with no
#    user-declared constructors (12.1), no private or protected
#    non-static data members (clause 11), no base classes (clause 10),
#    and no virtual functions (10.3).

Re: compile or not compile

[Eljay Love-Jensen]

Hi,

A POD-struct is a UDT, not a POD.

In the examples, f, f2 and cmp<int> are UDT.  (With foo, foo2, and c being 
instances thereof.)

--Eljay

Re: compile or not compile

[llewelly]

Eljay Love-Jensen <eljay@adobe.com> writes:

> Hi,
> 
> A POD-struct is a UDT, not a POD.
> 
> In the examples, f, f2 and cmp<int> are UDT.  (With foo, foo2, and c
> being instances thereof.)

Yes, I should have said foo, foo2, and c were 'of UDT', not
    'UDT'. Your earlier statement:

> For POD, ALWAYS pass-by-value and never pass-by-constant-reference.
> For UDT, ALWAYS pass-by-constant-reference and never pass-by-value.

led me to believe you wouldn't object to mixing object terminology
    with type terminology. :-)

(now that we are wholly off-topic)

Re: compile or not compile

[Alexandre Oliva]

On Jul  2, 2004, llewelly@xmission.com wrote:

> Karol Szkudlarek <karol@mikronika.com.pl> writes:

>> typedef int my_int;

>> class ALibraryClass { public: int foo(const my_int&) { return 0; }
>>   int foo(const bool&) { return 0; } };

>> class BClientClass { public: enum Items { item1=1000, item2=2000 };

>> void test() { ALibraryClass a; a.foo(BClientClass::item1);

> This should select A::foo(const my_int&) unambigously; enum to int is
>     a promotion (see 4.5) while enum to bool is a conversion (4.12)
>     and a promotion is a better match than conversion, (13.3.3.2/4).

But there's reference binding requiring conversion, so both are
user-defined conversions [over.ics.ref]/1, and none of them is better
than the other, because the tie-breaker is only the second conversion
sequence [over.ics.rank]/3, that is an exact match in both cases.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: compile or not compile

[Karol Szkudlarek]

Alexandre Oliva wrote:

>On Jul  2, 2004, llewelly@xmission.com wrote:
>
>  
>
>>Karol Szkudlarek <karol@mikronika.com.pl> writes:
>>    
>>
>
>  
>
>>>typedef int my_int;
>>>      
>>>
>
>  
>
>>>class ALibraryClass { public: int foo(const my_int&) { return 0; }
>>>  int foo(const bool&) { return 0; } };
>>>      
>>>
>
>  
>
>>>class BClientClass { public: enum Items { item1=1000, item2=2000 };
>>>      
>>>
>
>  
>
>>>void test() { ALibraryClass a; a.foo(BClientClass::item1);
>>>      
>>>
>
>  
>
>>This should select A::foo(const my_int&) unambigously; enum to int is
>>    a promotion (see 4.5) while enum to bool is a conversion (4.12)
>>    and a promotion is a better match than conversion, (13.3.3.2/4).
>>    
>>
>
>But there's reference binding requiring conversion, so both are
>user-defined conversions [over.ics.ref]/1, and none of them is better
>than the other, because the tie-breaker is only the second conversion
>sequence [over.ics.rank]/3, that is an exact match in both cases.
>
>  
>
OK. But why this compiles without error with gcc (3.3) on one platform
and one another (gcc 3.3) it doesn't?

Re: compile or not compile

[Alexandre Oliva]

On Jul 19, 2004, Karol Szkudlarek <karol@mikronika.com.pl> wrote:

> OK. But why this compiles without error with gcc (3.3) on one platform
> and one another (gcc 3.3) it doesn't?

Most likely not the same GCC.  IIRC you had one straight from the FSF,
and another from some GNU/Linux vendor, that presumably patched the
compiler.  I don't quite remember which failed to compile and which
accepted the ill-formed code, to tell whether the patch was a
standard-conformance bug fix or a bugward-compatibility patch.  Point
is, if it's not the same exact compiler sources, this would explain
differences.  Heck, even with the same sources, you might end up with
different compilers if the build compiler happened to be buggy and you
didn't go through a 2+-stage bootstrap.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}