On 12/18/14 16:28, Adriano dos Santos Fernandes wrote: > On 18/12/2014 11:16, Alex Peshkoff wrote: >> On 11/18/14 14:40, Adriano dos Santos Fernandes wrote: >> >> ..... >> >>> As an API writer of a project that doesn't follow standards (talking >>> specially about std exceptions), you need to create an API which is >>> usable by different ways, that can be mixed (each project uses in its >>> way). Current code mix the idea of customizable design with >>> non-customizable implementation. >> Adriano, hi! >> >> I've almost fixed issues mentioned by you, but I can't avoid one bad >> problem - declaration of fb_get_master_interface(). >> When we use API with app-defined policy we need to declare it returning >> appropriate value. >> What do you think - can we find a better way than macro >> >> #define DECLARE_GET_MASTER(P) extern "C" >> Firebird::FirebirdApi<P>::Master* ISC_EXPORT fb_get_master_interface(); >> >> with usage like: >> >> DECLARE_GET_MASTER(FirebirdPolicy) >> static IMaster* master = fb_get_master_interface(); >> >> (that works but IMHO itself does not look beautiful) >> >> > I was working on it since then, as I said, looking on a good way to > transform the templated classes into a namespace, so looks like we're > doing conflict works.
Sooner of all not. Main change from me now is avoiding conflicts when ISomething is used in struct in main API header. I.e. I've changed struct DtcStart to be an interface. > My work is in no way near something usable, so if you improve things, > feel free... I just need to know if you're going to commit soon, cause > my changes should be bigger and involve more areas (UDR, for example). In UDR I've placed wrong and dirty hack just to be able to compile fbstuff's fbtest - the only known to me test of Dtc. I'm sure it will be trivial to remove it when you are ready with full solution for UDR and Message. > I also started planing on a different way to customize the classes, with > inheritance instead of policy class. Well, in that case I do not put too many attention to Policy classes where they are unavoidable now. > Policy class is very dependent on the API classes, which depends on the > policy class. It was not a good thing. Yes, writing it happens to be a source of some unclear code. > fb_get_master_interface I solved putting it (with extern "C") in the > namespace. Multiple declarations in different namespaces, each one > returning its own IMaster. > > So like selecting the types with "using" (or explicitly), user would > select the functions too. Very good, hope removing added today macro DECLARE_GET_MASTER will also be not a problem. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
