Big problem with templates

[jacobnavia]

I am trying to maintain a huge C++database application with templates
all around.

In 2010, tokens and identifiers were resolved at template expansion
time. Somehow this behaviour changed between 2010 and today and now I am
getting hundreds of undefined references in those templates.

How can I revert to the good old times?

The compiler that compiled this is gcc-4.4.3, and still does.

The new compiler however will not do that even if I specify -std=c++98

Thanks in advance.

jacob

[Paavo Helde]

jacobnavia <ja...@jacob.remcomp.fr> wrote in news:mrnvfg$b9g$2@dont-
email.me:

> I am trying to maintain a huge C++database application with templates
> all around.
>
> In 2010, tokens and identifiers were resolved at template expansion
> time. Somehow this behaviour changed between 2010 and today and now I am
> getting hundreds of undefined references in those templates.
>
> How can I revert to the good old times?
>
> The compiler that compiled this is gcc-4.4.3, and still does.

I suspect this was a defect in older versions of gcc. Fix your code to
conform to the standard. If your templates are never instantiated, you can
just delete them, for example.

Cheers
Paavo

[jacobnavia]

Le 27/08/2015 23:46, Paavo Helde a écrit :
> Fix your code to
> conform to the standard.

Of course!

How stupid from me. I just have to fix 344,356 lines of templated code...

Thanks anyway.

jacob

[Ian Collins]

jacobnavia wrote:
> Le 27/08/2015 23:46, Paavo Helde a écrit :
>> Fix your code to
>> conform to the standard.
>
> Of course!
>
> How stupid from me. I just have to fix 344,356 lines of templated code...

The answer was as generic as the question. If you want a better answer,
provide some examples.

--
Ian Collins

[Paavo Helde]

jacobnavia <ja...@jacob.remcomp.fr> wrote in news:mro1ei$khj$1@dont-
email.me:

> Le 27/08/2015 23:46, Paavo Helde a écrit :
>> Fix your code to
>> conform to the standard.
>
> Of course!
>
> How stupid from me. I just have to fix 344,356 lines of templated code...

I was going through the same process at some timepoint in our codebase.
This involved deleting some unused templates and adding forward
declarations for a bunch of functions. The trickier part was to inject
'typename' and 'template' in the correct places, IIRC. Anyway, this did not
take more than half of a day, no big deal.

YMMV, of course.

Cheers
Paavo

[Bo Persson]

No, because the standard hasn't changed the rules for name lookup in
templates. It was this way already in C++98.

What happens is that newer compilers have improved their standards
compliance. There are generally no switches for putting old bugs back
into the compiler.


Bo Persson

[Öö Tiib]

On Friday, 28 August 2015 01:04:56 UTC+3, jacobnavia wrote:
> Le 27/08/2015 23:46, Paavo Helde a écrit :
> > Fix your code to
> > conform to the standard.
>
> Of course!
>
> How stupid from me. I just have to fix 344,356 lines of templated code...

WTF has happened to engineers these days? Don't you feel you lose
face by starting to whine sarcastically in public forum that there
is two days worth of engineering work to do. After you have fixed
the 20-30 conformance issues then it will likely also run on that
old non-conforming compiler. If you lack skill then we can help
just post clear questions.

Total rewrite of that amount of code can take 1-3 years of team
of 5 good specialists so it is anyway out of question.

[jacobnavia]

Le 29/08/2015 15:32, Öö Tiib a écrit :
> Don't you feel you lose
> face by starting to whine sarcastically in public forum that there
> is two days worth of engineering work to do

No. I just do not feel thatI "lose face" by asking a question, and no,
it is not 2-3 days of work.

The problem was already clear in 2010, when I last looked at that code.

But it couldn't be done because it involved several MONTHS of work
because of the opaque structure of the include files and also because it
wasn't clear that somebody knew, from the countless variations of
"GetNewPage()" for instance, which one should be used in which
instantiation of the templates.

5 years later not a single person of the original team is there.

Of course this forum is useless for asking this types of questions. I
know now that better.

I should not ask questions here then.

Thank you anyway.

[Paavo Helde]

jacobnavia <ja...@jacob.remcomp.fr> wrote in news:mrsg8o$mrn$1@dont-
email.me:

> Le 29/08/2015 15:32, Öö Tiib a écrit :
>> Don't you feel you lose
>> face by starting to whine sarcastically in public forum that there
>> is two days worth of engineering work to do
>
> No. I just do not feel thatI "lose face" by asking a question, and no,
> it is not 2-3 days of work.
>
> The problem was already clear in 2010, when I last looked at that code.
>
> But it couldn't be done because it involved several MONTHS of work
> because of the opaque structure of the include files and also because
it
> wasn't clear that somebody knew, from the countless variations of
> "GetNewPage()" for instance, which one should be used in which
> instantiation of the templates.

So what? Forward-declare all the overloads.

Or do you mean that there are different definitions of GetNewPage() in
different files with the same signature, violating the ODR rule? In this
case it appears that your codebase has much more problems than just
compilation problems, and fixing these issues is a good chance to
actually make the codebase better.

BTW, a comprehensive unit test suite is invaluable in such refactorings,
if you don't have one then you should consider creating one before
refactoring.

>
> 5 years later not a single person of the original team is there.
>
> Of course this forum is useless for asking this types of questions. I
> know now that better.
>
> I should not ask questions here then.

The only question you asked was "How can I revert to the good old
times?", and the obvious answer to that is: "Invent a time machine, and
when there, try to ignore all the problems in the past which you had
already forgotten meanwhile."

Cheers
Paavo

[Öö Tiib]

On Saturday, 29 August 2015 17:42:20 UTC+3, jacobnavia wrote:
> Le 29/08/2015 15:32, Öö Tiib a écrit :
> > Don't you feel you lose
> > face by starting to whine sarcastically in public forum that there
> > is two days worth of engineering work to do
>
> No. I just do not feel thatI "lose face" by asking a question, and no,
> it is not 2-3 days of work.

You did not ask a question, you did complain that non-conforming to
C++98 code that happened to compile on non-conforming compiler does
not compile on conforming compiler and so you have to do engineering
work. Good for you so far, you have work to do! You told us *nothing*
else. We aren't magicians, we are mere mortals here and we don't know
what your issue with us or your code-base is.

> The problem was already clear in 2010, when I last looked at that code.
>
> But it couldn't be done because it involved several MONTHS of work
> because of the opaque structure of the include files and also because it
> wasn't clear that somebody knew, from the countless variations of
> "GetNewPage()" for instance, which one should be used in which
> instantiation of the templates.

Instrument each instantiation with trace that tells it, and process
the trace into csv file with a simple script. Then paste it to your
wiki table and *everybody* can see from your project wiki what
instantiation uses what 'GetNewPage'. Please estimate the effort
needed for described task to be done or list difficulties that make
it take more than 5 years.

>
> 5 years later not a single person of the original team is there.

No one's nerves can bear with such whiny panic for 5 years.

> Of course this forum is useless for asking this types of questions. I
> know now that better.

All forums are useless for that. Everywhere you will be said to
stop muttering and whining and ask advice like man.

[Ian Collins]

jacobnavia wrote:
>
> Of course this forum is useless for asking this types of questions. I
> know now that better.
>
> I should not ask questions here then.

The quality of the answers you receive is a reflection of the the
quality of the questions.

You have a couple of choices:

1) Stick with the old compiler. Sometimes the effort required to work
with new tools is too great.

2) Ask meaningful questions with code samples and error messages and you
will get meaningful answers.

--
Ian Collins

[Ed Anson]

On 8/29/15 4:18 PM, Ian Collins wrote:
> 1) Stick with the old compiler. Sometimes the effort required to work
> with new tools is too great.

I'll second that. I have been working with a legacy code base that was
developed around 2000. The compiler is similarly non-compliant. My
organization's solution was to VERY carefully preserve the compiler that
was originally used and to continue using it.

Although this approach has the down side of preventing use of modern
tools, it also prevents the massive expense of refactoring -- and
re-testing -- the entire code base. For a legacy product that is no
longer being developed (bug fixes only), that is the most practical
decision.

OTOH if the product is still being actively developed, that is another
matter entirely. In that case, it may be well worth the expense to adapt
the code to work with current tools. You might even be surprised at how
many latent bugs are exposed in the process. IME the best practice is to
incrementally refactor code every time it is changed. That helps keep
the code base in good shape.

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Of course this forum is useless for asking this types of questions. I
> know now that better.

You have to maintain incorrectly-made code that just happened to compile on a
non-standard compiler, then you ask here what to do with a very vague question
without actual concrete examples, and then you get all butthurt when you get
a generic answer, and get a temper tantrum worthy of a 5-year-old.

Yes, that's the correct way of getting answers and solving your problems.
Stomp the floor and whine until somebody does what you want.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Chris Vine]

On Mon, 31 Aug 2015 07:37:39 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
> jacobnavia <ja...@jacob.remcomp.fr> wrote:
> > Of course this forum is useless for asking this types of questions.
> > I know now that better.
>
> You have to maintain incorrectly-made code that just happened to
> compile on a non-standard compiler, then you ask here what to do with
> a very vague question without actual concrete examples, and then you
> get all butthurt when you get a generic answer, and get a temper
> tantrum worthy of a 5-year-old.
>
> Yes, that's the correct way of getting answers and solving your
> problems. Stomp the floor and whine until somebody does what you want.

Bearing in mind the fact that the original question was so general as to
be meaningless and unanswerable, and given the OP's past contributions
to this newsgroup, I think it improbable that he is "trying to maintain
a huge C++ database application with templates all around" as stated.
That task would surely be given to someone who is actually a C++
programmer of reasonable experience.

It seems much more probable that the OP is pursuing his ludicrous "C
macros are as good as or better than C++ templates" meme with a bit of
troll fodder.

Chris

[jacobnavia]

Le 31/08/2015 14:59, Chris Vine a écrit :
> It seems much more probable that the OP is pursuing his ludicrous "C
> macros are as good as or better than C++ templates" meme with a bit of
> troll fodder.

Yes, of course.

Look, as many others I am forced to work through this monster
applications where C++ heads leave for the maintenance team or somebody
else to clean up after them.

I am just trying to make it compile clean. I started to do what was
proposed here: to add in each file the declarations where needed.

But then, the next problem started:

friend declarations can't have default arguments. Decision of the C++
standards committee of 1999.

In 2010 that code still compiled OK.

IN 2015 it doesn't. That was fixed in gcc-something.

In principle the solution is simple: Eliminate the default arguments and
make the all explicit.

I am almost through that. Then I will go on with the next mess.

jacob

P.S. Yes, I do not like C++. For obvious reasons. That makes me a troll?

Should I abstain from asking questions here?

[Melzzzzz]

On Mon, 31 Aug 2015 17:34:43 +0200
jacobnavia <ja...@jacob.remcomp.fr> wrote:

> Le 31/08/2015 14:59, Chris Vine a écrit :
> > It seems much more probable that the OP is pursuing his ludicrous "C
> > macros are as good as or better than C++ templates" meme with a bit
> > of troll fodder.
>
> Yes, of course.
>
> Look, as many others I am forced to work through this monster
> applications where C++ heads leave for the maintenance team or
> somebody else to clean up after them.
>
> I am just trying to make it compile clean. I started to do what was
> proposed here: to add in each file the declarations where needed.
>
> But then, the next problem started:
>
> friend declarations can't have default arguments. Decision of the C++
> standards committee of 1999.
>


> In 2010 that code still compiled OK.
>
> IN 2015 it doesn't. That was fixed in gcc-something.
>
> In principle the solution is simple: Eliminate the default arguments
> and make the all explicit.
>

What's wrong with adding declaration?

#include <iostream>

void f(int = 6);
struct A{
friend void f(int);
};

int main()
{
f();
}

void f(int a)
{
std::cout<<a<<'\n';

}

> I am almost through that. Then I will go on with the next mess.

Heh.

>
> jacob
>
> P.S. Yes, I do not like C++. For obvious reasons. That makes me a
> troll?

You do not like C++ simply because you like C too much ;p

>
> Should I abstain from asking questions here?
>
>

No.

[Melzzzzz]

On Mon, 31 Aug 2015 18:14:35 +0200
Melzzzzz <m...@zzzzz.com> wrote:

> On Mon, 31 Aug 2015 17:34:43 +0200
> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>
> > Le 31/08/2015 14:59, Chris Vine a écrit :
> > > It seems much more probable that the OP is pursuing his ludicrous
> > > "C macros are as good as or better than C++ templates" meme with
> > > a bit of troll fodder.
> >
> > Yes, of course.
> >
> > Look, as many others I am forced to work through this monster
> > applications where C++ heads leave for the maintenance team or
> > somebody else to clean up after them.
> >
> > I am just trying to make it compile clean. I started to do what was
> > proposed here: to add in each file the declarations where needed.
> >
> > But then, the next problem started:
> >
> > friend declarations can't have default arguments. Decision of the
> > C++ standards committee of 1999.
> >
>
>
> > In 2010 that code still compiled OK.
> >
> > IN 2015 it doesn't. That was fixed in gcc-something.
> >
> > In principle the solution is simple: Eliminate the default arguments
> > and make the all explicit.
> >

Also have you tried -fpermissive?

[jacobnavia]

Le 31/08/2015 18:28, Melzzzzz a écrit :
> Also have you tried -fpermissive?
>

Yes, of course that works. But doing that kind of stuff exposes me to
the QA manager that surely will look at that with a bad eye

:-(

[bart...@gmail.com]

"Dear mr manager, we fucked up 5 years ago and wrote a code that is
incompatible with the standard, but it works on our compiler.
Now these saboteur from gnu fix... I mean change it and we either
spend two day by typing "typename" in our code or we can compile
it with -fpermissive. I want to emphasize that our code will
be not less standard compatible than for the last 5 years."

;-)

This is a businesses decision. Put some effort to clean it
or go around the problem.

bartekltg

[Chris Vine]

Your original complaint was about an issue with templates, not with
friend functions. If -fpermissive solves the template issue as well
then I would guess it was a simple dependent name look-up issue in a
base class method called from a derived class method. gcc got more
strict about that a few years ago when moving to support two phase
look-up in conformity with the standard, but retained the old behaviour
for defective code with the -fpermissive flag.

If you had originally posted a more informative post with some code and
sample error messages instead of complaining about "getting hundreds of
undefined references in those templates" with the question "How can I
revert to the good old times?", and it was a name look-up issue, people
would have been able to help you and you would have been told to use
the -fpermissive flag to revert to the good old times.

The fact that you knew about this all along ("of course that works")
seems to prove the point that in your original posting you were not
asking a genuine question but just having a good rant.

But if I am wrong about that and you still want an answer about your
template problems (and being told "how can I revert to the good old
times" is not after all enough), you can solve the issue
without -fpermissive by disambiguating the dependent name look-up,
either with a type qualifier - so if B is the template base class and
f() is the method name, by calling B::f() explicitly in your derived
class method - or by using the this keyword by calling this->f(). If
the problem is with type names not identifier names, you might need more
liberal use of the 'typename' keyword.

If that doesn't work, the template problems stem from something else and
you are seeking genuine help, post something more informative.

Chris

[jacobnavia]

Le 31/08/2015 20:32, Chris Vine a écrit :
> The fact that you knew about this all along ("of course that works")
> seems to prove the point that in your original posting you were not
> asking a genuine question but just having a good rant.

No!

It works for the friend declaration in a class issue.

It DOES NOT WORK for the templates issue!

Please do not try to paint me in that "troll" corner.

I just have to do this idiotic job and that is punishment enough!

Thanks

jacob

[Öö Tiib]

If that is true then you are behaving like that news anchor in
comedy that happened to wrong place, lost her car and cellphone
and everybody thought that she is prostitute. What she did wrong
was constantly telling that she is not prostitute, not doing
blowjobs for heroine etc. That she did instead of explaining who
she is and what problems she has and what happened to her and what
she actually wants from others. She sort of painted herself into
that prostitute corner by her own behavior.

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Should I abstain from asking questions here?

I think you should abstain from an attitude of the sort "I don't like this
language, therefore I'll make provocative passive-aggressive posts in the
newsgroup of that language, and get a hissy-fit when I get responded in
kind."

Do you at the very least agree that C is not a panacea, and that there
are tons and tons of C projects out there that are at least as much of
a mess as your C++ project?

Take any big open source C project out there, and there's at least 50%
chance that it will be absolutely horrible design-wise, will be horrendously
inefficient, will have at least one memory leak, and will most probably
not compile without warnings, or even errors.

[jacobnavia]

Le 01/09/2015 10:17, Juha Nieminen a écrit :
> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> Should I abstain from asking questions here?
>
> I think you should abstain from an attitude of the sort "I don't like this
> language, therefore I'll make provocative passive-aggressive posts in the
> newsgroup of that language, and get a hissy-fit when I get responded in
> kind."
>
> Do you at the very least agree that C is not a panacea, and that there
> are tons and tons of C projects out there that are at least as much of
> a mess as your C++ project?
>

Of course I agree SIR!

(Otherwise I would be excluded from this group, sigh:-)

> Take any big open source C project out there, and there's at least 50%
> chance that it will be absolutely horrible design-wise, will be horrendously
> inefficient, will have at least one memory leak, and will most probably
> not compile without warnings, or even errors.
>

YES SIR!

jacob :-)

P.S. You will agree however that debugging C code is orders of magnitude
easier than debugging templated C++ code... Well if you do not mind SIR!

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> Take any big open source C project out there, and there's at least 50%
>> chance that it will be absolutely horrible design-wise, will be horrendously
>> inefficient, will have at least one memory leak, and will most probably
>> not compile without warnings, or even errors.
>
> YES SIR!
>
> jacob :-)
>
> P.S. You will agree however that debugging C code is orders of magnitude
> easier than debugging templated C++ code... Well if you do not mind SIR!

Ok, you are now officially an asshole.

[jacobnavia]

Le 01/09/2015 13:18, Juha Nieminen a écrit :
> Ok, you are now officially an asshole.

This shows the education of Mr Nieminen and his attitude towards people
that do not have the same programming language tastes.

I do not call people names, Mr Nieminen, it is just bad taste.


jacob

[Gareth Owen]

Juha Nieminen <nos...@thanks.invalid> writes:

> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> Should I abstain from asking questions here?
>
> I think you should abstain from an attitude of the sort "I don't like this
> language, therefore I'll make provocative passive-aggressive posts in the
> newsgroup of that language, and get a hissy-fit when I get responded in
> kind."

Heh.

Good luck with that.

[Richard]

[Please do not mail me a copy of your followup]

ja...@jacob.remcomp.fr spake the secret code
<mrnvfg$b9g$2...@dont-email.me> thusly:

>In 2010, tokens and identifiers were resolved at template expansion
>time. Somehow this behaviour changed between 2010 and today and now I am

>getting hundreds of undefined references in those templates.

Please post one specific example of your problem. Change
identifiers/whatever if you feel you need to protect your source code.

Reproducing the problem in a small scope always helps me understand
the problem better. Sometimes, the problem isn't what I thought it
was at all.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Juha Nieminen]

No, you only make patronizing and provocative comments with a smug attitude.
Because that's so much more civilized.

[SG]

On Thursday, August 27, 2015 at 11:31:20 PM UTC+2, jacobnavia wrote:
> I am trying to maintain a huge C++database application with templates
> all around.
>

> In 2010, tokens and identifiers were resolved at template expansion
> time. Somehow this behaviour changed between 2010 and today and now I am
> getting hundreds of undefined references in those templates.
>

> How can I revert to the good old times?
>

> The compiler that compiled this is gcc-4.4.3, and still does.
>
> The new compiler however will not do that even if I specify -std=c++98

C++ compilers always have been required to do a proper "two phase
lookup" (at least since its ISO standardization). It just took a
while for C++ compilers to catch up. I'm not sure what the current
status with Microsoft's compiler is. It may still be "too lazy" to
do a two phase lookup and accept a lot of invalid C++ code.

If you're interested in turning your code into valid C++ so it will
be accepted by a conforming compiler, please look into how "two phase
lookup" works. You may have to use the keywords "typename" or
"template" or use an explicit "this->" prefix for member access here
and there.

Two phase lookup is not all bad. Its purpose is to catch some errors
early before templates are even instantiated. But to be honest, I
find it embarrassing that we have to use additional template and
typename keywords for disambiguation, for example.

If you're looking for a book suggestion: I found "C++ Templates: The
Complete Guide" very illuminating.

Cheers!
sg

[Mike Stump]

In article <ms20p3$gbh$1...@dont-email.me>,

That was invented for people just like you, for companies just like
your company, for situations, wait for it, just like this. [ blink ]

Use it, in 2 more decades, when your company goes away, or the product
is no longer shipped or maintained, the use of the flag goes away.

If you expect to last more than 2 decades, you can start staging in
fixes for the issues and in another 2 years when you get the last one
fixed, you can then remove the flag. Management should be able to
provide guidance if they plan for the company to be around, if the
software is to be around.

[jacobnavia]

Le 09/09/2015 18:32, Mike Stump a écrit :
> In article <ms20p3$gbh$1...@dont-email.me>,
> jacobnavia <ja...@jacob.remcomp.fr> wrote:

>> Le 31/08/2015 18:28, Melzzzzz a écrit :

>>> Also have you tried -fpermissive?
>>
>> Yes, of course that works. But doing that kind of stuff exposes me to
>> the QA manager that surely will look at that with a bad eye
>
> That was invented for people just like you, for companies just like
> your company, for situations, wait for it, just like this. [ blink ]
>
> Use it, in 2 more decades, when your company goes away, or the product
> is no longer shipped or maintained, the use of the flag goes away.
>
> If you expect to last more than 2 decades, you can start staging in
> fixes for the issues and in another 2 years when you get the last one
> fixed, you can then remove the flag. Management should be able to
> provide guidance if they plan for the company to be around, if the
> software is to be around.
>

Thanks for this help Mr Stump. The situation changed now. I have worked
intensively for 10 days and solved all problems... I can't even realize
that I am finished.

Basically it involved in all those problems to go to the definition of
the template where the templated method was defined and put the name of
the template.

./DiskIndex.h:4843:12: error: use of undeclared identifier
'FindParentBranchIndex'
int pbi = FindParentBranchIndex(parent_node, node);
^
this->
replaced with:
int pbi = DiskBasedTree<T>::FindParentBranchIndex(parent_node, node);

This "fixes" the problem.

[SG]

On Thursday, September 10, 2015 at 3:35:56 PM UTC+2, jacobnavia wrote:
> Le 09/09/2015 18:32, Mike Stump a écrit :

You have yet to provide a short but *complete* example of one of your
problem cases. I'm guessing the context of this code fragment involves
templates and inheritance. If FindParentBranchIndex is supposed to be
a member function of a dependent parent class, you don't need to fully
qualify it by its class. It just takes a "this->":

int pbi = this->FindParentBranchIndex(parent_node, node);

This will make the compiler delay the name lookup until the 2nd phase
(instantiation). The reason why it's not possible to check this during
the 1st phase is because of a possible template specialization. Some
specialization of your base class template might not even have such a
member function.

I'm still recommending the book "C++ Templates: The Complete Guide".

Cheers!
sg

[Anand Hariharan]

On Thursday, August 27, 2015 at 5:04:56 PM UTC-5, jacobnavia wrote:
> Le 27/08/2015 23:46, Paavo Helde a écrit :
> > Fix your code to
> > conform to the standard.
>
> Of course!
>
> How stupid from me. I just have to fix 344,356 lines of templated code...
>

Imagine a legacy C code base that was strewn with 'gets' and 'asctime'. Would you not give the same advice? (Agreed the effort required in your case would be significantly more.)

- Anand

[Richard]

[Please do not mail me a copy of your followup]

Anand Hariharan <mailto.anan...@gmail.com> spake the secret code
<4c6a4a25-a50f-42c7...@googlegroups.com> thusly:

For performing automated transformations on large code bases, I
recommend using the clang tooling infrastructure to create a custom
tool that performs the exact transformation you need.

"Large code base" in this instance means certainly more than a hundred
instances of the transformation to be applied. Depending on the
difficulty of the transformation (i.e. something where a simple
find/replace won't work), it can be worth making a custom tool for it.

If you wish to pursue this, look at my talk from C++ Now! 2014
"Create Your Own Refactoring Tool with Clang"
<https://github.com/boostcon/cppnow_presentations_2014>
<https://www.youtube.com/watch?v=8PndHo7jjHk>