Re: [pygccxml-development] FT - name uniqueness
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-10-11 16:43:30
|
Roman Yakovenko wrote: >> >> > Hi. I would like to propose solution for function name uniqueness >> >> problems. >> >> > >> >> > Problem description: >> >> > >> >> > void do_smth( int& ); >> >> > void do_smth( int&, int& ); >> >> > >> >> > If user will specify output_t transformer for both functions the >> >> > generate code will >> >> > not compile, because Py++ will generate 2 functions with the same >> >> signature. >> >> > >> >> > In order to solve this problem, we have to mangle into function name >> >> next data: >> >> > 1. full name ( namespaces, class names ) >> >> > 2. return type information >> >> > 3. arguments type information >> >> > 4. template arguments type information >> >> >> >> Assuming that the name has been mangled, how do you invoke those two >> >> functions from Python? >> > >> > I don't change the "alias" of the function, only its wrapper name. >> > Python will see the original function name. >> >> Which of the above functions will be called when I do the following in >> Python: >> >> result = do_smth() >> >> And how can I invoke the other function? > > User will provide an aliase for the functions. Right. And as long as the alias is used for the wrapper names (which is currently the case) the above problem doesn't exist. The question may then rather be: who should report the error, Py++ or the compiler? I think it's desirable that Py++ notices this situation and can issue an error, but I don't think it's a good idea to mangle the name so that the code compiles but produces functions that could not be called because they are shadowed by other functions. In my opinion the current behavior that I will get a compile error is not that bad because it guarantees that such situations won't pass unnoticed. A mere Py++ warning would do nothing for me as I still get hundreds of warnings that I just can't go through right now, so I won't notice this warning. - Matthias - |