By this new method, if we have __UnnamedStruct111 and file #1 this is the 11th unnamed struct, but file #11 has unnamed struct 1. Are they merged? Should we instead use unnamedTmp.Printf(_T("%s%s%lu_%lu"), ...) so we have __UnnamedStruct1_11 and __UnnamedStruct11_1 ?
I think we must find a way to remove these __UnnamedStruct entries at all...
Quote from: Alpha on November 08, 2013, 02:49:14 PM
By this new method, if we have __UnnamedStruct111 and file #1 this is the 11th unnamed struct, but file #11 has unnamed struct 1. Are they merged? Should we instead use unnamedTmp.Printf(_T("%s%s%lu_%lu"), ...) so we have __UnnamedStruct1_11 and __UnnamedStruct11_1 ?
Alpha, may I ask where did you find this? I'm interested in such peculiar things and I would like to take a look at it.
Relevant changes are:
http://cb.biplab.in/websvn/comp.php?repname=codeblocks&compare[]=/@9437&compare[]=/@9438
(Found when reading through the log messages (http://cb.biplab.in/websvn/log.php?repname=codeblocks&path=%2F&isdir=1&).)
Quote from: Alpha on November 08, 2013, 02:49:14 PM
By this new method, if we have __UnnamedStruct111 and file #1 this is the 11th unnamed struct, but file #11 has unnamed struct 1. Are they merged? Should we instead use unnamedTmp.Printf(_T("%s%s%lu_%lu"), ...) so we have __UnnamedStruct1_11 and __UnnamedStruct11_1 ?
Hi, Alpha, thanks for the review, indeed this is a bug. I fix this bug in rev 9443 by adding an underscore between file index and token index.