Tyler Littlefield wrote: > I'm not quite sure where you made your "application layer," and "library > layer," up at, but beyond that point. Giving everyone a huge "library layer," > where you've wrapped libraries that use guess what, a pointer, in something > else might introduce stability over time, but it also introduces yet another > medium through which execution has to pass, and yet another fun bit of time > debugging.
I don't see this as a problem. And, if written correctly, debugging the library layer is rare. (And, if you must know, Safe C++ Design Principles is where I described the concept of segmenting applications into _three_ VERY SPECIFIC layers...not ten. I don't trust third-party code to have been written correctly, which is the ONLY reason there are three layers instead of two.) > So, assuming all students decide to use this "application/library layer of > yours," they get hidden from pointers until when? The fact that c++ has > classes and templates doesn't mean you don't need pointers. The trick is > knowing when to use which, and when not to. Ideally, if programming has to be taught in college (IMO, it should really be taught in elementary school), then the second, possibly third year of programming is where pointers should be taught. > Your trying to convert c++ to some higher-level language and hide the > big-bad-pointers from everyone for what reason? The fact that there are > memory leaks won't go away with your application/library layer, it'll just > mean more or that they'll stick around longer, because you didn't bother to > teach the people pointers. If the Application layer relies on a well-debugged Library layer (that has important things like a good automated test suite built-in), there is no problem with leaks. At all. I'm more after application _stability_ and _security_ than conversion. However, in the process, the applications I write do start looking rather high-level. Which is a good thing. I don't want to spend hours doing something that should only take a few seconds. If I have to wait two minutes for the compiler to build a powerful application that took me mere minutes to create from scratch, then so be it. > In short, hiding things on a "library layer," won't do us much good. Not true. One final note: This is my way of doing software development and you can complain about it all you want. However, it WORKS VERY WELL FOR *ME*. I haven't had a crash bug in an Application layer in several years and it has been over two years since my last crash bug in my Library layer. And I can't even remember when the last memory leak was. Granted, this method of development is still pretty new me (3-4 years vs. my 20+ years of programming expertise) but, before this method, my C and C++ applications were incredibly buggy. The only issues left for me to debug these days are logic bugs. At the Application layer. Those are a lot nicer to deal with. So, as I said, this approach works VERY WELL for ME for creating stable software. And, I recommend the approach for general use to anyone starting out in ANY programming language. I even use this approach in PHP and it works very well there too. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/ ------------------------------------ To unsubscribe, send a blank message to <mailto:[email protected]>.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/c-prog/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/c-prog/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
