Thread overview
Benign (and useful) redefinition of function implementations rejected ...
Jun 11, 2003
Matthew Wilson
Jun 11, 2003
Walter
Jun 11, 2003
Matthew Wilson
Jun 12, 2003
Heinz Saathoff
Jun 12, 2003
Walter
June 11, 2003
// 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?


June 11, 2003
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?
>
>


June 11, 2003
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?
> >
> >
>
>




June 12, 2003
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
June 12, 2003
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