www.digitalmars.com         C & C++   DMDScript  

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

reply "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
parent reply "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


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
next sibling parent "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




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
prev sibling parent reply 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
parent "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