<div dir="ltr">Wasn't aware of those limitations with itanium mangled.  I think you could come up with a useful set of common functionality though, especially if you just look at how we're currently inspecting mangled names and build the interface around the operations we're already doing.<br><br>As for increasing the size by 1 pointer, I think it would actually reduce the size by 1 pointer.  As discussed earlier, there's no advantage to storing both the mangled and demangled name in Mangled, because ConstString already has this.  So you could just store m_mangled directly in the Symbol.   Calculate the language from the string, create the appropriate mangler, then call Demangle on it and use it (without storing it the result).<div><br></div><div>Can you answer the question "is this name mangled" just by inspecting the string?  If the answer is yes, we don't even need the is_mangled flag and that solves that problem too.</div></div><br><div class="gmail_quote">On Fri Jan 30 2015 at 4:32:20 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am all for a powerful class that can pull apart mangled names and tell you about them. The power in the mangled names vary quite a bit so you can't rely on this. For example, in itanium mangling you detangle to "foo::bar::baz(int, float)", you have no idea if this is "namespace foo" or "class foo" or "struct foo", same goes for "bar" and you don't know if "baz" is a function or a method or a static class method. So Itanium mangling isn't great. There are languages that do mangle things very well and there is a wealth of knowledge to be extracted from it, so I agree we need a class to do it. If you want to go virtual, you will need to come up with another class other than Mangled because making it virtual increases the instance size by 1 pointer.<br>
<br>
Greg<br>
<br>
> On Jan 30, 2015, at 4:26 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri Jan 30 2015 at 4:03:59 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>> wrote:<br>
><br>
> > On Jan 30, 2015, at 3:50 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > I agree that if memory is important then we should use the opportunity to reduce memory usage rather than keeping it the same by changing stuff.  But the reason I asked leads into my next question.<br>
> ><br>
> > I've been thinking about mangling and demangling for a while and how it relates to Windows.  I see a lot of code all over the place that manually inspects mangled names, and usually the code is all custom and handrolled.  (If you're interested I can point you to a bunch of examples).  I don't like this way of doing things and I think it's generally fragile.  There should be one place that's responsible for anything to do with mangling.  All these places that are inspecting strings for _Z or ? should just be calling some class to ask it about the properties of this string.<br>
><br>
> Exactly, why can't we just look at the mangled name and look for the prefix and return the language we calculate?<br>
><br>
> > The most sensible place to do that, to me, seems like the ABI.  So I'm imagining that there's a Mangler base class, and then from that there is an ItaniumCppMangler, a MsCppMangler, and let's say perhaps a JavaMangler for the purposes of this CL.  Maybe they share some code, but that's not the important part.<br>
><br>
> Doesn't windows actually have 2 forms of mangling? Itanium + the $ mangling?<br>
> Yes but the mangling scheme is still tied to the ABI.  When Itanium mangling is used, it's because you compiled with GCC or some other non Microsoft compiler.  When MS ABI is used, it's because you compiled with cl.exe or clang-cl.  So with the difference in mangling, you also get all the other differences that come with an ABI change.<br>
><br>
><br>
> ><br>
> > ABI provides a method called getMangler().  It returns a singleton instance (which for Windows would be an MsCppMangler, and for everyone else would be an ItaiumCppMangler).<br>
><br>
> Again, why do we need to get so fancy. I would prefer to avoid this if we can just try demangling if it starts with one of the mangling prefixes.<br>
> Well, if you start with the notion that a Mangling abstraction for different ABIs and languages is useful, then this really isn't that much additional complicatation.  Say someone wanted to add support for debugging Java, or Haskell, or whatever language.  In order to fully integrate, they would need to fixup every location in the code that deals with mangled names.  The expression evaluator is a good example.  If you could just create a mangler instance with the appropriate properties, then everything just works.<br>
><br>
> I'm actually not totally against your idea of calculating the language from the mangled string.  Maybe it will have limitations in the future, but it's probably fine now.  What I think is a useful is, after you know the language and ABI, being able to have a single interface which you can ask questions to.  IsVariable(), IsFunction(), IsGuardVariable(), Demangle(), that kind of thing.  And there's enough useful functionality here that I think it's best exposed through a virtual interface with concrete implementations for each scheme.<br>
><br>
> For C++, this could be tied to the ABI class.  Some other way might be useful too, the ABI just seems logical to me.  Just some way to go from triple -> mangler though.  For other languages I can think of, the language itself defines the ABI, so you wouldn't need this separation.  There could just a single JavaMangler, for example.<br>
><br>
> You could still have a single function that analyzes a mangled string to calculate a language and return an appropriate Mangler instance though, I agree that seems like a fine approach.<br>
<br>
</blockquote></div>