- More about arabs.. - 1 Update
- g++-question - 14 Updates
| Juha Nieminen <nospam@thanks.invalid>: Jan 31 08:25PM >> Anyway, a smiley in such a message is extremely ambiguous. > Maybe for autists, but normal people recognize the meaning, > even more with an additional "hrhr". Why are you being such an asshole? For what purpose? |
| Sam <sam@email-scan.com>: Jan 31 07:06AM -0500 Bonita Montero writes: >> You probably can't. The value of std::type_info.name() is >> implementation defined. > I know, but probably there's a compiler-switch. No, there isn't. There is no valid reason to have such a compiler option in the first place. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 01:38PM +0100 >> I know, but probably there's a compiler-switch. > No, there isn't. There is no valid reason to have such a compiler option > in the first place. There is a reason: depending on the type of usage of typeid(x).name() you want to get the internal type-representation for efficient hand- ling or the readable representation for debugging-purposes. |
| David Brown <david.brown@hesbynett.no>: Jan 31 02:03PM +0100 On 31/01/2020 13:38, Bonita Montero wrote: > There is a reason: depending on the type of usage of typeid(x).name() > you want to get the internal type-representation for efficient hand- > ling or the readable representation for debugging-purposes. No, there is no reason to have such a switch - name() is not intended to give human-readable results, merely an identifier. So compilers handle it in different ways. Anyway, a few seconds googling gives this: <https://en.cppreference.com/w/cpp/types/type_info/name> <https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html> Hopefully that should give you what you need. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 02:15PM +0100 > No, there is no reason to have such a switch - name() is not intended to > give human-readable results, ... I told you the reason: it would be good for debugging-purposes. It may be not your taste how this might be implemented, but there are good reasons to make it the way I described. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 31 04:01PM +0200 On 31.01.2020 14:38, Bonita Montero wrote: > There is a reason: depending on the type of usage of typeid(x).name() > you want to get the internal type-representation for efficient hand- > ling or the readable representation for debugging-purposes. The typeid names are implementation specific anyway, so nothing has stopped gcc folks to generate more verbose names. The fact that they have not done so indicates that they have thought about it and selected the current solution as "the best". Why should they add another inconsistent behavior which would not be "the best"? And maybe you want to have both representations in a TU, a compiler switch would not help at all with this. Moreover, if there was such a compiler switch, it might cause glitches or inconsistent behavior when linking together libraries compiled with different options. Any potential benefit would not outweigh the loss of consistency, especially considering that it is trivial to add an abi::__cxa_demangle() call when needed. |
| Bart <bc@freeuk.com>: Jan 31 02:11PM On 31/01/2020 14:01, Paavo Helde wrote: > different options. Any potential benefit would not outweigh the loss of > consistency, especially considering that it is trivial to add an > abi::__cxa_demangle() call when needed. Not so trivial since none of the following seems to work, 'abi' being undefined in every case: #include <abi> #include <abi.h> abi::__cxa_demangle(typeid(x).name()) |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 03:15PM +0100 > The typeid names are implementation specific anyway, ... But they could be verbose for debugging-purposes. > have not done so indicates that they have thought about it and selected > the current solution as "the best". Why should they add another > inconsistent behavior which would not be "the best"? Getting the typename isn't good for nothing more than debugging -purposes. So there should be at least an option to have it verbose. You can completely disable typeinfo; I think the first reason for that is to make it harder to reverse-engineer code. If there's such an option there could be also the option I have in mind. > Moreover, if there was such a compiler switch, it might cause glitches > or inconsistent behavior when linking together libraries compiled with > different options. There are also "glitches" if you disable typeid by compilerswitch also; and no one cares for that. That's not a real issue. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 31 04:27PM +0200 On 31.01.2020 16:11, Bart wrote: > #include <abi> > #include <abi.h> > abi::__cxa_demangle(typeid(x).name()) Just include the correct header: #include <iostream> #include <cxxabi.h> int main() { int x = 42; int status; std::cout << abi::__cxa_demangle(typeid(x).name(), 0, 0, &status) << "\n"; } |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 31 09:30AM -0500 On 1/31/20 8:03 AM, David Brown wrote: > No, there is no reason to have such a switch - name() is not intended to > give human-readable results, merely an identifier. So compilers handle > it in different ways. I've reached the same conclusion, based upon precisely the opposite premises. There's nothing that can usefully be done with the string returned by name() EXCEPT print it out for humans to read. It's only purpose is to be human-readable. However, the issues of precisely what the string should say were sufficiently complicated that the committee elected to leave them for each implementation to decide. If an implementation doesn't produce results that are as easy to understand as you'd like, that's because the implementors decided that more useful results were not sufficiently valuable to justify the (considerable) difficulty of producing them. A compiler switch to enable more useful results therefore makes no sense. In order to support that switch, they'd need to put in that extra effort, which is what they were trying to avoid. If and when they do end up deciding to put in that effort, why provide an option which, if not selected, allows for the less useful results? |
| "Öö Tiib" <ootiib@hot.ee>: Jan 31 06:41AM -0800 On Friday, 31 January 2020 14:38:43 UTC+2, Bonita Montero wrote: > There is a reason: depending on the type of usage of typeid(x).name() > you want to get the internal type-representation for efficient hand- > ling or the readable representation for debugging-purposes. Most fruitful is to add text serialization support to data. Serialization can be useful for lot of other things than debugging. Work needed depends on serialization library used, on better cases it can be conditionally compiled out in release builds, and result will look something like: std::cout /* or my::logger */ << json::make_from(x) << '\n'; |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 04:09PM +0100 > std::cout << abi::__cxa_demangle(typeid(x).name(), 0, 0, &status) > << "\n"; > } That's rather a workaround for me. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 04:12PM +0100 > Most fruitful is to add text serialization support to data. That doesn't make sense since the extraced name from typeid(x).name() wouldn't help you when deserializing. Using type_index( typeid(x) ) to map through a hashtable to a deserialization-function would be a possible solution. |
| David Brown <david.brown@hesbynett.no>: Jan 31 04:31PM +0100 On 31/01/2020 15:30, James Kuyper wrote: > premises. There's nothing that can usefully be done with the string > returned by name() EXCEPT print it out for humans to read. It's only > purpose is to be human-readable. If I understand it correctly (from reading the links I posted), gcc and clang specifically choose to give the names using the mangling format specified by the Itanium C++ ABI. (Why the Itanium C++ ABI? I don't know, but I suppose its as good as any.) So they are giving a well-defined format that can be used by other software that follows the same standard. That includes the symbol names generated by the tools. Assuming I understand this all correctly, it means you can get the mangled symbol name for "foo(T)" by combing "foo" and "std::type_info.name(T)". This could have many more uses than just human-readable output. And you can get a more readable version from the abi::__cxa_demangle function. So gcc and clang gives a more useful and flexible solution here, though it requires a little more effort to use it in human debugging. > effort, which is what they were trying to avoid. If and when they do end > up deciding to put in that effort, why provide an option which, if not > selected, allows for the less useful results? I can't imagine it would have been terribly difficult for gcc to pass the type info strings through abi::__cxa-demangle to get a more human readable version of name(). The abi:: stuff will already be used in the compiler. But any switch here changing the output of name() would break other uses of it, and so be a terrible idea. |
| Manfred <noname@add.invalid>: Jan 31 05:15PM +0100 On 1/31/2020 4:31 PM, David Brown wrote: > know, but I suppose its as good as any.) So they are giving a > well-defined format that can be used by other software that follows the > same standard. I believe the keyword here is well-defined (possibly together with efficiency). Using the mangled name results in a 1:1 relationship between name() and the C++ type, whereas a human readable name would end up with things like "int unsigned" "unsigned int" and "unsigned" all denoting the same type. Assuming the priority is to provide a name somehow usable by the software, this kind of 1:1 equivalence is valuable. Moreover, some mangled names need to end up in the executable for dynamic linking anyway, so having name() return the same encoding can save some duplication. That includes the symbol names generated by the tools. > human-readable output. > And you can get a more readable version from the abi::__cxa_demangle > function. Which is perfectly suitable for debugging purposes. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment