www.digitalmars.com         C & C++   DMDScript  

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

reply 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
next sibling parent reply "W這dzimierz 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
parent reply 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這dzimierz 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
parent reply "W這dzimierz 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
parent Kon Tantos <ksoft1 attglobal.net> writes:
W這dzimierz 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
prev sibling next sibling parent 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
prev sibling parent reply 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
next sibling parent reply 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
next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent reply 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
parent reply "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
parent Heinz Saathoff <hsaat bre.ipnet.de> writes:
Matthew Wilson schrieb...
 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.

That's what I wanted to say! - Heinz
Apr 14 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Apr 10 2003
parent reply 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
parent reply "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
parent reply 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
parent "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