[llvm-commits] [llvm] r77579 - in /llvm/trunk/lib: Target/ARM/AsmPrinter/ARMAsmPrinter.cpp Transforms/IPO/ArgumentPromotion.cpp Transforms/IPO/GlobalOpt.cpp Transforms/Scalar/ScalarReplAggregates.cpp Transforms/Utils/PromoteMemoryToRegister.cpp

[Daniel Dunbar]

Agreed, this is a bad idea, what was I thinking!? :)

Fixed to require explicit constructor call. Maybe Twine::utostr was
actually best, we don't use this many places and it makes it more
readable, even if it is a little longer.

 - Daniel

On Wed, Jul 29, 2009 at 11:07 PM, Jakob Stoklund Olesen<stoklund at 2pi.dk> wrote:
>
> On 30/07/2009, at 06.20, Daniel Dunbar wrote:
>> Switch obvious clients to Twine instead of utostr (when they were
>> already using
>> a Twine, e.g., for names).
>> - I am a little ambivalent about this; we don't want the string
>> conversion of
>>   utostr, but using overload '+' mixed with string and integer
>> arguments is
>>   sketchy. On the other hand, this particular usage is something of
>> an idiom.
>
> Me too.
>
>> -                                    TheAlloca->getName()
>> +"."+utostr(i),
>> +                                    TheAlloca->getName()+"."+i,
>
> The problem with this kind of expression is that you have to be a
> language lawyer to find out what it does. The meaning of "."+i changes
> completely because operator+ is left-associative. What is worse, the
> compiler would be happy either way.
>
> Would it be possible to use something a little less magic? Perhaps an
> explicit Twine constructor:
>
>     explicit Twine(const int64_t &Val)  ...
>
>    TheAlloca->getName()+"."+Twine(i)
>
> /jakob
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>