On 18/11/2014 08:54, Alex Peshkoff wrote: > On 11/18/14 03:50, Adriano dos Santos Fernandes wrote: >> Hi! >> >> Currently the API is problematic in any non usage scenario different >> than one used internally in FB code. >> >> We have the "I" classes witch are typedefs for a "default" policy, a >> policy that is just not suitable for C++, as it ignore exceptions and >> avoids every piece of the policy idea. >> >> Even if the code is improved to support exceptions, it will be our own >> exception class, not something C++ people is going to use. >> >> We have the "I" classes used in places they should not, like structs, >> typedefs, prototypes, meaning these items are bound to an unique policy. > Adriano, probably I did not understand you correctly. Please provide one > or two samples.
When you have an IAttachment in DtcStart, or IStatus in any other (UDR) class, you're doing it wrong. IAttachment is bound to a policy. >> That's not what the cloop utility has designed for. >> >> We should have everything (structs - exception GDS_QUAD and legacy >> things), C++ concrete classes (the message code), etc inside the API class. >> >> But then, every use of the classes need a "prefix::". Generally, the >> user is going to do this: >> >> #include "firebird/Api.h" >> >> typedef ::Firebird::Api<SomePolicy> fb; >> >> fb::Attachment* attachment = ... >> >> This is one common way to use C++, many people does not "include" >> namespaces, but alias then to something more easy to type, when it's >> not. Most of time, this is really with namespaces, but in our case it >> will be a class. > Do you suggest it for external usage or internally? External. Internally, you can use the existing hacks, but I see no point in doing that. >> As a class, one cannot use (using keyword) they items. Also, as there >> are templates, the C++ version we use does not allow to typedef the >> items to extract them from the prefix class. >> >> If you do not want this, there is still alternative, but it's crap IMO. >> It consists of allowing a header to be included multiple times, and >> expect the user to write a piece of code (the policy in a namespace) and >> include that header in the middle of they code. > Adriano, looks like I can't understand you. Can you explain in few words > - what problem are you solving now? How to provide people a comfortable > way of writing a policy? > > The cloop example implements it right. You can use many polices even in the same cpp file, if you like. There is no difficulty to implement a policy. 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 ------------------------------------------------------------------------------ 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=157005751&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
