Constifier

  • Thread starter Thread starter Bonj
  • Start date Start date
B

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!

http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=3644&lngWId=10
Comments?
 
Bonj said:
Modifies code files in a C++ project to make as many class member
methods 'const' as possible. [...]
Click to expand...

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 said:
Bonj said:
Modifies code files in a C++ project to make as many class member
methods 'const' as possible. [...]
Click to expand...

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
Click to expand...
 
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!
Click to expand...

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 =]
 
Bonj said:
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/scripts/ShowCode.asp?txtCodeId=3644&lngWId=10
Comments?
Click to expand...

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 said:
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.
Click to expand...
 
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 said:
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!
Click to expand...

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 =]
Click to expand...
 
In general,.solving this problem is as difficult as writing a fully
optimizing C++ compiler.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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....
 
Bonj said:
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.
Click to expand...

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....
Click to expand...

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.
Click to expand...


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.
 
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!
Click to expand...

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.../en-us/winprog/winprog/header_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?
 
Hi said:
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?
Click to expand...

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/
 
Bonj said:
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...
Click to expand...

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.
 
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?
Click to expand...

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.
 
This is a great new feature! It can be *always" detected at compile
time
Click to expand...


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 said:
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.
Click to expand...
 
Hi said:
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?
Click to expand...

??? 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/
 
Vladimir said:
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. --
Click to expand...

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
 
Back
Top