"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.

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.

"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.
> >It's been fixed, too. Will appear in next update.
> Mute point I guess.. still makes me wonder though.

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.

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

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
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

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.
>> >It's been fixed, too. Will appear in next update.
>> Mute point I guess.. still makes me wonder though.
>
>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

"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
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 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
guess
> I should check out the spec.

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

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