> It depends, we are certainly thinking of a nice solution to support > SQL dialects, especially w.r.t. different types. > Do you have other uses in mind ?
Just as usually, was writing my question under time pressure... I am afraid you misunderstood my question.. What I mean one should define some keys/paths in the configuration file, where to store uniformly DBO backend specific settings... :), I try to finish my myqsl driver, but there are tons of settings that need to be configured depending on the deployment context. I think would be clever to define some policies, otherwise one day our components would not love each other :) >> and a little observation.. >> 1. SqlStatement::getResult family... passing output values as pointers >> are not really C++ (rather C style), or? (reference would be mabye >> preffered) > Perhaps that would have been better. But no point in changing it now, I think > ? > They are really different syntax for the same thing. same syntax indeed, but for me it became so natural. I never use pointer, when I am sure that the object exist. And in case of a return parameter the object behind the pointer should be present... But the argument list is long, long.. >> 2. Doing DB operations on constructors (SqlStatement, SqlConnection) >> is maybe not the best idea, as it makes exception handling, >> deallocation etc. generally difficult. What happens if a driver throws >> an exception on these constructors? > > I believe throwing exceptions from a constructor is perfectly fine ? > (http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2) yes... but what you quoted tries to say the same... better to avoud... but read here.. (pasted at the end of the email) my arguments are the same as here: (I had most of them before google came into being :) ) http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Doing_Work_in_Constructors > I have not checked the actual implementations of > SqlStatement/SqlConnection, but they could certainly be written so > that they do not leak memory when an exception occurs... Well... actually my problem is about knowing that after constructor it is usable. But this could be marked with some extra state "unusable". The constructor, or any other operation could set the connection and statement to an "unusable state" (I am reffering to the existing states defined in the sqlstatement) > Regards, > koen > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com from google c++ best practices... Doing Work in Constructors ▽ In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method. link Definition: It is possible to perform initialization in the body of the constructor. Pros: Convenience in typing. No need to worry about whether the class has been initialized or not. Cons: The problems with doing work in constructors are: There is no easy way for constructors to signal errors, short of using exceptions (which are forbidden). If the work fails, we now have an object whose initialization code failed, so it may be an indeterminate state. If the work calls virtual functions, these calls will not get dispatched to the subclass implementations. Future modification to your class can quietly introduce this problem even if your class is not currently subclassed, causing much confusion. If someone creates a global variable of this type (which is against the rules, but still), the constructor code will be called before main(), possibly breaking some implicit assumptions in the constructor code. For instance, gflags will not yet have been initialized. Decision: If your object requires non-trivial initialization, consider having an explicit Init() method. In particular, constructors should not call virtual functions, attempt to raise errors, access potentially uninitialized global variables, etc. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
