> Having hardcoded types or mapping somewhere in the registry smells like > a bad solution. The importer should be able to figure out everything, > since in the end its a compiler, which knows the language better than > us. This also allows switching the target-arch for parsing (as Janosch > mentioned earlier) for example. It does NOT have to be hardcoded. The importer can produce the exact same behaviour than add_standard_cxx_types, that is making sure that it names all numeric types in the normalized way and creates the proper aliases. It was solution (1).
add_standard_cxx_types is *definitely* arch-specific, and works only for the local arch. You can see for yourself, it makes sure that char is properly defined as signed/unsigned depending on the local target. In any case, we do NOT have to use add_standard_cxx_types in the clang importer since it can deduce the same information itself. > Having this mapping from "char" to "(u)int8" hardcoded somewhere is > arch-specific. As soon as an ARM talks to an x86 both would use the same > hardcoded mapping for chars (ints). They could talk to each other with > messages containing chars (or ints) while typelib should prevent it in > the first place, because they are different on the two machines? It would generate an error, yes. Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
