- g++-question - 8 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 11:18AM +0100 > What are you talking about? You made a thread that the typeid(x).name() > does not work. Yes it does not work. Therefore you have to stringize > type name with macro, ... I've shown how to do that without macros much cleaner. Macros are mostly bad code in C++. > I just suggest to use serialization / deserialization tools and > libraries that already inevitably contain those macros. ... No, they generate datatype-specific code. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 02 04:55AM -0800 On Sunday, 2 February 2020 12:18:51 UTC+2, Bonita Montero wrote: > > does not work. Yes it does not work. Therefore you have to stringize > > type name with macro, ... > I've shown how to do that without macros much cleaner. You mean what? To write it out manually for all types used in project: typeMappings[std::type_index(typeid(typing::Festival))] = "typing::Festival"; typeMappings[std::type_index(typeid(typing::Festival*))] = "typing::Festival*"; typeMappings[std::type_index(typeid(typing::Festival const*))] = "typing::Festival const*"; typeMappings[std::type_index(typeid(std::unique_ptr<typing::Festival>))] = "std::unique_ptr<typing::Festival>"; typeMappings[std::type_index(typeid(std::vector<typing::Festival>))] = "std::vector<typing::Festival>)"; // etc. No thanks. It will be tedious maintenance nightmare in any project worth writing. > Macros are mostly bad code in C++. Yes. Unless where other options are worse. Macros can be used to indicate source code file, function name and line #, avoid copy-paste typos and can be compiled to generate no code in release builds, so are quite unavoidable in user-defined debugging facilities of C++. > > I just suggest to use serialization / deserialization tools and > > libraries that already inevitably contain those macros. ... > No, they generate datatype-specific code. That you suggest to write manually. |
| Sam <sam@email-scan.com>: Feb 02 08:24AM -0500 Bonita Montero writes: > 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. dynamic_cast<> uses the typeinfo data. Not the entire metadata gets exposed by typeinfo, in typical implementations, but the underlying data must include the object's type that's encoded in some fashion. Otherwise there's no dynamic_cast<>. So, you cannot "completely disable" typeinfo. The end result will not be C++. It looks to me like gcc/clang chose their compact typename encoding to serve a double-duty: to make dynamic_cast<> find what it's looking for, and for name(). It would be somewhat inefficient for dynamic_cast<> to use verbose human-readable typenames, so implementations that return them must be duplicating a little bit of data and storing both an compact typename encoding and a human readable string in the underlying typeid (even if not exposed via a public API); or construct the name() from scratch, and since the string returned by name() does not have a specified lifetime, it must be allocated in dynamic scope, for the remaining lifetime of the program. Having name() return an encoded type string solves that problem. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 02:46PM +0100 > // etc. > No thanks. It will be tedious maintenance nightmare in any project worth > writing. Something like this might be generated by a persistence-generator like protocol buffers - without the necessity of macros. > That you suggest to write manually. No, not at the point where you told about serialization-libs. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 02 06:03AM -0800 On Sunday, 2 February 2020 15:46:31 UTC+2, Bonita Montero wrote: > > writing. > Something like this might be generated by a persistence-generator > like protocol buffers - without the necessity of macros. So code generation tools of serialization libs that I suggested. > > That you suggest to write manually. > No, not at the point where you told about serialization-libs. Why you lie like always, liar? I each time diligently mentioned code generation tools as alternative to macros. You had your "without macros much cleaner" nonsense. Now you argue against my own suggestion with my own suggestion. |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 02 08:05AM -0600 >the string returned by name() does not have a specified lifetime, it must be >allocated in dynamic scope, for the remaining lifetime of the program. >Having name() return an encoded type string solves that problem. While storing the mangled type name makes sense (although an even more compact representation might be even better), there's no reason name() couldn't demangle it before returning. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 02 04:29PM +0100 > code generation tools as alternative to macros. You had your > "without macros much cleaner" nonsense. Now you argue against my > own suggestion with my own suggestion. No, you told that these code-generation-tools might use macros also. I said that this is unclean code and not necessary. |
| Ian Collins <ian-news@hotmail.com>: Feb 03 07:26AM +1300 On 03/02/2020 03:03, Öö Tiib wrote: > Why you lie like always, liar? You've been trolled. -- Ian. |
| 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