Home > Archive > VC Language > June 2005 > Constifier
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Modifies code files in a C++ project to make as many class member methods
'const' as possible. It parses the methods in all the files, tries making
them 'const', tests whether the build succeeds and if not reverts to the
previous state.
The more methods that are const, the faster the C++ program will run, as the
compiler can allocate special sections of read-only memory for things it
knows are going to be constant - this also leads to better security. The
effect is snowballing - the first pass of the program on a project may, say,
convert 5% of methods to const methods, but running a second pass may
convert some more - as methods that call the methods that have now been made
const (but came early on in the sort order) may now be able to be constified
because they are now calling const methods.
Leave the program running overnight on your project continuously in a loop,
and when you wake up in the morning, as many methods as possible will be
const!
http://www.planetsourcecode.com/vb/...=3644&lngWId=10
Comments?
| |
| Victor Bazarov 2005-05-29, 8:58 pm |
| Bonj wrote:
> Modifies code files in a C++ project to make as many class member
> methods 'const' as possible. [...]
That's nice. My problem with [somebody else's] const-challenged code
is usually different, though. Either some arguments are left non-const
(it's often 'char*' instead of 'char const*'), or members of classes
over which I have no control (from a 3rd-patry library) and changing
those in the headers makes no sense. Can that thing do anything about
those? It should be able to do the former, but of course not the latter.
V
| |
|
| First of all, let me say that it only changes member declarations in .h
files if it finds a corresponding implementation in a .cpp file in the same
directory (whereupon it changes that aswell to match) - so you should find
it doesn't touch declarations of things that are in a 3rd-party library.
I ran it on my project and out of 136 methods, it constified about 8.
The challenge facing it really now is that to increase this success rate, at
the end of the day is really going to be proportional to the amount of AI
one be bothered to add. For instance, certain methods when changed to const
would cause compilation to fail, but would succeed if certain parameters
were also changed to const at the same time - the algorithm would have to be
a lot more complex in order to marry these up in order to score a hit.
Perhaps a compromise approach would be to develop a new strain of the
program to constify parameters rather than methods, running the two
alternatively on a project could eventually force more and more things down
the road of const-ness?, sort of like zig-zagging up a mountain...
The program of course isn't particularly optimized in terms of how fast it
actually runs, obviously I'd prefer to put the effort into improving the
success rate.
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:%23c9vjsHZFHA.228@TK2MSFTNGP12.phx.gbl...
> Bonj wrote:
>
> That's nice. My problem with [somebody else's] const-challenged code
> is usually different, though. Either some arguments are left non-const
> (it's often 'char*' instead of 'char const*'), or members of classes
> over which I have no control (from a 3rd-patry library) and changing
> those in the headers makes no sense. Can that thing do anything about
> those? It should be able to do the former, but of course not the latter.
>
> V
>
| |
| Bob Powell [MVP] 2005-05-29, 8:58 pm |
| Does this have anything whatsoever to do with C#?
--
Bob Powell [MVP]
Visual C#, System.Drawing
Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
"Bonj" <a@b.com> wrote in message
news:%23juwzCHZFHA.3364@TK2MSFTNGP12.phx.gbl...
> Modifies code files in a C++ project to make as many class member methods
> 'const' as possible. It parses the methods in all the files, tries making
> them 'const', tests whether the build succeeds and if not reverts to the
> previous state.
> The more methods that are const, the faster the C++ program will run, as
> the compiler can allocate special sections of read-only memory for things
> it knows are going to be constant - this also leads to better security.
> The effect is snowballing - the first pass of the program on a project
> may, say, convert 5% of methods to const methods, but running a second
> pass may convert some more - as methods that call the methods that have
> now been made const (but came early on in the sort order) may now be able
> to be constified because they are now calling const methods.
> Leave the program running overnight on your project continuously in a
> loop, and when you wake up in the morning, as many methods as possible
> will be const!
>
> http://www.planetsourcecode.com/vb/...=3644&lngWId=10
> Comments?
>
| |
| andré m.a 2005-05-30, 3:59 am |
|
> Leave the program running overnight on your project continuously in a
> loop, and when you wake up in the morning, as many methods as possible
> will be const!
I think if you need to leave a program compile overnight,
you're either compiling Windows XP on a 286 or you're
doing something wrong =]
| |
| Carl Daniel [VC++ MVP] 2005-05-30, 3:59 am |
| Bonj wrote:
> Modifies code files in a C++ project to make as many class member
> methods 'const' as possible. It parses the methods in all the files,
> tries making them 'const', tests whether the build succeeds and if not
> reverts to
> the previous state.
> The more methods that are const, the faster the C++ program will run,
> as the compiler can allocate special sections of read-only memory for
> things it knows are going to be constant - this also leads to better
> security.
> The effect is snowballing - the first pass of the program on a project
> may, say, convert 5% of methods to const methods, but running a
> second pass may convert some more - as methods that call the methods that
> have now
> been made const (but came early on in the sort order) may now be able
> to be constified because they are now calling const methods.
> Leave the program running overnight on your project continuously in a
> loop, and when you wake up in the morning, as many methods as possible
> will
> be const!
>
> http://www.planetsourcecode.com/vb/...=3644&lngWId=10
> Comments?
In general,.solving this problem is as difficult as writing a fully
optimizing C++ compiler.
I've seen the arguments that making things const could lead to speed
improvements, but I've never seen any actual measurement to back up those
claims. Have you found any?
My guess would be that a compiler smart enough to use const hints to better
allocate memory is probably also smart enough to discover on its own those
members that make no mutating accesses to the object and perform those same
optimizations without the const hint.
The improvement in code robustness through studioius use of const is
indisputable though.
-cd
| |
|
| This program is written IN c#, FOR c++.
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:em7SnGKZFHA.3220@TK2MSFTNGP14.phx.gbl...
> Does this have anything whatsoever to do with C#?
>
> --
> Bob Powell [MVP]
> Visual C#, System.Drawing
>
> Find great Windows Forms articles in Windows Forms Tips and Tricks
> http://www.bobpowell.net/tipstricks.htm
>
> Answer those GDI+ questions with the GDI+ FAQ
> http://www.bobpowell.net/faqmain.htm
>
> All new articles provide code in C# and VB.NET.
> Subscribe to the RSS feeds provided and never miss a new article.
>
>
>
>
>
> "Bonj" <a@b.com> wrote in message
> news:%23juwzCHZFHA.3364@TK2MSFTNGP12.phx.gbl...
>
>
| |
|
| No, I didn't say leave it compiling overnight, I said leave it running
overnight!
It takes a long time to run because it does a build with each change to a
source file it makes to see if the compiler will allow the change.
I agree if I it took overnight to compile I would have a problem, especially
C#!
"andré m.a" <a.m.a@videotron.ca> wrote in message
news:S0xme.20285$aq2.693033@weber.videotron.net...
>
>
>
> I think if you need to leave a program compile overnight,
> you're either compiling Windows XP on a 286 or you're
> doing something wrong =]
>
>
>
| |
|
| >
> In general,.solving this problem is as difficult as writing a fully
> optimizing C++ compiler.
Yes, exactly. My interest in it stems from the challenge of finding
'cheats', like my example of running two different strains in alternation to
catch parameters and then methods that use them.
>
> I've seen the arguments that making things const could lead to speed
> improvements, but I've never seen any actual measurement to back up those
> claims. Have you found any?
Well, no - but just because I haven't made or found any *proof* that
constifying leads to speed improvement, that doesn't mean to say that it
doesn't. I think it's just assumed that "it might do a little bit in some
circumstances" and most people accept that without bothering with the need
for hard evidence.
>
> My guess would be that a compiler smart enough to use const hints to
> better allocate memory is probably also smart enough to discover on its
> own those members that make no mutating accesses to the object and perform
> those same optimizations without the const hint.
Yes, it could be, granted - but how many levels of indirection does it go
to? For instance, it could say "I can make method A const, but to do that I
also need to make parameter B const - so I'll do it". But what if it's like
"I can make method A const, but only if I can make parameter B const, and I
can only do that if I can make method C const, and I can only do that if I
can make member variable D const....which after all that I can do." but did
it look that far? Again, this harks back to the assertion of doing multiple
types of code feature in alternation....
| |
| Carl Daniel [VC++ MVP] 2005-05-30, 4:01 pm |
| Bonj wrote:
>
> Yes, exactly. My interest in it stems from the challenge of finding
> 'cheats', like my example of running two different strains in
> alternation to catch parameters and then methods that use them.
>
>
> Well, no - but just because I haven't made or found any *proof* that
> constifying leads to speed improvement, that doesn't mean to say that
> it doesn't. I think it's just assumed that "it might do a little bit
> in some circumstances" and most people accept that without bothering
> with the need for hard evidence.
Yep. The question was raised out of curiousity, not accusation.
>
> Yes, it could be, granted - but how many levels of indirection does
> it go to? For instance, it could say "I can make method A const, but
> to do that I also need to make parameter B const - so I'll do it".
> But what if it's like "I can make method A const, but only if I can
> make parameter B const, and I can only do that if I can make method C
> const, and I can only do that if I can make member variable D
> const....which after all that I can do." but did it look that far?
> Again, this harks back to the assertion of doing multiple types of
> code feature in alternation....
Well, compilers like VC7+ that can do whole-program optimization in theory
look all the way down a call chain and are able to do cross-module
optimization and inlining through very deep call chains. Optimizing
compilers also do extensive data flow analysis to discover which variables
are effectively const, since that's an important fact when it comes to
planning register usage and other optimizations. One optimization I've
never seen a compiler make is to determine which methods are effectively
static and suppress generation of a 'this' pointer for those methods. That
might be another interesting modification to try - and IMO much more likely
to yield real speed/size improvements than const correctness. It's also an
optimization that could only be done by a whole-program optimizer, since it
impacts the code generated at the call sites.
-cd
| |
|
| > Well, compilers like VC7+ that can do whole-program optimization in theory
> look all the way down a call chain and are able to do cross-module
> optimization and inlining through very deep call chains. Optimizing
> compilers also do extensive data flow analysis to discover which variables
> are effectively const, since that's an important fact when it comes to
> planning register usage and other optimizations. One optimization I've
> never seen a compiler make is to determine which methods are effectively
> static and suppress generation of a 'this' pointer for those methods.
> That might be another interesting modification to try - and IMO much more
> likely to yield real speed/size improvements than const correctness. It's
> also an optimization that could only be done by a whole-program optimizer,
> since it impacts the code generated at the call sites.
>
Interesting theory, but the reason I did not do this to start with is that
(certainly for my own projects) I'm more likely to know off the top of my
head whether a method is going to be able to be static or not, than I am to
know whether it is going to be const or not. IOW, if a method's 'staticable'
then I'll instantly know to code it as static in the first place, something
that's less likely to stick out if it's const. But i'll give it a go.
| |
| Jochen Kalmbach [MVP] 2005-05-30, 8:59 pm |
| Hi Bonj!
> Modifies code files in a C++ project to make as many class member methods
> 'const' as possible. It parses the methods in all the files, tries making
> them 'const', tests whether the build succeeds and if not reverts to the
> previous state.
> The more methods that are const, the faster the C++ program will run, as the
> compiler can allocate special sections of read-only memory for things it
> knows are going to be constant - this also leads to better security. The
> effect is snowballing - the first pass of the program on a project may, say,
> convert 5% of methods to const methods, but running a second pass may
> convert some more - as methods that call the methods that have now been made
> const (but came early on in the sort order) may now be able to be constified
> because they are now calling const methods.
> Leave the program running overnight on your project continuously in a loop,
> and when you wake up in the morning, as many methods as possible will be
> const!
Nice project...
Just as a challange:
It would be nice if your project could also emit the new SAL annotations!
See: Header Annotations
http://msdn.microsoft.com/library/d...annotations.asp
Some annotations like "__in", "__in_opt", "__out", "__out_opt" could be
"easily" figured out only by looking into the source of the function...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
| |
|
| Looks a good syntax , clearly the 'way of the future', I might have a go at
incorporating it....
Seemingly a parameter would be __out if it can't be const, and a parameter
*should* be const if it is declared __in?
Also interested to know what effect __opt has at compile time compared to
run time, since whether a 'NULL' parameter is going to be passed surely
can't always be detected at compile time?
"Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
news:eAocQgUZFHA.2756@tk2msftngp13.phx.gbl...
> Hi Bonj!
>
> Nice project...
> Just as a challange:
> It would be nice if your project could also emit the new SAL annotations!
>
> See: Header Annotations
> http://msdn.microsoft.com/library/d...annotations.asp
>
> Some annotations like "__in", "__in_opt", "__out", "__out_opt" could be
> "easily" figured out only by looking into the source of the function...
>
> --
> Greetings
> Jochen
>
> My blog about Win32 and .NET
> http://blog.kalmbachnet.de/
| |
| Jochen Kalmbach [MVP] 2005-05-31, 9:14 am |
| Hi Bonj wrote:
> Also interested to know what effect __opt has at compile time compared to
> run time, since whether a 'NULL' parameter is going to be passed surely
> can't always be detected at compile time?
This is a great new feature! It can be *always" detected at compile
time! The new VS2005 has a static code-analysis-tool, which can find out
all possible code-paths...
If the calling function passes a parameter which was declared as __in
(without __opt), then it checks if this parameter might become NULL (for
example if this is a passed-in parameter, then this parameter must also
be declared as _not_ __opt).
From my point, it is a great feature!
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
| |
| Simon Trew 2005-05-31, 9:00 pm |
| "Bonj" <a@b.com> wrote in message
news:eN7%23KGIZFHA.3648@TK2MSFTNGP14.phx.gbl...
> the algorithm would have to be a lot more complex in order to marry these
> up in order to score a hit.
> Perhaps a compromise approach would be to develop a new strain of the
> program to constify parameters rather than methods, running the two
> alternatively on a project could eventually force more and more things
> down the road of const-ness?, sort of like zig-zagging up a mountain...
On the right lines I think (I haven't looked at your program yet and am just
working off the description you gave). I think Bayesian probability/dynamic
programming could help you here-- it helps reduce the number of permutations
drastically.
| |
| Vladimir Nesterovsky 2005-06-02, 9:06 am |
| > I've seen the arguments that making things const could lead to speed
> improvements, but I've never seen any actual measurement to back up those
> claims. Have you found any?
To prove that using of const can lead to a speed improvements, consider
passing const reference of an object instead of a copy of the object to a
function.
void func(C c);
void func(const C &c);
If size of object C is considerable, I believe a measurement will show speed
improvement.
I believe const helps to a developer to avoid unnecessary objects copying.
--
Vladimir Nesterovsky
e-mail: vladimir@nesterovsky-bros.com
home: www.nesterovsky-bros.com
| |
|
|
> This is a great new feature! It can be *always" detected at compile
> time
How? What if I pass a user-entered value in such a parameter, e.g. say from
a text-box? Would it regard that as unable to ever be NULL?
| |
|
| explain more... what's Bayesian?
"Simon Trew" <ten.enagro@werts> wrote in message
news:ulmovNjZFHA.2128@TK2MSFTNGP14.phx.gbl...
> "Bonj" <a@b.com> wrote in message
> news:eN7%23KGIZFHA.3648@TK2MSFTNGP14.phx.gbl...
>
> On the right lines I think (I haven't looked at your program yet and am
> just working off the description you gave). I think Bayesian
> probability/dynamic programming could help you here-- it helps reduce the
> number of permutations drastically.
>
| |
| Jochen Kalmbach [MVP] 2005-06-02, 4:01 pm |
| Hi Bonj wrote:
>
> How? What if I pass a user-entered value in such a parameter, e.g. say from
> a text-box? Would it regard that as unable to ever be NULL?
??? The user cannot pass something into the source-code... the
source-code is static.
But nevertheless, here is a small example:
void FuncDeep(__in int *somePointer)
{
// I do *not* need to check here if the pointer is "NULL",
// because "__opt" is _not_specified.
*somePointer = 12;
}
void FuncAbove(__in __opt int *someOtherPointer)
{
FuncDeep(someOtherPointer);
// => This will generate an compile-time error,
// because it is not allowed to pass an
// possible NULL-pointer to "FuncDeep"
}
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
| |
| Carl Daniel [VC++ MVP] 2005-06-02, 4:01 pm |
| Vladimir Nesterovsky wrote:
>
> To prove that using of const can lead to a speed improvements,
> consider passing const reference of an object instead of a copy of
> the object to a function.
>
> void func(C c);
> void func(const C &c);
>
> If size of object C is considerable, I believe a measurement will
> show speed improvement.
>
> I believe const helps to a developer to avoid unnecessary objects
> copying. --
But poassing a non-const reference would have the same speed/size benefits,
as would passing a plain pointer (granted, those aren't "drop-in"
replacements since they might affect the call site).
const is getting good press here but isn't really helping with speed (note
that I have nothing against const ref parameters).
-cd
| |
|
| It's not made clear if this is only for pointers, or any type of parameter.
But what if I, say, pass the value in a textbox to a function with
parameters that aren't declared __opt?
Also, what syntactically is there to distinguish between "not using __opt"
and "not using this feature at all" - is there a compiler switch?
"Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
news:eJ6MS$2ZFHA.2076@TK2MSFTNGP15.phx.gbl...
> Hi Bonj wrote:
>
> ??? The user cannot pass something into the source-code... the source-code
> is static.
>
> But nevertheless, here is a small example:
>
>
> void FuncDeep(__in int *somePointer)
> {
> // I do *not* need to check here if the pointer is "NULL",
> // because "__opt" is _not_specified.
> *somePointer = 12;
> }
>
> void FuncAbove(__in __opt int *someOtherPointer)
> {
> FuncDeep(someOtherPointer);
> // => This will generate an compile-time error,
> // because it is not allowed to pass an
> // possible NULL-pointer to "FuncDeep"
> }
>
> --
> Greetings
> Jochen
>
> My blog about Win32 and .NET
> http://blog.kalmbachnet.de/
| |
|
|
|
| I've discovered another problem with using this, which is such a ballache
you probably wouldn't want to do it unless you got round this problem.
Namely, that it may make a method in a base class const, but not a method
that's overriden in a derived class. Hence, on an instance of a derived
class calling the function through pointer to base will call the base
class's function, giving a run-time bug.
"Bonj" <a@b.com> wrote in message
news:%23juwzCHZFHA.3364@TK2MSFTNGP12.phx.gbl...
> Modifies code files in a C++ project to make as many class member methods
> 'const' as possible. It parses the methods in all the files, tries making
> them 'const', tests whether the build succeeds and if not reverts to the
> previous state.
> The more methods that are const, the faster the C++ program will run, as
> the compiler can allocate special sections of read-only memory for things
> it knows are going to be constant - this also leads to better security.
> The effect is snowballing - the first pass of the program on a project
> may, say, convert 5% of methods to const methods, but running a second
> pass may convert some more - as methods that call the methods that have
> now been made const (but came early on in the sort order) may now be able
> to be constified because they are now calling const methods.
> Leave the program running overnight on your project continuously in a
> loop, and when you wake up in the morning, as many methods as possible
> will be const!
>
> http://www.planetsourcecode.com/vb/...=3644&lngWId=10
> Comments?
>
|
|
|
|
|