Constifier

[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?

[Victor Bazarov]

Re: Constifier

Bonj wrote:[color=blue]
> Modifies code files in a C++ project to make as many class member
> methods 'const' as possible. [...][/color]

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

[Bonj]

Re: Constifier

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@com Acast.net> wrote in message
news:%23c9vjsHZ FHA.228@TK2MSFT NGP12.phx.gbl.. .[color=blue]
> Bonj wrote:[color=green]
>> Modifies code files in a C++ project to make as many class member
>> methods 'const' as possible. [...][/color]
>
> 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
>[/color]

[Bob Powell [MVP]]

Re: Constifier

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:%23juwzCHZ FHA.3364@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> 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/s...3644&lngWId=10
> Comments?
>[/color]

[andré m.a]

Re: Constifier


[color=blue]
> 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![/color]

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]

Re: Constifier

This program is written IN c#, FOR c++.

"Bob Powell [MVP]" <bob@_spamkille r_bobpowell.net > wrote in message
news:em7SnGKZFH A.3220@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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:%23juwzCHZ FHA.3364@TK2MSF TNGP12.phx.gbl. ..[color=green]
>> 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/s...3644&lngWId=10
>> Comments?
>>[/color]
>
>[/color]

[Bonj]

Re: Constifier

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@videotro n.ca> wrote in message
news:S0xme.2028 5$aq2.693033@we ber.videotron.n et...[color=blue]
>
>[color=green]
>> 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![/color]
>
> 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 =]
>
>
>[/color]

[Jochen Kalmbach [MVP]]

Re: Constifier

Hi Bonj![color=blue]
> 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![/color]

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/default.asp?url=/library/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/

[Bonj]

Re: Constifier

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:eAocQgUZFH A.2756@tk2msftn gp13.phx.gbl...[color=blue]
> Hi Bonj![color=green]
>> 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![/color]
>
> 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/de...nnotations.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/[/color]

[Jochen Kalmbach [MVP]]

Re: Constifier

Hi Bonj wrote:
[color=blue]
> 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?[/color]

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]

Re: Constifier

"Bonj" <a@b.com> wrote in message
news:eN7%23KGIZ FHA.3648@TK2MSF TNGP14.phx.gbl. ..[color=blue]
> 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...[/color]

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.

[Bonj]

Re: Constifier

explain more... what's Bayesian?


"Simon Trew" <ten.enagro@wer ts> wrote in message
news:ulmovNjZFH A.2128@TK2MSFTN GP14.phx.gbl...[color=blue]
> "Bonj" <a@b.com> wrote in message
> news:eN7%23KGIZ FHA.3648@TK2MSF TNGP14.phx.gbl. ..[color=green]
>> 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...[/color]
>
> 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.
>[/color]

[Bonj]

Re: Constifier

[color=blue]
> This is a great new feature! It can be *always" detected at compile
> time[/color]


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?

[Jochen Kalmbach [MVP]]

Re: Constifier

Hi Bonj wrote:[color=blue][color=green]
>>This is a great new feature! It can be *always" detected at compile
>>time[/color]
>
> 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?[/color]

??? 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 *someOtherPoint er)
{
FuncDeep(someOt herPointer);
// => 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/

[Bonj]

Re: Constifier

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$2ZFH A.2076@TK2MSFTN GP15.phx.gbl...[color=blue]
> Hi Bonj wrote:[color=green][color=darkred]
>>>This is a great new feature! It can be *always" detected at compile
>>>time[/color]
>>
>> 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?[/color]
>
> ??? 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 *someOtherPoint er)
> {
> FuncDeep(someOt herPointer);
> // => 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/[/color]