www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

c++ - Benign (and useful) redefinition of function implementations rejected ...

↑ ↓ ← "Matthew Wilson" <matthew stlsoft.org> writes:
// In header
char *someFunc(char *arg);



// In implementation file
char *someFunc(char *const arg)
{
    ... Do something

}


Redefining to const means that arg cannot be changed, albeit that its
contents can. This tactic is used in general in functions whereby you may
access the argument in more than one point within the function body, and
wish to protect yourself (or rather the implementation) from maintenance
"improvements", in which someone may carelessly reuse one of the function
arguments to avoid a frame variable (often from a misguided sense of
efficiency), thereby invalidating the axioms of your implementation.

Most of the other compilers to hand happily allow this. DMC++, alas, does
not. It is my belief, though it's been a _long_ time since I dealt with this
issue, that it is standard compliant.

btw, all please not that this is not advocating

// In implementation file
char *someFunc(char const *arg)
{
    ... Do something

}

as that is an entirely different semantic from the perspective of the the
caller.

A simpler way to look at this is

// In header
int someFunc(int arg);



// In implementation file
int someFunc(int const arg)
{
    ... Do something

}

I've not run this through DMC++, but I presume it would behave the same.

Any chance of a fix, Walter?
Jun 11 2003
↑ ↓ "Walter" <walter digitalmars.com> writes:
Are you saying it should or should not compile it?

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bc7ec6$27ln$1 digitaldaemon.com...
 // In header
 char *someFunc(char *arg);



 // In implementation file
 char *someFunc(char *const arg)
 {
     ... Do something

 }


 Redefining to const means that arg cannot be changed, albeit that its
 contents can. This tactic is used in general in functions whereby you may
 access the argument in more than one point within the function body, and
 wish to protect yourself (or rather the implementation) from maintenance
 "improvements", in which someone may carelessly reuse one of the function
 arguments to avoid a frame variable (often from a misguided sense of
 efficiency), thereby invalidating the axioms of your implementation.

 Most of the other compilers to hand happily allow this. DMC++, alas, does
 not. It is my belief, though it's been a _long_ time since I dealt with

 issue, that it is standard compliant.

 btw, all please not that this is not advocating

 // In implementation file
 char *someFunc(char const *arg)
 {
     ... Do something

 }

 as that is an entirely different semantic from the perspective of the the
 caller.

 A simpler way to look at this is

 // In header
 int someFunc(int arg);



 // In implementation file
 int someFunc(int const arg)
 {
     ... Do something

 }

 I've not run this through DMC++, but I presume it would behave the same.

 Any chance of a fix, Walter?

Jun 11 2003
→ "Matthew Wilson" <matthew stlsoft.org> writes:
Should

"Walter" <walter digitalmars.com> wrote in message
news:bc7v9l$2ofs$1 digitaldaemon.com...
 Are you saying it should or should not compile it?

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bc7ec6$27ln$1 digitaldaemon.com...
 // In header
 char *someFunc(char *arg);



 // In implementation file
 char *someFunc(char *const arg)
 {
     ... Do something

 }


 Redefining to const means that arg cannot be changed, albeit that its
 contents can. This tactic is used in general in functions whereby you


 access the argument in more than one point within the function body, and
 wish to protect yourself (or rather the implementation) from maintenance
 "improvements", in which someone may carelessly reuse one of the


 arguments to avoid a frame variable (often from a misguided sense of
 efficiency), thereby invalidating the axioms of your implementation.

 Most of the other compilers to hand happily allow this. DMC++, alas,


 not. It is my belief, though it's been a _long_ time since I dealt with

 issue, that it is standard compliant.

 btw, all please not that this is not advocating

 // In implementation file
 char *someFunc(char const *arg)
 {
     ... Do something

 }

 as that is an entirely different semantic from the perspective of the


 caller.

 A simpler way to look at this is

 // In header
 int someFunc(int arg);



 // In implementation file
 int someFunc(int const arg)
 {
     ... Do something

 }

 I've not run this through DMC++, but I presume it would behave the same.

 Any chance of a fix, Walter?


Jun 11 2003
Heinz Saathoff <hsaat bre.ipnet.de> writes:
Walter schrieb...
 
 Are you saying it should or should not compile it?

It should compile. Here a reference to the standard: In chapter 8.3.5 (3) Functions I found this: "After producing the list of parameter types, several transformations take place upon these types to determine the function type. Any cv-qualifier modifying a parameter type is deleted. [Example: the type void (*)(const int) becomes void (*)(int) -end example]. Such cv-qualifiers affect only the definition of the parameter within the body of the function; they do not affect the function type." So this declarations denote the same function! void func(int); void func(const int); void func(volatile int); - Heinz
Jun 12 2003
↑ ↓ → "Walter" <walter digitalmars.com> writes:
Thanks, that's pretty clear. -Walter

"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.195246a5927aaca79896c0 news.digitalmars.com...
 Walter schrieb...
 Are you saying it should or should not compile it?

It should compile. Here a reference to the standard: In chapter 8.3.5 (3) Functions I found this: "After producing the list of parameter types, several transformations take place upon these types to determine the function type. Any cv-qualifier modifying a parameter type is deleted. [Example: the type void (*)(const int) becomes void (*)(int) -end example]. Such cv-qualifiers affect only the definition of the parameter within the body of the function; they do not affect the function type." So this declarations denote the same function! void func(int); void func(const int); void func(volatile int); - Heinz

Jun 12 2003