Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
June 11, 2003 Benign (and useful) redefinition of function implementations rejected ... | ||||
---|---|---|---|---|
| ||||
// 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 Re: Benign (and useful) redefinition of function implementations rejected ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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 Re: Benign (and useful) redefinition of function implementations rejected ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: Benign (and useful) redefinition of function implementations rejected ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: Benign (and useful) redefinition of function implementations rejected ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Heinz Saathoff | 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 |
Copyright © 1999-2021 by the D Language Foundation