> #include <stdio.h>
> 
> 
> 
> class  CCPP
> {
>    public :
>       CCPP ()                       {}
>       CCPP ( char  **data )         {}
>       CCPP ( const char  **data )   {}
> };
> 
> 
> 
> int  main ( int  arc, char  *argv [] )
> {
>    char       **buf  = 0;
> 
>    const char **ptr  = 0;
> 
>    CCPP    *ccpp0 = new  CCPP ();
>    CCPP    *ccpp1 = new  CCPP ( buf );
>    CCPP    *ccpp2 = new  CCPP ( ptr );
> }



P:\APK\TEST>s:\bin\dmc test1.cpp
      CCPP ( const char  **data )   {}
                                    ^
test1.cpp(10) : Error: 'CCPP::CCPP' is already defined
--- errorlevel 1

Arjan Knepper <ask@me.to> wrote in news:b6c9km$2d1h$1@digitaldaemon.com:
> P:\APK\TEST>s:\bin\dmc test1.cpp

:-)

I just noticed it too.

here is a minimal script to show problem.

class test
{
  test(const char **data) { };
  test(char **data) { };
}

It does not work neither with latest official nor latest beta.

For those interested it is about compiling wxWindows (www.wxwindows.org) with DigitalMars and bringing it to compilers supported in wxWindows community.

ABX

Yes it is!



Arjan Knepper wrote:

> > #include <stdio.h>
> >
> >
> >
> > class  CCPP
> > {
> >    public :
> >       CCPP ()                       {}
> >       CCPP ( char  **data )         {}
> >       CCPP ( const char  **data )   {}
> > };
> >
> >
> >
> > int  main ( int  arc, char  *argv [] )
> > {
> >    char       **buf  = 0;
> >
> >    const char **ptr  = 0;
> >
> >    CCPP    *ccpp0 = new  CCPP ();
> >    CCPP    *ccpp1 = new  CCPP ( buf );
> >    CCPP    *ccpp2 = new  CCPP ( ptr );
> > }
>
> P:\APK\TEST>s:\bin\dmc test1.cpp
>        CCPP ( const char  **data )   {}
>                                      ^
> test1.cpp(10) : Error: 'CCPP::CCPP' is already defined
> --- errorlevel 1

Arjan Knepper wrote:
>> #include <stdio.h>
>>
>>
>>
>> class  CCPP
>> {
>>    public :
>>       CCPP ()                       {}
>>       CCPP ( char  **data )         {}
>>       CCPP ( const char  **data )   {}
>> };
>>
>>
>>
>> int  main ( int  arc, char  *argv [] )
>> {
>>    char       **buf  = 0;
>>
>>    const char **ptr  = 0;
>>
>>    CCPP    *ccpp0 = new  CCPP ();
>>    CCPP    *ccpp1 = new  CCPP ( buf );
>>    CCPP    *ccpp2 = new  CCPP ( ptr );
>> }
> 
> 
> 
> 
> P:\APK\TEST>s:\bin\dmc test1.cpp
>       CCPP ( const char  **data )   {}
>                                     ^
> test1.cpp(10) : Error: 'CCPP::CCPP' is already defined
> --- errorlevel 1
> 
I just tried the code using the on-line compiler at Comeau Computing. It compiles cleanly, so you can say with almost certain assurance that this is a DMC compiler bug.

Hi,

I have a list of patches to wxWindows 2.40 which allow it to be compiled & linked with dmc 8.30. I have built the 2.4 lib & compiled various wx samples with dmc. I have an earlier post to this ng (around 18th of January).

I was planning incorporating the patches to 2.5, but I have just been totally snowed under.

I am happy to lend what time I can to this project.

Kon Tantos

W³odzimierz Skiba wrote:
> Arjan Knepper <ask@me.to> wrote in news:b6c9km$2d1h$1@digitaldaemon.com:
> 
>>P:\APK\TEST>s:\bin\dmc test1.cpp
> 
> 
> :-)
> 
> I just noticed it too.
> 
> here is a minimal script to show problem.
> 
> class test
> {
>   test(const char **data) { };
>   test(char **data) { };
> }
> 
> It does not work neither with latest official nor latest beta.
> 
> For those interested it is about compiling wxWindows (www.wxwindows.org) with DigitalMars and bringing it to compilers supported in wxWindows community.
> 
> ABX

Kon Tantos <ksoft1@attglobal.net> wrote in news:3E8C9B7D.6090709@attglobal.net:

> Hi,
> 
> I have a list of patches to wxWindows 2.40 which allow it to be compiled & linked with dmc 8.30.

If they are patches to hide compiler bugs then they should be rather fixed on compiler side. Are there such patches ? Have you reported them here? If the patches are not compiler but package specific have you tried reporting them as described at http://www.wxwindows.org/technote/patches.htm ? Have you noticed thread http://lists.wxwindows.org/cgi-bin/ezmlm- cgi?8:sss:34337:200303:djlnmogdddmnmknfcdob ?

So where are your patches available ? Can I ask for list ?

> I have an earlier post to this ng (around 18th of January).

You mean http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/2029 ? Oh, there is zip, thanks.

ABX

W³odzimierz Skiba wrote:
> Kon Tantos <ksoft1@attglobal.net> wrote in
> news:3E8C9B7D.6090709@attglobal.net: 
> 
> 
>>Hi,
>>
>>I have a list of patches to wxWindows 2.40 which allow it to be
>>compiled & linked with dmc 8.30.
> 
> 
> If they are patches to hide compiler bugs then they should be rather fixed on compiler side. Are there such patches ? Have you reported them here?
> If the patches are not compiler but package specific have you tried reporting them as described at http://www.wxwindows.org/technote/patches.htm ? Have you noticed thread http://lists.wxwindows.org/cgi-bin/ezmlm-
> cgi?8:sss:34337:200303:djlnmogdddmnmknfcdob ?

I did post to comp.soft-sys.wxwindows about this, but noone responded.
I also contacted Julian Smart who told me that 2.4 was closed & all new work was on 2.5.

I simply have not had time to learn all the wxWindows procedures etc.

> 
> So where are your patches available ? Can I ask for list ?
> 
> 
>>I have an earlier post to this ng (around 18th of January).
> 
> 
> You mean http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/2029 ?
> Oh, there is zip, thanks.
> 
> ABX

In article <b6cslo$2s2g$1@digitaldaemon.com>, Paul McKenzie says...

>I just tried the code using the on-line compiler at Comeau Computing. It compiles cleanly, so you can say with almost certain assurance that this is a DMC compiler bug.
>

Sorry to raise the dead here, but I'm confused about the general consensus on this issue, and the basis on which this example has been determined to be a compiler bug.

According to 12.3.1.1, a single parm c'tor without explicit spec is a user defined conversion in the form of a converting constructor, and according to 8.3.5.3, it is an overloaded function. Reading further in 8.3.5.3, it states that cv-qualifiers are removed from the parameter list in determining the type of the function, and that such cv-qualifiers only effect the behavior of the parameter inside the function.

So, it seems to me that the example provided is a redeclaration of a converting constructor, and the second definition is - in fact - an attempt to redefine an already existing function.

class c {
c(int** p { };
c(const int** cp) { };
};

int main() { }

So, my question is, other than another compilers willingness to compile the above example (and apparent general agreement), what is the argument that the example above should compile?

Richard

> Sorry to raise the dead here, but I'm confused about the general consensus on
> this issue, and the basis on which this example has been determined to be a
> compiler bug.
> 
> According to 12.3.1.1, a single parm c'tor without explicit spec is a user
> defined conversion in the form of a converting constructor, and according to
> 8.3.5.3, it is an overloaded function. Reading further in 8.3.5.3, it states
> that cv-qualifiers are removed from the parameter list in determining the type
> of the function, and that such cv-qualifiers only effect the behavior of the
> parameter inside the function.

Is this stuff somewhere online?

Thanks,
Arjan

Richard Grant wrote:
> In article <b6cslo$2s2g$1@digitaldaemon.com>, Paul McKenzie says...
> 
> 
>>I just tried the code using the on-line compiler at Comeau Computing. It compiles cleanly, so you can say with almost certain assurance that this is a DMC compiler bug.
>>
> 
> 
> Sorry to raise the dead here, but I'm confused about the general consensus on
> this issue, and the basis on which this example has been determined to be a
> compiler bug.
> 
> According to 12.3.1.1, a single parm c'tor without explicit spec is a user
> defined conversion in the form of a converting constructor, and according to
> 8.3.5.3, it is an overloaded function. Reading further in 8.3.5.3, it states
> that cv-qualifiers are removed from the parameter list in determining the type
> of the function, and that such cv-qualifiers only effect the behavior of the
> parameter inside the function.
> 
> So, it seems to me that the example provided is a redeclaration of a converting
> constructor, and the second definition is - in fact - an attempt to redefine an
> already existing function.
> 
> class c {
> c(int** p { };
> c(const int** cp) { };
> };
> 
> int main() { }
> 

The compiler does & must use cv qualifiers to determine which fn to call.

Try changing the 'int**' to 'int*' & you will see that dmc now compiles the code ok, ie distinguishes between the overloaded fns. What's more try passing an 'const int*' to the fn which takes an 'int*', you will find that the compiler won't accept it.

eg
void func1( int* ) {...}

const int*	ip = 0;
func1( ip );		// this line will not compile ( & should not)

> So, my question is, other than another compilers willingness to compile the
> above example (and apparent general agreement), what is the argument that the
> example above should compile?
> 
> Richard
> 
>