Digital Mars - c++ - Is this a compiler (8.33) bug?

↑ ↓ ← → Arjan Knepper <ask me.to> writes:

 #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

Apr 01 2003

↑ ↓ ← → "W�odzimierz Skiba" <abx abx.art.pl> writes:

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

Apr 01 2003

↑ ↓ ← → Kon Tantos <ksoft1 attglobal.net> writes:

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

Apr 03 2003

↑ ↓ ← → "W�odzimierz Skiba" <abx abx.art.pl> writes:

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 c++/2029 ?
Oh, there is zip, thanks.

ABX

Apr 04 2003

↑ ↓ ← → Kon Tantos <ksoft1 attglobal.net> writes:

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 c++/2029 ?
 Oh, there is zip, thanks.
 
 ABX

Apr 04 2003

↑ ↓ ← → Jan Knepper <jan smartsoft.us> writes:

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

Apr 01 2003

↑ ↓ ← → Paul McKenzie <paul paul.net> writes:

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
 


It compiles cleanly, so you can say with almost certain assurance that 
this is a DMC compiler bug.

Apr 01 2003

↑ ↓ ← → Richard Grant <fractal clark.net> writes:

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

Apr 10 2003

↑ ↓ ← → Arjan Knepper <ask me.to> writes:

 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

Apr 10 2003

↑ ↓ ← → Kon Tantos <ksoft1 attglobal.net> writes:

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

Apr 10 2003

↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:

Richard Grant schrieb...
 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) { };
 };


From 8.3.5.3 this should be considered uncompilable:

  class c {
     c(int **p);
     c(int ** const p);
 //           ^^^^^
 // this const will be removed and therefore we have
 // the same signature as the construktor above
  };

This also means that you can declare c in a header as

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

and write the implementation as

   c::c(int ** const p) {
     //...
     int ** const temp = something;
     p = temp;  // does not compile, p is const
   }


- Heinz

Apr 10 2003

↑ ↓ ← → "Matthew Wilson" <dmd synesis.com.au> writes:

I've not followed the thread intimately, so I may be jumping in half-cocked,
but it seems like you've mixed up

 c(const int** cp)

with


     c(int ** const p);


They are very different beasts.

"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.19008542e38bd2879896b9 news.digitalmars.com...
 Richard Grant schrieb...
 According to 12.3.1.1, a single parm c'tor without explicit spec is a




 defined conversion in the form of a converting constructor, and




 8.3.5.3, it is an overloaded function. Reading further in 8.3.5.3, it




 that cv-qualifiers are removed from the parameter list in determining




 of the function, and that such cv-qualifiers only effect the behavior of




 parameter inside the function.

 So, it seems to me that the example provided is a redeclaration of a




 constructor, and the second definition is - in fact - an attempt to




 already existing function.

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


 From 8.3.5.3 this should be considered uncompilable:

   class c {
      c(int **p);
      c(int ** const p);
  //           ^^^^^
  // this const will be removed and therefore we have
  // the same signature as the construktor above
   };

 This also means that you can declare c in a header as

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

 and write the implementation as

    c::c(int ** const p) {
      //...
      int ** const temp = something;
      p = temp;  // does not compile, p is const
    }


 - Heinz

Apr 11 2003

↑ ↓ ← → Richard Grant <fractal clark.net> writes:

In article <b74n8d$1uv$2 digitaldaemon.com>, Walter says...
"Paul McKenzie" <paul paul.net> wrote in message
news:b6cslo$2s2g$1 digitaldaemon.com...
 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.


It's been fixed, too. Will appear in next update.


Mute point I guess.. still makes me wonder though.

Apr 10 2003

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Richard Grant" <fractal clark.net> wrote in message
news:b74oq6$2v1$1 digitaldaemon.com...
 In article <b74n8d$1uv$2 digitaldaemon.com>, Walter says...
"Paul McKenzie" <paul paul.net> wrote in message
news:b6cslo$2s2g$1 digitaldaemon.com...
 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.






I did a little research on it. Unsurprisingly, it is complicated, and rather
difficult to figure out just what the spec is saying. These kinds of things
are why const, as a type modifier, is not in D.

Apr 10 2003

↑ ↓ ← → Richard Grant <fractal clark.net> writes:

In article <b753db$9bu$1 digitaldaemon.com>, Walter says...
"Richard Grant" <fractal clark.net> wrote in message
news:b74oq6$2v1$1 digitaldaemon.com...
 In article <b74n8d$1uv$2 digitaldaemon.com>, Walter says...
"Paul McKenzie" <paul paul.net> wrote in message
news:b6cslo$2s2g$1 digitaldaemon.com...
 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.






I did a little research on it. Unsurprisingly, it is complicated, and rather
difficult to figure out just what the spec is saying. These kinds of things
are why const, as a type modifier, is not in D.


Ok. I guess that since all the other compilers can compile it, there must at
least be precedent. Since you just had a glance at the issue, what about
something like:

typedef int A[5];
typedef const A CA;

void fn(CA* a) { }
// Error: type qualifiers and static can only appear in outermost array of
function parameter

void fn0(const A* a) { }
// Error: type qualifiers and static can only appear in outermost array of
function parameter

int main() {}

Before the current argument (when I thought I understood cv-qualification as it
applies in parameter conversions and overloading), I would have said nope, the
above shouldn't compile. Anyway, it doesn't compile with current compiler.

As for D, I assume you do away with const by virtue of contract in/out
declarations - or is there no such thing as an immuttable object? Well, I guess
I should check out the spec.

Richard

Apr 12 2003

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Richard Grant" <fractal clark.net> wrote in message
news:b7a0nn$j4v$1 digitaldaemon.com...
 Ok. I guess that since all the other compilers can compile it, there must


 least be precedent. Since you just had a glance at the issue, what about
 something like:

 typedef int A[5];
 typedef const A CA;

 void fn(CA* a) { }
 // Error: type qualifiers and static can only appear in outermost array of
 function parameter

 void fn0(const A* a) { }
 // Error: type qualifiers and static can only appear in outermost array of
 function parameter

 int main() {}

 Before the current argument (when I thought I understood cv-qualification


 applies in parameter conversions and overloading), I would have said nope,


 above shouldn't compile. Anyway, it doesn't compile with current compiler.


As you can see, there are no end of special cases. It's a quagmire that very
few programmers really understand. I've recommended to C++ programmers to
just avoid using const.

 As for D, I assume you do away with const by virtue of contract in/out
 declarations - or is there no such thing as an immuttable object? Well, I


 I should check out the spec.


There are const storage classes, but no const type modifiers.

Apr 12 2003