On Sat, Jun 20, 2009 at 9:22 PM, Przemyslaw Czerpak <dru...@acn.waw.pl> wrote: > > On Sat, 20 Jun 2009, Szak�ts Viktor wrote: > > I wanted to suggest that, as current code makes LOTS OF > > otherwise valid code prone to such errors and unexpected > > behaviour. > > Please do. > > Fine, I'll commit it in a while.
Thank you. >> As a next step we will have to convert all our codebase to >> use the new APIs to avoid such problems. >> Because of this, probably some very simple sounding >> API names would be the best here, or, keeping current >> familiar names and solve compatibility from PP. I'd be >> very happy if it could be done that way, as I expect majority >> of current hb_par*() usages don't use the extra optional >> parameter. > > I suggest to remove support for variable number of parameters > from current hb_par*() and hb_stor*() functions and add new set > of functions hb_parv*() and hb_storv*() which will accepts variable > number of parameters. It should reduce number of modifications in > existing code (additional parameters are used rather seldom). > Unfortunately I do not know any way to use C PP to automatically > update existing code. AFAIK it's imposible to create such macro > even using C99 ... macro argument and __VA_ARGS__. > Maybe some C compilers have presporcessor with some local extensions > which can be used for it but it's not a choice for us. GNU extension > in GCC PP are IMHO not enough to implement it. I fully agree with your proposal. This will be the cleanest. In this case extend.api will need to be mapped to hb_parv*()/hb_storv*(). That's easy. And code will need to be changed where hb_par*()/hb_stor*() is used with extra array index parameter. Such usage is very rare. This will be easy as they will come up as compile time errors. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
