On 3/1/2016 11:29 AM, Dimitry Sibiryakov wrote: > 01.03.2016 17:14, Jim Starkey wrote: >> The "error prone" argument gets tossed around a lot, but I generally >> don't buy it. Language features are not a substitute for testing. Sure, >> "override" will get a compiler error if you blow an overriding method >> prototype, but so will cursory testing. The argument makes more sense >> in a rapid agile development environment, but much less so in a 30 year >> old database system. > Imagine situation that you added a new member to a class. Now, with VS > 2010 you have to > visit every constructor of this class and add initialization of this member. > Doable? Sure. > Can you miss one constructor of half of dozen? Possible. Probability that > this subtle bug > will be noticed by tests? Very low. > Another example right from our codebase: dumb pointers were replaced by > smart pointers > which implements auto cast to a dump pointer for backward compatibility. > Fine, but now > some statements like "if (ptr)" act as "if (true)", because now they test not > pointer but > the envelope itself. And compiler is silent about this. > Copy constructors that aren't explicitly deleted also can make you busy. > In my life I wasted enough time debugging to strongly believe that simple > code is the best. >
First, if you have so many constructors that you can't keep track of them, you're creating class spaghetti, and making this easier to do isn't doing you a service. Second, have you ever considered breaking out common initialization code into a separate init function? I agree that being able to call one constructor from another a la Java is a plus, but is it worth writing off platforms without compilers that don't support that feature? What I would like is for the memory allocator to initialize everything to zero/null/false like Java and my original memory pools. Why waste the code to manually initialize everything with the risk of missing something when it could easily be centralized. But C++ semantics what they are, it would make classes ultra-non-portable. I've used smart pointers a number of times and have a pair of smart point templates in my set of base classes, but I've found them to next to useless. Functions don't need them and a conditional call to release in a destructor is no big deal. The one case where they might be useful -- releasing resources on block exit -- is almost always better handled by a local instance with a destructor for cleanup. Unless sparingly used, smart pointers bloat up and slow down the code with unnecessary addRef and releases, but if sparingly used, you run the risk of running into the problem they are intended to solve. Copy constructors are mostly useful for wrappers around other things. I think the only two I have in Amorphous are the String class (wrapper around a managed character string) and a BigInt wrapper around an MPIR number. Well worth the effort to debug. The point is, way to often people go looking for excuses to try out new features and end up with worse code for it. The cardinal sin in C++ is over generalization -- trying to make the ultimate XYZ class that lays track, gathers eggs, and consoles old people. A more effective approach is to build the minimal class that addresses the problem at hand, extending it when necessary, but not before. Oh, and const correctness, the most anti-OO false religion in computingdom. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
