Thread: [Dev-C++] Use of const qualifier
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: Scott W. <se...@al...> - 2002-10-31 21:37:40
|
Hi, You've all been so helpful, I'm back for more . . . I'm curious about the use of the "const" qualifier as it applies to prototyping function arguments. In particular, suppose I have a function: double myfunc(double x, double *y) where myfunc uses the values of x and the array members of y but doesn't change them. Is there then an efficiency (speed) to be gained by instead declaring: double myfunc(const double x, const double *y)? Are there other advantages/disadvantages? Thanks, Scott |
|
From: Abhijit S. <mu...@gm...> - 2002-10-31 22:32:22
|
> where myfunc uses the values of x and the array members of y but doesn't > change them. Is there then an efficiency (speed) to be gained by instead > declaring: > > double myfunc(const double x, const double *y)? More than speed, the const qualifier is for debugging. It prevents the programmer from inadvertently changing the values of certain variables. Some new optimizing compilers also use it to align memory more efficiently. ___________________________________________________________ Abhijit Shylanath E-mail: mu...@gm... || ibr...@bi... Web-site: http://mudeth.tripod.com/ |
|
From: Scott W. <se...@al...> - 2002-11-01 18:37:37
|
Thanks for the reply--very helpful. You might know the answer to a related question. . . I have a math-intensive subroutine that is called millions of times (yes, millions) by a numerical algorithm. Currently, all of the variables in this subroutine are of automatic extent. Would there be any efficiency gained by instead giving them static extent? Each call to the subroutine is independent so retaining values across calls is not an issue. Rather, this is a question of how the memory access itself is handled. Thanks. Scott -----Original Message----- From: Abhijit Shylanath [mailto:mu...@gm...] Sent: Thursday, October 31, 2002 5:30 PM To: se...@al...; Dev-C++ Mailing List Subject: Re: [Dev-C++] Use of const qualifier > where myfunc uses the values of x and the array members of y but doesn't > change them. Is there then an efficiency (speed) to be gained by instead > declaring: > > double myfunc(const double x, const double *y)? More than speed, the const qualifier is for debugging. It prevents the programmer from inadvertently changing the values of certain variables. Some new optimizing compilers also use it to align memory more efficiently. ___________________________________________________________ Abhijit Shylanath E-mail: mu...@gm... || ibr...@bi... Web-site: http://mudeth.tripod.com/ |
|
From: Ioannis V. <no...@ho...> - 2002-11-01 20:32:22
|
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf
> Of Scott Williams
> Sent: Friday, November 01, 2002 8:38 PM
> To: Abhijit Shylanath; Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Use of const qualifier
>
>
> Thanks for the reply--very helpful. You might know the
> answer to a related
> question. . .
>
> I have a math-intensive subroutine that is called millions of
> times (yes,
> millions) by a numerical algorithm. Currently, all of the
> variables in this
> subroutine are of automatic extent. Would there be any
> efficiency gained by
> instead giving them static extent? Each call to the subroutine is
> independent so retaining values across calls is not an issue.
> Rather, this
> is a question of how the memory access itself is handled.
Yes. Also if you can make it easy to be inlined things will be more
better. Like:
// C++ code
inline int summary(const int &x, const int &y)
{
return x+y;
}
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys
|
|
From: Abhijit S. <mu...@gm...> - 2002-11-02 05:11:20
|
> Yes. Also if you can make it easy to be inlined things will be more > better. Inlining a function is decided by the compiler. Functions with loops, etc. are generally not inlined, so this won't be of much help. You can achieve the same end by simply eliminating the function (moving all of the code into the main routine). This will remove the overhead of function calls and memory allocation (which should help a lot in this case). This should be a case of code-elegance versus execution-speed. Also consider generating look-up tables of sine and cos. There are a lot of articles on the web about optimizing programs. I remember one that spoke in explicit detail about how memory can be optimized... unfortunately, I don't remember saving it. Google helps. ___________________________________________________________ Abhijit Shylanath E-mail: mu...@gm... || ibr...@bi... Web-site: http://mudeth.tripod.com/ |
|
From: Per W. <pw...@ia...> - 2002-11-01 20:56:36
|
Sorry, no correct answer on that one :-( Depends on compiler, processor and what the calling function did. If only targeted for a very specific machine, you have to time execution with the two alternatives, else leave the function as it is. Without relying on assembler - which is definitely CPU-specific - you can't force static variables to be placed at an optimum alignment, and you can't align the auto variables on the stack. The auto is probably the best all-around alternative, since it allows the compiler to use floating point registers. A static variable implies the survival of the value to the next call, which will probably reduce the effectivity of the compiler optimization step. /Per W On Fri, 1 Nov 2002, Scott Williams wrote: > Thanks for the reply--very helpful. You might know the answer to a related > question. . . > > I have a math-intensive subroutine that is called millions of times (yes, > millions) by a numerical algorithm. Currently, all of the variables in this > subroutine are of automatic extent. Would there be any efficiency gained by > instead giving them static extent? Each call to the subroutine is > independent so retaining values across calls is not an issue. Rather, this > is a question of how the memory access itself is handled. > > Thanks. > Scott > > > -----Original Message----- > From: Abhijit Shylanath [mailto:mu...@gm...] > Sent: Thursday, October 31, 2002 5:30 PM > To: se...@al...; Dev-C++ Mailing List > Subject: Re: [Dev-C++] Use of const qualifier > > > > where myfunc uses the values of x and the array members of y but doesn't > > change them. Is there then an efficiency (speed) to be gained by instead > > declaring: > > > > double myfunc(const double x, const double *y)? > > More than speed, the const qualifier is for debugging. It prevents the > programmer from inadvertently changing the values of certain variables. Some > new optimizing compilers also use it to align memory more efficiently. > > ___________________________________________________________ > > Abhijit Shylanath > > E-mail: mu...@gm... || ibr...@bi... > Web-site: http://mudeth.tripod.com/ > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Dev-cpp-users mailing list > Dev...@li... > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users > |
|
From: Scott W. <se...@al...> - 2002-11-01 21:33:00
|
Per, Thanks for the reply and info--it's good to know. I've learned a lot from your responses . Here are a couple more efficiency issues I'm curious about: 1) if(fabs(x) < num) versus if(x < num && x > -num) 2) sx = sin(x); cx = cos(x); versus cx = cos(x); sx = (x<PI) ? sqrt(1.0 - cx*cx) : -sqrt(1.0 - cx*cx); where in the latter case I know apriori that x lies within [0, TWOPI]. 3) same as 2 but have to pre-condition x first: x = fmod(x, TWOPI); cx = cos(x); sx = (x>-PI && x<PI) ? sqrt(1.0 - cx*cx) : -sqrt(1.0 - cx*cx); I know these probably seem fairly inconsequential but over millions of iterations, I'll take all the minor efficiency improvements i can get! Thanks, Scott -----Original Message----- From: Per Westermark [mailto:pw...@ia...] Sent: Friday, November 01, 2002 3:56 PM To: Scott Williams Cc: Abhijit Shylanath; Dev-C++ Mailing List Subject: RE: [Dev-C++] Use of const qualifier Sorry, no correct answer on that one :-( Depends on compiler, processor and what the calling function did. If only targeted for a very specific machine, you have to time execution with the two alternatives, else leave the function as it is. Without relying on assembler - which is definitely CPU-specific - you can't force static variables to be placed at an optimum alignment, and you can't align the auto variables on the stack. The auto is probably the best all-around alternative, since it allows the compiler to use floating point registers. A static variable implies the survival of the value to the next call, which will probably reduce the effectivity of the compiler optimization step. /Per W On Fri, 1 Nov 2002, Scott Williams wrote: > Thanks for the reply--very helpful. You might know the answer to a related > question. . . > > I have a math-intensive subroutine that is called millions of times (yes, > millions) by a numerical algorithm. Currently, all of the variables in this > subroutine are of automatic extent. Would there be any efficiency gained by > instead giving them static extent? Each call to the subroutine is > independent so retaining values across calls is not an issue. Rather, this > is a question of how the memory access itself is handled. > > Thanks. > Scott > > > -----Original Message----- > From: Abhijit Shylanath [mailto:mu...@gm...] > Sent: Thursday, October 31, 2002 5:30 PM > To: se...@al...; Dev-C++ Mailing List > Subject: Re: [Dev-C++] Use of const qualifier > > > > where myfunc uses the values of x and the array members of y but doesn't > > change them. Is there then an efficiency (speed) to be gained by instead > > declaring: > > > > double myfunc(const double x, const double *y)? > > More than speed, the const qualifier is for debugging. It prevents the > programmer from inadvertently changing the values of certain variables. Some > new optimizing compilers also use it to align memory more efficiently. > > ___________________________________________________________ > > Abhijit Shylanath > > E-mail: mu...@gm... || ibr...@bi... > Web-site: http://mudeth.tripod.com/ > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Dev-cpp-users mailing list > Dev...@li... > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users > |
|
From: Ioannis V. <no...@ho...> - 2002-11-01 17:16:30
|
> -----Original Message----- > From: dev...@li... > [mailto:dev...@li...] On Behalf > Of Scott Williams > Sent: Thursday, October 31, 2002 11:38 PM > To: Dev-Cpp-Users@Lists. Sourceforge. Net > Subject: [Dev-C++] Use of const qualifier > > > Hi, > > You've all been so helpful, I'm back for more . . . > > I'm curious about the use of the "const" qualifier as it applies to > prototyping function arguments. In particular, suppose I > have a function: > > double myfunc(double x, double *y) > > where myfunc uses the values of x and the array members of y > but doesn't > change them. Is there then an efficiency (speed) to be > gained by instead > declaring: > > double myfunc(const double x, const double *y)? > > Are there other advantages/disadvantages? The main benefit is type safety, that is protection from accidental errors. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.freeurl.com * Alternative URL: http://run.to/noicys |
