> > And string does not answer localization issue, however for numbers at least > there is one precedent to follow.
And strings have precedent for localization also, just look into how GCC's error messages are done. Or even any of the Mac OS X programs which does all localization based on strings. I don't see this as a problem. > > The other issue that numbers come with is are the corresponding messages > > sharable between compilers and compiler versions? > > > > Again it is a not a unsolvable issue. > > Plus strings do not play nice with command messages. What do you mean by play nice. variable names play nice so it has to play nice already > > > Like say, call location was not inlined because number of times this > > function > > can be inlined was hit. Shouldn't we provide this information to the user > > instead > > of saying it was not inlined (with no reason). Yes this is extension range > > but > > what happens when two compilers says the same thing but a third cannot say > > that but > > instead says "because 10 inlines is too much for the function". > > > > So ? What are you trying to say here ? That we cannot make a set of numbers that match up every single possibility that could exist even currently. > > > > Or with the vectorizer in mind, we have to version this loop for alignment > > because > > we can only prove the alignment is 4 bytes. Isn't that better than just > > saying the > > loop was version because alignment cannot be proved to be 16bytes? > > > > So, what are you trying to say here ? Likewise, I was trying to give an example of why numbers just fail. -- Pinski
